CentOS 8 nodes available now
Hello, I'm happy to say that CentOS 8 images are now live in OpenDev infra. Using a node label of "centos-8" will get you started. --- The python environment setup on these images is different to our other images. Firstly, some background: currently during image build we go to some effort to: a) install the latest pip/virtualenv/setuptools b) ensure standard behaviour: /usr/bin/python -> python2 /usr/bin/pip -> python2 install /usr/bin/pip3 -> python3 install /usr/bin/virtualenv -> creates python2 environment by default; python3 virtualenv package in sync This means a number of things; hosts always have python2, and because we overwrite the system pip/virtualenv/setuptools we put these packages on "hold" (depending on the package manager) so jobs don't re-install them and create (even more of) a mess. This made sense in the past, when we had versions of pip/setuptools in distributions that couldn't understand syntax in requirements files (and other bugs) and didn't have the current fantastic job inheritance and modularity that Zuul (v3) provides. However, it also introduces a range of problems for various users, and has a high maintenance overhead. Thus these new images are, by default, python3 only, and have upstream pip and virtualenv packages installed. You will have a default situation: /usr/bin/python -> not provided /usr/bin/pip -> not provided, use /usr/bin/pip3 or "python3 -m pip" /usr/bin/virtualenv -> create python3 environment; provided by upstream python3-virtualenv package /usr/bin/pyvenv -> not provided (is provided by Ubuntu python3-venv), use /usr/bin/pyvenv-3 or "python3 -m venv". Ergo, the "standard behaviour" is not so standard any more. I would suggest if you wish to write somewhat portable jobs/roles etc., you do the following: * in general don't rely on "unversioned" calls of tools at all (python/pip/virtualenv) -- they can all mean different things on different platforms. * scripts should always be #!/usr/bin/python3 * use "python3 -m venv" for virtual environments (if you really need "virtualenv" because of one of the features it provides, use "-m virtualenv") * use "python3 -m pip" to install global pip packages; but try not too -- mixing packages and pip installs never works that well. * if you need python2 for some reason, use a bindep file+role to install it (don't assume it is there) --- For any Zuul admins, note that to use python3-only images similar to what we make, you'll need to set "python-path" to python3 in nodepool so that Ansible calls the correct remote binary. Keep an eye on [1] which will automate this for Ansible >=2.8 after things are merged and released. --- Most of the job setup has been tested (network configs, setting mirrors, adding swap etc.) but there's always a chance of issues with a new platform. Please bring up any issues in #openstack-infra and we'll be sure to get them fixed. --- If you're interested in the images, they are exported at https://nb01.openstack.org/images/ although they are rather large, because we pre-cache a lot. If you'd like to build your own, [2] might help with: DISTRO=centos-minimal DIB_RELEASE=8 --- Thanks, -i [1] https://review.opendev.org/#/c/682797/ [2] https://opendev.org/openstack/project-config/src/branch/master/tools/build-i...
Hello,
I'm happy to say that CentOS 8 images are now live in OpenDev infra. Using a node label of "centos-8" will get you started.
---
The python environment setup on these images is different to our other images. Firstly, some background: currently during image build we go to some effort to:
a) install the latest pip/virtualenv/setuptools b) ensure standard behaviour: /usr/bin/python -> python2
On Wed, 2019-10-16 at 10:03 +1100, Ian Wienand wrote: python on centos8 should be a link to python3 infact ideally python 2 should not be installed at all.
/usr/bin/pip -> python2 install /usr/bin/pip3 -> python3 install /usr/bin/virtualenv -> creates python2 environment by default; python3 virtualenv package in sync
This means a number of things; hosts always have python2,
why would we want this. ideally we should try to ensure that there is non python 2 on the system so that we can ensure we are not using it bay mistake and can do an entirly python3 only install on centos8 ---- later: i realised read later that you are descibing how thigns work on other images here.
and because we overwrite the system pip/virtualenv/setuptools we put these packages on "hold" (depending on the package manager) so jobs don't re-install them and create (even more of) a mess.
This made sense in the past, when we had versions of pip/setuptools in distributions that couldn't understand syntax in requirements files (and other bugs) and didn't have the current fantastic job inheritance and modularity that Zuul (v3) provides. However, it also introduces a range of problems for various users, and has a high maintenance overhead.
Thus these new images are, by default, python3 only, and have upstream pip and virtualenv packages installed. You will have a default situation:
/usr/bin/python -> not provided /usr/bin/pip -> not provided, use /usr/bin/pip3 or "python3 -m pip" /usr/bin/virtualenv -> create python3 environment; provided by upstream python3-virtualenv package /usr/bin/pyvenv -> not provided (is provided by Ubuntu python3-venv), use /usr/bin/pyvenv-3 or "python3 -m venv".
Ergo, the "standard behaviour" is not so standard any more.
I would suggest if you wish to write somewhat portable jobs/roles etc., you do the following:
* in general don't rely on "unversioned" calls of tools at all (python/pip/virtualenv) -- they can all mean different things on different platforms. * scripts should always be #!/usr/bin/python3 see i think that is an anti pattern they could be but i think /usr/bin/python should map to /usr/bin/python3 and you should assume
* use "python3 -m venv" for virtual environments (if you really need "virtualenv" because of one of the features it provides, use "-m virtualenv") * use "python3 -m pip" to install global pip packages; but try not too -- mixing packages and pip installs never works that well. well from a devstack point of view we almost exclucive install form
* if you need python2 for some reason, use a bindep file+role to install it (don't assume it is there) +1 also dont assmue python will be python
---
For any Zuul admins, note that to use python3-only images similar to what we make, you'll need to set "python-path" to python3 in nodepool so that Ansible calls the correct remote binary. Keep an eye on [1] which will automate this for Ansible >=2.8 after things are merged and released.
---
Most of the job setup has been tested (network configs, setting mirrors, adding swap etc.) but there's always a chance of issues with a new platform. Please bring up any issues in #openstack-infra and we'll be sure to get them fixed.
---
If you're interested in the images, they are exported at
https://nb01.openstack.org/images/
although they are rather large, because we pre-cache a lot. If you'd like to build your own, [2] might help with:
DISTRO=centos-minimal DIB_RELEASE=8
---
Thanks,
oh i see you were descirbinbg the standard behavior of our other envs before this is closer to what i was expecting alther i would personally prefer to have /usr/bin/python -> /user/bin/python3 linux distros seem to be a bit split on this i belive arch and maybe debian (i saw on of the other majory disto families adopt the same apparch) link python to python3 the redhat family of operating systems do not provide python any more an leave it to the user to either use only the versions specific pythons or user update-alternitives to set there default python that it now python3. if you dont do that hen every script that has ever been writtne or packaged needs to be updated to reference python3 explictly. there were much fewer user of python1 when that tansition happened but python became a link to the default systme python and eventully pointed to python2 i think we should continue to do that and after a decase of deprecating python2 we should reclaim the python symlink and point it to python3 pip so installing python packages form the disto is the anti pattern not installing form pip. that said we shoudl consider moving devstack to use --user at somepoint. thanks for al the work on this.
-i
[1] https://review.opendev.org/#/c/682797/ [2] https://opendev.org/openstack/project-config/src/branch/master/tools/build-i...
On Tue, Oct 15, 2019, at 5:35 PM, Sean Mooney wrote:
Hello,
I'm happy to say that CentOS 8 images are now live in OpenDev infra. Using a node label of "centos-8" will get you started.
---
The python environment setup on these images is different to our other images. Firstly, some background: currently during image build we go to some effort to:
a) install the latest pip/virtualenv/setuptools b) ensure standard behaviour: /usr/bin/python -> python2
On Wed, 2019-10-16 at 10:03 +1100, Ian Wienand wrote: python on centos8 should be a link to python3 infact ideally python 2 should not be installed at all.
/usr/bin/pip -> python2 install /usr/bin/pip3 -> python3 install /usr/bin/virtualenv -> creates python2 environment by default; python3 virtualenv package in sync
This means a number of things; hosts always have python2,
why would we want this. ideally we should try to ensure that there is non python 2 on the system so that we can ensure we are not using it bay mistake and can do an entirly python3 only install on centos8 ---- later: i realised read later that you are descibing how thigns work on other images here.
See below but being specific about the version of python we want is one way to help ensure we test with the correct python. Also, some of our platforms don't have python3 (so we will continue to install python2 there).
and because we overwrite the system pip/virtualenv/setuptools we put these packages on "hold" (depending on the package manager) so jobs don't re-install them and create (even more of) a mess.
This made sense in the past, when we had versions of pip/setuptools in distributions that couldn't understand syntax in requirements files (and other bugs) and didn't have the current fantastic job inheritance and modularity that Zuul (v3) provides. However, it also introduces a range of problems for various users, and has a high maintenance overhead.
Thus these new images are, by default, python3 only, and have upstream pip and virtualenv packages installed. You will have a default situation:
/usr/bin/python -> not provided /usr/bin/pip -> not provided, use /usr/bin/pip3 or "python3 -m pip" /usr/bin/virtualenv -> create python3 environment; provided by upstream python3-virtualenv package /usr/bin/pyvenv -> not provided (is provided by Ubuntu python3-venv), use /usr/bin/pyvenv-3 or "python3 -m venv".
oh i see you were descirbinbg the standard behavior of our other envs before this is closer to what i was expecting alther i would personally prefer to have /usr/bin/python -> /user/bin/python3
linux distros seem to be a bit split on this i belive arch and maybe debian (i saw on of the other majory disto families adopt the same apparch) link python to python3
the redhat family of operating systems do not provide python any more an leave it to the user to either use only the versions specific pythons or user update-alternitives to set there default python
This is actually one of the recommendations from PEP 394, https://www.python.org/dev/peps/pep-0394/#for-python-runtime-distributors. For our purposes I think it works well. Our jobs should be explicit about which version of python they use so there is no ambiguity in testing, but if jobs want to set up the alias they can opt into doing so. In general though I expect we'll stick to the various distro expectations for each distro as we build images for them. This avoids confusion when people discover `python` is something other than what you get if you download the image from the cloud provider. For this reason I don't think we should alias `python` to `python3` on CentOS8.
Ergo, the "standard behaviour" is not so standard any more.
I would suggest if you wish to write somewhat portable jobs/roles etc., you do the following:
* in general don't rely on "unversioned" calls of tools at all (python/pip/virtualenv) -- they can all mean different things on different platforms. * scripts should always be #!/usr/bin/python3 see i think that is an anti pattern they could be but i think /usr/bin/python should map to /usr/bin/python3 and you should assume that it now python3. if you dont do that hen every script that has ever been writtne or packaged needs to be updated to reference python3 explictly.
Or simply execute it with the interpreter you need: python3 /usr/local/bin/pbr freeze Is a common invocation for me.
* use "python3 -m venv" for virtual environments (if you really need "virtualenv" because of one of the features it provides, use "-m virtualenv") * use "python3 -m pip" to install global pip packages; but try not too -- mixing packages and pip installs never works that well. well from a devstack point of view we almost exclucive install form
there were much fewer user of python1 when that tansition happened but python became a link to the default systme python and eventully pointed to python2 i think we should continue to do that and after a decase of deprecating python2 we should reclaim the python symlink and point it to python3 pip so installing python packages form the disto is the anti pattern not installing form pip. that said we shoudl consider moving devstack to use --user at somepoint.
I actually resurrected the install into virtualenv idea when pip 10 (I think that was the version) happened as it refused to uninstall distutils installed packages. It is mostly doable though there are a few corner cases that kept it from happening.
* if you need python2 for some reason, use a bindep file+role to install it (don't assume it is there) +1 also dont assmue python will be python
---
For any Zuul admins, note that to use python3-only images similar to what we make, you'll need to set "python-path" to python3 in nodepool so that Ansible calls the correct remote binary. Keep an eye on [1] which will automate this for Ansible >=2.8 after things are merged and released.
---
Most of the job setup has been tested (network configs, setting mirrors, adding swap etc.) but there's always a chance of issues with a new platform. Please bring up any issues in #openstack-infra and we'll be sure to get them fixed.
---
If you're interested in the images, they are exported at
https://nb01.openstack.org/images/
although they are rather large, because we pre-cache a lot. If you'd like to build your own, [2] might help with:
DISTRO=centos-minimal DIB_RELEASE=8
---
Thanks, thanks for al the work on this.
-i
[1] https://review.opendev.org/#/c/682797/ [2] https://opendev.org/openstack/project-config/src/branch/master/tools/build-i...
On 2019-10-16 01:35:48 +0100 (+0100), Sean Mooney wrote: [...]
i would personally prefer to have /usr/bin/python -> /user/bin/python3
linux distros seem to be a bit split on this i belive arch and maybe debian (i saw on of the other majory disto families adopt the same apparch) link python to python3 [...]
Debian definitely does not. The current plan for when Debian stops shipping Python 2.7 is that it will have no /usr/bin/python installed. The unversioned /usr/bin/python is and has long been an interpreter for the Python 2 language. Python 3 is a different language, and its interpreter should not by default assume the command name of the Python 2 interpreter. I think Arch Linux made a huge mistake in pretending they were the same thing, and sincerely hope no other distribution does the same.
i think /usr/bin/python should map to /usr/bin/python3 and you should assume that it now python3.
I think that's a disaster waiting to happen.
if you dont do that hen every script that has ever been writtne or packaged needs to be updated to reference python3 explictly.
Yep, that has to happen anyway in most cases to address Python 2 vs 3 language compatibility differences. Being explicit about which language a script is written in is a good thing.
there were much fewer user of python1 when that tansition happened but python became a link to the default systme python and eventully pointed to python2 i think we should continue to do that and after a decase of deprecating python2 we should reclaim the python symlink and point it to python3 [...]
The language did not change in significantly backward-incompatible ways with 2.0. On the other hand "Python 3000" (3.0) was essentially meant as a redesign of the language where backward-incompatibility was a tool to abandon broken paradigms. It's possible to write software which will run under both interpreters (and we have in fact, rather a lot even), but random scripts written for Python 2 without concerns with forward-compatibility usually won't work on a Python 3 interpreter.
well from a devstack point of view we almost exclucive install form pip so installing python packages form the disto is the anti pattern not installing form pip. that said we shoudl consider moving devstack to use --user at somepoint. [...]
It's hard not to call https://review.openstack.org/562884 an anti-pattern. The pip maintainers these days basically don't want to have to continue supporting system-context installs, as responses on https://github.com/pypa/pip/issues/4805 clearly demonstrate. DevStack's been working around that for a year and a half now, as have our image builds (until Ian's efforts to stop doing that for the centos-8 images). Yes doing --user or venv installs is likely the core of the solution for DevStack but it needs more folks actually working to make it happen, and the ugly hack has been in place for so long I have doubts we'll see a major overhaul like that any time soon. -- Jeremy Stanley
On 2019-10-16 01:35:48 +0100 (+0100), Sean Mooney wrote: [...]
i would personally prefer to have /usr/bin/python -> /user/bin/python3
linux distros seem to be a bit split on this i belive arch and maybe debian (i saw on of the other majory disto families adopt the same apparch) link python to python3
[...]
Debian definitely does not. The current plan for when Debian stops shipping Python 2.7 is that it will have no /usr/bin/python installed. The unversioned /usr/bin/python is and has long been an interpreter for the Python 2 language. Python 3 is a different language, and its interpreter should not by default assume the command name of the Python 2 interpreter. I think Arch Linux made a huge mistake in pretending they were the same thing, and sincerely hope no other distribution does the same.
TL;DR ok the way the image will work makes sense :) all i really care about is /usr/bin/python should not be a symlink to /usr/bin/python2 on python3 "only" distors to ensure we dont execute code under python 2 by mistake. On Wed, 2019-10-16 at 02:43 +0000, Jeremy Stanley wrote: perhaps though i would argue that the code name of the python2 interperatr was always python2 or python2.7 no python. python was the name of system python the fact that they happen to be the same thin was a historical acident fo rthe last decade but if i exend your argument then we never should have had #!/usr/bin/python at all as a script entry point which in hindsight may have been correct. https://www.python.org/dev/peps/pep-0394/#for-python-runtime-distributors allow effectivly all of the possible options so there is no wrong answer just different tradeoffs.
i think /usr/bin/python should map to /usr/bin/python3 and you should assume that it now python3.
I think that's a disaster waiting to happen.
perhaps the only thin i hope we really avoid going forward is a python that maps to python2 that silntly allows things to work when we think we are running python 3 only. e.g. i prefer spipts that can run under python3 sliently doing so then over silently running on python2. if on python3 systems distro ensure that python does not map to python2 even when python 2 is installed unless the system admin expcitly sets up the symlink i guess that acive the same goal. it seams that is the path debain an rhel are taking e.g. dont provide "python" via packages so that it is only created if the sytem admin creates it.
if you dont do that hen every script that has ever been writtne or packaged needs to be updated to reference python3 explictly.
Yep, that has to happen anyway in most cases to address Python 2 vs 3 language compatibility differences. Being explicit about which language a script is written in is a good thing.
i guess but it feels kind of sad to say that forever we will have to type python3 in stead of python just because legacy script coudl break. i woudl prefer them to break and have the convinece. the is partly because most python2 i have encounterd has been vaild python3 but i know that that was not the case for alot of scripts.
there were much fewer user of python1 when that tansition happened but python became a link to the default systme python and eventully pointed to python2 i think we should continue to do that and after a decase of deprecating python2 we should reclaim the python symlink and point it to python3
[...]
The language did not change in significantly backward-incompatible ways with 2.0. On the other hand "Python 3000" (3.0) was essentially meant as a redesign of the language where backward-incompatibility was a tool to abandon broken paradigms. It's possible to write software which will run under both interpreters (and we have in fact, rather a lot even), but random scripts written for Python 2 without concerns with forward-compatibility usually won't work on a Python 3 interpreter.
well from a devstack point of view we almost exclucive install form pip so installing python packages form the disto is the anti pattern not installing form pip. that said we shoudl consider moving devstack to use --user at somepoint.
[...]
It's hard not to call https://review.openstack.org/562884 an anti-pattern.
The pip maintainers these days basically don't want to have to continue supporting system-context installs, as responses on https://github.com/pypa/pip/issues/4805 clearly demonstrate. yep i was just trying to suggest that we shoudl avoid installing the disto version and basicaly only install the interpreter form the distro to avoid mixing packages as much as possible. DevStack's been working around that for a year and a half now, as have our image builds (until Ian's efforts to stop doing that for the centos-8 images). Yes doing --user or venv installs is likely the core of the solution for DevStack i do think its worth revisiting devstack venv install capablity at some point i know its there but have never really used it but hte fact that devstack installs but the requirement.txt and test-requriement.txt gloablly has caused issue in
but it needs more folks actually working to make it happen, and the ugly hack has been in place for so long I have doubts we'll see a major overhaul like that any time soon. well the main thing that motivated me to even comment on this thread was the fact we currently have a hack that with lib_from_git where if you enable
i ment when using devstack prefering distro pacagke over pip would be an anti patteren as part of the reason we install form pip in the first place is to normalise the install so that it is contolled and as similar as possible beteen distors. the fact we have to do that in devstack ya does feel like a hack i was not aware we did that. the past. i tried to remove install the test-requirement.txt in the past but some jobs depend on that to install optional packages so we cant. python 3 i will install the lib under python 2 and python3. the problem is the interperter line at the top of the entry point will be replaced with the python2 version due to the order of installs. so if you use libs_form _git with nova or with a lib that provides a setup tools console script entrypoint you can get into a situation where your python 3 only build can end up trying to run "python2" scripts. this has lead to some interesting errors to debug in the past. anyway i was looking forward to having a python3 only disto to not have to deal with that in the future with it looks like
On Wed, 2019-10-16 at 12:05 +0100, Sean Mooney wrote:
but it needs more folks actually working to make it happen, and the ugly hack has been in place for so long I have doubts we'll see a major overhaul like that any time soon. well the main thing that motivated me to even comment on this thread was the fact we currently have a hack that with lib_from_git where if you enable python 3 i will install the lib under python 2 and python3. the problem is the interperter line at the top of the entry point will be replaced with the python2 version due to the order of installs. so if you use libs_form _git with nova or with a lib that provides a setup tools console script entrypoint you can get into a situation where your python 3 only build can end up trying to run "python2" scripts. this has lead to some interesting errors to debug in the past. anyway i was looking forward to having a python3 only disto to not have to deal with that in the future with it looks like
You should probably look at https://review.opendev.org/#/c/687585/ so Stephen
participants (5)
-
Clark Boylan
-
Ian Wienand
-
Jeremy Stanley
-
Sean Mooney
-
Stephen Finucane