[Pulp-dev] Content paths in Pulp 3

David Davis daviddavis at redhat.com
Tue Apr 10 12:20:01 UTC 2018


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.


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.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
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> 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/d289b757/attachment.htm>


More information about the Pulp-dev mailing list