<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 28, 2018 at 10:21 AM, Austin Macdonald <span dir="ltr"><<a href="mailto:amacdona@redhat.com" target="_blank">amacdona@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"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Tue, Mar 27, 2018 at 6:11 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>In terms of removing <span style="font-variant-ligatures:normal">POST /api/v3/repositories/<uuid>/</span><span style="font-variant-ligatures:normal">ve<wbr>rsions/ from core, I want to bring it back to the MVP language and REST which drove the original design. The MVP has: "As an authenticated user, I can create a new version by adding or removing content to the latest version."</span> To facilitate that in a generic way, we need a core endpoint to do that, i.e. /api/v3/repositories/<uuid>/ve<wbr>rsions/. My concern is that removing it would cause us to not fulfill our use cases without requiring more code from some plugin writers. Also in terms of REST philosophy, POSTing to the RespotoryVersion resource to create a new RepositoryVersion is the traditional url design.<br><br></div><div>For pulp_ansible, for example, the generic add/remove functionality at core endpoint ^ would be meet all of the pulp_ansible user's needs because of the way the pulp_ansible content is modelled. So removing this endpoint means more work for pulp_ansible developers w.r.t creating repo versions and providing tasks and endpoints. I don't see this extra responsibility on plugin writers coming with a clear benefit.<br></div><div><br></div></div></blockquote><div><br></div></span><div>I'm sensitive to adding work for the plugin writers, but convenience needs to be discussed after correctness.</div><div><br></div><div>I haven't seen a counterargument to the assertion that it is **incorrect** to control repo membership without allowing plugin validation.</div><span class=""><div></div></span></div></div></div></blockquote><div><br></div><div>We could add hooks for plugins to provide validation for each content type. The Content model in pulpcore could define "add_to_repository_version" and "remove_from_repository_version" methods that take repository version as a parameter. The default behavior would be that exists now. The Content models in the plugins could then override the methods and provide validation needed for removing from and adding to a repository version. The repository version REST api would then use these methods on the content models to add and remove content. <br><br></div><div>Thoughts on this idea?<br></div><div><br><br></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"><div class="gmail_quote"><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></div><div>One idea I liked in this discussion is to have a documented convention that encourages plugin writers to put their viewsets in a namespaced area. They still need the ability to put them anywhere due to live API goals/requirements so this would only be a convention for those tasks they are offering directly to their users.<br></div><div><br></div><div><br></div><div><br><br></div></div><div class="m_-6565439574302426857HOEnZb"><div class="m_-6565439574302426857h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 27, 2018 at 5:40 PM, David Davis <span dir="ltr"><<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@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">I like Austin’s task proposal in that the plugin writers can focus on serializers and tasks that can be easily integrated with core. That said, I agree on the counterpoints raise about the new resource endpoints and turning much of pulp into a task running system. So I am a bit mixed on which approach is better.<div><br></div><div>I do think that we should remove <span style="font-variant-ligatures:normal">POST /api/v3/repositories/<uuid>/</span><span style="font-variant-ligatures:normal">ve<wbr>rsions/ from core.</span></div></div><div class="gmail_extra"><span class="m_-6565439574302426857m_-4701703141178248475HOEnZb"><font color="#888888"><br clear="all"><div><div class="m_-6565439574302426857m_-4701703141178248475m_8395088390151553616gmail_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_-6565439574302426857m_-4701703141178248475h5">On Tue, Mar 27, 2018 at 3:49 PM, Austin Macdonald <span dir="ltr"><<a href="mailto:amacdona@redhat.com" target="_blank">amacdona@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_-6565439574302426857m_-4701703141178248475h5"><div dir="ltr"><div dir="auto"><span><div><div class="gmail_quote"><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"><ul><li>/api/v3/repositories/<uuid>/ve<wbr>rsions/ endpoint does not perform plugin specific validation which can lead to "broken" repository versions.</li><li>Plugin authors don't have any convention to follow when creating custom REST API endpoints for creating repository versions. <br></li><li>As a result of ^, a user will have a hard time identifying repository version creation APIs in different plugins. <br></li></ul></div></div></blockquote></div></div><div dir="auto"><br></div></span><div dir="auto">I agree with these points.</div><div dir="auto"><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 class="gmail_extra"><ul><li></li></ul>My first inclination is to disable the ability to POST to /api/v3/repositories/<uuid>/ve<wbr>rsions/ and require users to use the plugin specific APIs for creating repository versions. However, I think that integrators of build systems that produce a variety of content types would have a lot more flexibility if they could use a single generic API endpoint to create a repository version independent of the content type. <br><br></div><div class="gmail_extra">Let's continue this discussion by answering the following question: <br><ul><li>Should we disable the ability to POST to /api/v3/repositories/<uuid>/ve<wbr>rsions/ and require users to always use a plugin specific repository version creation API?</li></ul></div></div></blockquote></span><div>Yes, I think we should disable<span 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:left;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"><span> </span>POST to /api/v3/repositories/<uuid>/</span><span 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:left;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">ve<wbr>rsions/ </span><br></div><div><br></div><div>Simplifying integration is important, but we should not sacrifice correctness enforcement.</div></div></div></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>
<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></div></blockquote></span></div><br></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>