<div dir="ltr">Ugh, I’m wondering if this means we should also apply this content logic to publishers and remotes then?</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 Tue, Apr 10, 2018 at 12:38 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">I think we should assume there could be multiple Remote's from a single plugin. For example the Galaxy remote pulp_ansible syncs from is launching a backwards incompatible API (their v3), so we will probably need to maintain a v2Remote and a v3Remote. There could be a similar backwards compatibility difference in published metadata motivating multiple Publishers from a single plugin also.<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 10, 2018 at 8:10 AM, 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’m not sure I understand the reasoning behind implementing a “v3/content/ansible/“ route. For example, we currently have “v3/content/file/“ but no “v3/content/“ route. <div><br></div><div>I think the point you raise around remotes and publishers is valid. Will plugins ever implement multiple remotes or publishers? I was thinking that there would always be one remote and one publisher class for each plugin but I suppose this could be wrong.</div><div class="gmail_extra"><span class="m_1813975113817877729HOEnZb"><font color="#888888"><br clear="all"><div><div class="m_1813975113817877729m_4003932961497177788m_6816300601163288891gmail_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></font></span><div><div class="m_1813975113817877729h5">
<br><div class="gmail_quote">On Mon, Apr 9, 2018 at 1:32 PM, 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">I've updated the issue <a href="https://pulp.plan.io/issues/3472" target="_blank">https://pulp.plan.io/iss<wbr>ues/3472</a> to reflect the current consensus. <div><br></div><div>However, I have some other points I'd like to discuss before we move on.</div><div><br></div><div><b>Implied endpoint:</b></div><div>v3/content/ansible/roles/ implies that there is a v3/content/ansible/. Even though this does not exist, it could, but it is a little awkward.</div><div><br></div><div>Implent v3/content/ansible/:</div><div><ol><li>Create a model viewset and serializer for the ansible level:</li><ol><li>class AnsibleContent(core.plugin.mod<wbr>els.Content)</li><li>class AnsibleContentSerializer(core.<wbr>plugin.serializers.ContentSeri<wbr>alizer)</li><li>class AnsibleContentViewSet(core.plu<wbr>gin.viewsets.ContentViewSet)</li><ol><li>endpoint = "ansible"</li></ol></ol><li>Make the Role model, VS, and Serializer inherit from the AnsibleContent Model, VS, and Serializer</li></ol><div>The end result is that v3/content/ansible/ will return all Ansible content units, including Roles. v3/content/ansible/roles/ will only return Roles.</div></div><div><br></div><div><b>Publishers and Remotes</b></div><div>The above workflow makes sense and is useful if there are multiple units, but for the File plugin, this pattern adds an endpoint and 3 classes to the Content. If we want to be consistent and apply this to Remotes and Publishers, this is 3 useless endpoints and 9 extra classes. (These classes are simple, even if they are extraneous, conceptually)</div><div><br></div><div><b>IMO</b></div><div>I think we should document all of this in the plugin docs. For single type (and single remote, and single publisher) plugins, it will make more sense not to add an extra namespace. If we document how to add the extra namespace and when/why plugins should, that will be sufficient. Promoting consistency over simplicity in this case seems too far.</div><div><br></div><div><b>Or...</b></div><div>We could alter the Master/Detail code. I only have vague ideas about how to do this, but Master/Detail would essentially become Master/Plugin/Detail. This seems "right", but there isn't as much gain here as you might think. If we did it this, plugins would be required to namespace, and would be still be required to make all those extra classes. The only practical difference is that the AnsibleRoleViewSet.endpoint = "roles" instead of "ansible/roles". Either way, the endpoint would be v3/content/ansible/roles/</div></div><div class="m_1813975113817877729m_4003932961497177788m_6816300601163288891HOEnZb"><div class="m_1813975113817877729m_4003932961497177788m_6816300601163288891h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 6, 2018 at 10:25 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">+1 to option 1. It's consistent.<br></div><div class="m_1813975113817877729m_4003932961497177788m_6816300601163288891m_-4585850672440906059HOEnZb"><div class="m_1813975113817877729m_4003932961497177788m_6816300601163288891m_-4585850672440906059h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 6, 2018 at 10:21 AM, 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">Option 1 is the most consistent. +1 to option 1<br><br></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_1813975113817877729m_4003932961497177788m_6816300601163288891m_-4585850672440906059m_-2588553887303934882h5">On Fri, Apr 6, 2018 at 10:19 AM, 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_1813975113817877729m_4003932961497177788m_6816300601163288891m_-4585850672440906059m_-2588553887303934882h5"><div dir="ltr"><div>IMO:</div><div>We should suggest v3/content/<plugin>/<type>/. [Proposal 1] We should mention the other options with the pros, cons in the plugin writer docs.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 5, 2018 at 10:54 AM, 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: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>[0] <a href="https://pulp.plan.io/issues/3407" target="_blank">https://pulp.plan.io/issue<wbr>s/3407</a></div></div></div></div></blockquote><div><br></div><div>The correct link is: <a href="https://pulp.plan.io/issues/3472" target="_blank">https://pulp.plan.io/issues/34<wbr>72</a></div></div></div></div>
<br></div></div>______________________________<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>
<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></div><br></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></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></div></blockquote></div><br></div>