diff options
| author | Scott Moser <smoser@ubuntu.com> | 2016-05-25 17:05:09 -0400 | 
|---|---|---|
| committer | Scott Moser <smoser@ubuntu.com> | 2016-05-25 17:05:09 -0400 | 
| commit | 7f2e99f5345c227d07849da68acdf8562b44c3e1 (patch) | |
| tree | 54421fbe9dba1b6b4509c74f843bc46960d7f7a2 /cloudinit/sources/helpers/vmware/imc | |
| parent | 6115beae5f7b87f2dd684deec422f1b21d3cd4eb (diff) | |
| download | vyos-cloud-init-7f2e99f5345c227d07849da68acdf8562b44c3e1.tar.gz vyos-cloud-init-7f2e99f5345c227d07849da68acdf8562b44c3e1.zip  | |
commit to push for fear of loss.
== 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 
Diffstat (limited to 'cloudinit/sources/helpers/vmware/imc')
0 files changed, 0 insertions, 0 deletions
