| Age | Commit message (Collapse) | Author |
|---|
|
Network configuration version 2 format is implemented in a package
called netplan (nplan)[1] which allows consolidated network config
for multiple network controllers.
- Add a new netplan renderer
- Update default policy, placing eni and sysconfig first
This requires explicit policy to enable netplan over eni
on systems which have both (Yakkety, Zesty, UC16)
- Allow any network state (parsed from any format cloud-init supports) to
render to v2 if system supports netplan.
- Move eni's _subnet_is_ipv6 to common code for use by other renderers
- Make sysconfig renderer always emit /etc/syconfig/network configuration
- Update cloud-init.service systemd unit to also wait on
systemd-networkd-wait-online.service
1. https://lists.ubuntu.com/archives/ubuntu-devel/2016-July/039464.html
|
|
Previously, the distro had hard coded which network renderer it would
use. This adds support for just picking the right renderer based
on what is available.
Now, that can be set via a priority in system_info, but should
generally work. That config looks like:
system_info:
network:
renderers: ["eni", "sysconfig"]
When no renderers are found, a specific RendererNotFoundError is raised.
stages.py is modified to catch that and log it at error level. This
path should not really be exercised, but could occur if for example an
Ubuntu system did not have ifupdown, or a rhel system did not have
sysconfig. In such a system previously we would have quietly rendered
ENI configuration but that would have been ignored. This is one step
better in that we at least log the error.
|
|
log a warning rather than raising ValueError if we see more than three
nameserver addresses.
LP: #1670052
|
|
Recent fedora releases use "dnf" instead of "yum" for package
management. While there is a compatible "yum" cli available, there's
no guarantee that it will be available.
With this patch, cloud-init will check for /usr/bin/dnf and use that
if it exists instead of yum.
rhbz: https://bugzilla.redhat.com/show_bug.cgi?id=1194451
LP: #1647118
|
|
This has been a recurring ask and we had initially just made the change to
the cloud-init 2.0 codebase. As the current thinking is we'll just
continue to enhance the current codebase, its desirable to relicense to
match what we'd intended as part of the 2.0 plan here.
- put a brief description of license in LICENSE file
- put full license versions in LICENSE-GPLv3 and LICENSE-Apache2.0
- simplify the per-file header to reference LICENSE
- tox: ignore H102 (Apache License Header check)
Add license header to files that ship.
Reformat headers, make sure everything has vi: at end of file.
Non-shipping files do not need the copyright header,
but at the moment tests/ have it.
|
|
Cloud-config provided like:
users:
- default
- name: foobar
groups: sudo, adm
Would result in adduser being called as:
useradd foobar --groups 'sudo, adm' -m
Which would cause error:
useradd: group ' adm' does not exist
The fix here is just to always normalize groups and remove whitespace.
Additionally a fix and unit tests to explicitly set system=False
or no_create_home=True. Previously those paths did not test the value
of the entry, only the presense of the entry.
LP: #1354694
|
|
The documentation shows group names in the 'groups:' key delimited by
", ", but this will result in group names that contain spaces. This
can cause the 'groupadd' or 'useradd' commands to fail.
This patch ensures that we strip whitespace from either end of the
group names passed to the 'groups:' key.
LP: #1354694
|
|
Ubuntu Core images use the `snap create-user` to add users to an
Ubuntu Core system. Add support for creating snap users by adding
a key to the users dictionary.
users:
- name: bob
snapuser: bob@bobcom.io
Or via the 'snappy' dictionary:
snappy:
email: bob@bobcom.io
Users may also create a snap user without contacting the SSO by
providing a 'system-user' assertion by importing them into snapd.
Additionally, Ubuntu Core systems have a read-only /etc/passwd such that
the normal useradd/groupadd commands do not function without an additional
flag, '--extrausers', which redirects the pwd to /var/lib/extrausers.
Move the system_is_snappy() check from cc_snappy module to util for
re-use and then update the Distro class to append '--extrausers' if
the system is Ubuntu Core.
|
|
Set the default value for 'ssh_svcname' in rhel distros.
This means that it no longer needs to be set in system_info config.
|
|
The amount of code to do user and group normalization
and extraction deserves its own file so move the code
that does this to a new file and update references to the
old location.
This removes some of the funkyness done in config modules
to avoid namespace and attribute clashes as well.
|
|
This gets Gentoo work on simple configs with static IPs or
DHCP on physical interfaces. This gets Gentoo bootable again.
|
|
os.uname is a method, not a property.
|
|
|
|
|
|
Previous commit disabled the consumption of 'injected' files in
configdrive (openstack server boot --file=/target/file=local-file)
unless the datasource was in 'pass' mode. The default mode is 'net'
so that would never happen.
Also here are:
a.) a fix for 'links_path_prefix' string from debian, to finally
disable the rendering of systemd.link files (LP: #1594546)
b.) some comments to apply_network_config
c.) implement a backwards compatibility for for distros that do
not yet implement apply_network_config by converting the network
config into ENI format and calling apply_network.
This is required because prior to the previous commit, those distros
would have had 'apply_network' called with the openstack provided
ENI file. But after this change they will have apply_network_config
called by cloudinit's main.
d.) a network_state_to_eni helper for converting net config to eni
it supports the not-actually-correct 'hwaddress' field in ENI.
LP: #1602373
|
|
Under revno 1243 a failed attempt was made to not render systemd.link
files into /etc/systemd/network/ . The 'config' that was passed in was
incorrect though, and resulted in link files still getting rendered.
(original bug was LP: #1594546).
|
|
|
|
These are unnecessary, as cloud-init is renaming the nics
that should be renamed itself.
|
|
|
|
pylint --errors-only found several errors. Some of the changes
here represent real errors, others just code that pylint did
not like.
|
|
|
|
|
|
|
|
|
|
currently does not work in lxc
https://github.com/lxc/lxd/issues/2063
|
|
== background ==
DataSource Mode (dsmode) is present in many datasources in cloud-init.
dsmode was originally added to cloud-init to specify when this datasource
should be 'realized'.
cloud-init has 4 stages of boot.
a.) cloud-init --local . network is guaranteed not present.
b.) cloud-init (--network). network is guaranteed present.
c.) cloud-config
d.) cloud-init final
'init_modules' [1] are run "as early as possible". And as such, are executed
in either 'a' or 'b' based on the datasource. However, executing them means
that user-data has been fully consumed. User-data and vendor-data may have
'#include http://...' which then rely on the network being present. boothooks
are an example of the things run in init_modules.
The 'dsmode' was a way for a user to indicate that init_modules
should run at 'a' (dsmode=local) or 'b' (dsmode=net) directly.
Things were further confused when a datasource could provide networking
configuration. Then, we needed to apply the networking config at 'a'
but if the user had provided boothooks that expected networking, then the
init_modules would need to be executed at 'b'. The config drive datasource
hacked its way through this and applies networking if *it* detects it is
a new instance.
== Suggested Change ==
The plan is to
1. incorporate 'dsmode' into DataSource superclass
2. make all existing datasources default to network
3. apply any networking configuration from a datasource on first boot only
apply_networking will always rename network devices when it runs.
for bug 1579130.
4. run init_modules at cloud-init (network) time frame unless datasource
is 'local'.
5. Datasources can provide a 'first_boot' method that will be called when
a new instance_id is found. This will allow the config drive's write_files
to be applied once.
Over all, this will very much simplify things. We'll no longer have
2 sources like DataSourceNoCloud and DataSourceNoCloudNet, but would just
have one source with a dsmode.
== Concerns ==
Some things have odd reliance on dsmode. For example, OpenNebula's get_hostname
uses it to determine if it should do a lookup of an ip address.
== Bugs to fix here ==
http://pad.lv/1577982 ConfigDrive: cloud-init fails to configure network from network_data.json
http://pad.lv/1579130 need to support systemd.link renaming of devices in container
http://pad.lv/1577844 Drop unnecessary blocking of all net udev rules
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ubuntu cloud images in created a file during build that
would interfere with cloud-init's discovered or rendered networking.
To avoid the issues, cloud-init was deleting
/etc/network/interfaces.d/eth0.cfg .
The build process no longer creates this file.
However, to address any existing files cloud-init will still remove
the file if it has known content and warn otherwise.
LP: #1563487
|
|
Instead of passing the raw object and expecting the write_file to work
automatically make sure we explicitly pass the string version of it so
that the write_file routine can correctly encode/decode it as needed.
LP: #1479988
|
|
revision 1179 regressed adding a user that did not have a 'groups'
entry present in cloud-config.
This handles that correctly, making 'add_user' able to take:
a.) groups="group1,group2"
b.) groups=["group1", "group2"]
c.) groups=None
d.) no groups parameter
Additionally, if a primary group is specified it will also be created.
End result is that this is functional:
#cloud-config
groups: ["sudo"]
users:
- name: sysop
primary-group: sysop
groups: "sudo,adm"
shell: /bin/bash
- name: user1
primary-group: users
groups: sudo
- name: foo1
- name: bar
gecos: Bar
groups: ["bargroup"]
Resulting in:
$ groups sysop
sysop : sysop adm sudo
$ groups user1
user1 : users sudo
$ groups foo1
foo1 : foo1
$ groups bar
bar : bar bargroup
LP: #1562918
|
|
|
|
When provided with gzipped data, an exception would be raised
because of a conversion to string.
This fixes the issue and adds a test for write_files.
LP: #1565638
|
|
|
|
revision 1179 regressed adding a user that did not have a 'groups'
entry present. This should handle that correctly, making 'add_user'
able to take:
a.) groups="group1,group2"
b.) groups=["group1", "group2"]
c.) groups=None
d.) no groups parameter
LP: #1562918
|
|
3 things here:
a.) do not raise exception, only warn when trying to apply a network
config for a distro that does not have an implementation.
This is important since debian/ubuntu is the only one *with* an
implementation at the moment
b.) apply network config in 'cloud-init --local' even if there is
no datasource found.
c.) do not write 70-persistent-net.rules
the code was writing both 70-persistent-net.rules and
/etc/systemd/network/50-cloud-init-*.link files
that would just be confusing.
|
|
|
|
there is no data source that has a populated network_config()
so at this point this doesn't do anything.
|
|
|
|
functional
|
|
|
|
|
|
this adds the consumption of 'network-config' to the datasourcenocloud.
There is an implementation of the network rendering taht is untested
in distros/debian.
|
|
This add 'lxd' to the list of groups that the default user is added to.
It also changes behavior to create any necessary groups that are listed
for the user rather than failing to add the user.
Theres also a fix for usage of logexc that I found along the way.
LP: #1539317
|
|
|
|
Update make check target to use pep8, pyflakes, pyflakes3.
|
