Agreed on publications not having 'natural key's for the same reasons you outline.
The tasking system has a progress reporting feature to report progress, but it's not a place for general reporting. The reasoning is outlined in the notes from @ichimonji10 and myself earlier. >From a high level, we want a relationship between objects produced by tasks and the tasks that produce them. I think this motivates having Publication.task (FK to Task). With this design the user would 1. POST to http://localhost:8000/api/v3/repositories/foo/publishers/example/bar/publications/ with {'publisher': 'http://path/to/my/publisher'} 2. The user receives a 201 with Publication.task containing the url to monitor by. 3. The user monitors the publication via the URL. We mostly avoid this problem with sync because the updates aren't about objects created it's more about "what is going on" reporting. -Brian On Mon, Oct 23, 2017 at 2:45 PM, Michael Hrivnak <mhriv...@redhat.com> wrote: > > > 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 > >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
