FFE: curtin enhancements for 14.04

[Scott Moser]

[Description]
Curtin is the fast path installer, used primarily by maas for installing a pre-made root filesystem onto disk.
These changes are necessary to put curtin closer to function-parity with d-i and/or to support MAAS development.

[Proposed Changes]
We expect to add the following features to curtin:
 * specifying through configuration a kernel to be installed into the image. This will allow HWE kernels to be selected.
 * LVM/Raid support: basic support for configuring volumes in a raid or lvm
 * non-destructive install: currently curtin wipes all disks. It needs to be able to be told to leave some disks un-modified
 * kexec support: support for using kexec to boot into the installed system rather than reboot
 * config-archive support: allow a single config file to contain multiple parts. This will just look like cloud-init's "cloud-config-archive". It all
ows multiple parties to add config without messing up others.

[Dave Walker (davewalker)]

The d/changelog of the uploaded package doesn't seem to mention the config-archive support. However, I see it present in the diff.

However, I don't see the LVM/Raid support. Is that present in curtin_0.1.0~bzr95-0ubuntu2_0.1.0~bzr121-0ubuntu1, or is that still planned?

Separately, I see the KERNEL_MAPPING update. Would it be prudent to consider putting this data in distro-info, making enablement kernels easier to update, rather than uploading a new curtain each time?

Package accepted, awaiting update on LVM/Raid feature, before closing bug.

[Scott Moser (smoser)]

0.1.0~bzr121-0ubuntu1 is in trusty-proposed as of 2 minutes ago.
it contains all but LVM/RAID that are listed in this FFE

[Scott Moser (smoser)]

<Daviey> smoser: Have you thought about how to update it in a timely manner as SRU?
<Daviey> ie, it needs to be co-ordinated, right?
<smoser> well, only kinda-sorta
<smoser> the fallback is "do nothing"
<smoser> and that will work fine for 14.10, 15.04, and 15.10 and even 16.04
<smoser> the place it fails is hwe kernels.
<smoser> so yeah, the package would have to be updated to address that.
<smoser> but the user can in their maas update that.
<smoser> ie, they can provide config. so its not *terrible*
<smoser> and we can actually release the update as soon as the kernel version for a given release is known.
<smoser> ie, as soon as kernel team says "we're using 3.15 for 14.10" we can push that curtin update.
<smoser> the update doesn't actually *have* to happen until the hwe-u kernel for 14.04 is available.