97c01e48ed
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
61 lines
2.3 KiB
ReStructuredText
61 lines
2.3 KiB
ReStructuredText
===========
|
|
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
|