aee4fc0d35
This is a follow-on to I475a253091cbaf63687b91c748c31a6753bb0f57 as we are still seeing issues on some clouds with unconfigured networking. We increase the timeout, but also make it configurable so we can fiddle it without a dib release in the gate. To follow-on from the experimentation done by clarkb, I can confirm by emperical testing on a Centos 7 image (from today, today being this change's date) that setting net.ipv6.conf.all.autoconf=0 by itself is "fatal" and the interfaces do not come up; i.e. nm does not by default seem to re-enable ipv6 for the interface. However, explicitly adding: IPV6INIT=yes IPV6_AUTOCONF=yes to the interface file *does* seem to make it work, even if "all.autoconf=0" is set (then again, there's also bugs about the effect of this [1]). However, no extant distribution (I can currently find) does anything like this by default. If this continues, this may be an option. Another might be to avoid the use of the nm-settings-ifcfg-rh profiles and move directly to nm ini files with glean. [1] https://bugzilla.kernel.org/show_bug.cgi?id=11655 Change-Id: I869ebffc8cde3bbff573f6583fd9dd02a5598590 |
||
|---|---|---|
| .. | ||
| environment.d | ||
| install.d | ||
| post-install.d | ||
| README.rst | ||
| element-deps | ||
| package-installs.yaml | ||
| pkg-map | ||
| source-repository-simple-init | ||
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_refFor example to test glean change 364516 do:
git clone https://opendev.org/opendev/glean /tmp/glean
cd /tmp/glean
git review -d 364516
git checkout -b my-test-refThen 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-refNetworkManager
By default, this uses the "legacy" scripts on each platform. To use
NetworkManager instead, set DIB_SIMPLE_INIT_NETWORKMANAGER
to non-zero. See the glean documentation for what the implications for
this are on each platform.
This is currently only implemented for CentOS and Fedora platforms.