cloud-init-dev team mailing list archive

[Scott Moser <smoser@xxxxxxxxxx>]

The proposal to merge lp:~smoser/cloud-init/trunk.fix-networking into lp:cloud-init has been updated.

Description changed to:

I'll improve this description later. 

  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


For more details, see:
https://code.launchpad.net/~smoser/cloud-init/trunk.fix-networking/+merge/296272
-- 
Your team cloud init development team is requested to review the proposed merge of lp:~smoser/cloud-init/trunk.fix-networking into lp:cloud-init.