<div dir="ltr"><div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial"><blockquote class="gmail_quote" style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Regarding the first bullet point, I think it’s an admirable goal but I worry that aiming for REST purity can cause us to do some funny things like defining fake resources that are really just actions on existing resources. It’s a bit like trying to be purely OO in Python and having to wrap a function in a fake class. I think this is what I found unappealing about the plugin tasks proposal. </span></blockquote><br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial">This comment makes it sound like the Tasks proposal is forcing REST on the design, but IMO our design is a great fit for REST. The fact is that Tasks are resources no matter what, nothing fake about them. Whether we treat them like all other resources is an open question. IMO we should only make the API more RESTful if that also makes the API better.<br></div><div> </div><blockquote class="gmail_quote" style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">You mention consistency of REST but I found the plugin tasks proposal to lack consistency in certain areas. For example, some deletes are handled on resources (distributions, artifacts, etc) while other deletions would live in the tasks namespace (repos, publishers, etc).</span></blockquote><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial">That is not how it is designed. All object CRUD would stay where it is. We are trying to focus on the problems and goals for now, but when the time comes, I'll be sure to highlight this part of the design.</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"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">My overall question is: are these related problems?<span> </span></span></blockquote><div><br></div><div>When our goal is consistency, problems of related endpoints become related. Jeff's earlier comment applies: <span style="font-size:12.8px">"Looks like half of the plugins will need to participate in creating repository versions (outside of sync). The API design should take a consistent approach to creating repository versions (</span><i style="font-size:12.8px">add</i><span style="font-size:12.8px"> </span><u style="font-size:12.8px">and</u><span style="font-size:12.8px"> </span><i style="font-size:12.8px">sync</i><span style="font-size:12.8px">)."</span></div><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"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Is self-consistency really a goal? I think it's a placeholder for consistency for REST since the "rest" of the API is RESTful. After reading parts of Roy Fielding's writeup of the definition of REST I believe "action endpoints are not RESTful" to be a true statement. Maybe "Action endpoints are problematic" should be replaced with "Action endpoints are not RESTful" perhaps and have the self-consistency bullet removed?</span></blockquote><div><br></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Milan's "In my mind being RESTful implies consistency" +1. I value consistency, REST is just one way to get it.</span></div><div><br></div><div>I think we are close to being able to move forward. It seems like there is broad agreement about the goals/problems, with minor semantic differences.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 10, 2018 at 6:44 PM, 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">
<div text="#000000" bgcolor="#FFFFFF"><span class="">
<br>
<br>
<div class="m_-5277914780457999070moz-cite-prefix">On 04/10/2018 04:15 PM, Dennis Kliban
wrote:<br>
</div>
</span><div><div class="h5"><blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Tue, Apr 10, 2018 at 2:04 PM,
Brian Bouterse <span dir="ltr"><<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@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>These are good problem statements. I didn't
understand all of the aspects of it, so I put some
inline questions.<br>
<br>
My overall question is: are these related problems? To
share my answer to this, I believe the first two
problems are related and the third is separate. The
classic divide and conquor approach we could use here
is to confirm that the problems are unrelated and
focus on resolving one of them first.<br>
<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I don't think all 3 are related problems. The
motivation for grouping all together is that a subset of
the action endpoints from problem 1 are used to create
repository versions and Problem 3 is a problem with the
repository version creation API. <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>
<div>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote"><span>On
Mon, Apr 9, 2018 at 3:18 PM, Austin
Macdonald <span dir="ltr"><<a href="mailto:austin@redhat.com" target="_blank">austin@redhat.com</a>></span>
wrote:<br>
</span><span>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>Folks,</div>
<div><br>
</div>
<div>Austin, Dennis, and Milan have
identified the following issues with
current Pulp3 REST API design:</div>
<div>
<ul>
<li>Action endpoints are
problematic.<br>
</li>
<ul>
<li>Example
POST@/importers/<plugin>/sync/</li>
<li>They are non-RESTful and
would make client code tightly
coupled with the server code.</li>
<li>These endpoints are
inconsistent with the other
parts of the REST API.</li>
</ul>
</ul>
</div>
</div>
</blockquote>
</span>
<div>Is self-consistency really a goal? I
think it's a placeholder for consistency
for REST since the "rest" of the API is
RESTful. After reading parts of Roy
Fielding's writeup of the definition of
REST I believe "action endpoints are not
RESTful" to be a true statement. Maybe
"Action endpoints are problematic" should
be replaced with "Action endpoints are not
RESTful" perhaps and have the
self-consistency bullet removed?<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>+1 to "Action endpoints are not RESTful"<br>
</div>
<div>+1 to removing the self-consistency language<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>
<div>
<div>
<div class="gmail_extra">
<div class="gmail_quote"><span>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<ul>
<ul>
<li>DRF is not being used as
intended for action endpoints
so we have to implement extra
code. (against the grain)</li>
</ul>
</ul>
</div>
</div>
</blockquote>
</span>
<div>I don't know much about this. Where is
the extra code?<br>
</div>
<span>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<ul>
<li>We don't have a convention for
where plug-in-specific, custom
repository version creation
endpoints.<br>
</li>
<ul>
<li>example
POST@/api/v3/<where?>/docker/a<wbr>dd/</li>
<li>needs to be discoverable
through the schema</li>
</ul>
</ul>
</div>
</div>
</blockquote>
</span>
<div>What does discoverable via the schema ^
mean? Aren't all urls listed in the
schema?<br>
<br>
</div>
<div>I think of ^ problem somewhat
differently. Yes all urls need to be
discoverable (a REST property), but isn't
it more of an issue that the urls which
produce repo versions can't be identified
distinctly from any other
plugin-contributed url? To paraphrase this
perspective: making a repo version is
strewn about throughout the API in random
places which is a bad user experience. Is
that what is motivation url discovery?<br>
</div>
<span>
<div> </div>
</span></div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Yes. I envision a CLI that can discover new plugin
repository-version-creating functionality without having
to install new client packages. Allowing plugin writers to
add endpoints in arbitrary places for creating repository
versions will make it impossible for the client to know
what all the possible ways of creating a repository
version are. <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>
<div>
<div>
<div class="gmail_extra">
<div class="gmail_quote"><span>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<ul>
<li>For direct repository version
creation, plugins are not
involved.<br>
</li>
<ul>
<li>validation correctness
problem: <a href="https://pulp.plan.io/issues/3541" target="_blank">https://pulp.plan.io/issues/35<wbr>41</a></li>
<li>example:
POST@/api/v3/repositories/<rep<wbr>ository_id>/versions/</li>
</ul>
</ul>
</div>
</div>
</blockquote>
</span>
<div>I agree with this problem statement. In
terms of scope it affects some plugin
writers but not all.<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I think it affects all plugin writers. Even the File
plugin needs to provide some validation when creating a
repository version. Right now you can add a FileContent
with the same relative path as another FileContent in the
repository version. This should not be possible because
it's not a valid combination of FileContent units in the
same repository version. <br>
</div>
</div>
</div>
</div>
</blockquote>
<br></div></div>
Not necessarily. Two files with the same relative path will have
different digest (different content). The assumption that they both
cannot be in the same repository makes assumptions about how the
repository is used which I don't think is a good idea. Image two
different versions of abc.iso.<span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
<div class="gmail_extra">
<div class="gmail_quote">
<div> <br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
<div dir="ltr">
<div>We would like to get feedback on
these issues being sound and worth
resolving before we resume
particular solution discussion[1].</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Austin, Dennis, and Milan</div>
<div><br>
</div>
<div>[1] <a href="https://www.redhat.com/archives/pulp-dev/2018-March/msg00066.html" target="_blank">https://www.redhat.com/archive<wbr>s/pulp-dev/2018-March/msg00066<wbr>.html</a><br>
</div>
<div><br>
</div>
</div>
<br>
</span><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>
</div>
</div>
</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>
<br>
<fieldset class="m_-5277914780457999070mimeAttachmentHeader"></fieldset>
<br>
<pre>______________________________<wbr>_________________
Pulp-dev mailing list
<a class="m_-5277914780457999070moz-txt-link-abbreviated" href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a>
<a class="m_-5277914780457999070moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/pulp-dev" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a>
</pre>
</blockquote>
<br>
</span></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>