<div dir="ltr"><div>Agreed on publications not having 'natural key's for the same reasons you outline.<br><br>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.</div><div><br></div><div>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</div><div><br></div><div>1. POST to <a href="http://localhost:8000/api/v3/r">http://localhost:8000/api/v3/r</a><wbr>epositories/foo/publishers/exa<wbr>mple/bar/publications/ with {'publisher': '<a href="http://path/to/my/publisher">http://path/to/my/publisher</a>'}</div><div>2. The user receives a 201 with Publication.task containing the url to monitor by.</div><div>3. The user monitors the publication via the URL.<br></div><div><br></div><div>We mostly avoid this problem with sync because the updates aren't about objects created it's more about "what is going on" reporting.</div><div><br></div><div>-Brian</div><div><br></div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 23, 2017 at 2:45 PM, Michael Hrivnak <span dir="ltr"><<a href="mailto:mhrivnak@redhat.com" target="_blank">mhrivnak@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="gmail-h5">On Mon, Oct 23, 2017 at 11:06 AM, Jeff Ortel <span dir="ltr"><<a href="mailto:jortel@redhat.com" target="_blank">jortel@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_-1646359657004866590gmail-"><br>
On 10/23/2017 09:55 AM, Michael Hrivnak wrote:<br>
><br>
> A task status should not include an exhaustive list of every resource created. For example, a publish task<br>
> should not include a reference to every metadata artifact it made. It would be sufficient to include a<br>
> reference to the publication, the task's primary output, which then can be used to reference subordinate<br>
> resources.<br>
><br>
> On a task status representation, this could be included in a field called "created_resources", "output",<br>
> "return_value", or similar.<br>
<br>
</span>Tasks (status) are a transient mechanism used to accomplish work and should not be used to track resources<br>
created.  Once the task has completed, the user should be free to forget the task ID and be able to use<br>
natural keys to find and inspect resources that got created/updated.<br></blockquote><div><br></div></div></div><div>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? <br></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>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.</div></div><span class="gmail-"><div><br></div>-- <br><div class="gmail-m_-1646359657004866590gmail_signature"><div dir="ltr"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px;padding:0px"><span style="margin:0px;padding:0px">Michael</span> <span style="margin:0px;padding:0px">Hrivnak</span></p><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px;padding:0px"></p><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px;padding:0px"><span style="margin:0px;padding:0px">Principal Software Engineer</span><span style="margin:0px;padding:0px">, <span style="margin:0px;padding:0px">RHCE</span></span> </span><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px"></span><br style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px;padding:0px"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px;padding:0px">Red Hat</p></div></div>
</span></div></div>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div></div></div>