openstack/diskimage-builder

History

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
..
environment.d	Move elements & lib relative to diskimage_builder package	2016-11-01 17:27:41 -07:00
install.d	Move elements & lib relative to diskimage_builder package	2016-11-01 17:27:41 -07:00
element-deps	Move elements & lib relative to diskimage_builder package	2016-11-01 17:27:41 -07:00
package-installs.yaml	Move elements & lib relative to diskimage_builder package	2016-11-01 17:27:41 -07:00
pkg-map	Move elements & lib relative to diskimage_builder package	2016-11-01 17:27:41 -07:00
README.rst	Move elements & lib relative to diskimage_builder package	2016-11-01 17:27:41 -07:00
source-repository-simple-init	Move elements & lib relative to diskimage_builder package	2016-11-01 17:27:41 -07:00

README.rst

simple-init

Basic network and system configuration that can't be done until boot

Unfortunately, as much as we'd like to bake it in to an image, we can't know in advance how many network devices will be present, nor if DHCP is present in the host cloud. Additionally, in environments where cloud-init is not used, there are a couple of small things, like mounting config-drive and pulling ssh keys from it, that need to be done at boot time.

Autodetect network interfaces during boot and configure them

The rationale for this is that we are likely to require multiple network interfaces for use cases such as baremetal and there is no way to know ahead of time which one is which, so we will simply run a DHCP client on all interfaces with real MAC addresses (except lo) that are visible on the first boot.

The script /usr/local/sbin/simple-init.sh will be called early in each boot and will scan available network interfaces and ensure they are configured properly before networking services are started.

Processing startup information from config-drive

On most systems, the DHCP approach desribed above is fine. But in some clouds, such as Rackspace Public cloud, there is no DHCP. Instead, there is static network config via config-drive. simple-init will happily call glean which will do nothing if static network information is not there.

Finally, glean will handle ssh-keypair-injection from config drive if cloud-init is not installed.

Chosing glean installation source

By default glean is installed using pip using the latest release on pypi. It is also possible to install glean from a specified git repository location. This is useful for debugging and testing new glean changes for example. To do this you need to set these variables:

DIB_INSTALLTYPE_simple_init=repo
DIB_REPOLOCATION_glean=/path/to/glean/repo
DIB_REPOREF_glean=name_of_git_ref

For example to test glean change 364516 do:

git clone https://git.openstack.org/openstack-infra/glean /tmp/glean
cd /tmp/glean
git review -d 364516
git checkout -b my-test-ref

Then set your DIB env vars like this before running DIB:

DIB_INSTALLTYPE_simple_init=repo
DIB_REPOLOCATION_glean=/tmp/glean
DIB_REPOREF_glean=my-test-ref