<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 23, 2017 at 10:55 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Unless the publication can be created before the response is returned, the response code will need to still be 202.<div><br></div><div>As for the path, either way seems workable, although I have two hesitations about POSTing to publications/.</div><div><br></div><div>1) Normally in REST when a user creates a resource via POST to a collection endpoint, they are expected to provide a representation of the new resource, even if it is only partial. In the case of initiating a publish task, we do not want the user to provide any part of the new publication's state. We only want the user to optionally provide a bit of information about *how* to create a new publication. Should the publication be incremental or not? Which repo version should be published? etc. The difference may seem subtle, but I think it's important.</div><div><br></div><div>2) The act of creating a publication may also change state of other resources, and not only subordinate resources such as a publication artifact. For example, if there is a Distribution with auto_update set to True, its state will be changed by a publish task. That could be seen as an unexpected side effect when merely POSTing to a publications/ endpoint. When an operation affects state across multiple resources and resource types, that's usually a good time to use a "controller" type endpoint that is specific to the operation.<br></div></div></blockquote><div><br></div><div>We should probably reevaluate the value of 'auto_update' on a Distribution. Information about distributions that need to be updated can be passed in the body of the POST to publications/. This way the user explicitly instructs Pulp to perform the update.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><br></div><div>Our asynchronous tasks will often need to create one or more resources. A publish task creates a publication. An upload-related task may create one or more content units. A sync/associate/unassociate task will create a new repository version. New resources are the output of those tasks. However each of those tasks will sometimes not create any resources, such as when an equivalent resource already exists. Creating resources is a common characteristic of tasks, so it would make sense to report that in a standard part of the task status.</div></div></div></blockquote><div><br></div><div>A repository version would probably be it's own REST resource. So you would perform a POST to repositories/foo/versions/ with information about what should be done to create a new version: sync with a particular importer or associate/unassosiate content. <br></div><div> </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div></div><div>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.</div><div><br></div><div>On a task status representation, this could be included in a field called "created_resources", "output", "return_value", or similar.</div><div><br></div><div>Thoughts on that idea?</div></div></div><div class="gmail_extra"><div><div class="m_-833612552393733417m_-199429148651140421m_2869785077699492166h5"><br><div class="gmail_quote">On Fri, Oct 20, 2017 at 11:27 AM, Mihai Ibanescu <span dir="ltr"><<a href="mailto:mihai.ibanescu@gmail.com" target="_blank">mihai.ibanescu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">That seems sensible, and in line with REST's mantra of "nouns in resource URLs, not verbs".</div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_-833612552393733417m_-199429148651140421m_2869785077699492166m_-2793330206287526934h5">On Thu, Oct 19, 2017 at 3:27 PM, Dennis Kliban <span dir="ltr"><<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_-833612552393733417m_-199429148651140421m_2869785077699492166m_-2793330206287526934h5"><div dir="ltr"><div><div>@jortel and I have been discussing[0] how a user should find out what publication was created after a request is made to <a href="http://localhost:8000/api/v3/repositories/foo/publishers/example/bar/publish/" target="_blank">http://localhost:8000/api/v3/r<wbr>epositories/foo/publishers/exa<wbr>mple/bar/publish/</a><br><br></div>I propose that we get rid of the above URL from our REST API and add ability to POST to <a href="http://localhost:8000/api/v3/repositories/foo/publishers/example/bar/publications/" target="_blank">http://localhost:8000/api/v3/r<wbr>epositories/foo/publishers/exa<wbr>mple/bar/publications/</a> instead. The response would be a 201. Each publication would have a task associated with it. <br><br></div>This work would probably be done by whoever picks up issue 3033[1].<br><div><div><br>[0] <a href="https://pulp.plan.io/issues/3035" target="_blank">https://pulp.plan.io/issues/30<wbr>35</a><br></div><div>[1] <a href="https://pulp.plan.io/issues/3033" target="_blank">https://pulp.plan.io/issues/30<wbr>33</a><br></div></div></div>
<br></div></div>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="m_-833612552393733417m_-199429148651140421m_2869785077699492166HOEnZb"><font color="#888888">-- <br><div class="m_-833612552393733417m_-199429148651140421m_2869785077699492166m_-2793330206287526934gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><span style="margin:0px!important;padding:0px!important">Michael</span> <span style="margin:0px!important;padding:0px!important">Hrivnak</span></p><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"></p><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><span style="margin:0px!important;padding:0px!important">Principal Software Engineer</span><span style="margin:0px!important;padding:0px!important">, <span style="margin:0px!important;padding:0px!important">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!important;padding:0px!important"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important">Red Hat</p></div></div>
</font></span></div>
</blockquote></div><br></div></div>