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 

1 files changed, 2 insertions, 0 deletions

diff --git a/cloudinit/distros/__init__.py b/cloudinit/distros/__init__.py
index 0f222c8c..3bfbc484 100644
--- a/cloudinit/distros/__init__.py
+++ b/cloudinit/distros/__init__.py
@@ -128,6 +128,8 @@ class Distro(object):
                                         mirror_info=arch_info)
 
     def apply_network(self, settings, bring_up=True):
+        # this applies network where 'settings' is interfaces(5) style
+        # it is obsolete compared to apply_network_config
         # Write it out
         dev_names = self._write_network(settings)
         # Now try to bring them up