Open Stack

Hello,

I don't really mind removing it if what you are saying about Python 4 is true, I don't know so I will take your word for it.


I agree with Takashi, that we can remove it but should do it consistenly and then be done with it, just stopping to use it

because it takes literally five seconds more to fix a patch seems like something one can live with until then.


Remember that we've for years been working on consistency, cleaning up and removing duplication, I wouldn't want to

start introducing then after that.


So yes, let's remove it but require everything up until that point to be consistent, maybe a short timespan to squeeze

all those changes into Wallaby though. Is this a change you want to drive Thomas?


Best regards and have a good start of the week everybody.

Tobias

________________________________
From: Takashi Kajinami <tkajinam at redhat.com>
Sent: Sunday, February 28, 2021 3:12:42 PM
To: Thomas Goirand
Cc: OpenStack Discuss
Subject: Re: [puppet-openstack] stop using the ${pyvers} variable



On Sun, Feb 28, 2021 at 8:22 PM Thomas Goirand <zigo at debian.org<mailto:zigo at debian.org>> wrote:
On 2/28/21 12:10 PM, Takashi Kajinami wrote:
>
> On Sun, Feb 28, 2021 at 3:32 AM Thomas Goirand <zigo at debian.org<mailto:zigo at debian.org>
> <mailto:zigo at debian.org<mailto:zigo at debian.org>>> wrote:
>
>     Hi,
>
>     On 2/27/21 3:52 PM, Takashi Kajinami wrote:
>     > I have posted a comment on the said patch but I prefer using pyvers in
>     > that specific patch because;
>     >  - The change seems to be a backport candidate and using pyvers
>     helps us
>     > backport the change
>     >    to older branches like Train which still supports python 2 IIRC.
>
>     Even Rocky is already using python3 in Debian/Ubuntu. The last distro
>     using the Python 2 version would be Stretch (which is long EOLed) and
>     Bionic (at this time, people should be moving to Focal, no ?, which IMO
>     are not targets for backports.
>
>     Therefore, for this specific patch, even if you want to do a backport,
>     it doesn't make sense.
>
>     Are you planning to do such a backport for the RPM world?
>
> We still have queens open for puppet-openstack modules.
> IIRC rdo rocky is based on CentOS7 and Python2.
> Also, I don't really like to see inconsistent implementation caused by
> backport
> knowing that we don't support python3 in these branches.
> Anyway we can consider that when we actually backport the change.

I'm a bit surprised that you still care about such an old release as
Queens. Is this the release shipped with CentOS 7?
RDO Queens anr RDO Rocky are based on CentOS 7.
RDO Train supports both CentOS7 and CentOS8 IIRC.

In any ways, thanks for letting me know, I have to admit I don't know
much about the RPM side of things.

In such case, I'm ok to keep the ${pyvers} variable for the CentOS case
for a bit longer then, but can we agree when we stop using it? Also IMO,
forcing it for Debian/Ubuntu doesn't make sense anymore.
IMO we can think about backport separately(we can make any required changes
in backport only) so we can get rid of pyvers in master for both CentOS and Ubuntu/Debian.

However I prefer to deal with that removal separately and consistently, so that we won't
create inconsistent implementation where some relies on pyvers and the others doesn't
rely on pyvers.


Thanks everyone for participating in this thread,
Cheers,

Thomas Goirand (zigo)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210301/a3e1fb4c/attachment-0001.html>