On Tue, Apr 10, 2018 at 1:36 PM, David Davis 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,
Ugh, I’m wondering if this means we should also apply this content logic to
publishers and remotes then?
David
On Tue, Apr 10, 2018 at 12:38 PM, Brian Bouterse
wrote:
> I think we should assume there could be multiple Remote's from a single
> plugin. For example the Galaxy remote pulp_ansible
Yes, this was my point about option 1 being more RESTful. I’m not sure if
you are arguing that 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
wrote:
> This change highlights a subtle rel
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
compatibilit
This change highlights a subtle related issue, which is the plurality of
endpoints. [0]
*v3/content//*
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 highligh
If ya'll don't mind leaving out v3/content// 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
wrote
On Tue, Apr 10, 2018 at 8:20 AM, David Davis 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 tha
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 wrote:
> On Mon, Apr 9, 2018 at 1:32 PM, Austin Macdonald
> wrote:
>
>>
On Mon, Apr 9, 2018 at 1:32 PM, Austin Macdonald
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
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
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,
+1 to option 1. It's consistent.
On Fri, Apr 6, 2018 at 10:21 AM, Dennis Kliban wrote:
> Option 1 is the most consistent. +1 to option 1
>
>
> On Fri, Apr 6, 2018 at 10:19 AM, Austin Macdonald
> wrote:
>
>> IMO:
>> We should suggest v3/content///. [Proposal 1] We should
>> mention the other opt
Option 1 is the most consistent. +1 to option 1
On Fri, Apr 6, 2018 at 10:19 AM, Austin Macdonald
wrote:
> IMO:
> We should suggest v3/content///. [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
IMO:
We should suggest v3/content///. [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 wrote:
>
> [0] https://pulp.plan.io/issues/3407
>
The correct link is: https://pulp.plan.io/issues/3472
Currently, we access content units at paths like /api/v3/content/file/.
This works great if your plugin has a single content type that corresponds
to the name of the plugin.
In pulp_ansible though, we have multiple content types (roles, role
versions, etc) so we’ve opened an issue [0] we need feed
15 matches
Mail list logo