This element does some funky stuff WRT python2 vs python3 so lets get
some multi-distro testing in place.
Change-Id: I1e3c3bfa0a109419d4cbee7fa32a18392b7e1a93
Tripleo-image-elements have an install.d file '05-heat-cfntools' that runs
the following command:
virtualenv --setuptools $VENV
With the recent change to diskimage-builder (moving the install of pip
and virtualenv to the 10- range) virtualenv is no longer available for
this elementr; as a side-effect, the trove kick-start command is now
broken and gate jobs are failing.
The solutions is to move the (now) 10-install-pip to 04-install-pip.
This should still alleviate the race condition that
https://review.openstack.org/#/c/408277/ attempted to fix, as all
*-package-installs files are 00-, 01- or 02-.
Change-Id: Ia4e01f00c4c5e9a2087df1e2a91d9154480a0422
Closes-Bug: #1650008
We are explicitly calling python in this element which does not work on
systems which only have python3.
Change-Id: Ia730850a48e2478fd5461710a9d2619408725cd8
We currently have this as a 01- script which causes it to race with
package-installs (the deps are installed after the script runs).
Change-Id: I7b04b4c186eaae783b8e2bda1aa724c0d7823eab
SUSE packages the 'xml' python module as a separate package so make
sure it's pulled in before we attempt to install the pip module
since the latter depends on it. Fixes the following problem when
building with the opensuse-minimal and pip-and-virtualenv elements:
Traceback (most recent call last):
File "/tmp/get-pip.py", line 19177, in <module>
main()
File "/tmp/get-pip.py", line 194, in main
bootstrap(tmpdir=tmpdir)
File "/tmp/get-pip.py", line 82, in bootstrap
import pip
File "/tmp/tmpOiESjX/pip.zip/pip/__init__.py", line 16, in <module>
File "/tmp/tmpOiESjX/pip.zip/pip/vcs/subversion.py", line 9, in <module>
File "/tmp/tmpOiESjX/pip.zip/pip/index.py", line 32, in <module>
File "/tmp/tmpOiESjX/pip.zip/pip/_vendor/html5lib/__init__.py", line 16, in <module>
File "/tmp/tmpOiESjX/pip.zip/pip/_vendor/html5lib/html5parser.py", line 6, in <module>
File "/tmp/tmpOiESjX/pip.zip/pip/_vendor/html5lib/inputstream.py", line 10, in <module>
File "/tmp/tmpOiESjX/pip.zip/pip/_vendor/html5lib/utils.py", line 10, in <module>
ImportError: No module named xml.etree.ElementTree
Change-Id: I1bec12dfcde05fb07f41bcec994148c3eacbb287
Currently we have all our elements and library files in a top-level
directory and install them into
<root>/share/diskimage-builder/[elements|lib] (where root is either /
or the root of a virtualenv).
The problem with this is that editable/development installs (pip -e)
do *not* install data_files. Thus we have no canonical location to
look for elements -- leading to the various odd things we do such as a
whole bunch of guessing at the top of disk-image-create and having a
special test-loader in tests/test_elements.py so we can run python
unit tests on those elements that have it.
data_files is really the wrong thing to use for what are essentially
assets of the program. data_files install works well for things like
config-files, init.d files or dropping documentation files.
By moving the elements under the diskimage_builder package, we always
know where they are relative to where we import from. In fact,
pkg_resources has an api for this which we wrap in the new
diskimage_builder/paths.py helper [1].
We use this helper to find the correct path in the couple of places we
need to find the base-elements dir, and for the paths to import the
library shell functions.
Elements such as svc-map and pkg-map include python unit-tests, which
we do not need tests/test_elements.py to special-case load any more.
They just get found automatically by the normal subunit loader.
I have a follow-on change (I69ca3d26fede0506a6353c077c69f735c8d84d28)
to move disk-image-create to a regular python entry-point.
Unfortunately, this has to move to work with setuptools. You'd think
a symlink under diskimage_builder/[elements|lib] would work, but it
doesn't.
[1] this API handles stuff like getting files out of .zip archive
modules, which we don't do. Essentially for us it's returning
__file__.
Change-Id: I5e3e3c97f385b1a4ff2031a161a55b231895df5b
This reverts commit a645fa4ffb.
It is really devstack causing problems here; it was removing the
python-virtualenv package & re-installing using pip (see depends-on).
This failed because the pip-install we did here removed the egg-file
that rpm expected to be there, so rpm bailed out on the removal.
But even if it worked, this just leads you back down the path of the
original problem; that the system packaged version can be re-installed
and overwrites the pip installed version. Thus I still believe this
is the correct thing to do in the dib element.
Note it is not a common problem (devstack aside); most jobs don't
touch python-virtualenv & related packages (the one we did notice this
on was being brought over from travisci where it was required for some
reason).
Change-Id: I82acb865378a0fa5903a6267bfcee0e2962eced0
Depends-On: Ib0edf6c4ee8a510e9d671213de35d787f56acfed
Other fedora/centos elements can use the YUM variable, already set in
some base elements (fedora, centos-minimal). This commit also exports it
for centos/centos7.
Set a fallback value in pip-and-virtualenv element.
Change-Id: I681d77b924be035c81043bb34c72ec5f859e7108
Closes-Bug: 1598087
If we're installing pip/virtualenv from source, we need to make sure
we pre-install the packaged versions before the upstream
versions. Otherwise, CI jobs later on that depend on packaged versions
of pip/virtualenv can bring them in and overwrite the upstream
versions we have installed, which leads to a heck of a mess and
usually very confusing failures.
I have also moved in a small hack from system-config:install_puppet.sh
that we found was necessary when using pip versions from upstream.
Note this is not as much of an issue on Debian/Ubuntu, as they keep
their pip packages in a separate place to the system packages, so you
don't have these overwite conflicts as much.
Change-Id: Ib40708c07b939b84661c44df88a5a308fd0c7216
Add a pkg-map file so that Gentoo can avoid polluting the FS with
files not tracked in the package manager.
Changed the directory name so that the source-install method would
actually be disabled when DIB_INSTALLTYPE_pip_and_virtualenv=package
is set. Also changed source-repository line to be consistent with
the element name.
Change-Id: I5225bd7113ff2588c755ad4cd4ae9a2d78fff196
This element allows installation of pip and virtualenv from either
distro packages or git.
Change-Id: Id294f0936c8fef8a3b27a415bfcc93b3f327e104
Depends-On: I731cc8a0f5bfeda8f17a78c33b9f44062323a361
