[Pulp-dev] Content paths in Pulp 3

Tue Apr 10 17:36:19 UTC 2018

Yes, this was my point about option 1 being more RESTful. I’m not sure if
you are arguing that <plugin> should also be plural. I believe it’s more of
a namespace though like the “v3” part of our urls.

David

On Tue, Apr 10, 2018 at 11:50 AM, Austin Macdonald <amacdona at redhat.com>
wrote:

> This change highlights a subtle related issue, which is the plurality of
> endpoints. [0]
>
> *v3/content/<type>/*
>
> 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.
>
> *v3/content/file/*
>
> The namespace plan highlights the problem.
>
> *v3/content/<plugin>/<type>/*
>
> 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.
>
> *v3/content/file/files/*
>
> [0]: https://docs.pulpproject.org/en/3.0/nightly/
> contributing/3.0-development/rest-api.html#rest-api-guidelines
>
> On Tue, Apr 10, 2018 at 11:38 AM, Austin Macdonald <amacdona at redhat.com>
> wrote:
>
>> If ya'll don't mind leaving out v3/content/<plugin>/ endpoints, then I
>> think we are all set. https://pulp.plan.io/issues/3472 should be ready
>> to  be groomed. Since I updated with the suggested implementation, would
>> one of you mind marking it groomed?
>>
>> On Tue, Apr 10, 2018 at 9:03 AM, Austin Macdonald <amacdona at redhat.com>
>> wrote:
>>
>>>
>>>
>>> On Tue, Apr 10, 2018 at 8:20 AM, David Davis <daviddavis at redhat.com>
>>> wrote:
>>>
>>>> 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.
>>>>
>>>
>>> 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 *could* make
>>> this call. We don't currently implement v3/content though, so maybe this
>>> isn't a big deal.
>>>
>>>
>>>>
>>>> David
>>>>
>>>> On Tue, Apr 10, 2018 at 8:13 AM, Dennis Kliban <dkliban at redhat.com>
>>>> wrote:
>>>>
>>>>> On Mon, Apr 9, 2018 at 1:32 PM, Austin Macdonald <amacdona at 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.
>>>>>>
>>>>>
>>>>> I don't think this endpoint needs to exist. What use case does it
>>>>> support?
>>>>>
>>>>>
>>>>>>
>>>>>> 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 <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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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/20180410/46f025aa/attachment.htm>