Per the bug report, %I results in -'s in the interface name being
replaced with /'s, which means when we try to look up the interface
by path in dhcp-all-interfaces.sh we end up at an invalid path.
Using %i instead should fix the problem.
See https://www.freedesktop.org/software/systemd/man/systemd.unit.html
Essentially what is happening is that we start with a name like
br-ex that wasn't escaped in the first place. However, because of
the - it looks like it could have been escaped to systemd. When
we use %I, which tries to unescape escaped values, it unescapes a
value that was already not escaped.
Change-Id: I434ed2e084d4477dc7a2b7827164586f8ea0c1e3
Closes-Bug: 1649409
As described in the bug, there are conditions with certain switches
in which the interface is 'admin down'ed during initialization.
Doing a 'cat' on /sys/class/net/<interface>/carrier when it is
'admin down'ed produces an 'Invalid Argument' error and the script
terminates. What this fix does is ignore failures of the 'cat'
operation (by '|| echo 0') and place the link up inside the retry
loop.
Change-Id: I4f098aa5078b8482681394a3e9a6b17ed4bd4451
Closes-Bug: 1654046
Xenial's bind of /dev into the chroot includes /dev/shm which is in
use by the host. An alternitive fix for this would be to use rbind
to recursivly bind mount /dev instead of just the base bind of /dev
Change-Id: I2c0f70afd1e82dd52a522f0dd2b3ea618b30b6c6
As noted in the bug, there may be circumstances where a longer
timeout than the current default is needed. This patch allows users
to tune this timeout for their environment if need be.
Change-Id: I173f3dad684894fbc3c27dece5ae15b5f63bae5a
Closes-Bug: 1654027
When we configure dhcp interfaces before network.target has run,
network.target will try to bring up those interfaces a second time
after our service does so. This causes two issues - first, the
network target will always fail because it can't bring up an
interface that is already up, and second, when configuring interfaces
that don't actually have an available DHCP server it will result in
a five minute delay waiting for DHCP on those interfaces. This will
also cause the network target to fail and is an unnecessary delay.
By moving the dhcp-interface service to run after the network
target we avoid both of these problems. network.target will still
bring up the interfaces on subsequent boots. This could result in
the five minute delay happening on reboots, but the expected use
case for interfaces without DHCP is that they would be configured
statically on initial deployment so this should be a minor issue.
The dhcp-interface service is also configured to run before the
network-online target so that services which depend on the network
actually being available will not race the DHCP process.
A snippet from /var/log/messages on a node with this patch applied
is included in the bug to demonstrate the behavior described above.
Change-Id: I5cfabf20f920beea52abf4c42362b6f6ac0b37c4
Closes-Bug: 1653812
The components documentation was previously referring to the
ramdisk image for deployment, which was previously deprecated.
Corrected to point to the ironic-agent element.
Change-Id: I770460041eb13523896aaadb7705bdc3db1a54ca
We landed the fix for this in
Icdb769541eee9793f261b4b8ec563be76ee13fe2.
This reverts commit 2978ff885b.
Change-Id: Iecfc41ab2aad57bc4f6f86a13810b534d19a8fd5
debian ships a modified site.py which has some interesting behavior when
VIRTUAL_ENV is set. In this case it will add
/usr/lib/pythonx.x/site-packages to the start of sys.path. This causes
pip to install packages to this location (rather than /usr/local). As a
result, later on when booting where VIRTUAL_ENV is not set this branch
is not hit and the path where python packages were installed is not part
of sys.path.
Change-Id: Icdb769541eee9793f261b4b8ec563be76ee13fe2
When using up to date distributions for dib development, pep8
installs using python3. This patch fixes the problem, that
not the complete dib-lint (which is called) is compatible
with python3.
Change-Id: I417d03746edb4d34011b997edf8b5b9662ea6f09
Signed-off-by: Andreas Florath <andreas@florath.net>
There are issues with pip packages and a python3 only Xenial systems.
This is occuring after Ie609de51cc5fcde701296c9474e315981d9778a2.
We believe the issue is with VIRTUAL_ENV being set within the chroot
and messing up pip installs
(Icdb769541eee9793f261b4b8ec563be76ee13fe2) but a full solution is not
yet clear.
For now, set Xenial to ensure we use python2. Install the package for
the ubuntu element (75-debian-minimal-baseinstall will install python2
for the minimal elements).
Change-Id: Id403919b0af93b375a900186c01a0d3a3bdfafea
Because we run this image in openstack-infra, we want to increase our
test coverage to help avoid potential breaks to our CI systems.
Change-Id: I26405e3f7465654075278ec35b5e0da1338bb45e
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Since we still run these 3 version of ubuntu-minimal elements in
openstack-infra, also run functional testing for them.
Trusty and xenial will be in voting gate, precise added as skipped for
non-voting.
Add the default skip/run status to the "-l" output just to confirm
this too.
Change-Id: Icfbfd0cb7d9acae824972474b77e2fe0486c4f69
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Every run we are doing a full tar.gz of the chroot environment that
never gets used.
It's not suitable for CI since we use fresh images each time there.
The cache in general isn't really isn't a very safe thing to have
around, because there's no invalidation procedure and no real way to
make one -- we've no guarantee that a new chroot build even moments
after a previous one wouldn't bring in or different packages, etc (of
course this is *unlikely*, but the longer you go between builds the
worse the problem becomes. Also, tons of packages get installed after
this not from any cache, so potential speed-up is rather marginal.
Debian turned this off with I58fc485aacacaa17243bf9ce760ed91256d1f182.
However, given the reasons above and it's complete lack of testing, I
don't see this as useful.
If we really want this type of thing, I think we should come up with a
way to use a persistent external yum/dnf cache that yum/dnf keeps in
sync with it's usual invalidation rules.
Change-Id: I66789c35db75c41bc45ea1ad2e26f87456de4e4d
Set the grub timeout to 5 seconds by default, and add notes on how to
update this. This will stop infra having to carry an element that
goes and rewrites the grub configuration.
Change-Id: I556b3f48eff1b67ee8c4b9b64f749af95100fb99
Our setuptools action classifiers are woefully out of date, notably: we
are no longer alpha and we support python3.
Change-Id: I2425152129406e22073936275761bd5d850903fb
The squashfs format brings a couple of advantages over the other
formats. Image is often an order of magnitude smaller and it can
be used natively, either as an initrd, either with loop mount.
Change-Id: If72940b0c4dafb2504c52dd0429a8eb3f8305751
We now support tgz (tar.gz) as an output format.
Change-Id: Iadec92f2f96c3f904f28bd49f87ffc7d48ef7bd7
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
dracut has a "hostonly" mode where it builds an initramfs that is
suitable for booting the system it is building on. This is on by
default, but obviously in our nested multi-platform chroot situation
this is fraught with danger.
As highlighted by [1] our builds were inadvertently turning off
"hostonly" mode when the mountpoints in the chroot were not found.
The CentOS 7.3 behaviour change broke this and we ended up with an
initramfs with no file-system modules.
Iaf2a1e8470f642bfaaaad3f9b7f26cfc8cc445c9 introduced a regeneration of
the initramfs, which I think does work as described because it runs in
the loopback device.
However, dracut includes a package that installs configuration
overrides to build a generic initramfs. This is really what we want,
and should solve the problem no matter where the initramfs is created.
Add this package into yum-minimal and remove the extra re-create call
which should not be necessary.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1405238
Change-Id: I5d203f2abe743cb23a44d449850e692a948e7871
