Commit Graph

9 Commits

Author SHA1 Message Date
Ian Wienand
5bc9e87da1 centos: avoid head pipe failure
I just saw in the trace output of a failure

  > grep -o 'CentOS-.[^>]*GenericCloud-.[^>]*.qcow2'
  > sort -r
  > head -1
  sort: fflush failed: 'standard output': Broken pipe
  sort: write error

i.e. the "head -1" has exited after reading one line, but "sort -r"
still wants to write and thus has hit a pipe failure, and because we
run with "-o pipefail" this has halted the script.

This seems like it has been there more or less forever, maybe we just
got lucky hitting it now?  Anyway, we can work around this by using a
process substitution and passing the output of this into head, this
way we won't hit a pipe failure.

I also updated the fedora path as it does the same thing.

Change-Id: I44d97e5bb31702aacf396e0229329a2ef9c64f2f
2022-04-26 17:28:00 +10:00
Steve Baker
9a7c107741 Use https for base centos image download
Change-Id: I85879ad784995405a1fa9fe8178e1b1d53d9e41a
2022-01-14 10:00:15 +13:00
Sagi Shnaidman
d5a01519c6 Update centos element for 9-stream
This adds 9-stream support to the centos element.

See https://review.opendev.org/q/topic:cs9 for related patches.

Change-Id: Ib80fbd21edb77c25764eff2c0d66e55bde7a90af
2021-10-20 09:39:27 +11:00
Maksim Malchuk
ca83a4c3cb Don't use hardcode while override base image file
The trvial fix allow override to work in air-gapped envirments where
the command 'curl -s https://cloud.centos.org/...' would fail.

Change-Id: I84296d8816042e4cd4cb02f15746b86d600d13d6
Signed-off-by: Maksim Malchuk <maksim.malchuk@gmail.com>
2021-03-04 10:54:32 +00:00
Carlos Goncalves
e4b6a2faef Add support for CentOS 8 Stream cloud image
This patch adds support for CentOS 8 Stream [1] to the centos element
(cloud image). Users should set DIB_RELEASE=8-stream.

[1] https://www.centos.org/stream/

Change-Id: Ib8f542031c46326ffed812fa60cbc9e56db9d6fd
2020-08-10 11:33:38 +02:00
Carlos Goncalves
1f9619cdb5 Download latest CentOS cloud image
DIB was retrieving the oldest cloud image file which, presently, means
retrieving CentOS 8.1 instead of CentOS 8.2. Even though DIB runs a
system update and so catches up to latest, this takes bandwidth, time
and final image space (8.1 + system update = 765M qcow2, vs 8.2 + system
update = 518M qcow2).

This patch fixes that by taking the first image name in a descending
order list.

Change-Id: I648fe19f1f76c03c97492b6ac7be6381f6f9261b
2020-06-22 11:03:36 +02:00
Carlos Goncalves
8226384cf0 Add CentOS 8 support
* Add "centos" element, a CentOS version-independent element. This is in
  line with the same work done for RHEL in Stein cycle.
* Deprecate the centos7 element. CentOS 7 support itself it not
  deprecated though. The new "centos" element provides the same support
  level as the "centos7" element.
* Add functional testing

The default CentOS version is 8. You can adjust it using the DIB_RELEASE
environment variable.

Change-Id: I373ba2296c4613765676e59aabd9c651345298d1
2020-02-19 10:44:56 +01:00
Ian Wienand
a00d02f6a1 Remove centos and rhel elements
Several people have popped up in IRC recently with failures in these
elements.  Without Python 2.7 available in the image they are
unsupported (OpenStack hasn't supported it for a long time).  Remove
these to avoid further confusion.

The centos/centos7 DISTRO split that has happened with centos-minimal
is unfortunate but I don't think it helps to rename centos7/rhel7 ATM.
To summarise; DISTRO=centos7 means image based build,
DISTRO=centos && DIB_RELEASE=7 means the minimal build.

In the future, I think it is important that the minimal builds and
image builds set the same DISTRO.  This reflects that "upper" layers
shouldn't care about the exact building of the lower layers.  I see
CentOS 8 going one of two ways

1) the changes are so significant, we start separate centos8 /
centos8-minimal elements.  They both set DISTRO=centos8 (and
DIB_RELEASE to point-release maybe?).  This means we have to update
all "if DISTRO == centos || DISTRO == centos7" branches to also check
for "centos8".  Evenually (!)  "centos" goes away for versioned DISTRO
only

2) we restore centos element with DISTRO=centos and DIB_RELEASE=8, and
centos-minimal remains the same.  This means we have to audit all "if
DISTRO == centos" calls to make sure they're appropriate for version 8
(stick a "&& DIB_RELEASE=7" on them all basically).

I'm not sure we can fully decide until we start to see excatly how the
distro switching/matching bits look, but (2) is consistent with Ubuntu
and probably the preferred solution.

Some "rhel" parts have been cleaned up.  More could be done in
rhel-common, but given our lack of coverage of that I'd prefer to
leave it for now.

Change-Id: I6ea784116ef59ca22878c8512c963f29c815a00a
2017-06-28 12:26:24 +10:00
Ian Wienand
97c01e48ed Move elements & lib relative to diskimage_builder package
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
2016-11-01 17:27:41 -07:00