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.
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. David On Mon, Apr 9, 2018 at 1:32 PM, Austin Macdonald <amacd...@redhat.com> wrote: > I've updated the issue https://pulp.plan.io/issues/3472 to reflect the > current consensus. > > However, I have some other points I'd like to discuss before we move on. > > *Implied endpoint:* > 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. > > Implent v3/content/ansible/: > > 1. Create a model viewset and serializer for the ansible level: > 1. class AnsibleContent(core.plugin.models.Content) > 2. class AnsibleContentSerializer(core. > plugin.serializers.ContentSerializer) > 3. class AnsibleContentViewSet(core.plugin.viewsets.ContentViewSet) > 1. endpoint = "ansible" > 2. Make the Role model, VS, and Serializer inherit from the > AnsibleContent Model, VS, and Serializer > > The end result is that v3/content/ansible/ will return all Ansible content > units, including Roles. v3/content/ansible/roles/ will only return Roles. > > *Publishers and Remotes* > 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) > > *IMO* > 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. > > *Or...* > 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/ > > On Fri, Apr 6, 2018 at 10:25 AM, Brian Bouterse <bbout...@redhat.com> > wrote: > >> +1 to option 1. It's consistent. >> >> On Fri, Apr 6, 2018 at 10:21 AM, Dennis Kliban <dkli...@redhat.com> >> wrote: >> >>> Option 1 is the most consistent. +1 to option 1 >>> >>> >>> On Fri, Apr 6, 2018 at 10:19 AM, Austin Macdonald <amacd...@redhat.com> >>> wrote: >>> >>>> IMO: >>>> We should suggest v3/content/<plugin>/<type>/. [Proposal 1] We should >>>> mention the other options with the pros, cons in the plugin writer docs. >>>> >>>> On Thu, Apr 5, 2018 at 10:54 AM, David Davis <davidda...@redhat.com> >>>> wrote: >>>> >>>>> >>>>> [0] https://pulp.plan.io/issues/3407 >>>>> >>>> >>>> The correct link is: https://pulp.plan.io/issues/3472 >>>> >>>> _______________________________________________ >>>> Pulp-dev mailing list >>>> Pulp-dev@redhat.com >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>>> >>> >>> _______________________________________________ >>> Pulp-dev mailing list >>> Pulp-dev@redhat.com >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >>> >> > > _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
