(mirror of https://github.com/marekm72/vyos-cloud-init.git) https://git.amelek.net/marekm72/vyos-cloud-init.git/atom?h=20.3 2016-06-14T21:56:51+00:00 2016-06-14T21:56:51+00:00 Joshua Harlow harlowja@gmail.com 2016-06-14T21:56:51+00:00 urn:sha1:93afde09d89e60c29dfd20790e30a06f031c82e1 This allows for the test_cli test to be more sane. 2016-05-31T21:17:39+00:00 Scott Moser smoser@ubuntu.com 2016-05-31T21:17:39+00:00 urn:sha1:1b8a09389654a29af7e618b803bffaed0185e9e8 currently does not work in lxc https://github.com/lxc/lxd/issues/2063 2016-05-26T19:51:09+00:00 Scott Moser smoser@ubuntu.com 2016-05-26T19:51:09+00:00 urn:sha1:c21ef05925954e5781c793429316cd4eff64ee37 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. 2016-05-26T14:50:32+00:00 Scott Moser smoser@ubuntu.com 2016-05-26T14:50:32+00:00 urn:sha1:f358f286dc4887fc40b5e2ad370dc35d46905121 2016-05-26T00:36:40+00:00 Scott Moser smoser@ubuntu.com 2016-05-26T00:36:40+00:00 urn:sha1:443df65a45e42c354b8eb7638528970adf036290 2016-05-25T21:05:09+00:00 Scott Moser smoser@ubuntu.com 2016-05-25T21:05:09+00:00 urn:sha1:7f2e99f5345c227d07849da68acdf8562b44c3e1 == 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 2016-04-15T17:54:05+00:00 Scott Moser smoser@ubuntu.com 2016-04-15T17:54:05+00:00 urn:sha1:53931ee132f0d236e3ed1b7fd6e0e0b519f40bda 2016-04-15T16:16:14+00:00 Scott Moser smoser@ubuntu.com 2016-04-15T16:16:14+00:00 urn:sha1:79b59658dfdc0172818c54e3c7149e6ed914a93b 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. 2016-03-29T17:43:14+00:00 Scott Moser smoser@ubuntu.com 2016-03-29T17:43:14+00:00 urn:sha1:30d8a1f2336f9e05b047136903d47025fdf28f5a 3 things here: a.) do not raise exception, only warn when trying to apply a network config for a distro that does not have an implementation. This is important since debian/ubuntu is the only one *with* an implementation at the moment b.) apply network config in 'cloud-init --local' even if there is no datasource found. c.) do not write 70-persistent-net.rules the code was writing both 70-persistent-net.rules and /etc/systemd/network/50-cloud-init-*.link files that would just be confusing. 2016-03-23T14:31:11+00:00 Scott Moser smoser@ubuntu.com 2016-03-23T14:31:11+00:00 urn:sha1:5b3cad36be8981cd12cffdf5c5e539b522404000 This fixes a bug where modules mode was not passing a 'existing' flag to fetch. fetch had existing default to 'check'. The DataSourceNoCloud when fed with data from a disk will return False to check() as it is not a guarantee'd hit. That caused fetch to go looking for a new datasource. That would have actually worked, but modules and single create the Init with deps=[]. So it went looking for Datasources that matched those deps, and only found DataSourceNone. I'm going to keep having modules and single specify deps=[] as that will prevent them from going to look for a DS and further making things worse.