[Pulp-dev] Content paths in Pulp 3
daviddavis at redhat.com
Tue Apr 10 12:10:26 UTC 2018
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.
On Mon, Apr 9, 2018 at 1:32 PM, Austin Macdonald <amacdona at redhat.com>
> 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.
> 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)
> 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.
> 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
> On Fri, Apr 6, 2018 at 10:25 AM, Brian Bouterse <bbouters at redhat.com>
>> +1 to option 1. It's consistent.
>> On Fri, Apr 6, 2018 at 10:21 AM, Dennis Kliban <dkliban at redhat.com>
>>> Option 1 is the most consistent. +1 to option 1
>>> On Fri, Apr 6, 2018 at 10:19 AM, Austin Macdonald <amacdona at redhat.com>
>>>> 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 <daviddavis at redhat.com>
>>>>>  https://pulp.plan.io/issues/3407
>>>> The correct link is: https://pulp.plan.io/issues/3472
>>>> Pulp-dev mailing list
>>>> Pulp-dev at redhat.com
>>> Pulp-dev mailing list
>>> Pulp-dev at redhat.com
> Pulp-dev mailing list
> Pulp-dev at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev