<div dir="ltr">Personally I am not opposed to the url endpoint you suggest. <div><br></div><div>It also seems like there is some consensus around adding a ‘created resources’ relationship to Task or at least prototyping that out to see what it would look like. </div><div><br></div><div>If no one disagrees, should I update issue #3033 with those two items?</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>David<br></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Oct 25, 2017 at 1:23 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Wed, Oct 25, 2017 at 11:24 AM, David Davis <span dir="ltr"><<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a>></span> wrote:<br></span><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I don’t know that the ambiguity around whether a task has a publication or not is a big deal. If I call the publication endpoint, I’d expect a publication task which either has 1 publication or 0 (if the publication failed) attached to it.<div><br></div><div>In terms of ambiguity, I see a worse problem around adding a task_id field to publications. As a user, I don’t know if a publication failed or not when I get back a publication object. Instead, I have to look up the task to see if it is a real (or successful) publication. Moreover, since we allow users to remove/clean up tasks, that task may not even exist anymore.</div><div class="gmail_extra"><span class="m_2936729538491654488m_-853916050448828890HOEnZb"><font color="#888888"><br clear="all"></font></span></div></div></blockquote><div><br></div></span><div>I agree that the ephemeral nature of tasks makes the originally proposed solution non-deterministic. I am open to associating 'resources created' with a task instead. <br></div><div><br></div><div>However, I still think there is value in changing the rest API endpoint for starting a publish task to POST /api/v3/repositories/<repo-id><wbr>/publishers/<type>/<name>/<wbr>publications/. However, I will start a separate thread for that discussion.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div> - Dennis<br></div></font></span><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class="m_2936729538491654488m_-853916050448828890HOEnZb"><font color="#888888"><div><div class="m_2936729538491654488m_-853916050448828890m_-316607522055615108m_-6808906535450087787gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>David<br></div></div></div></div></div></div></div></div>
<br></font></span><div class="gmail_quote"><div><div class="m_2936729538491654488m_-853916050448828890h5">On Wed, Oct 25, 2017 at 11:03 AM, Brian Bouterse <span dir="ltr"><<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@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_2936729538491654488m_-853916050448828890h5"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Tue, Oct 24, 2017 at 10:00 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 class="m_2936729538491654488m_-853916050448828890m_-316607522055615108m_-6808906535450087787m_6632627535531766682gmail-">On Tue, Oct 24, 2017 at 2:11 PM, Brian Bouterse <span dir="ltr"><<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>></span> wrote:<br></span><span class="m_2936729538491654488m_-853916050448828890m_-316607522055615108m_-6808906535450087787m_6632627535531766682gmail-"><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><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></blockquote><div><br></div></span><div>I may have missed something, but I do not think this is clear. I know that Pulp 2's API included a lot of unstructured data, but that is not at all what I'm suggesting here.</div><div><br></div><div>It is standard and recommended practice for REST API responses to include links to resources along with information about what type of resource each link references. We could include a reference to the created resource and an identifier for what type of resource it is, and that would be well within the bounds of good REST API design. HAL is just one of several ways to accomplish that, and I'm not pitching any particular solution there. In any case, I'm not sure what the problem would be with this approach.</div></div></div></div></blockquote><div> </div></span><div>I agree it is a standard practice for a resource to include links to other resources, but the proposal is to include "generic" links is different and creates a different user experience. I believe referencing the task from the publication will be easier for users and clients. When a user looks up a publication, they will always know they'll get between 0 and 1 links to a task. You can use that to check the state of the publication. If we link to "generic" resources (like a publication) from a task, then if I ask a user "do you expect task ede3af3e-d5cf-4e18-8c57-69ac4d<wbr>4e4de6 to contain a link to a publication or not?" you can't know until you query it. I think that ambiguity was a pain point in Pulp2. I don't totally reject this solution, but this is an undesirable property (I think).<br></div><span><div> <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"><span class="m_2936729538491654488m_-853916050448828890m_-316607522055615108m_-6808906535450087787m_6632627535531766682gmail-"><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></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></blockquote><div><br></div></span><div>In theory if a user queried for a publication from a specific publisher that was created between the start and end times of the task, that should unambiguously identify the correct publication. But depending on timestamps is not a particularly robust nor confidence-inspiring way to reference a resource.</div></div></div></div></blockquote></span><div>Agreed and Agreed</div><span><div> <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"><span class="m_2936729538491654488m_-853916050448828890m_-316607522055615108m_-6808906535450087787m_6632627535531766682gmail-"><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></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></blockquote><div><br></div></span><div>I think the problem with this is that a user cannot create a publication. A user can only ask a plugin to create a publication. Until the plugin creates the publication, there is no publication.</div></div></div></div></blockquote><div><br></div></span><div>Note a publication is an object, but really we mean a publication and it's related PublishedArtifact, PublishedMetadat, etc objects. It would be straightforward for a user to create a publication using the viewset and have the task associated with it call the publisher to build out the associated PublishedArtifact, PublishedContent, PublishedMetadata, etc. We should explore if this is good or not, but it is possible.<br></div><div><br></div><div>As an aside, this is related to a problem everyone should be aware of: the existence of a publication does not guarantee that publication is finished publishing. Even with option 1, where the task creates the publisher and links to it in the task status, while the publisher is running it must save the Publication so that the PublishedArtifact, etc can link to it. So for any given publication, in order to know if it's "fully finished and consistent" you must be able to check the status of the associated task that produced it.<br></div><span><div> <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"><span class="m_2936729538491654488m_-853916050448828890m_-316607522055615108m_-6808906535450087787m_6632627535531766682gmail-"><div><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><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></blockquote><div><br></div></span><div>Versioned repos is a potential solution. In that scenario, a user would request publication of a specific repo version (perhaps defaulting to the latest), the publication would be linked to that version, and that is an easy mechanism for the user to find the publication they want. Ultimately the user is interested in working with a specific content set anyway. They get a repo to a state where it has the content they want, and then they publish that content set. No matter what we do with publications, users will think of them in terms of related content sets. A repo version is that immutable content set they can work with confidently.</div></div></div></div></blockquote><div><br></div></span><div>It's neat to me that that versions are snapshots of content and publications are snapshots of content. Publications already create much of the value propostion of versioned repos with publications. They allow you to work with specific content sets like you describe. Also they allow for rollback. So that is all great for our users. For this thread, I want to bring the conversation back to where it started, solving a small problem about linking two resources that already exist.<br></div><span><div> <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><br></div><div>It helps the rollback scenario a lot as well. Versioning repos allows a user to see what the differences are between two content sets, and thus two different publications, which informs them about when and how far back they should roll back a distribution. <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>- user discovers a horrible flaw in a piece of content</div><div>- user queries for which version of the repo introduced that piece of content</div><div>- user updates the distribution to serve the publication that came before the one which introduced the piece of content, optionally re-publishing that version in case its publication was deleted or had never been made in the first place.</div><span class="m_2936729538491654488m_-853916050448828890m_-316607522055615108m_-6808906535450087787m_6632627535531766682gmail-HOEnZb"><font color="#888888"><div><br></div><div>-- </div></font></span></div><span class="m_2936729538491654488m_-853916050448828890m_-316607522055615108m_-6808906535450087787m_6632627535531766682gmail-"><div class="m_2936729538491654488m_-853916050448828890m_-316607522055615108m_-6808906535450087787m_6632627535531766682gmail-m_-9033012112162740157gmail_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></span></div><br></div></div>
<br></div></div><span>______________________________<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></span></blockquote></div><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></div></div><br></div></div>
</blockquote></div><br></div>