<div dir="ltr">This change highlights a subtle related issue, which is the plurality of endpoints. [0]<div><div><br></div><div><i>v3/content/<type>/</i></div><div><br></div><div>Here, the "type" seems to refer to the plugin, which is "file". This implies the false assumption that there is only one content type per plugin.</div><div><br></div><div><i>v3/content/file/</i></div><div><br></div><div>The namespace plan highlights the problem.</div><div><br></div><div><i>v3/content/<plugin>/<type>/</i></div><div><br></div><div>The context is subtly shifted. The "plugin" is file, which is singular, but the "type" refers to FileContent, which is an object and should be plural.<br></div><div><br></div><div><i>v3/content/file/files/</i></div><div><br></div></div><div>[0]: <a href="https://docs.pulpproject.org/en/3.0/nightly/contributing/3.0-development/rest-api.html#rest-api-guidelines">https://docs.pulpproject.org/en/3.0/nightly/contributing/3.0-development/rest-api.html#rest-api-guidelines</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 10, 2018 at 11:38 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">If ya'll don't mind leaving out v3/content/<plugin>/ endpoints, then I think we are all set. <a href="https://pulp.plan.io/issues/3472" target="_blank">https://pulp.plan.io/<wbr>issues/3472</a> should be ready to  be groomed. Since I updated with the suggested implementation, would one of you mind marking it groomed?</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 10, 2018 at 9:03 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"><span><br><div class="gmail_quote">On Tue, Apr 10, 2018 at 8:20 AM, David Davis <span dir="ltr"><<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a>></span> wrote:</div></span><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">I’m imagining v3/content/rpm/ returning all the content types for the rpm plugin (rpm, errata, package groups, etc) and thinking that will be very strange and awkward.</div></blockquote><div><br></div></span><div>Yes, that is what it would do. I don't know if anyone would need that, my point was that the url structure would imply that you <i>could</i> make this call. We don't currently implement v3/content though, so maybe this isn't a big deal.</div><div><div class="m_-5571411808505865827h5"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><span class="m_-5571411808505865827m_1518827544890511532HOEnZb"><font color="#888888"><br clear="all"><div><div class="m_-5571411808505865827m_1518827544890511532m_-2793213130190848807gmail_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_-5571411808505865827m_1518827544890511532h5">
<br><div class="gmail_quote">On Tue, Apr 10, 2018 at 8:13 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"><div class="gmail_extra"><div class="gmail_quote"><span>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></span><span><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></blockquote><div><br></div></span><div>I don't think this endpoint needs to exist. What use case does it support? <br></div><div><div class="m_-5571411808505865827m_1518827544890511532m_-2793213130190848807h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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_-5571411808505865827m_1518827544890511532m_-2793213130190848807m_5058271815318916157HOEnZb"><div class="m_-5571411808505865827m_1518827544890511532m_-2793213130190848807m_5058271815318916157h5"><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_-5571411808505865827m_1518827544890511532m_-2793213130190848807m_5058271815318916157m_-74822257317828118HOEnZb"><div class="m_-5571411808505865827m_1518827544890511532m_-2793213130190848807m_5058271815318916157m_-74822257317828118h5"><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_-5571411808505865827m_1518827544890511532m_-2793213130190848807m_5058271815318916157m_-74822257317828118m_-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_-5571411808505865827m_1518827544890511532m_-2793213130190848807m_5058271815318916157m_-74822257317828118m_-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></div></div><br></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></div></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>