| Age | Commit message (Collapse) | Author |
|---|
|
if get_smartos_environ() returned a None, then
the datasoure would raise a ValueError when get_data was called.
Fix that.
|
|
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 network config file is /etc/network/interfaces formated.
We will decode that here so that the user can expect that it is
a string. The issue was that it was bytes but convert_eni_data
was expecting a string.
|
|
|
|
|
|
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 didn't really work. See bug for more info.
LP: #1577844
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
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.
|
|
|
|
|
