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, 12 insertions, 8 deletions

diff --git a/bin/cloud-init b/bin/cloud-init
index 5857af32..482b8402 100755
--- a/bin/cloud-init
+++ b/bin/cloud-init
@@ -236,6 +236,7 @@ def main_init(name, args):
         else:
             LOG.debug("Execution continuing, no previous run detected that"
                       " would allow us to stop early.")
+
     else:
         existing = "check"
         if util.get_cfg_option_bool(init.cfg, 'manual_cache_clean', False):
@@ -265,17 +266,20 @@ def main_init(name, args):
             else:
                 return (None, ["No instance datasource found."])
 
-    if args.local:
-        if not init.ds_restored:
-            # if local mode and the datasource was not restored from cache
-            # (this is not first boot) then apply networking.
-            init.apply_network_config()
-        else:
-            LOG.debug("skipping networking config from restored datasource.")
-
     # Stage 6
     iid = init.instancify()
     LOG.debug("%s will now be targeting instance id: %s", name, iid)
+
+    if init.is_new_instance():
+        # on new instance, apply network config.  if not in local mode,
+        # then we just bring up new networking as the OS has already
+        # brought up the configured networking.
+        init.apply_network_config(bringup=not args.local)
+
+    if args.local and init.datasource.dsmode != sources.DSMODE_LOCAL:
+        return (init.datasource, [])
+
+    # update fully realizes user-data (pulling in #include if necessary)
     init.update()
     # Stage 7
     try: