[Pulp-dev] [pulp 3] proposed change to publishing REST api

Dennis Kliban dkliban at redhat.com
Mon Oct 23 16:30:01 UTC 2017

On Mon, Oct 23, 2017 at 10:56 AM, Jeff Ortel <jortel at redhat.com> wrote:

> This is interesting.
> Some thoughts:
> If adopted, I propose the publication task create the publication and pass
> to the publisher which would
> require a change in the plugin API - Publisher.publish(publication).  If
> the publisher fails, I think the
> publication should be deleted.

The ViewSet would create the publication, dispatch a publish task with the
publication id as an argument, update the publication with the task id,
return a serialized Publication to the API user. The user is responsible
for deleting any publication that is not created successfully.

> On 10/19/2017 02:27 PM, Dennis Kliban wrote:
> > @jortel and I have been discussing[0] how a user should find out what
> publication was created after a request
> > is made to http://localhost:8000/api/v3/repositories/foo/publishers/exa
> mple/bar/publish/
> >
> > I propose that we get rid of the above URL from our REST API and add
> ability to POST to
> > http://localhost:8000/api/v3/repositories/foo/publishers/exa
> mple/bar/publications/ instead. The response would
> > be a 201. Each publication would have a task associated with it.
> Associated how?  I hope you are not suggesting adding Publication.task_id
> (FK).  I don't think that would be a
> good idea.

That is exactly what I had in mind. Though the field can be NULL if the
task has been removed from the database already. This way a serialized
version of a Publication would provide a reference to a task that can be
tracked to see if the publication was successfully created. If a failure
occurs, the user can choose to delete the publication. Why do you think
it's not a good idea to add this association?

> I still like the idea of adding Publication.name as a natural key that can
> be specified by the user.  It can
> default to the task ID when not specified.  This gives users something
> meaningful to use when selecting a
> publication for association to a Distribution or when deleting.

I also think it's valuable to let users name their publications. However,
we should avoid forcing users to form URLs to resources on their own.
Jeremy put it well in his response.

> >
> > This work would probably be done by whoever picks up issue 3033[1].

Since 3033 is well under way, this work would be done as issue 3035.

> >
> > [0] https://pulp.plan.io/issues/3035
> > [1] https://pulp.plan.io/issues/3033
> >
> >
> > _______________________________________________
> > Pulp-dev mailing list
> > Pulp-dev at redhat.com
> > https://www.redhat.com/mailman/listinfo/pulp-dev
> >
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20171023/c979bd7c/attachment.htm>

More information about the Pulp-dev mailing list