| Age | Commit message (Collapse) | Author |
|---|
|
The huge table was scrolling off the page for me and it made more sense
to break this up and have sections for each item anyway.
|
|
|
|
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
|
|
|
|
Takeover the moreinfo.rst page and update initially with pages
a user can use to learn about cloud-init. For now, other docs
and presentations about cloud-init.
Goal is to use this page to collect very commonly asked questions.
|
|
|
|
The detection for brightbox in both ds-identify and in
identify_brightbox would incorrectly match the domain 'bobrightbox',
which is not a brightbox platform. The fix here is to restrict
matching to '*.brightbox.com' rather than '*brightbox.com'
Also, while here remove a url to bug 1661693 which added the
knowledge of brightbox.
|
|
VMWware customization already has support to run a custom script during
the VM customization. Adding this option allows a VM administrator to
disable the execution of customization scripts. If set the script
will not execute and the customization status is set to
GUESTCUST_ERROR_SCRIPT_DISABLED.
|
|
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
|
|
LP: #1843276
|
|
* Create makefile and tox targets for documentation building and testing
to better replicate the live web docs using the same theme.
* Created docs.rst to explain how to build and contribute to documentation
with style guide and tips.
* doc/rtd/conf.py:
* Add copyright to rtd config
* Use Sphinx's RTD theme to replicate actual docs
|
|
|
|
|
|
|
|
When rendering secondary vnic configuration from IMDS, only emit
configuration for the IP and MTU values only. Add support to mutate
either a v1 or a v2 network_config input.
|
|
Make sure Exoscale supplements or overrides existing system config
setting cloud_config_modules instead of replacing it with a one item
list set-passords
LP: #1841454
|
|
This refactors read_initramfs_config to support multiple different types
of initramfs network configuration. It introduces an
InitramfsNetworkConfigSource abstract base class. There is currently a
single sub-class, KlibcNetworkConfigSource, which contains the logic
which previously was directly within read_initramfs_config.
|
|
Emit a script allowing cloud-init to set linux/nvidia/latelink
debconf selection to true. This avoids having to call
debconf-set-selections and allows cloud-init to pre-confgure
linux-restricted-modules to link NVIDIA drivers to the running kernel.
Cloud-init loads this debconf template and sets the value to true in the
debconf database by sourcing debconf's /usr/share/debconf/confmodule and
uses db_x_loadtemplatefile to register cloud-init's setting for
linux/nvidia/latelink.
LP: #1840080
|
|
Since this is the first code snippet some users might see,
they could end up in the same situation like me today
when they wonder why their yaml user config is not
working at all.
|
|
To accept NVIDIA EULA, cloud-init needs to emit latelink=true debconf
setting to the linux-restricted-modules package to allow NVIDIA
drivers to properly link to the running kernel.
LP: #1840080
|
|
The Oracle platform provides networking configuration from two sources:
* the primary interface configuration comes from the initramfs, because
Oracle instance all iSCSI boot
* secondary interface configuration comes from an IMDS accessed over
HTTP
As we need to combine these two sources of network configuration, the
default "prefer initramfs config over data source config" behaviour
isn't appropriate; we would never get the IMDS interfaces via that
route. Instead, the Oracle data source has code to combine these two
sources, so we prefer its network configuration over the initramfs
configuration.
(This is not appropriate default behaviour, because _in general_ data
sources won't know how to merge initramfs-provided configuration into
their provided configuration, so switching this order for all data
sources would result in initramfs configuration being discarded on any
data source that implements network_config.)
|
|
The cleanups, specifically, are to sort the list of content types, and
remove trailing whitespace.
|
|
This will hopefully avoid people submitting PRs against our mirror repo.
(Thanks to GitHub user @max06 for this suggestion!)
|
|
|
|
|
|
Collect and record the following information through KVP:
+ timestamps related to kernel initialization and systemd activation
of cloud-init services
+ system information including cloud-init version, kernel version,
distro version, and python version
+ diagnostic events for the most common provisioning error issues
such as empty dhcp lease, corrupted ovf-env.xml, etc.
+ increasing the log frequency of polling IMDS during reprovision.
|
|
Oracle Cloud Infrastructure's Instance Metadata Service provides network
configuration information for non-primary NICs. This commit introduces
support, on Virtual Machines[0], for fetching that network metadata,
converting it to v1 network-config[1] and combining it into the network
configuration generated for the primary interface.
By default, this behaviour is not enabled. Configuring the Oracle
datasource to `configure_secondary_nics` enables it:
datasource:
Oracle:
configure_secondary_nics: true
Failures to fetch and generate secondary NIC configuration will log a
warning, but otherwise will not affect boot.
[0] The expected use of the IMDS-provided network configuration is
substantially different on Bare Metal Machines, so support for that
will be addressed separately.
[1] This is v1 config, because cloudinit.net.cmdline generates v1 config
and we need to integrate the secondary NICs into that configuration.
|
|
Building the subp arguments for a `useradd` call in a variable named
`adduser_cmd` is extremely confusing; let's not do that.
(This also changes the snap and freebsd variables to something more
apropos.)
|
|
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.
|
|
This adds an empty publish_host_keys() method to the default datasource
that is called by cc_ssh.py. This feature can be controlled by the
'ssh_publish_hostkeys' config option. It is enabled by default but can
be disabled by setting 'enabled' to false. Also, a blacklist of key
types is supported.
In addition, this change implements ssh_publish_hostkeys() for the GCE
datasource, attempting to write the hostkeys to the instance's guest
attributes. Using these hostkeys for ssh connections is currently
supported by the alpha version of Google's 'gcloud' command-line tool.
(On Google Compute Engine, this feature will be enabled by setting the
'enable-guest-attributes' metadata key to 'true' for the
project/instance that you would like to use this feature for. When
connecting to the instance for the first time using 'gcloud compute ssh'
the hostkeys will be read from the guest attributes for the instance and
written to the user's local known_hosts file for Google Compute Engine
instances.)
|
|
- dsidentify switches to the new Exoscale datasource on matching DMI name
- New Exoscale datasource added
Signed-off-by: Mathieu Corbin <mathieu.corbin@exoscale.ch>
|
|
We don't use it in our doc builds, and if sphinx.pocoo.org is down then
it causes doc build issues.
|
|
What we had previously was inaccurate in a few respects.
LP: #1838794
|
|
Previously "cmdline" network configuration could be either
user-specified network-config=... configuration data, or
initramfs-provided configuration data. Before data sources could modify
the order in which network config sources were considered, this
conflation didn't matter (and, indeed, in the default data source
configuration it will continue to not matter).
However, it _is_ desirable for a data source to be able to specify that
its network configuration should be preferred over the
initramfs-provided network configuration but still allow explicit
network-config=... configuration passed to the kernel cmdline to
continue to override both of those sources.
(This also modifies the Oracle data source to use read_initramfs_config
directly, which is effectively what it was using
read_kernel_cmdline_config for previously.)
|
|
Currently, if a platform provides any network configuration via the
"cmdline" method (i.e. network-data=... on the kernel command line,
ip=... on the kernel command line, or iBFT config via /run/net-*.conf),
the value of the data source's network_config property is completely
ignored.
This means that on platforms that use iSCSI boot (such as Oracle Compute
Infrastructure), there is no way for the data source to configure any
network interfaces other than those that have already been configured by
the initramfs.
This change allows data sources to specify the order in which network
configuration sources are considered. Data sources that opt to use this
mechanism will be expected to consume the command line network data and
integrate it themselves.
(The generic merging of network configuration sources was considered,
but we concluded that the single use case we have presently (a) didn't
warrant the increased complexity, and (b) didn't give us a broad enough
view to be sure that our generic implementation would be sufficiently
generic. This change in no way precludes a merging strategy in future.)
|
|
- Update paramiko and cryptography module versions (2.4.2) to
address issues with algo and deprecation warnings.
- Modify ssh keypair generation to work with updated paramiko
- tools/xkvm sync with newer version from curtin
- Update NoCloudKvm instance.py to work with updated xkvm
- pass -name to instance, useful for debugging on shared host
- Add cache_mode platform config; default to cache=none,aio=native
- Switch to yaml.safe_load() in platforms.py
|
|
If input to network_state.parse_net_config_data was netplan (v2 yaml)
then the network state would lose the mtu information on bond or vlan.
LP: #1836949
|
|
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
|
|
Bump the version in cloudinit/version.py to be 19.2 and update ChangeLog.
LP: #1836921
|
|
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
|
|
The debian ntp.conf template did not contain a newline for the
comment used to mark the rendered ntp pools configured. This
resulted in an invalid line:
'# poolspool 0.int.pool.ntp.org iburst'
rather than:
'# pools
pool 0.int.pool.ntp.org iburst'
This patch fixes the template and updates the unittest to
verify that the rendered templates puts servers and pools
at the beginning of a line.
LP: #1836598
|
|
Support is for now implemented in such a way that it will fall back to
the old `_write_network()` if netplan is not available on the image.
|
|
|
|
With a large size ISO file attached to iso dev, ds-identify might
grep it entirely if iso dev is ISO9660, it takes very long time to
start OS.
Resolve this by:
- Adding a checker to read the ISO size (from sysfs). If
the size of the ISO filesystem is > 10MiB then the ISO will be
ignored (logged as oversized).
- Move the ovf vmware guest customization checker to be
ahead of cdrom ovf checker, so no need check the ISO size if vmware
guest customization is enabled.
LP: #1806701
|
|
cloud-init does not trigger reboots of a VM therefore adding custom
scripts to rc.local does not execute the post scripts. This patch
moves post-scripts into per-instance scripts dir and has cc_scripts
module run the post-scripts.
Also in this branch:
- Remove the sh interpreter and execute the customization script
directly.
- Update the unit test.
LP: #1833192
|
|
This branch introduces a new command line feature for cloud-init.
Currently, the cloud-init module has the capability to analyze events in
cloud-init.log in three ways: 'show', 'blame', 'dump'.
These changes add a fourth capability, called 'boot'.
Running the command 'cloud-init analyze boot' will provide the user three
timestamps.
1) Timestamp for when the kernel starts initializing.
2) Timestamp for when the kernel finishes its initialization.
3) Timestamp for when systemd activates cloud-init.
This feature enables cloud-init users to analyze different boot phases.
This would aid in debugging performance issues related
to cloud-init startup or tracking regression.
|
|
On Debian, ifupdown uses `source-directory /etc/network/interfaces.d`
(for new installs) to include files.
https://salsa.debian.org/debian/ifupdown/blob/master/debian/postinst#L23
The current filename, 50-cloud-init.cfg, does not match against the RE
that is used to scan the directory for configurations (ASCII upper- and
lower-case letters, ASCII digits, ASCII underscores, and ASCII
minus-hyphens):
https://salsa.debian.org/debian/ifupdown/blob/master/interfaces.5.pre#L122
Of course many installations use `source /etc/network/interfaces.d/*`,
but not all.
|
|
bonds may inherit mac address from a physical interface
LP: #1812857
|
|
* cc_lxd: fix copy/paste error in debug logging
* DataSourceCloudSigma: remove unreachable code
* This unreachable code was introduced in a refactor (in 2015) which
removed the need for an exception handler, but retained the logging
from the exception handler as an unreachable fall-through.
|
|
|
