8f9b156acc
On Fedora 29+, the network.service scripts have been moved into a separate deprecated package. NetworkManager is the supported interface for configuring networks. We have ignored NM for a long time, but we are now running out of options. Luckily we can support this fairly easily with the ifcfg-rh disto plugin that NM provides. Using this, the existing /etc/sysconfig/network-scripts files are used by NM. The only slight difference to the config files is that we need to tell NM it's ok to use it by removing NM_CONTROLLED=no. We also need to update the .service file which needs to call glean with the flag to enable NM, and doesn't need to call ifup. We have found that local-fs.target seems to be the best place to run this so it's nice and early. This is plumbed through from simple-init in DIB (I4d76e88ce25e5675fd5ef48924acd09915a62a4b) which will call glean-install with the new --use-nm flag if DIB_SIMPLE_INIT_NETWORKMANAGER is set. Since all Centos and Feodora are using NetworkManager by default, there is an argument that we should just switch to this and not bother with a flag. However, since NM brings in new libraries and possibly other changes to the base system, it's very possible we will either want to revert the change temporarily or perhaps even run parallel with and without. In these cases we can simply flip the variable in DIB and rebuild rather than having to revert code and do new glean releases. Longer term (say, around time we bring up CentOS 8), I see this becoming the default. Other platforms have distro plugins for NM to read their "legacy" configuration files too in the same way as here. This is left as future work. NetworkManager enabled build and boot for Centos and Fedora is tested in I640838c68a05f3b22683c1e90279725a77678526 Change-Id: I3d379d35e7b000f32c3f6cc197c8aaafebc683fb
126 lines
4.6 KiB
ReStructuredText
126 lines
4.6 KiB
ReStructuredText
=====
|
|
glean
|
|
=====
|
|
|
|
Glean is a program intended to configure a system based on
|
|
configuration provided in a `configuration drive
|
|
<http://docs.openstack.org/user-guide/cli_config_drive.html>`__.
|
|
|
|
Why would you want glean?
|
|
-------------------------
|
|
|
|
Different cloud providers have different ways of providing networking
|
|
and other configuration to guest virtual-machines. Many use DHCP but
|
|
others, notably Rackspace, use configuration provided via a
|
|
configuration drive.
|
|
|
|
What does glean do?
|
|
-------------------
|
|
|
|
Broadly, glean checks for configuration drive based information and,
|
|
if found, uses that to configure the network. If config-drive is not
|
|
found, it falls back to configuring any available interfaces with
|
|
DHCP.
|
|
|
|
Specifically, it will mount the special block-device with label
|
|
`config-2` and parse the `network_info.json` and `vendor_info.json`
|
|
files within. If appropriate network configuration is found, it will
|
|
write out network configuration files.
|
|
|
|
The format of the `network_info.json` file is documented `here
|
|
<http://specs.openstack.org/openstack/nova-specs/specs/liberty/implemented/metadata-service-network-info.html#rest-api-impact>`__.
|
|
Please note that glean does not implement every feature listed.
|
|
|
|
If no network info is found there, available interfaces can be probed
|
|
from `/sys/class/net` and any that appear to be up will be configured
|
|
for use with DHCP.
|
|
|
|
It will also handle `authorized_keys` and host-name info provided from
|
|
`meta_data.json`.
|
|
|
|
How does glean do this?
|
|
+++++++++++++++++++++++
|
|
|
|
Glean determines the network configuration environment for the running
|
|
platform and configures the interfaces appropriately.
|
|
|
|
systemd environment
|
|
===================
|
|
|
|
On platforms where systemd is detected `glean-install` will add a
|
|
`udev` rules file (`99-glean.rules`) that triggers on any network
|
|
device being added. This will run the `glean@.service` systemd
|
|
template for the interface specified.
|
|
|
|
This systemd unit firstly determines if there is already a
|
|
`/etc/sysconfig/network/` configuration for the interface; if so, the
|
|
interface is considered configured and skipped.
|
|
|
|
If not, glean is started with the interface that triggered this event
|
|
specified as an argument. The configuration drive is probed to see if
|
|
network configuration for the interface is available. If so, it will
|
|
be added, otherwise the interface will configured for DHCP.
|
|
|
|
.. note ::
|
|
|
|
By default glean provides configuration for the network init
|
|
scripts service ``network.service`` on RedHat platforms (or the
|
|
equivalent on other platforms). You should ensure this service is
|
|
enabled and other tools such as NetworkManager are disabled for
|
|
correct operation in this mode. Note on Fedora 29 onwards, this is
|
|
in a separate package `network-scripts` and is considered
|
|
deprecated.
|
|
|
|
Alternatively, to use NetworkManager with the `ifcfg-rh` plugin
|
|
with to manage the interfaces, call `glean-install` with the
|
|
`--use-nm` flag. In this case, ensure NetworkManager is installed.
|
|
This will trigger glean to write out configuration files that are
|
|
suitable for use with NetworkManager and use a slightly different
|
|
service file that doesn't trigger legacy tools like `ifup`.
|
|
|
|
|
|
networkd
|
|
========
|
|
|
|
`networkd` support is implemented as a separate distribution type.
|
|
Currently it is only supported on Gentoo, and will be automatically
|
|
selected by `glean-install`. It will similarly install a systemd
|
|
service file or openrc config file (both are supported on Gentoo) and
|
|
udev rules to call glean.
|
|
|
|
Other platforms
|
|
===============
|
|
|
|
`upstart` and `sysv` environments are also supported. These will have
|
|
init scripts installed to run glean at boot.
|
|
|
|
How do I use glean?
|
|
-------------------
|
|
|
|
Glean ships `glean-install`, a script which install glean into your
|
|
system startup environment. It should handle `sysv`, `upstart` and
|
|
`systemd` to cover all major distributions. This should be run once,
|
|
during install or image build.
|
|
|
|
The startup environment will be modified as described above to
|
|
configure any found interfaces.
|
|
|
|
Differences to cloud-init?
|
|
--------------------------
|
|
|
|
Glean differs to `cloud-init` mainly in its very reduced dependency
|
|
footprint. In a dynamic CI environment such as OpenStack, many of the
|
|
python dependencies for `cloud-init` can cause conflicts with packages
|
|
or versions required for testing.
|
|
|
|
Glean also better supports static IP allocation within config-drive,
|
|
particuarly important within the Rackspace environment.
|
|
|
|
More details
|
|
------------
|
|
|
|
* Free software: Apache license
|
|
* Documentation: http://docs.openstack.org/infra/glean
|
|
* Source: http://git.openstack.org/cgit/openstack-infra/glean
|
|
* Bugs: http://storyboard.openstack.org
|