| Age | Commit message (Collapse) | Author |
|---|
|
This also simplifies the implementation to rely on the stdlib, instead
of our own NIH checking.
|
|
This will be required for the mirror URL sanitisation work,
|
|
- tested on OpenBSD 6.6
- tested on OpenStack without config drive, and NoCloud with ISO config
drive
|
|
Add support for the NetBSD Operating System.
Features in this branch:
* Add BSD distro parent class from which NetBSD and FreeBSD can
specialize
* Add *bsd util functions to cloudinit.net and cloudinit.net.bsd_utils
* subclass cloudinit.distro.freebsd.Distro from bsd.Distro
* Add new cloudinit.distro.netbsd and cloudinit.net.renderer for
netbsd
* Add lru_cached util.is_NetBSD functions
* Add NetBSD detection for ConfigDrive and NoCloud datasources
This branch has been tested with:
- NoCloud and OpenStack (with and without config-drive)
- NetBSD 8.1. and 9.0
- FreeBSD 11.2 and 12.1
- Python 3.7 only, because of the dependency oncrypt.METHOD_BLOWFISH.
This version is available in NetBSD 7, 8 and 9 anyway
|
|
* freebsd: introduce the freebsd renderer
Refactoring of the FreeBSD code base to provide a real network renderer
for FreeBSD.
Use the generic update_sysconfig_file() from rhel_util to handle the
access to /etc/rc.conf.
Interfaces are not automatically renamed by FreeBSD using
the following configuration in /etc/rc.conf:
```
ifconfig_fxp0_name="eth0"
```
* freesd: use regex named groups
Reduce the complexity of `get_interfaces_by_mac_on_freebsd()` with
named groups.
* freebsd: breaks up _write_network() in tree small functions
- `_write_ifconfig_entries()`
- `_write_route_entries()`
- `_write_resolve_conf()`
* extend find_fallback_nic() to support FreeBSD
this uses `route -n show default` to find the default interface
* freebsd: use dns keys from NetworkState class
The NetworkState class (settings instance) exposes the DNS configuration
in two keys:
- `dns_nameservers`
- `dns_searchdomains`
On OpenStack, these keys are set when a global DNS server is set. The
alternative is the `dns_nameservers` and `dns_search` keys from each
subdomain. We continue to read those.
* freebsd: properly target the /etc/resolv.conf file
* freebsd: ignore 'service routing restart' ret code
On FreeBSD 10, the restart of routing and dhclient is likely to fail because
- routing: it cannot remove the loopback route, but it will still set up
the default route as expected.
- dhclient: it cannot stop the dhclient started by the netif service.
In both case, the situation is ok, and we can proceed.
* freebsd: handle case when metadata MAC local locally
Handle the case where the metadata configuration comes with a MAC that
does not exist locally.
See:
- https://github.com/canonical/cloud-init/pull/61/files/635ce14b3153934ba1041be48b7245062f21e960#r359600604
- https://github.com/canonical/cloud-init/pull/61/files/635ce14b3153934ba1041be48b7245062f21e960#r359600966
* freebsd: show up a warning if several subnet found
The FreeBSD provider currently only allow one subnet per interface.
* freebsd: honor the target parameter in _write_network
* freebsd: log when a bad route is found
* freebsd: pass _postcmds to start_services()
* freebsd: updatercconf() is depercated
Replace `updatercconf()` by `rhel_util.update_sysconfig_file()`.
* freebsd: ensure gateway is ipv4 before using it
With the legacy ENI format, an IPv6 gateway may be pushed. This instead
of the expected IPv4.
* freebsd: find_fallback_nic, support FB10
On FreeBSD <= 10, `ifconfig -l` ignores the down interfaces.
* freebsd: use util.target_path() to load resolv.conf
Ensure we access `/etc/resolv.conf`, not `etc/resolv.conf`.
* freebsd: skip subnet without netmask
Those are likely to be either invalid of in IPv6 format. IPv6 support
will be addressed later in a new patchset.
* freebsd: get_devicelist returns netif list
Ensure `get_devicelist()` returns the list of known netif on FreeBSD.
* replace rhel_util.update_sysconfig_file wrapper call, with a wrapper function
* reverse if condition to remove an indent
Co-authored-by: Igor Galić <me+github@igalic.co>
|
|
|
|
The change that introduced this issue was handling interfaces that are
bonded in the kernel, in a way that doesn't present as "a bond" to
userspace in the normal way. Both members of this "bond" will share a
MAC address, so we filter one of them out to avoid incorrect MAC address
collision warnings.
Unfortunately, the matching condition was too broad, so that change also
affected normal bonds and bridges. This change specifically excludes
bonds and bridges from that determination, to address that regression.
LP: #1846535
|
|
Some network devices are transformed into a bond via kernel magic
and do not have the 'bonding' sysfs attribute, but like a bond they
have a duplicate MAC of other bond members. On Azure Advanced
Networking SRIOV devices are auto bonded and will have the same MAC
as the HyperV nic. We can detect this via the 'master' sysfs attribute
in the device sysfs path and this patch adds this to the list of devices
we ignore when enumerating device lists.
LP: #1844191
|
|
Add support for detecting netfailover[1] device 3-tuple in networking
layer. In the Oracle datasource ensure that if a provided network
config, either fallback or provided config includes a netfailover master
to remove any MAC address value as this can break under 3-netdev
as the other two devices have the same MAC.
1. https://www.kernel.org/doc/html/latest/networking/net_failover.html
|
|
The function generate_fallback_config is used by Azure by default when
not consuming IMDS configuration data. This function is also used by any
datasource which does not implement it's own network config. This simple
fallback configuration sets up dhcp on the most likely NIC. It will now
emit network v2 instead of network v1.
This is a step toward moving all components talking in v2 and allows us
to avoid costly conversions between v1 and v2 for newer distributions
which rely on netplan.
|
|
On systems with many interfaces, processing udev events may take a while.
Cloud-init expects devices included in a provided network-configuration
to be present when attempting to configure them. This patch adds a step
in net configuration where it will check for devices provided in the
configuration and if not found, issue udevadm settle commands to wait
for them to appear.
Additionally, the default path for udev persistent network rules
70-persistent-net.rules may also be written to systems which include
the 75-net-generator.rules. During boot, cloud-init and the
generator may race and interleave values causing issues. OpenSUSE
will now use a newer file, 85-persistent-net-cloud-init.rules which
will take precedence over values created by 75-net-generator and
avoid collisions on the same file.
LP: #1817368
|
|
The EphemeralDHCP context manager did not parse or handle
rfc3442 classless static routes which prevented reading
datasource metadata in some clouds. This branch adds support
for extracting the field from the leases output, parsing the
format and then adding the required iproute2 ip commands to
apply (and teardown) the static routes.
LP: #1821102
|
|
bonds may inherit mac address from a physical interface
LP: #1812857
|
|
We add a new Optional parameter: connectivity_url
This is used in __enter__ to verify if a connection already exists.
If it does exist, no operations are performed.
|
|
Previously we explicitly excluded mac address '00:00:00:00:00:00'.
But then some nics (tunl0 and sit0) ended up having a mac address like
'00:00:00:00'.
The change here just ignores all 00[:00[:00...]].
LP: #1796917
|
|
OpenStack ironic references Infiniband interfaces via a 6 byte 'MAC
address' formed from bytes 13-15 and 18-20 of interface's hardware
address. This address is used as the ethernet_mac_address of Infiniband
links in network_data.json in configdrives generated by OpenStack nova.
We can use this address to map links in network_data.json to their
corresponding interface names.
When generating interface configuration files, we need to use the
interface's full hardware address as the HWADDR, rather than the 6 byte
MAC address provided by network_data.json.
This change allows IB interfaces to be referenced in this dual mode - by
MAC address and hardware address, depending on the context.
Support TYPE=InfiniBand for sysconfig configuration of IB interfaces.
|
|
On OpenStack based OVH public cloud, we got DHCP response with
fixed-address 54.36.113.86;
option subnet-mask 255.255.255.255;
option routers 54.36.112.1;
The router clearly is not on the subnet. So 'ip' would fail when
we tried to add the default route.
The solution here is to add an explicit route on that interface
to the router and then add the default route.
Also add 'bgpovs' to the list of 'physical' types for OpenStack
network configuration. That type is used on OVH public cloud.
LP: #1792415
|
|
When attempting to apply network configuration for SmartOS's container
platform, cloud-init would not identify nics. The nics on provided
in this container service do not have 'addr_assign_type'. That
was being interpreted as being a "stolen" mac, and would be filtered
out by get_interfaces.
|
|
The cloud-init-local.service expects that any network device name changes
have already been completed by the kernel or udev daemon.
In some situations we've found that the renaming of interfaces from kernel
names (eth0, eth1, etc) to their persistent names (eno1, ens3, enp0s1,
etc) may happen after cloud-init-local has started where it reads values
from sysfs about what network devices are present, and which device to use
as a fallback nic.
Subsequently, cloud-init-local would write out network configuration for a
kernel device name which would no longer be present by the time that
networking services start to bring up the devices. The result is that the
instance does not get networking configured. Prior to use of
systemd-networkd, the Ubuntu 'networking.service' unit included a call to
udevadm settle which is why this race is not seen on a Xenial system.
This change adds the ability to detect if an interface has a stable name,
if if we find one without stable names and stable names have not been
disabled (net.ifnames=0 in /proc/cmdline), then cloud-init will invoke
udevadm settle.
LP: #1766287
|
|
This enables warnings produced by pylint for unused variables (W0612),
and fixes the existing errors.
|
|
net.apply_network_config_names currently only accepts network-config
in version 1 format. When users include a netplan format network-config the
rename code does not find any of the 'set-name' directives and does not rename
any of the interfaces. This causes some netplan configurations to fail.
This patch adds support for parsing netplan format and extracts the needed
information (macaddress and set-name values) to allow cloud-init to issue
interface rename commands. We know raise a RuntimeError if presented with
an unknown config format.
LP: #1709715
|
|
Network configuration in OpenNebula would only work if the host correctly
guessed the names of the devices in the guest. OpenNebula provided data
in its context.sh like 'ETH0_NETWORK', but if the guest named devices
differently then results were not predictable. This would occur with
Predictable Network Interface Names. To address this,
newer versions (of OpenNebula provide the mac address ETH0_MAC.
This function is present in 4.14 and documented officially in 5.0 docs.
This provides support for reading the mac addresses from the context.sh.
It also fixes cases where context.sh provided a field (ETH0_NETWORK
or ETH0_MASK) with a empty string. Previously the empty string would
be used rather than falling back to the default.
LP: #1719157, #1716397, #1736750
|
|
This branch is a prerequisite for IPv6 support in AWS by allowing Ec2
datasource to query the metadata source version 2016-09-02 about whether
or not it needs to configure IPv6 on interfaces. If version 2016-09-02
is not present, fallback to the min_metadata_version of 2009-04-04. The
DataSourceEc2Local not run on FreeBSD because dhclient in doesn't
support the -sf flag allowing us to run dhclient without filesystem
side-effects.
To query AWS' metadata address @ 169.254.169.254, the instance must have
a dhcp-allocated address configured. Configuring IPv4 link-local
addresses result in timeouts from the metadata service. We introduced a
DataSourceEc2Local subclass which will perform a sandboxed dhclient
discovery which obtains an authorized IP address on eth0 and crawl
metadata about full instance network configuration.
Since ec2 IPv6 metadata is not sufficient in itself to tell us all the
ipv6 knownledge we need, it only be used as a boolean to tell us which
nics need IPv6. Cloud-init will then configure desired interfaces to
DHCPv6 versus DHCPv4.
Performance side note: Shifting the dhcp work into init-local for Ec2
actually gets us 1 second faster deployments by skipping init-network
phase of alternate datasource checks because Ec2Local is configured in
an ealier boot stage. In 3 test runs prior to this change: cloud-init
runs were 5.5 seconds, with the change we now average 4.6 seconds.
This efficiency could be even further improved if we avoiding dhcp
discovery in order to talk to the metadata service from an AWS
authorized dhcp address if there were some way to advertize the dhcp
configuration via DMI/SMBIOS or system environment variables.
Inspecting time costs of the dhclient setup/teardown in 3 live runs the
time cost for the dhcp setup round trip on AWS is:
test 1: 76 milliseconds
dhcp discovery + metadata: 0.347 seconds
metadata alone: 0.271 seconds
test 2: 88 milliseconds
dhcp discovery + metadata: 0.388 seconds
metadata alone: 0.300 seconds
test 3: 75 milliseconds
dhcp discovery + metadata: 0.366 seconds
metadata alone: 0.291 seconds
LP: #1709772
|
|
get_interfaces_by_mac and get_interfaces just looked much alike.
This makes get_interfaces_by_mac call get_interfaces.
|
|
This is not yet called, but will be called in a subsequent Ec2-related branch to manually initialize a network interface with the responses using dhcp discovery without any dhcp-script side-effects. The functionality has been tested on Ec2 ubuntu and CentOS vms to ensure that network interface initialization works in both OS-types.
Since there was poor unit test coverage for the cloudinit.net.__init__ module, this branch adds a bunch of coverage to the functions in cloudinit.net.__init. We can also now have unit tests local to the cloudinit modules. The benefits of having unittests under cloudinit module:
- Proximity of unittest to cloudinit module makes it easier for ongoing devs to know where to augment unit tests. The tests.unittest directory is organizated such that it
- Allows for 1 to 1 name mapping module -> tests/test_module.py
- Improved test and module isolation, if we find unit tests have to import from a number of modules besides the module under test, it will better prompt resturcturing of the module.
This also branch touches:
- tox.ini to run unit tests found in cloudinit as well as include all test-requirements for pylint since we now have unit tests living within cloudinit package
- setup.py to exclude any test modules under cloudinit when packaging
|
|
The network device renaming code previously required the case of
the mac address input to match that of the data read from the system.
For example, if user provided network config with mac address
in upper case, then cloud-init would not rename the device correctly
as /sys/class/net/address stores lower case values.
The fix here is to always compare lower case mac addresses.
LP: #1705147
|
|
On systems with network devices with duplicate mac addresses, cloud-init
will fail to rename the devices according to the specified network
configuration. Refactor net layer to search by device driver and device
id if available. Azure systems may have duplicate mac addresses by
design.
Update Azure datasource to run at init-local time and let Azure datasource
generate a fallback networking config to handle advanced networking
configurations.
Lastly, add a 'setup' method to the datasources that is called before
userdata/vendordata is processed but after networking is up. That is
used here on Azure to interact with the 'fabric'.
|
|
The code deciding which interface to choose as the default to request the
IP address through DHCP does not sort the interfaces correctly. On Ubuntu
Xenial images for example, the interfaces are named ens1, ens2, ens3...,
ens11, ... depending on the pci bus address. The python sorting will list
'ens11' before 'ens3' for example despite the fact that 'ens3' should be
before 'ens11'.
This patch address this issue and sort the interface names according to a
human sorting.
Signed-off-by: Marc-Aurèle Brothier <m@brothier.org>
|
|
Some interfaces (greptap0 in the bug) have a mac address of
'00:00:00:00:00:00'. That was causing a duplicate mac detection
as the 'lo' device also has that mac.
The change here is to just ignore macs other than 'lo' that have that.
LP: #1692028
|
|
Introduce is_vlan function and call that when building dictionary of
interfaces by mac address.
LP: #1682871
|
|
When cloud-init ran in the init stage (after networking had come up).
A bug could occur where cloud-init would attempt and fail to rename
network devices that had "inherited" mac addresses.
The intent of apply_network_config_names was always to rename only
the devices that were "physical" per the network config. (This would
include veth devices in a container). The bug was in creating
the dictionary of interfaces by mac address. If there were multiple
interfaces with the same mac address then renames could fail.
This situation was guaranteed to occur with bonds or vlans or other
devices that inherit their mac.
The solution is to change get_interfaces_by_mac to skip interfaces
that have an inherited mac.
Also drop the 'devs' argument to get_interfaces_by_mac. It was
non-obvious what the result should be if a device in the input
list was filtered out. ie should the following have an entry for
bond0 or not. get_interfaces_by_mac(devs=['bond0'])
LP: #1669860
|
|
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.
|
|
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.
|
|
I've seen cases of unable to read from files as
well as the existing os errors so catch io error
and skip by using the smarter read_sys_net instead.
LP: #1625766
|
|
When using get_interface_mac, on a system with bond slaves, it would
return the bond_master's address. That isn't expected, and causes
problems in a caller like get_interfaces_by_mac which would then seem to
find duplicate macs on the system.
Additionally, in read_sys_net catch a errno.ENOTDIR error as ENOENT.
Opening a path as a file that has <existing_file>/anything will will raise
ENOTDIR rather than ENOENT. This handles that case in read_sys_net as a
if the file did not exist.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
'id' on a link in the openstack spec should be "Generic, generated ID".
current implementation was to use the host's name for the host
side nic. Which provided names like 'tap-adfasdffd'.
We do not want to name devices like that as its quite unexpected
and non user friendly. So here we use the system name for any
nic that is present, but then require that the nics found also
be present at the time of rendering.
The end result is that if the system boots with net.ifnames=0
then it will get 'eth0' like names. and if it boots without net.ifnames
then it will get enp0s1 like names.
|
|
this adds ability to support ENI that has:
hwadress ether 36:4c:e1:3b:14:31
or
hwaddress 36:4c:e1:3b:14:31
the former is written by openstack (at least on dreamhost).
Also, in the conversion of eni to network config support broadcast
and netmask.
|
|
|
|
The one issue i'm aware of currently is that tap devices
(ip tuntap add mode tap user root mytap1)
do not work correctly with 'is_up' which means the check
does not bring them down and the rename fails.
The LOG.debug message should be cleaned up too, as it currently
references the function rather function.__name__ for nicer message.
|
|
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
|
|
|
|
|
|
|
