Enable filesystem creation on Azure, many disk_setup cleanups

There are a lot of cleanups here around Azure, SmartOS and disk_setup.
disk_setup correctly identifies disk "aliases" (block device mappings
from ec2), anywhere where you would use a device name.

You can also specify these mappings to the Azure or SmartOS datasource
in their datasource config (device_aliases).

Also, stop Azure from calling blkid repeatedly in its tests, which
really pounded my laptop.

2 files changed, 63 insertions, 27 deletions

diff --git a/doc/examples/cloud-config-disk-setup.txt b/doc/examples/cloud-config-disk-setup.txt
index db2c52a7..3fc47699 100644
--- a/doc/examples/cloud-config-disk-setup.txt
+++ b/doc/examples/cloud-config-disk-setup.txt
@@ -19,36 +19,36 @@ Default disk definitions for AWS
 
 Default disk definitions for Windows Azure
 ------------------------------------------
-(Not implemented yet due to conflict with WALinuxAgent in Ubuntu)
 
+device_aliases: {'ephemeral0': '/dev/sdb'}
 disk_setup:
-    /dev/sdb:
+    ephemeral0:
          type: mbr
          layout: True
          overwrite: False
 
 fs_setup:
     - label: ephemeral0
-      filesystem: ext3
+      filesystem: ext4
       device: ephemeral0
-      partition: any
+      partition: auto
 
 
 Default disk definitions for SmartOS
 ------------------------------------
 
-ephemeral_disk: /dev/vdb
+device_aliases: {'ephemeral0': '/dev/sdb'}
 disk_setup:
-    /dev/vdb:
+    ephemeral0:
          type: mbr
-         layout: True
+         layout: False
          overwrite: False
 
 fs_setup:
     - label: ephemeral0
       filesystem: ext3
-      device: /dev/vdb
-      partition: 1
+      device: ephemeral0
+      partition: auto
 
 Cavaut for SmartOS: if ephemeral disk is not defined, then the disk will
     not be automatically added to the mounts.
@@ -188,13 +188,43 @@ Where:
         of the ephemeral storage layer.
 
     <PART_VALUE>: The valid options are:
-        "auto": auto is a special in the sense that you are telling cloud-init
-            not to care whether there is a partition or not. Auto will put the
-            first partition that does not contain a file system already. In
-            the absence of a partition table, it will put it directly on the
-            disk.
-
-        "none": Put the partition directly on the disk.
+        "auto|any": tell cloud-init not to care whether there is a partition
+            or not. Auto will use the first partition that does not contain a
+            file system already. In the absence of a partition table, it will
+            put it directly on the disk.
+
+            "auto": If a file system that matches the specification in terms of
+            label, type and device, then cloud-init will skip the creation of
+            the file system.
+
+            "any": If a file system that matches the file system type and device,
+            then cloud-init will skip the creation of the file system.
+
+            Devices are selected based on first-detected, starting with partitions
+            and then the raw disk. Consider the following:
+                NAME     FSTYPE LABEL
+                xvdb
+                |-xvdb1  ext4
+                |-xvdb2
+                |-xvdb3  btrfs  test
+                \-xvdb4  ext4   test
+
+            If you ask for 'auto', label of 'test, and file system of 'ext4'
+            then cloud-init will select the 2nd partition, even though there
+            is a partition match at the 4th partition.
+
+            If you ask for 'any' and a label of 'test', then cloud-init will
+            select the 1st partition.
+
+            If you ask for 'auto' and don't define label, then cloud-init will
+            select the 1st partition.
+
+            In general, if you have a specific partition configuration in mind,
+            you should define either the device or the partition number. 'auto'
+            and 'any' are specifically intended for formating ephemeral storage or
+            for simple schemes.
+
+        "none": Put the file system directly on the device.
 
         <NUM>: where NUM is the actual partition number.
 
diff --git a/doc/sources/smartos/README.rst b/doc/sources/smartos/README.rst
index e2d3312e..8b63e520 100644
--- a/doc/sources/smartos/README.rst
+++ b/doc/sources/smartos/README.rst
@@ -73,15 +73,21 @@ or not to base64 decode something:
         (i.e. /etc/cloud/cloud.cfg.d) that sets which values should not be
         base64 decoded.
 
-ephemeral_disk:
+disk_aliases and ephemeral disk:
 ---------------
-
-In order to instruct Cloud-init which disk to auto-mount. By default,
-SmartOS only supports a single ephemeral disk.
-
-The default SmartOS configuration will prepare the ephemeral disk and format
-it for you. SmartOS does not, by default, prepare the ephemeral disk for you.
-
-If you change ephemeral_disk, you should also consider changing
-the default disk formatting parameters. See
-doc/examples/cloud-config-disk-setup.txt for information on using this.
+By default, SmartOS only supports a single ephemeral disk.  That disk is
+completely empty (un-partitioned with no filesystem).
+
+The SmartOS datasource has built-in cloud-config which instructs the
+'disk_setup' module to partition and format the ephemeral disk.
+
+You can control the disk_setup then in 2 ways:
+ 1. through the datasource config, you can change the 'alias' of
+    ephermeral0 to reference another device. The default is:
+      'disk_aliases': {'ephemeral0': '/dev/vdb'},
+    Which means anywhere disk_setup sees a device named 'ephemeral0'
+    then /dev/vdb will be substituted.
+ 2. you can provide disk_setup or fs_setup data in user-data to overwrite
+    the datasource's built-in values.
+
+See doc/examples/cloud-config-disk-setup.txt for information on disk_setup.