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

Michael Hrivnak mhrivnak at redhat.com
Mon Oct 23 19:20:54 UTC 2017


On Mon, Oct 23, 2017 at 12:30 PM, Dennis Kliban <dkliban at redhat.com> wrote:

> 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.
>

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.

-- 

Michael Hrivnak

Principal Software Engineer, RHCE

Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20171023/7dfac3be/attachment.htm>


More information about the Pulp-dev mailing list