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, 7 deletions

diff --git a/cloudinit/sources/DataSourceOpenStack.py b/cloudinit/sources/DataSourceOpenStack.py
index dfd96035..c06d17f3 100644
--- a/cloudinit/sources/DataSourceOpenStack.py
+++ b/cloudinit/sources/DataSourceOpenStack.py
@@ -33,13 +33,11 @@ DEFAULT_IID = "iid-dsopenstack"
 DEFAULT_METADATA = {
     "instance-id": DEFAULT_IID,
 }
-VALID_DSMODES = ("net", "disabled")
 
 
 class DataSourceOpenStack(openstack.SourceMixin, sources.DataSource):
     def __init__(self, sys_cfg, distro, paths):
         super(DataSourceOpenStack, self).__init__(sys_cfg, distro, paths)
-        self.dsmode = 'net'
         self.metadata_address = None
         self.ssl_details = util.fetch_ssl_details(self.paths)
         self.version = None
@@ -125,11 +123,8 @@ class DataSourceOpenStack(openstack.SourceMixin, sources.DataSource):
                         self.metadata_address)
             return False
 
-        user_dsmode = results.get('dsmode', None)
-        if user_dsmode not in VALID_DSMODES + (None,):
-            LOG.warn("User specified invalid mode: %s", user_dsmode)
-            user_dsmode = None
-        if user_dsmode == 'disabled':
+        self.dsmode = self._determine_dsmode([results.get('dsmode')])
+        if self.dsmode == sources.DSMODE_DISABLED:
             return False
 
         md = results.get('metadata', {})