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
The centos cloud images are both arround a GB in size, and
downloading them causes lot of CI timeouts, downloading the
compressed version saves 700MB of bandwith and should save
a lot of time.
Change-Id: I8dcd1db81fe5c4661945638ef3e6344fdf651243
The ability to specify a distro mirror is part of other
distro elements, centos should have one too.
Change-Id: I4cc9062ff92fbe301f414820798e08c66e9793f7
This exact repository along with others are part of the
centos cloud image. From the looks of it this was required for
a very early cloud image.
Change-Id: Ib928e4ea739bc48f196f81c96ed4fba3177471f0
The default value was set in the centos7 element, but not
exported, which caused issues in rpm-distro. Also changed
a test in rpm-distro to only check for DIB_RELEASE > 22
if it's fedora.
Closes-Bug: #1477172
Change-Id: Ib6f4227411c2e8f1965c3b78bc318512c59a7876
We should make use of the CentOS-7-x86_64-GenericCloud.qcow2 symlink from
http://cloud.centos.org/centos/7/images/ instead of having a hard coded cloud
image. Specific cloud images can still be downloaded by overriding
$DIB_RELEASE.
More importantly, using the symlink will keep us automatically up to date with
the latest CentOS 7 cloud image. The image in use by the hard coded value
occassionally exhibits "No space left on device" errors after the cloud-init
filesystem resize. More info about this issue is at:
http://xfs.org/index.php/XFS_FAQ#Q:_Why_do_I_receive_No_space_left_on_device_after_xfs_growfs.3F
The newer cloud image (with a newer kernel) does not exhibit this issue.
Change-Id: I3e19f6269ceba937fcd630bab265d132bd525519
Instead of manually creating epel.repo files, make use of the epel
element, which will properly install epel-release.
Change-Id: Iea7b389bc1ade716c622fd39d5e7dcf119dcb447
rhel7 and centos7 images are both only available on x86_64 arch.
if $ARCH is misconfigured, some strange error will happen during the build.
For example, DIB will try to install EPEL i386 on the 64bit root system.
For the record, tripleo-incubator $NODE_ARCH default value is i386. The
problem will happend as soon as the default value is used with one of
these root elements.
This commit ensure the $ARCH is set to amd64 as soon as the centos7 or
rhel7 root element are used.
Change-Id: Ie41fa2da48eac6bf89b96cfa137c0f572dae6734
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
This is the final released image; it is the same one deployed in many
cloud provers such as HP and AWS. It is also safe from all known
vulnerabilities up to its release
Change-Id: Ib8ba561662d2a98da55eb292b850dc019226dd59
Each distro had its own copy of the file, but they were all the
same and it's actually installed in redhat-common so it belongs
there.
Change-Id: Iad15f39fd28d1c4e20d30dcb2eb0ae6f2fa2b015
The centos7 images come with the base version of cloud-init already
installed.
---
$ virt-inspector CentOS-7-x86_64-GenericCloud-GA-7.0.1406_01.qcow2
...
<application>
<name>cloud-init</name>
<version>0.7.5</version>
<release>10.el7.centos.1</release>
<arch>x86_64</arch>
</application>
...
---
I think this is a hang-over from early rhel7 images that didn't have
it.
Change-Id: Idf488942222d9e6bca4d66f04f5af42e6707944d
Update to newer Centos7 images as announced at [1].
Changes included:
* update to GA image
* respect TMP_DIR for image working directory
* use suffix-match rather than prefix-match to build RAW_IMAGE name
to be more robust against weird names
* partition layout work-arounds not needed any-more, all one
partition.
Resulting image booted locally with kvm and virtualbox (after
conversion to vdi)
[1] https://www.redhat.com/archives/rdo-list/2014-August/msg00045.html
Closes-Bug: #1363146
Change-Id: Ie24033468b78587ea87188ee1b843b26895798ff
Due to changes in centos7 element to use package-installs the order
of yum-repos in pre-install.d needs to be changed, to make yum repos
available before package-installs is called to install packages.
Change-Id: I47b584506465d90247f30bad515a32323e52180e
Initial support for a centos7 image.
This is separate to rhel7 because the major differences are things
like repo and image locations, which are always going to be different.
We should merge any real changes into the redhat-common layers.
Apart from the added support files in centos7/*, the other change is
mostly modifications to redhat-common's extract-image to handle
different partition layouts of the centos7 image.
Change-Id: I943abe5ff0a803f36eda266a79af0d9220edcae7
