Ugh, I’m wondering if this means we should also apply this content logic to publishers and remotes then?
David On Tue, Apr 10, 2018 at 12:38 PM, Brian Bouterse <[email protected]> wrote: > 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. > > On Tue, Apr 10, 2018 at 8:10 AM, David Davis <[email protected]> > wrote: > >> 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 <[email protected]> >> 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.plu >>> gin.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 <[email protected]> >>> wrote: >>> >>>> +1 to option 1. It's consistent. >>>> >>>> On Fri, Apr 6, 2018 at 10:21 AM, Dennis Kliban <[email protected]> >>>> wrote: >>>> >>>>> Option 1 is the most consistent. +1 to option 1 >>>>> >>>>> >>>>> On Fri, Apr 6, 2018 at 10:19 AM, Austin Macdonald <[email protected] >>>>> > 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 <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> [0] https://pulp.plan.io/issues/3407 >>>>>>> >>>>>> >>>>>> The correct link is: https://pulp.plan.io/issues/3472 >>>>>> >>>>>> _______________________________________________ >>>>>> Pulp-dev mailing list >>>>>> [email protected] >>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Pulp-dev mailing list >>>>> [email protected] >>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> Pulp-dev mailing list >>> [email protected] >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >>> >> >> _______________________________________________ >> Pulp-dev mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
