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

Brian Herring bherring at redhat.com
Wed Mar 6 20:08:51 UTC 2019


All:

Replied on a different list.

Thanks!


BRIAN HERRING

QUALITY ENGINEER - PULP QE

Red Hat

<https://www.redhat.com/>

100 East Davie Street

Raleigh, NC, 27601

bherring at redhat.com    M: +19193238427     IM: bherring
<https://red.ht/sig>


On Wed, Mar 6, 2019 at 9:51 AM Eric Helms <ehelms at redhat.com> wrote:

> My key with proposal with Option 2 is to set Pulp 3+ up to be the future
> without carrying any baggage. Let's put the baggage on the older bits and
> keep it there and leave the future as wide open as possible for Pulp 3+.
>
> As I am spending time looking at deploying Pulp 3 alongside Pulp 2 in a
> Katello environment, I'd like to get this change implemented as soon as
> possible. This is mostly an operational change and should have a minimal
> impact.
>
> is my next step to file a Redmine issue against Pulp 2?
>
> On Tue, Mar 5, 2019 at 11:15 AM Tatiana Tereshchenko <ttereshc at redhat.com>
> wrote:
>
>> +1 to option 2, rename of Pulp2 services.
>> It's a low risk change for Pulp2, in my opinion, and clear distinction of
>> legacy version.
>> I also agree with all the mentioned reasons to keep Pulp3 ones unchanged
>> and more importantly without version in the name.
>> -0 to make names configurable.
>>
>> Tanya
>>
>> On Tue, Mar 5, 2019 at 5:01 PM Ina Panova <ipanova at redhat.com> wrote:
>>
>>> +1 to rename Pulp2 services. This way we would ensure that the users
>>> have  upgraded to  a minimal version of Pulp 2 before upgrading to Pulp 3.
>>> As a suggestion i would not make this change with the next Pulp2 release
>>> but whenever we'd be able to tell for sure that this Pulp2.Y version is the
>>> version we are supporting the upgrade from.
>>> +1 on Eric's reasoning about being more strict and allow less variation
>>> in naming conventions.
>>> +1 on Eric's point about if renaming Pulp3 services then this will lock
>>> services names to Pulp version.
>>>
>>> @dana eventually in the discussion on the issue we decided to make only
>>> the hyphens change.
>>> @asmacdo <amacdona at redhat.com> https://pulp.plan.io/issues/4497 i think
>>> this is a dupe of https://pulp.plan.io/issues/4429
>>>
>>> --------
>>> Regards,
>>>
>>> Ina Panova
>>> Software Engineer| Pulp| Red Hat Inc.
>>>
>>> "Do not go where the path may lead,
>>>  go instead where there is no path and leave a trail."
>>>
>>>
>>> On Tue, Mar 5, 2019 at 3:44 PM Matt Pusateri <mpusater at redhat.com>
>>> wrote:
>>>
>>>> I like Option2, as long as we do it with and upgrade and we put Doc
>>>> notes in, I don't see it as a problem.
>>>>
>>>> Matt P.
>>>>
>>>> On Tue, Mar 5, 2019 at 8:48 AM Robin Chan <rchan at redhat.com> wrote:
>>>>
>>>>> To clarify, regarding @dana's comment - I wasn't necessarily voting
>>>>> for Option 1. Just pointing out the downside to option 2 wasn't a concern
>>>>> to my knowledge.
>>>>>
>>>>> @bherring - we have made changes to pulp 3 service names as @david
>>>>> pointed out. I do agree that making changes to pulp3 names seems to be the
>>>>> least invasive in the short term at first glance. Eric has given us
>>>>> feedback that the previous name change was not distinct enough. However I
>>>>> agree with his observation that specifying "3" won't be a great future
>>>>> proofed solution. I would argue that Option 2 is the  "least invasive" in
>>>>> the short term because the lasting impacts would be the most short lived
>>>>> (ironically for the same reasons you noted.)
>>>>>
>>>>> @kersom & @bherring - given your concerns about Option 2, can you
>>>>> suggest any variations/names for Option 1 that addresses the concern about
>>>>> longevity of the solution? Do you share Eric's concern regarding Austin's
>>>>> proposal to allow a user to specify? I agree with Eric's concern as I'd
>>>>> prefer that the naming be set to simplify debugging real life issues if
>>>>> there isn't a clear benefit to allowing this to be user specified (to be
>>>>> clear a -0 on Austin's suggestion - would like to hear more thoughts on
>>>>> this.)
>>>>>
>>>>> -Robin
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Mar 5, 2019 at 8:19 AM Brian Herring <bherring at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Is one of our goals is to move all possible resources to working on
>>>>>> Pulp3?
>>>>>>
>>>>>> If so, I am going to agree with Kersom on the basis that it seems
>>>>>> strange to make changes to a product we are attempting to sunset and should
>>>>>> be making minimal changes.
>>>>>>
>>>>>> Do we know all the impacts that changing service names in Pulp2 would
>>>>>> have on Pulp2 yet? If we have and are still making changes to Pulp3,
>>>>>> doesn't it  make more sense to make those changes there when the product
>>>>>> has yet to be launched?
>>>>>>
>>>>>> BRIAN HERRING
>>>>>>
>>>>>> QUALITY ENGINEER - PULP QE
>>>>>>
>>>>>> Red Hat
>>>>>>
>>>>>> <https://www.redhat.com/>
>>>>>>
>>>>>> 100 East Davie Street
>>>>>>
>>>>>> Raleigh, NC, 27601
>>>>>>
>>>>>> bherring at redhat.com    M: +19193238427     IM: bherring
>>>>>> <https://red.ht/sig>
>>>>>>
>>>>>>
>>>>>> On Mon, Mar 4, 2019 at 1:44 PM Kersom <kersom at redhat.com> wrote:
>>>>>>
>>>>>>> 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 <dawalker at redhat.com>
>>>>>>> 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
>>>>>>>>
>>>>>>>> <https://www.redhat.com>
>>>>>>>> <https://red.ht/sig>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Mar 4, 2019 at 1:06 PM Dennis Kliban <dkliban at redhat.com>
>>>>>>>> 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 <ehelms at redhat.com>
>>>>>>>>> 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 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
>>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>
>> _______________________________________________
>> 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/20190306/db5eb59b/attachment.htm>


More information about the Pulp-dev mailing list