Installs from a curtinator-created image use latest kernel

[Rod Smith]

MAAS causes nodes it deploys to download and install the latest kernel. (This is done by the /usr/lib/python2.7/dist-packages/curtin/commands/curthooks.py script on the MAAS server.) The result is that using curtinator to create an image of an older distribution (say, 12.04.1) results in a node being brought up with all of the appropriate software versions for that release *EXCEPT* for the kernel, which is likely to be the latest kernel available for that series. From our (server certification) point of view, this is undesirable behavior, since we want the nodes to the use the kernel associated with the specific point release whose image we're building.

Currently, our workaround has been to patch curtinator's data/preseed.txt file to download an override script to be installed in the image (at /target/curtin/curtin-hooks). The modified preseed.txt file and curtin-hooks script are at:

http://people.canonical.com/~rodsmith/maas-certification-images/preseed.txt
http://people.canonical.com/~rodsmith/maas-certification-images/curtin-hooks

A cleaner solution would be to have curtinator place /target/curtin/curtin-hooks into the images directly. One possible complication, of either my workaround or proposed curtinator change, is that if MAAS changes its scripts, curtin-hooks may need to be updated, too.

Of course, this assumes that the intent of curtinator is to give the user complete control over the software to be installed, including the kernel version. If the intent is that MAAS's behavior with respect to the kernel be honored, then this isn't really a bug.

[Daniel Manrique (roadmr)]

I think curtin is pretty stable and placing a hook in the image itself (/curtin/curtin-hooks) is a reasonable approach, not much of a chance of curtin changes affecting us.

curtinator could do this directly on the received tarball, we have more flexibility and control than what can be achieved in the preseed.

I hadn't noticed this behavior since at the moment, all I've been doing is ensuring that the system boots correctly after maas provisioning; but for our use case, we also want to boot with the image's own kernel, for certification purposes (although for certification we mostly care about the latest point release so it may not be such a big issue for us).