SUSE: Fix groups used for ownership of cloud-init.log
On SUSE distributions the neither the "adm" nor the "wheel" group are set
up by default causing log file permission change to fail. Set the
user:group to root:root in the cloud-init default config file generated
during install.
ds-identify: check /writable/system-data/ for nocloud seed.
Ubuntu core seeds information to nocloud via a bind-mount of
/writable/system-data/var/lib/cloud over /var/lib/cloud.
When ds-identify runs as a systemd generator that mount is not
guaranteed to have been done. It is guaranteed at
cloud-init-local.service time, but not generator time.
Images built with 'ubuntu-image --cloud-init=user-data-file'
would have cloud-init disabled.
The fix here is just to consider the seed dir under /writable/system-data.
This changes tools/run-centos to collect up your git working directory
via 'git' commands rather than just collecting the whole directory.
The reason for this is that even a clean tree that has had tox run
on it might have up to 400M of data in it.
It adds a '--dirty' flag to run-centos to collect up local changes.
tests: add support for logs with lxd from snap and future lxd 3.
This puts in place detection for if 'show-log' will work with lxc
client, and uses that if present. The 'lxc console --show-log' is
not expected to work until lxd/liblxc3.0. That should come in a
few months. The hope is that when that function arrives, this
code will move over to using it.
For other scenarios (all current lxd installs) this will now
support getting logs from a snap installed lxd or a package installed
lxd via the old 'lxc.console.logfile'.
If installed from snap, a platform error will be raised until
the user does:
sudo mkdir --mode=1777 -p /var/snap/lxd/common/consoles
EC2: Fix get_instance_id called against cached datasource pickle.
Fix an issue in EC2 where the datasource.identity had not been
initialized before being used when restoring datasource from pickle.
This is exposed in upgrade and reboot path.
cli: fix cloud-init status to report running when before result.json
Fix various corner cases for cloud-init status subcommand. Report
'runnning' under the following conditions:
- No /run/cloud-init/result.json file exists
- Any stage in status.json is unfinished
- status.json reports a non-null stage it is in progress on
net: accept network-config in netplan format for renaming interfaces
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.
docs: Update RTD content for cloud-init subcommands.
Give a bit more detailed information which others can quickly reference to
discover new CLI subcommand functionality. This section was a bit stale as
we've introduced cloud-init status, clean and analyze content that was a
bit under represented. Since we've had a few request of externals who try
to run cloud-init subcommands on the commandline instead of rebooting,
it's probably worth a bit of content here to describe how those init and
module subcommands work.