<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><div><div class="gmail_extra"><br><div class="gmail_quote"><span class="">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 class=""><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"><div></div><span class=""><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 class=""><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 class=""><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 class=""><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><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 class=""><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 class="">______________________________<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">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></div>