[Pulp-dev] Content paths in Pulp 3

Austin Macdonald amacdona at redhat.com
Mon Apr 9 17:32:58 UTC 2018


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 <bbouters at redhat.com> wrote:

> +1 to option 1. It's consistent.
>
> On Fri, Apr 6, 2018 at 10:21 AM, Dennis Kliban <dkliban at redhat.com> wrote:
>
>> 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>
>> 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 <daviddavis at 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 at redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>>
>>
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180409/5eff16d4/attachment.htm>


More information about the Pulp-dev mailing list