Commit graph

7 commits

Author SHA1 Message Date
Bob Fournier
14a3776885 Do not include efibootmgr and efivars for ppc architectures
These don't exist and are not needed for ppc.

Change-Id: I9ba53e22583b148b43f74cd9b8ec79402796d09b
2020-02-25 13:27:13 -05:00
Iury Gregory Melo Ferreira
6986441e2c Add efi packages for ironic-agent
On IPA we are using efivar and efibootmgr, we already added the
packages on ipa-builder.
Adding the pacakges on diskimage-builder, so that people who use
it to build the images won't get into trouble.

Change-Id: I9ab6588f20302b4808b09dc060aced5fd267a3d2
2020-02-11 17:26:59 +01:00
Dmitry Tantsur
928c6e61f0 ironic-agent: install mdadm on the ramdisk
The newly introduced software RAID support requires it.

Change-Id: Ic438865006f1472abc0c9f4d40cc40c91b4ada71
2019-06-07 14:05:41 +02:00
Matthew Thode
e1f01d513a
IPA requires iptables
iptables -L is used in log collection

Change-Id: Id7e69a9e9f87db6621b928a2104df4b94f10044e
2018-05-17 11:14:44 -05:00
Tim Flink
f8bcc51b55 Don't install dmidecode on Fedora ppc64le
While Debian-based distros use the label of ppc64el for ppc64 little
endian, Fedora uses ppc64le.

The ironic-agent was doing arch specific package install of lshw over
dmidecode for ppc64 and ppc64el but was attempting to install dmidecode
on Fedora ppc64le which caused the test to fail due to a missing
package.

This change just adds ppc64le to the arch-specific package installation
description for the ironic-agent element.

Change-Id: I38c3c1480bbbb2df817856614e6b740a0c02723a
Closes-Bug: 1744944
2018-01-29 10:53:43 +11:00
Michael Turek
7054a71f7d Remove architecture rules on lshw dependency in ironic-agent
There's a patch in flight in ironic-python-agent to switch the
default hardware manager to use lshw instead of dmidecode. [0]
This would require lshw to be installed regardless of
architecture. This patch removes the architecture rules from
lshw in the package-installs list.

[0] Ie370331df6bb5ef131c5cb60f458877e2a7ad71a

Change-Id: Idaf05b8efce28cd0cbf339cf693db4f55a693d9b
Partial-Bug: #1715790
2017-12-06 17:02:46 -05: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
Renamed from elements/ironic-agent/package-installs.yaml (Browse further)