<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 23, 2017 at 3:20 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"><span>On Mon, Oct 23, 2017 at 12:30 PM, Dennis Kliban <span dir="ltr"><<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@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"><div class="gmail_extra"><div class="gmail_quote"><span>On Mon, Oct 23, 2017 at 10:56 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">This is interesting.<br>
<br>
Some thoughts:<br>
<br>
If adopted, I propose the publication task create the publication and pass to the publisher which would<br>
require a change in the plugin API - Publisher.publish(publication)<wbr>.  If the publisher fails, I think the<br>
publication should be deleted.<br></blockquote><div><br></div></span><div>The ViewSet would create the publication, dispatch a publish task with the publication id as an argument, update the publication with the task id, return a serialized Publication to the API user. The user is responsible for deleting any publication that is not created successfully. <br></div></div></div></div></blockquote><div><br></div></span><div>For me, your wording illustrates the problem well. Why should a user have to delete a resource that was never created?</div><div><br></div><div>This sounds like we'd be introducing a partially-created state for publications. There would be some kind of placeholder representation that could be referenced as a location where a real publication *might or might not* eventually appear. And this representation would live side-by-side in a "publications/" endpoint with representations of actual publications? How would a user know which are which? It seems like this just shifts the async problem onto the publication model.</div><div><br></div><div>I go back to this: When creation of a resource is requested, the response should either be 201 if the resource was created, or 202 if creation is deferred. We should not attempt partial creation.</div></div></div></div></blockquote><div> </div><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></div><div>It's easy to lose sight of this, so maybe it's worth also observing that a resource is not just a DB record or some JSON. The existence of a resource representation requires that the resource itself exists in every way that is necessary for it to make sense. We should be careful not to misrepresent the existence of a publication. <br></div></div></div></div></blockquote><div> </div><div></div>The description of issue 3033[0] does not clearly establish what a serialized version of a Publication looks like. In our current design, I imagine that it will contain three fields: _href, created, and publisher. @jortel, do you have the same vision?<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">If we start associating tasks with Publications, then the serialized publication would have 4 fields: _href, created, publisher, task. The API would then allow filtering based on the status of the associated task. e.g. publications/?task__status=suc<wbr>cessful to retrieve all publications that are successfully created. <br></div><div class="gmail_quote"><div><br></div><div>We could also add validation on the Distribution that will check whether the publication being associated with the Distribution has a task associated with it, and if so that it successfully completed. <br></div><div><br></div><div>A POST to /publications/ could return a 202 and a serialized version of
 the 
publication. This lets the user know that the task of creating a 
publication was accepted. Any GET requests to 
/publications/<publication_id> would return 202 until the 
publication task has completed. Once the publication task is complete a 
GET request to /publications/<publication_id> would return 200 if 
the task finished successfully or 410 (gone) if it did not complete 
successfully.  </div><div><br></div><div><br></div><div>[0] <a href="https://pulp.plan.io/issues/3033" target="_blank">https://pulp.plan.io/issues/30<wbr>33</a><br></div><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> </div></div><span>-- <br><div class="m_-2755321066944191611gmail-m_6967813158501141951gmail-m_-1073741787288496293m_-4336724559318255394m_5999865348674558350gmail_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>
</blockquote></div><br></div></div>