On Mon, Oct 23, 2017 at 11:06 AM, Jeff Ortel <jor...@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 were monitoring? 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. -- Michael Hrivnak Principal Software Engineer, RHCE Red Hat
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
