2601b25a7c
It seems platform.dist and platform.linux_distribution are broken with newer operating systems. Specifically /etc/os-release seems to be the new hotness. EG: opensuse-tumbleweed and fedora-27. Vendor the distro (1.2.0) package, as not to have external dependencies installed. Change-Id: Ib9580aa7fe84a20e44d32248d7b4716456684dbc Depends-On: https://review.openstack.org/545183/ Signed-off-by: Paul Belanger <pabelanger@redhat.com> |
||
|---|---|---|
| doc/source | ||
| glean | ||
| .coveragerc | ||
| .gitignore | ||
| .gitreview | ||
| .mailmap | ||
| .testr.conf | ||
| CONTRIBUTING.rst | ||
| HACKING.rst | ||
| LICENSE | ||
| MANIFEST.in | ||
| README.rst | ||
| rebuild-test-output.sh | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
README.rst
glean
Glean is a program intended to configure a system based on configuration provided in a configuration drive.
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. 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?
systemd environment
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 specified. 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.
glean uses the network init scripts service
network.serviceon 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.
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