== 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.

The 'dsmode' was a way for a user to indicate that this datasource 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'.

== Suggested Change ==
The plan is to 
 1. drop 'dsmode' entirely.
 2. apply any networking configuration from a datasource on first boot only
 3. always run init_modules at cloud-init (network) time frame.

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.

== 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.

--
[1] http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/config/cloud.cfg#L25