[Pulp-dev] [pulp 3] proposed change to publishing REST api
mhrivnak at redhat.com
Mon Oct 23 18:45:21 UTC 2017
On Mon, Oct 23, 2017 at 11:06 AM, Jeff Ortel <jortel at redhat.com> wrote:
> On 10/23/2017 09:55 AM, Michael Hrivnak wrote:
> > A task status should not include an exhaustive list of every resource
> created. For example, a publish task
> > should not include a reference to every metadata artifact it made. It
> would be sufficient to include a
> > reference to the publication, the task's primary output, which then can
> be used to reference subordinate
> > resources.
> > On a task status representation, this could be included in a field
> called "created_resources", "output",
> > "return_value", or similar.
> Tasks (status) are a transient mechanism used to accomplish work and
> should not be used to track resources
> created. Once the task has completed, the user should be free to forget
> the task ID and be able to use
> natural keys to find and inspect resources that got created/updated.
I'm also not sure what natural key a publication will be able to reliably
have. If I publish the same repo three times, how do I know which
publication resulted from each task? Or when a repo version is created by a
sync, how would an end user know which version was created by the task they
Just as a 201 response should include a link to the resource that was
created, a 202 should include a link to a resource that can monitor the
status of the request to create something. Why would that status monitor
not upon completion include a link to the resource that got created? It's
fulfilling the same end goal that could otherwise be achieved from a 201
response, but with an asynchronous part of the workflow.
Principal Software Engineer, RHCE
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev