<div dir="ltr"><div><div><div><div>Thanks everyone for all the discussion! I'll try to recap the problem and some of the solutions I've heard. I'll also share some of my perspective on them too.<br><br></div>What problem are we solving?<br></div>When a user calls "publish" (the action API endpoint) they get a 202 w/ a link to the task. That task will produce a publication. How can the user find the publication that was produced by the task? How can the user be sure the publication is fully complete?<br></div><div><br></div><div><br></div>What are our options?</div><div>1) Start linking to created objects from task status. I believe its been clearly stated about why we can't do this. If it's not clear, or if there are other things we should consider, let's talk about it. Acknowledging or establishing agreement on this is crucial because a change like this would bring back a lot of the user pain from pulp2. I believe the HAL suggestion falls into this area.<br></div><div><br></div><div>2) Have the user find the publication via query that sorts on time and filters only for a specific publisher. This could be fragile because with a multi-user system and no hard references between publications and tasks, answering the question "which is the publication for me" is hard because another user could have submitted a publish too. While not totally perfect, this could work.<br></div><div><br></div><div>3) Have the user create a publication directly like any other REST resource, and help the user understand the state of that resource over time. I believe the proposal at the start of this thread is recommending this solution. I'm also +1 on this solution.</div><div><br></div><div><br></div><div>As an aside, I don't think considering versioned repos as a possible solution is helping us with this problem. The scope of the current problem is relatively small and the scope of planning for versioned repos is large.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 24, 2017 at 9:43 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br> <br> On 10/23/2017 06:14 PM, Dennis Kliban wrote:<br> > On Mon, Oct 23, 2017 at 3:20 PM, Michael Hrivnak <<a href="mailto:mhrivnak@redhat.com" target="_blank">mhrivnak@redhat.com</a> <mailto:<a href="mailto:mhrivnak@redhat.com" target="_blank">mhrivnak@redhat.com</a>>> wrote:<br> ><br> ><br> ><br> > On Mon, Oct 23, 2017 at 12:30 PM, Dennis Kliban <<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a> <mailto:<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a>>> wrote:<br> <div><div class="m_-9096267518737684516m_-4646860011694349480h5">><br> > On Mon, Oct 23, 2017 at 10:56 AM, Jeff Ortel <<a href="mailto:jortel@redhat.com" target="_blank">jortel@redhat.com</a> <mailto:<a href="mailto:jortel@redhat.com" target="_blank">jortel@redhat.com</a>>> wrote:<br> ><br> > 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<br> > would<br> > require a change in the plugin API - Publisher.publish(publication)<wbr>. If the publisher fails, I<br> > think the<br> > publication should be deleted.<br> ><br> ><br> > The ViewSet would create the publication, dispatch a publish task with the publication id as an<br> > argument, update the publication with the task id, return a serialized Publication to the API user.<br> > The user is responsible for deleting any publication that is not created successfully.<br> ><br> ><br> > For me, your wording illustrates the problem well. Why should a user have to delete a resource that was<br> > never created?<br> ><br> > This sounds like we'd be introducing a partially-created state for publications. There would be some kind<br> > of placeholder representation that could be referenced as a location where a real publication *might or<br> > might not* eventually appear. And this representation would live side-by-side in a "publications/"<br> > endpoint with representations of actual publications? How would a user know which are which? It seems like<br> > this just shifts the async problem onto the publication model.<br> ><br> > I go back to this: When creation of a resource is requested, the response should either be 201 if the<br> > resource was created, or 202 if creation is deferred. We should not attempt partial creation.<br> ><br> ><br> ><br> > It's easy to lose sight of this, so maybe it's worth also observing that a resource is not just a DB<br> > record or some JSON. The existence of a resource representation requires that the resource itself exists<br> > in every way that is necessary for it to make sense. We should be careful not to misrepresent the<br> > existence of a publication.<br> ><br> ><br> > The description of issue 3033[0] does not clearly establish what a serialized version of a Publication looks<br> > like. In our current design, I imagine that it will contain three fields: _href, created, and publisher.<br> > @jortel, do you have the same vision?<br> <br> </div></div>Yes.<br> <span><br> ><br> > If we start associating tasks with Publications, then the serialized publication would have 4 fields: _href,<br> > created, publisher, task. The API would then allow filtering based on the status of the associated task. e.g.<br> > publications/?task__status=suc<wbr>cessful to retrieve all publications that are successfully created.<br> ><br> > We could also add validation on the Distribution that will check whether the publication being associated with<br> > the Distribution has a task associated with it, and if so that it successfully completed.<br> <br> </span>I don't think we should store broken publications in the DB.<br> <span><br> ><br> > A POST to /publications/ could return a 202 and a serialized version of the publication. This lets the user<br> > know that the task of creating a publication was accepted. Any GET requests to /publications/<publication_id><br> > would return 202 until the publication task has completed. Once the publication task is complete a GET request<br> > to /publications/<publication_id> would return 200 if the task finished successfully or 410 (gone) if it did<br> > not complete successfully.<br> <br> </span>My main objection to storing the task_id on the publication is that task_id is only meaningful to the user for<br> a very short period. Just long enough to make subsequent API calls but nothing further unless the user writes<br> it down with a note giving it meaning. But imagine a user listing publications later, trying to select one to<br> associate with a distribution. Or to be delted. The task ID would be meaningless. The natural key<br> Publication.name was an attempt to give the user something meaningful for all use cases. After further<br> consideration, I'm not convinced that adding "name" is the best solution either.<br> <br> I wonder if versioned repositories isn't the real answer. If the repository was versioned then publications<br> would be naturally versioned as well. The serialized publication could include the repository "version"<br> number. This would be meaningful to the user for all use cases.<br> <br> ><br> ><br> > [0] <a href="https://pulp.plan.io/issues/3033" rel="noreferrer" target="_blank">https://pulp.plan.io/issues/30<wbr>33</a> <<a href="https://pulp.plan.io/issues/3033" rel="noreferrer" target="_blank">https://pulp.plan.io/issues/3<wbr>033</a>><br> <div class="m_-9096267518737684516m_-4646860011694349480HOEnZb"><div class="m_-9096267518737684516m_-4646860011694349480h5">><br> ><br> > --<br> ><br> > Michael Hrivnak<br> ><br> > Principal Software Engineer, RHCE<br> ><br> > Red Hat<br> ><br> ><br> <br> </div></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></div></div>