5b5b78bf59
The linux kernel and NetworkManager fight each other over control for interface management when router advertisements are in use. Long story short if the linux kernel configures a network interface for ipv6 before NetworkManager attempts to manage that interface then NM will ignore the interface and not configure ipv4 on it. This can happen because the kernel is configured to send router advertisements solicitations which result in router advertisements which the kernel uses to configure the interface(s). There is a default of a 1 second delay before sending the solicitation which in many cases is long enough that NM has started before then. However, in slower environments like those used for testing with qemu this isn't long enough. Some testing by hand indicates that 15 seconds is about right so increase the delay to 15 seconds via sysctl.conf. Note this may increase boot times in ipv6 only environments (though it is hard to be sure due to how systemd starts everything at once and does socket activation and the like). Change-Id: I475a253091cbaf63687b91c748c31a6753bb0f57 |
||
---|---|---|
.. | ||
environment.d | ||
install.d | ||
post-install.d | ||
element-deps | ||
package-installs.yaml | ||
pkg-map | ||
README.rst | ||
source-repository-simple-init |
=========== 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://opendev.org/opendev/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 NetworkManager -------------- 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.