The previous commit removes dkms from the base element, which
means the centos elements should no longer have a dependency on
EPEL. Therefore, we should not hardcode the epel dependency. It
can still be included in image builds as desired by using the epel
element explicitly.
Co-Authored-By: Ben Nemec <bnemec@redhat.com>
Change-Id: Iceff0d5bedd9816adfd2990970e7c216b67b6bd0
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
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
I'm not sure why this comment is here. base works with centos-minimal
(we changed it in I2956aaa49ba3137a799f97e0983ab4b7c93a0a0c) and we've
got images deployed with such a configuration.
Update the comment
Change-Id: I3207f87dc29280183c0960ea863533a4d441081c
I guess I hadn't tried centos-minimal without the puppet elements that
install this for us. But the "base" element wants dkms, which is only
in EPEL for centos. But it's a helpful convenience so is globally
useful.
Change-Id: Ia9af97efdbd855fb8202353196ad649093788cb8
The "base" element is included by default, and if centos-minimal tries
to provide it then we die because two elements are providing the same
thing.
Change-Id: I2956aaa49ba3137a799f97e0983ab4b7c93a0a0c
Add an environment variable to control the creation of eth0/1
interface enablement scripts.
With a tool such as glean, the presence of these scripts will indicate
the interface is configured and configuration-drive settings will not
be applied. This means in a non-dhcp situation like on Rackspace,
network is broken.
On Fedora, where later systemd provides "predictable network interface
names" [1] eth0 & eth1 ironically aren't predictable so this just
confuses things. You really need cloud-init or glean or something to
bring up your interfaces in a sane fashion.
This maintains the status-quo on centos-minimal, but disables creation
for fedora-minimal.
[1] http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
Change-Id: I3f1ffeb6de3b1f952292a144efab9554f7f99a5f
Now that we have a generic yum-minimal element, just use it in centos
instead of rinse. Adding base as an element-provides of yum-minimal
because this element conflicts with the base element.
Co-Authored-By: Gregory Haynes <greg@greghaynes.net>
Change-Id: I15275d821781171c118f21aa0c0bca55f65a65b3
Commit 36b59c001c introduces
DIB_DEBUG_TRACE, to be checked in element scripts for enabling tracing.
In the aforementioned conversion, few scripts were left with
unconditional "set -x" calls: remove them, changing the default value
for unset DIB_DEBUG_TRACE from 0 to 1, to retain their older behaviour
(as it was done in 36b59c001c too).
Change-Id: I3d1a9290021bf63de7d4e7752e809852e784ac8b
There is a wide variety of tracing options through the various shell
scripts. Some use "set -eux", others explicity set xtrace and others
do nothing. There is a "-x" option to bin/disk-image-create but it
doesn't flow down to the many scripts it calls.
This adds a global integer variable set by disk-image-create
DIB_DEBUG_TRACE. All scripts have a stanza added to detect this and
turn on tracing. Any other tracing methods are rolled into this. So
the standard header is
---
if [ "${DIB_DEBUG_TRACE:-0}" -gt 0 ]; then
set -x
fi
set -eu
set -o pipefail
---
Multiple -x options can be specified to dib-create-image, which
increases the value of DIB_DEBUG_TRACE. If script authors feel their
script should only trace at higher levels, they should modify the
"-gt" value. If they feel it should trace by default, they can modify
the default value also.
Changes to pachset 16 : scripts which currently trace themselves by
default have retained this behaviour with DIB_DEBUG_TRACE defaulting
to "1". This was done by running [1] on patch set 15. See the thread
beginning at [2]
dib-lint is also updated to look for the variable being matched.
[1] https://gist.github.com/ianw/71bbda9e6acc74ccd0fd
[2] http://lists.openstack.org/pipermail/openstack-dev/2014-November/051575.html
Change-Id: I6c5a962260741dcf6f89da9a33b96372a719b7b0
There are times when a much more stripped down base image is desired
over the distro cloud images. For instance, Infra would like some base
images that do not have cloud-init or really much of anything else. This
is easy to accomplish with debootstrap and rinse.
Change-Id: I44ff22457165afb048fdaea469210ae47d83dd3f
