Re: [Pulp-dev] Pulp 2 and 3 Service Name Clashes

[Kersom]

I do not think we should names in Pulp 2. Since this can cause impacts that
we do not know. This will increase the amount of time that we will spend
working on Pulp 2, changing, fixing, testing. At this point less changes in
Pulp 2 is what I think we should do.

On Mon, Mar 4, 2019 at 1:10 PM Dana Walker  wrote:

> As I understand the discussion on 4497, it was to be hyphens *in addition
> to* a name change, but you're right @ehelms that I only see the hyphen
> change.
>
> I'm +1 on @rchan's suggestion that the change take place in pulp2.
>
> Also given the migration and complexities with support, I agree with
> @ehelms that custom configuration of these names would be problematic, so
> I'm -0 on this unless we have a compelling user story for needing the
> customizability (assuming we are making the change to the service names in
> pulp2 ourselves).
>
> --Dana
>
> Dana Walker
>
> Associate Software Engineer
>
> Red Hat
>
> 
> 
>
>
> On Mon, Mar 4, 2019 at 1:06 PM Dennis Kliban  wrote:
>
>> I agree with @rchan that we will require users to upgrade to  a minimal
>> version of Pulp 2 before they can upgrade to Pulp 3.
>>
>> We should just rename Pulp 2 services in a future release of Pulp 2.
>>
>> On Mon, Mar 4, 2019 at 11:31 AM Eric Helms  wrote:
>>
>>> Howdy,
>>>
>>> In some migration of Pulp 2 to Pulp 3 cases, both will need to be ran
>>> side-by-side on the same box. Given that pulp workers and pulp resource
>>> manager are the same concept in both, this leads to their systemd resources
>>> being named the same (or in today's case so slightly different enough you
>>> can't tell them apart).
>>>
>>> I'd like to propose a change to the service names to facilitate this
>>> situation.
>>>
>>>
>>> Option 1: Include Pulp version in Pulp 3 services
>>>
>>> Example: pulp3-resource-manager
>>>
>>> Pro: Explicit naming and understanding of new services.
>>>
>>> Con: This locks services names to Pulp version, which will be odd with
>>> semantic versioning if 4 or 5 comes along.
>>>
>>>
>>> Option 2: Re-name Pulp 2 services to pulp2-
>>>
>>> Example: pulp2-resource-manager
>>>
>>> Pro: Explicitly identifies pulp2 services, easy to retro-fit by users
>>> onto their setups or through RPM releases.
>>>
>>> Con: Requires users to have upgraded to at least a particular Pulp2
>>> version to migrate to Pulp 3 (this may be required anyway).
>>> ___
>>> Pulp-dev mailing list
>>> Pulp-dev@redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Pulp 2 and 3 Service Name Clashes

[Dana Walker]

As I understand the discussion on 4497, it was to be hyphens *in addition
to* a name change, but you're right @ehelms that I only see the hyphen
change.

I'm +1 on @rchan's suggestion that the change take place in pulp2.

Also given the migration and complexities with support, I agree with
@ehelms that custom configuration of these names would be problematic, so
I'm -0 on this unless we have a compelling user story for needing the
customizability (assuming we are making the change to the service names in
pulp2 ourselves).

--Dana

Dana Walker

Associate Software Engineer

Red Hat





On Mon, Mar 4, 2019 at 1:06 PM Dennis Kliban  wrote:

> I agree with @rchan that we will require users to upgrade to  a minimal
> version of Pulp 2 before they can upgrade to Pulp 3.
>
> We should just rename Pulp 2 services in a future release of Pulp 2.
>
> On Mon, Mar 4, 2019 at 11:31 AM Eric Helms  wrote:
>
>> Howdy,
>>
>> In some migration of Pulp 2 to Pulp 3 cases, both will need to be ran
>> side-by-side on the same box. Given that pulp workers and pulp resource
>> manager are the same concept in both, this leads to their systemd resources
>> being named the same (or in today's case so slightly different enough you
>> can't tell them apart).
>>
>> I'd like to propose a change to the service names to facilitate this
>> situation.
>>
>>
>> Option 1: Include Pulp version in Pulp 3 services
>>
>> Example: pulp3-resource-manager
>>
>> Pro: Explicit naming and understanding of new services.
>>
>> Con: This locks services names to Pulp version, which will be odd with
>> semantic versioning if 4 or 5 comes along.
>>
>>
>> Option 2: Re-name Pulp 2 services to pulp2-
>>
>> Example: pulp2-resource-manager
>>
>> Pro: Explicitly identifies pulp2 services, easy to retro-fit by users
>> onto their setups or through RPM releases.
>>
>> Con: Requires users to have upgraded to at least a particular Pulp2
>> version to migrate to Pulp 3 (this may be required anyway).
>> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Pulp 2 and 3 Service Name Clashes

[Eric Helms]

On Mon, Mar 4, 2019 at 12:50 PM Austin Macdonald 
wrote:

> There is some additional work to be done with the installer
> https://pulp.plan.io/issues/4187#note-3
>
> I've created a new story for the installer to allow a user to override the
> default and specify whatever name they choose for each component.
> https://pulp.plan.io/issues/4497
>

Sorry to be a bit of nacker here, but I don't want to set my own naming
conventions. And, as a project, I wouldn't want users overriding that
either. The less opinionated you are the harder the supportability, as you
are introducing variations that any user or developer has to parse to
understand the issue.

The changing of Pulp 2's service names seems the least invasive as they
would be changed in the RPM spec files and automatically updated when that
version was installed. This gives Pulp 3+ the cleanest flexibility going
forward and more clearly identifies legacy components.


>
>
> On Mon, Mar 4, 2019 at 12:32 PM Eric Helms  wrote:
>
>> If I read the solution as hyphens vs underscores as implemented in
>> ansible-pulp3 today then yes, it's still very confusing which is which.
>>
>> On Mon, Mar 4, 2019, 12:25 PM David Davis  wrote:
>>
>>> I agree with rchan and am thus leaning towards option 2.
>>>
>>> Just to be clear though, we renamed pulp 3’s services recently to avoid
>>> conflict[0] with pulp 2. However, it sounds like this solution isn’t good
>>> enough as it’s hard for users to identify which set of services go with
>>> which version of pulp?
>>>
>>> [0] https://pulp.plan.io/issues/4187
>>>
>>> David
>>>
>>>
>>> On Mon, Mar 4, 2019 at 11:55 AM Robin Chan  wrote:
>>>
 See comment below on option 2.

 On Mon, Mar 4, 2019 at 11:31 AM Eric Helms  wrote:

> Howdy,
>
> In some migration of Pulp 2 to Pulp 3 cases, both will need to be ran
> side-by-side on the same box. Given that pulp workers and pulp resource
> manager are the same concept in both, this leads to their systemd 
> resources
> being named the same (or in today's case so slightly different enough you
> can't tell them apart).
>
> I'd like to propose a change to the service names to facilitate this
> situation.
>
>
> Option 1: Include Pulp version in Pulp 3 services
>
> Example: pulp3-resource-manager
>
> Pro: Explicit naming and understanding of new services.
>
> Con: This locks services names to Pulp version, which will be odd with
> semantic versioning if 4 or 5 comes along.
>
>
> Option 2: Re-name Pulp 2 services to pulp2-
>
> Example: pulp2-resource-manager
>
> Pro: Explicitly identifies pulp2 services, easy to retro-fit by users
> onto their setups or through RPM releases.
>
> Con: Requires users to have upgraded to at least a particular Pulp2
> version to migrate to Pulp 3 (this may be required anyway).
>
 [rchan] My expectation is that we will levy this requirement on
 upgrades/migrations anyway, so I don't think this con applies for this
 suggestion.

 ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
 ___
 Pulp-dev mailing list
 Pulp-dev@redhat.com
 https://www.redhat.com/mailman/listinfo/pulp-dev

>>> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Pulp 2 and 3 Service Name Clashes

[Eric Helms]

If I read the solution as hyphens vs underscores as implemented in
ansible-pulp3 today then yes, it's still very confusing which is which.

On Mon, Mar 4, 2019, 12:25 PM David Davis  wrote:

> I agree with rchan and am thus leaning towards option 2.
>
> Just to be clear though, we renamed pulp 3’s services recently to avoid
> conflict[0] with pulp 2. However, it sounds like this solution isn’t good
> enough as it’s hard for users to identify which set of services go with
> which version of pulp?
>
> [0] https://pulp.plan.io/issues/4187
>
> David
>
>
> On Mon, Mar 4, 2019 at 11:55 AM Robin Chan  wrote:
>
>> See comment below on option 2.
>>
>> On Mon, Mar 4, 2019 at 11:31 AM Eric Helms  wrote:
>>
>>> Howdy,
>>>
>>> In some migration of Pulp 2 to Pulp 3 cases, both will need to be ran
>>> side-by-side on the same box. Given that pulp workers and pulp resource
>>> manager are the same concept in both, this leads to their systemd resources
>>> being named the same (or in today's case so slightly different enough you
>>> can't tell them apart).
>>>
>>> I'd like to propose a change to the service names to facilitate this
>>> situation.
>>>
>>>
>>> Option 1: Include Pulp version in Pulp 3 services
>>>
>>> Example: pulp3-resource-manager
>>>
>>> Pro: Explicit naming and understanding of new services.
>>>
>>> Con: This locks services names to Pulp version, which will be odd with
>>> semantic versioning if 4 or 5 comes along.
>>>
>>>
>>> Option 2: Re-name Pulp 2 services to pulp2-
>>>
>>> Example: pulp2-resource-manager
>>>
>>> Pro: Explicitly identifies pulp2 services, easy to retro-fit by users
>>> onto their setups or through RPM releases.
>>>
>>> Con: Requires users to have upgraded to at least a particular Pulp2
>>> version to migrate to Pulp 3 (this may be required anyway).
>>>
>> [rchan] My expectation is that we will levy this requirement on
>> upgrades/migrations anyway, so I don't think this con applies for this
>> suggestion.
>>
>> ___
>>> Pulp-dev mailing list
>>> Pulp-dev@redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Pulp 2 and 3 Service Name Clashes

[David Davis]

I agree with rchan and am thus leaning towards option 2.

Just to be clear though, we renamed pulp 3’s services recently to avoid
conflict[0] with pulp 2. However, it sounds like this solution isn’t good
enough as it’s hard for users to identify which set of services go with
which version of pulp?

[0] https://pulp.plan.io/issues/4187

David


On Mon, Mar 4, 2019 at 11:55 AM Robin Chan  wrote:

> See comment below on option 2.
>
> On Mon, Mar 4, 2019 at 11:31 AM Eric Helms  wrote:
>
>> Howdy,
>>
>> In some migration of Pulp 2 to Pulp 3 cases, both will need to be ran
>> side-by-side on the same box. Given that pulp workers and pulp resource
>> manager are the same concept in both, this leads to their systemd resources
>> being named the same (or in today's case so slightly different enough you
>> can't tell them apart).
>>
>> I'd like to propose a change to the service names to facilitate this
>> situation.
>>
>>
>> Option 1: Include Pulp version in Pulp 3 services
>>
>> Example: pulp3-resource-manager
>>
>> Pro: Explicit naming and understanding of new services.
>>
>> Con: This locks services names to Pulp version, which will be odd with
>> semantic versioning if 4 or 5 comes along.
>>
>>
>> Option 2: Re-name Pulp 2 services to pulp2-
>>
>> Example: pulp2-resource-manager
>>
>> Pro: Explicitly identifies pulp2 services, easy to retro-fit by users
>> onto their setups or through RPM releases.
>>
>> Con: Requires users to have upgraded to at least a particular Pulp2
>> version to migrate to Pulp 3 (this may be required anyway).
>>
> [rchan] My expectation is that we will levy this requirement on
> upgrades/migrations anyway, so I don't think this con applies for this
> suggestion.
>
> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Pulp 2 and 3 Service Name Clashes

[Robin Chan]

See comment below on option 2.

On Mon, Mar 4, 2019 at 11:31 AM Eric Helms  wrote:

> Howdy,
>
> In some migration of Pulp 2 to Pulp 3 cases, both will need to be ran
> side-by-side on the same box. Given that pulp workers and pulp resource
> manager are the same concept in both, this leads to their systemd resources
> being named the same (or in today's case so slightly different enough you
> can't tell them apart).
>
> I'd like to propose a change to the service names to facilitate this
> situation.
>
>
> Option 1: Include Pulp version in Pulp 3 services
>
> Example: pulp3-resource-manager
>
> Pro: Explicit naming and understanding of new services.
>
> Con: This locks services names to Pulp version, which will be odd with
> semantic versioning if 4 or 5 comes along.
>
>
> Option 2: Re-name Pulp 2 services to pulp2-
>
> Example: pulp2-resource-manager
>
> Pro: Explicitly identifies pulp2 services, easy to retro-fit by users onto
> their setups or through RPM releases.
>
> Con: Requires users to have upgraded to at least a particular Pulp2
> version to migrate to Pulp 3 (this may be required anyway).
>
[rchan] My expectation is that we will levy this requirement on
upgrades/migrations anyway, so I don't think this con applies for this
suggestion.

___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] Pulp 2 and 3 Service Name Clashes

[Eric Helms]

Howdy,

In some migration of Pulp 2 to Pulp 3 cases, both will need to be ran
side-by-side on the same box. Given that pulp workers and pulp resource
manager are the same concept in both, this leads to their systemd resources
being named the same (or in today's case so slightly different enough you
can't tell them apart).

I'd like to propose a change to the service names to facilitate this
situation.


Option 1: Include Pulp version in Pulp 3 services

Example: pulp3-resource-manager

Pro: Explicit naming and understanding of new services.

Con: This locks services names to Pulp version, which will be odd with
semantic versioning if 4 or 5 comes along.


Option 2: Re-name Pulp 2 services to pulp2-

Example: pulp2-resource-manager

Pro: Explicitly identifies pulp2 services, easy to retro-fit by users onto
their setups or through RPM releases.

Con: Requires users to have upgraded to at least a particular Pulp2 version
to migrate to Pulp 3 (this may be required anyway).
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] New Pulp 3.0 RC date

[David Davis]

In order to give more time to some outstanding discussions like whether to
switch to UUIDs[0] or to drop pulp-manager[1], we’re pushing back the
release of Pulp 3 RC by one week. The new feature freeze date is March 13,
2019 while the release is expected to be on March 27, 2019.

[0] https://www.redhat.com/archives/pulp-dev/2019-February/msg00088.html
[1] https://pulp.plan.io/issues/4450

David
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Unified interface for plugin actions

[Austin Macdonald]

The v3/actions would not need to be limited to plugins, but I think we
ought to leave object CRUD how it is. So asynchronous object
create/update/delete should remain on the object viewset.

The only endpoints I'd like to move are sync, publish, export, and
plugin-defined actions like one-shot upload. It might also be worth moving
the orphan removal for core. Suggested endpoint:
`v3/actions/core/remove_orphans/`

On Fri, Mar 1, 2019 at 4:27 PM David Davis  wrote:

> I'm curious about how these "actions" are defined. Is the /v3/actions/
> namespace limited to plugins? Or, for example, should distribution
> create/update/delete be nested under /v3/actions/? What about repository
> create/update/delete?
>
> David
>
>
> On Fri, Mar 1, 2019 at 9:08 PM Justin Sherrill 
> wrote:
>
>>
>> On 3/1/19 2:45 PM, Robin Chan wrote:
>>
>> Justin,
>> Would such a change make a significant difference in the effort,
>> complexity, or time to migrate existing (or support new) plugins in Katello?
>>
>> It would be a very small and simple change.
>>
>>
>>
>> Robin
>>
>> On Fri, Mar 1, 2019 at 2:00 PM Justin Sherrill 
>> wrote:
>>
>>> To me this makes a lot of sense, allows for plugin flexibility, and is
>>> more consistent across plugins.
>>>
>>> I feel like this will make differences between plugins more
>>> understandable by reading the api docs, rather than scanning the
>>> README's of the respective plugin and trying to work out what is
>>> different.
>>>
>>> Justin
>>>
>>> On 2/28/19 1:42 PM, Austin Macdonald wrote:
>>> > Now that we have a handful of plugins that have somewhat different
>>> > workflows, surprising user-facing differences in the interface for
>>> > plugin-related actions are becoming apparent.
>>> >
>>> > Example: Publish
>>> > File:
>>> > Create a publisher
>>> > v3/publishers/file/1/publish/ repository=$REPO
>>> > Ansible:
>>> > (no publisher)
>>> > v3/publications/ repository=$REPO
>>> >
>>> > The difference is not huge, having a different endpoint does defy
>>> > expectations of a user who is familiar with one plugin, who then moves
>>> > to another plugin.
>>> >
>>> > Plugins can also implement other endpoints, like RPM's one-shot
>>> > upload. The problem is that we have mixed idioms. Plugins are
>>> > encouraged to create task endpoints for objects (remote's sync,
>>> > publisher's publish), but they are also encouraged to create arbitrary
>>> > endpoints for any other actions. Users are not able to form reasonable
>>> > expectations for this part of the interface from plugin to plugin.
>>> >
>>> > Proposal:
>>> > We could move all "actions" into a single area, namespaced by plugin
>>> > (by convention). This would allow the plugins the freedom to do
>>> > whatever they need to do while keeping the interface consistent and
>>> > predictable for users of multiple plugins. These "actions" could be
>>> > synchronous or asynchronous. Importantly, this would also create a
>>> > logical "group" of endpoints a user could look for in the REST API
>>> docs.
>>> >
>>> > Examples:
>>> > v3/actions/file/publish/ publisher=$PUB repository=$REPO
>>> > v3/actions/ansible/publish/ repository=$REPO
>>> > v3/actions/rpm/upload/ file@./foo-4.1-1.noarch.rpm repository=$REPO
>>> >
>>> > Will this push back the RC?
>>> > No. The changes to the plugin API will be small, and the changes to
>>> > each plugin would be moving sync and publish endpoints, leaving the
>>> > logic almost identical. I anticipate the most time consuming aspect of
>>> > this will be adjusting the documentation of each plugin-- but since
>>> > they will follow similar patterns, this shouldn't be too much work
>>> either.
>>> >
>>> > To sum up:
>>> > We should move sync and publish endpoints to
>>> > /actions/// to be consistent with other
>>> > plugin-defined actions like one-shot upload. This will look very nice
>>> > in swagger docs, and should provide more consistent workflows for
>>> > users of multiple plugins.
>>>
>>> ___
>>> Pulp-dev mailing list
>>> Pulp-dev@redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev