<div dir="ltr"><div><div><div><div><div><div><div><div><div><div>I do not think that it's a valid argument to ban the proposal just because the proposal will bring changes to the existing plugins. Because:<br><br></div>1) i think it would be fair to think of other plugins and find a solution all plugins will be happy with --> so we are back to the generic correctness problem <br></div>2) we are not GA, not even Beta, we are free and eligible to make changes, no promises made yet.<br></div>3) if we bring changes *this* exactly is the time to do because we have just 2 plugins working with basic functionality :)<br><br></div>W/r to the "Pulp turning into a task running system" ..and yet that's a system based on distributed task system<br><br></div>I suggest to organize a meeting with an agenda in advance that would list 1) concerns 2) questions<br></div>I also think it would be valuable to hear Jeff's feedback.<br><br></div>If the team finds that meeting idea is beneficial with the believe that after the meeting we will:<br>1) i am not naive to believe that we would reach consensus but at least we would move forward<br></div>2) we will decrease the frustration level, because face2face conversation is more profitable, since we do see faces, have social interaction and not type onto keyboard and stare at the text on the monitor.<br><br></div>then...I will take the action item and schedule the meeting.<br><br></div><div>Meanwhile we'll have time to chew on Easter eggs and give to the proposal a deeper, unbiased, full of protein (that helps brain thinking) thought. <br></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><br><br>--------<br>Regards,<br><br>Ina Panova<br>Software Engineer| Pulp| Red Hat Inc.<br><br>"Do not go where the path may lead,<br> go instead where there is no path and leave a trail."<br></div></div></div>
<br><div class="gmail_quote">On Wed, Mar 28, 2018 at 12:11 AM, 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>/<wbr>versions/. 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>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="HOEnZb"><div class="h5"><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_6260395847129403755HOEnZb"><font color="#888888"><br clear="all"><div><div class="m_6260395847129403755m_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_6260395847129403755h5">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_6260395847129403755h5"><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><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>