support cloud-init networking with snappy

Hmm.
You can disable cloud-init writing network config by putting config in /etc/cloud/cloud.cfg.d/ that says
  network:
    config: disabled

However, that will entirely disable cloud init writing networking information that the data source provided it with.

Currently that is openstack config drive or NoCloud.
But in the future it will be other sources. Basically, the cloud can provide the intended networking to the instance, and the instance should apply it.

2 options I can think of are
 1 adding function for cloud-init to not write 'fallback' networking config but still write carapace provided config
2 having cloud init read and render the snappy provided config

https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1563296

The short term fix is to disable cloud-init's networking code by
writing a file /etc/cloud/cloud.cfg.d/99-snappy-disable-network-config.cfg
with:
| network:
| config: "disabled"

The file is yaml text.

This unfortunately, will have two shortcomings:
 a.) ConfigDrive and other cases where the datasource provides network config will not have that networking rendered on snappy.
 b.) cloud-init has slightly smarter "fallback" config than snappy (to my limited knowledge).
if cloud-init does not find networking configuration from a source, then it defines a fallback as roughly equivalent to "dhcp on eth0" , but the 'eth0' name is chosen by finding an existing network device and filtering out those that are not connected.

Later we will have 2 options to re-enable this
1.) snappy could delegate writing of network config to cloud-init
2.) cloud-init could feed network config it found to snappy and let snappy write the config.

'2' could be accomplished via snappy REST interface or shell via:
   http://paste.ubuntu.com/15559735/

Having this happen via 'fallback' (and thus all the time) might mean that
cloud-init would overwrite what the gadget snap provided. So maybe for
fallback case, cloud-init would want to first query if there was gadget
provided config, and if not then provide the fallback.

This bug was fixed in the package livecd-rootfs - 2.395

---------------
livecd-rootfs (2.395) xenial; urgency=medium

  * create /etc/cloud/cloud.cfg.d/99-snappy-disable-network-config.cfg on
    snappy so we do not end up with broken network config after cloud-init
    ran (LP: #1563296).

 -- Oliver Grawert <email address hidden> Fri, 01 Apr 2016 16:31:50 +0200

Scott, that should be fix released in cloud-init as well right?