| Age | Commit message (Collapse) | Author |
|---|
|
bigger things here:
* fix the checking for stop_files.
the check for no-net actually checked the size of the file
and the implementation was just touching it. so it never would
have been found. no-net is valid only in upstart anyway.
do not stop early on presense of the obj_pkl but check it.
this is required since we write the obj_pkl on exit when
local mode finds a datasource but found in network mode.
* use 'mode' rather than checking args.local.
set mode to be sources.DSMODE_NETWORK or sources.DSMODE_LOCAL
for easier / more consistent checking.
* log exit paths.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
packages/bddeb failed to work after flake8 and hacking were added to
test-requirements.txt. The necessary fix is just to know about the
debian package names for those pypi packages.
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
|
|
Note that runcmd runs only on first boot.
Note that strings need to be quoted, not escaped.
Switch bootcmd list text to use - not * like everything else.
|
|
Timeouts and retries were triggering so make it so
that tests do not use the typical timesouts and retries
so that the tests finish faster.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
If no timestamp was passed into a ReportingEvent, then the default was
used. That default was 'time.time()' which was evaluated once only at
import time.
|
|
If the datasource's instance id contained a '/' then the instance_id path
would not be as expected under /var/lib/cloud/instances/instance_id.
LP: #1575938
|
|
After reboot cloud-init would fail as the previously pickled object
would have a check_instance_id signature but it didn't match expected
LP: #1575055
|
|
LP: #1576273
|
|
r1213 (Ensure instance path is a child of cloud_dir) stripped the
leading path separator. This patch goes further by replacing all
path seperators with '_' which will avoid a deep directory structure
under /var/lib/cloud/instances.
LP: #1575938
|
|
It could be that there are also 'dhclient6.leases' files in /var/lib/dhcp
when DHCPv6 is used next to DHCPv4.
This patch makes sure we only read from DHCPv4 lease files
|
|
A cloud has an instance-id metadata value in the form:
/Compute-$TENANT/$CLOUDUSERNAME/$UUID
The leading '/' causes /var/lib/cloud/instance to link to
/Compute-$TENANT/$CLOUDUSERNAME/$UUID rather than
/var/lib/cloud/instances/Compute-$TENANT/$CLOUDUSERNAME/$UUID
This patch strips the leading path separator from the instance-id.
LP: #1575938
|
|
When ip= on the kernel command line defines the networking, set
those network devices to be manually controlled, instead of 'auto'.
The reason for this is that if they're marked as 'auto':
a.) a second attempt will be made to ifup them.
b.) they'll be brought down on shutdown
'b' is problematic on network root filesystem.
Also this picks up 2 changes from curtin's net module:
- Cleanup newline logic so we always have a clean '\n\n' between stanza
- Add a unittest to validate bonding network config render, specifically
when to emit auto $iface for dependent bond slaves.
LP: #1568637
|
|
|
|
when reading the initramfs configurewd devices and turning them
into network config, we change to not have 'auto' control (or allow=auto).
The reason for this is that if the device was still up:
a.) it would try to bring it up again (due to bug 1570142)
b.) it would be brought down.
'b' is problematic if there is an iscsi or network root filesystem.
Note, that ifupdown does now support 'no-auto-down' which means
that the nic should not be brought down on 'ifdown -a'.
LP: #1568637
|
|
This picks up newline cleanup and some bond fixes from curtin at rev 374.
- Cleanup newline logic so we always have a clean '\n\n' between stanza
- Add a unittest to validate bonding network config render, specifically
when to emit auto $iface for dependent bond slaves.
|
|
Do not apply networking configuration whenever a previous datasource
has been loaded from disk and found to be valid (via positive
return 'check_instance_id' or user configuration of manual_cache_clean).
This effectively means that we apply fallback networking only once
per instance rather than every boot on any datasource with
'check_instance_id' implemented.
LP: #1571004
|
|
|
|
This attempts to only apply the networking once per instance
by doing so only if the datasource was restored from disk.
This will work by default for datasources with a functioning
check_instance_id or if the user has set manual_cache_clean to true.
|
|
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
|
|
Just skip devices that are named veth*.
The fix here is to ignore lxd created devices, but any other veth
device that is created at this point in boot is probably not the
right interface to dhcp on.
LP: #1569064
|
|
This simply allows the phone_home template to pass the systems fully
qualified domain name.
LP: #1566824
|
|
Now, validation_key is always a path to a file, as it is in
chef's client.rb syntax.
validation_cert is always the *content* of that file that should
be written. However, if validation_cert is the string "system",
then we do not write that value, but rather assume the file exists.
LP: #1568940
|
|
It does not make sense to consider bridges when searching for fallback
networking. If the system is configured with a bridge, then its probably
for some purpose other than to get to a metadata service.
Considering the bridge could make cloud-init pick the wrong device on reboot.
LP: #1569974
|
