| Age | Commit message (Collapse) | Author |
|---|
|
This adds support for reading networking information from the
SmartOS metadata service and applying.
|
|
|
|
if local does not find a datasource, then we try to apply networking.
but that would then hit the NULL_DATA_SOURCE which does not work
with is_new_instance. avoid that.
|
|
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
|
|
|
|
|
|
This was broken for keys already existing in the local keyring.
There instead of the keycontent it reported the header like:
pub 1024R/03683F77 2009-10-27
uid Launchpad PPA for Scott Moser
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
i dont want to expose this as i'd rather have some json there
or write to /run/cloud-init/status.json . would also like to indicate
'first_boot' somewhere.
|
|
configdrive
|
|
|
|
|
|
|
|
|
|
the fix for instance_id is clear and necessary.
making instancify write the cache is required for how we are having
the local datasource be relevant.
|
|
previously, if you did: paths.get_ipath("bogus")
it would silenetly hand you back just the directory. now it
will fail, which seems much more sane.
|
|
|
|
settings on the kernel command line (cc:) were documented to override
all local settings, but a bug in implementation meant they would only
override those that are in /etc/cloud/cloud.cfg, not any found in
/etc/cloud/cloud.cfg.d.
LP: #1582323
|
|
|
|
== 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
|
|
|
|
The change to get_instance_userdata is to fix an issue that
was causing retry in the test when it was not desired.
if user_data returned 404 it means "there was no user-data", so
dont bother retrying. However, _skip_retry_on_codes was returning
False indicating that readurl should retry.
test_merging was creating 2500 random tests, shrink that down to 100.
test_seed_runs is still on my system the slowest test, but
taking < .5 seconds where it was taking > 3.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
key is the filename, and "old" input shall be handled as it was all the time.
For compatibility this will (continue to) overwrite the file of multiple
options that did not specify an output file (they all get the same default).
Yet it will process them all - as it always did - e.g. to add the keys of all
of them.
Any users of the new format won't have these issues, as they will always have
a key.
|
|
|
|
|
|
This allows it to be used outside of cloudinit
more easily in the future.
|
