On Mon, Oct 23, 2017 at 3:20 PM, Michael Hrivnak <mhriv...@redhat.com> wrote:
> > > On Mon, Oct 23, 2017 at 12:30 PM, Dennis Kliban <dkli...@redhat.com> > wrote: > >> On Mon, Oct 23, 2017 at 10:56 AM, Jeff Ortel <jor...@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. >> > > For me, your wording illustrates the problem well. Why should a user have > to delete a resource that was never created? > > This sounds like we'd be introducing a partially-created state for > publications. There would be some kind of placeholder representation that > could be referenced as a location where a real publication *might or might > not* eventually appear. And this representation would live side-by-side in > a "publications/" endpoint with representations of actual publications? How > would a user know which are which? It seems like this just shifts the async > problem onto the publication model. > > I go back to this: When creation of a resource is requested, the response > should either be 201 if the resource was created, or 202 if creation is > deferred. We should not attempt partial creation. > > It's easy to lose sight of this, so maybe it's worth also observing that a > resource is not just a DB record or some JSON. The existence of a resource > representation requires that the resource itself exists in every way that > is necessary for it to make sense. We should be careful not to misrepresent > the existence of a publication. > The description of issue 3033[0] does not clearly establish what a serialized version of a Publication looks like. In our current design, I imagine that it will contain three fields: _href, created, and publisher. @jortel, do you have the same vision? If we start associating tasks with Publications, then the serialized publication would have 4 fields: _href, created, publisher, task. The API would then allow filtering based on the status of the associated task. e.g. publications/?task__status=successful to retrieve all publications that are successfully created. We could also add validation on the Distribution that will check whether the publication being associated with the Distribution has a task associated with it, and if so that it successfully completed. A POST to /publications/ could return a 202 and a serialized version of the publication. This lets the user know that the task of creating a publication was accepted. Any GET requests to /publications/<publication_id> would return 202 until the publication task has completed. Once the publication task is complete a GET request to /publications/<publication_id> would return 200 if the task finished successfully or 410 (gone) if it did not complete successfully. [0] https://pulp.plan.io/issues/3033 > > -- > > Michael Hrivnak > > Principal Software Engineer, RHCE > > Red Hat >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
