tripleoci: excludes in yum/dnf conf images can break testing beds
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
tripleo |
Fix Released
|
High
|
Sorin Sbarnea |
Bug Description
It seems that the prepared images used on rdo or openstack-upstream can have some package excludes added to them, excludes that would invalidate our testing code because we would run with adulterated systems instead of clean ones.
While I do understand that we may need to pre-configure some stuff (like a mirror/proxy, DNS, NTP...), I do not think that any yum/dnf package excludes should *not* be part of this in any case.
One such example was found at: https:/
msg: 'Failed to find required executable virtualenv in paths: /usr/local/
Imagine that ansible pip module failed with this error, when previous task succeeded installing `python3-
After some digging, I was able to figure out what seems to be the cause (yumlog):
DEBUG Excludes in dnf.conf: python2-pip, python2-setuptools, python2-virtualenv, python3-pip, python3-setuptools, python3-virtualenv
This means that if packages are listed as excludes, ansible package module will return SUCCESS even if it does not install them.... Clearly there is little joy in this and I am not sure if this counts as a feature or bug of ansible or yum/dnf.
Changed in tripleo: | |
importance: | Undecided → High |
Changed in tripleo: | |
assignee: | nobody → Sorin Sbarnea (ssbarnea) |
milestone: | none → stein-rc1 |
tags: | added: ci quickstart |
Changed in tripleo: | |
status: | New → Triaged |
tags: |
added: alert removed: quickstart |
Changed in tripleo: | |
status: | Triaged → Fix Released |
In infra images, this is coming from [1].
The whole history of that is long; and there's many comments in there about what's going on. The crux is that due to many setuptools/pip bugs over time, we *need* the latest versions (to be able to even deal with requirements files, but many other little bugs have crept in too). However, on centos7 era, pip and system packages do not live nicely together. That's why we install the packages, *then* overwrite with latest versions from pip, *then* put the packages on hold to stop them being removed+ re-installed again, which overwrites the upstream versions and creates a big mess (yes ... this happens :)
Two things -- Fedora now does a better job of keeping pip installs and rpm installs separate (as debuntu has always done). I would welcome someone really digging into this to understand what we can do. Also, pabelanger was mentioning that there might be better ways to put the packages on hold with dnf, such that they don't appear as completely missing. If someone has ideas on that, it's welcome too.
[1] http:// git.openstack. org/cgit/ openstack/ diskimage- builder/ tree/diskimage_ builder/ elements/ pip-and- virtualenv/ install. d/pip-and- virtualenv- source- install/ 04-install- pip#n188