Commit graph

5 commits

Author SHA1 Message Date
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
vmud213
45628993e8 Do not remove sudo in ironic-agent
"ironic-agent" element is currently removing sudo, which breaks other
elements such as devuser.  There appears to be no security or other
reason to do this, it's just the way it has always been.  Leave sudo
in as it is considered part of the base cloud images.

Change-Id: Ida9b1885f745146071e4b2d85ae59341ac85d5c8
Closes-Bug: #1572486
2016-05-16 10:39:04 +10:00
Ian Wienand
b960614c9c Don't remove python3 & grubby in 99-remove-extra-packages
python3 is a hard requirement of dnf so can't be removed [1]

grubby is also required for kernel installs on Fedora.  For too much
detail see I1a6e45d04755515286b3d49f8280c16b527e2f48; but the kernel,
via dracut, now has this as a "recommends" due to people removing it
and making unbootable systems.

[1] http://logs.openstack.org/76/248976/2/check/gate-dib-dsvm-functests-devstack-f21/734c8bd/console.html

Change-Id: I5867ecd57834eece9477aa9ea4b8bdd70e238084
2016-02-16 13:40:01 +11:00
Ian Wienand
cb0e0e903d Use dnf to cleanup old kernels
As described in the comment, there is a dnf equivalent of this command
that doesn't require us installing yum-utils (which drags in yum on
dnf-only systems such as f23)

This is a small consequence to this -- due to us not installing
yum-utils some installs will now be completely yum free.  This causes
a breakage in ironic-agent 99-remove-extra-packages where we remove
the yum package.  There is a long-standing bug/feature where missing
packages in a group of packages do not cause yum/dnf to exit with
failure, but uninstalling a single package will.  Because we have made
the systems yum-free, the uninstall of yum can fail in this corner
case.

It has always been like this, so I'm in favour of the "ain't broke"
approach.  To work-around this, I have just put yum into the existing
list of packages to be cleaned up.  I have added a note to the yum
installer taking note of this behaviour for future reference.

Change-Id: I8bbdc07ccdb89a105b4fc70d5a215077c42fcd03
2016-02-08 14:20:56 +11:00
Lucas Alvares Gomes
1181fb8543 Reduce the size of the ironic-agent ramdisk
This patch is reducing the size of the ramdisk image generated by the
ironic-agent element. It does remove extra packages (graphical stuff,
dev stuff, miscs, docs, etc...) and purges directories that are not
needed for a ramdisk (like /boot since it boots using an external
kernel)

Currently it was tested generating a Fedora 22 image and reduced the
size of the final image from 464 MB to 211MB compacted (54% decrease).

I was able to boot a VM with 1.3 GiB of ram instead of the previous 3 GiB
needed.

Change-Id: Id6333ca5d99716ccad75ea1964896acf371fa72a
2015-08-06 16:34:30 +01:00