On 06/10/2014 05:21 PM, Lars Kurth wrote:
== #4 Cloud Image from Cloud Image SIG == We could rely on pre-built cloud images from the Cloud Images SIG. People could just download the cloud image once it's done and customize it, rather than installing / building their own.
Advantages: seems easy
Disadvantages: coordination with Cloud Images SIG. May not be flexible enough
We ship a test/devel grade CentOS-6-x86_64-pv image ( well, its a qcow2 image, should work for pvhvm as well, the fstab is label driven ).[1]
The biggest problem in doing pre-baked images is the instance metadata. We need to find an easy way to get network settings into the instance and the root password ( or key ), and finally - in some cases, console redirection/setup, but i dont think the console is a deal breaker or a big deal. The network and access credentials however are.
In a typical cloud environ this info would come from the cloud controller's metadata service; on a typical virtualised setup though this becomes an issue ( and isnt really Xen specific ).
We could work around this by making some assumptions, we could 'own' dnsmasq and ensure that either libvirt is running and doing dhcp, otherwise we do the dhcp with some sane defaults, or we setup a script to 'instantiate image', which asks how the user wants to setup the instance ( pvhvm, hvm, pv ), the root password or key to use, and the network settings ( and if this is run on the dom0, we could even ask what bridge or device to connect with as well as the settings ).[2]
Ofcourse, having these images pushed from here mean that clouds or virtualised environs that have metadata services are able to just-use the image as is, not needing any more tooling etc. And we can easily push monthly image updates and when things like heartbleed come around, there is a single place we need to update.
- KB [1]: http://cloud.centos.org/centos/6/devel/
[2] might need to pull in all of libguestfs to make the changes, which in turn has its own challenges if run inside a virtualised environ.