[Pulp-dev] Content paths in Pulp 3

Tue Apr 10 18:14:07 UTC 2018

On Tue, Apr 10, 2018 at 1:36 PM, David Davis <daviddavis at redhat.com> wrote:

> Ugh, I’m wondering if this means we should also apply this content logic
> to publishers and remotes then?
>

I think we probably need to. This is the conclusion I'm drawing from this
convo.

>
>
> David
>
> On Tue, Apr 10, 2018 at 12:38 PM, Brian Bouterse <bbouters at redhat.com>
> 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 <daviddavis at redhat.com>
>> 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 <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.
>>>>
>>>> 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/93354165/attachment.htm>