[openstack-dev] RFC: custom metadata per VM instance at boot time (eg for kernel args)
brian.lamar at rackspace.com
Wed Jan 30 16:10:44 UTC 2013
On Jan 30, 2013, at 8:13 AM, "Daniel P. Berrange" <berrange at redhat.com> wrote:
> I have a need to be able to provide custom kernel command line args per
> VM instance at boot time. For example, if glance is storing a kernel and
> initrd pair associated with the Fedora installer, it is neccessary to
> also provide a command line arg to tell the installer where to download
> a kickstart automation script from, or where the install tree is located.
> While some of this data could be stored in glance as metadata properties
> against the 'kernel' image, some it is inherantly data that changes per
> VM instance spawned. Thus I need some way to provide it at 'nova boot'
> Two approaches come to mind for me
> - Add an explicit 'kernel-args' parameter to the 'nova boot' command
> and corresponding REST/RPC APIs
> - Add a generic 'properties' dict parameter to the 'nova boot' command
> and corresponding REST/RPC APIs, and define a standard property
> name 'kernel-args'.
> I'm figuring the latter would be preferrable since it gives us an
> extensible framework for instance metadata. NB, this is separate
> from metadata that you can alrady provide to feed through to the
> cloud-init services via config-drive / metadata service. It is
> metadata intended for interpretation by Nova itself, where as the
> existing metadata is for interpretation by the guest OS.
> |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org -o- http://virt-manager.org :|
> |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
This is definitely something we're missing and is definitely needed. That being said I don't know it's the place of nova to take on the responsibility of handling kernel args. Shouldn't this be a glance responsibility to hold and provide kernel-args for an image?
The way I see it, if an image has a type of "aki" then it's a kernel and you should be able to set a kernel-args property on it. That property can be read by nova at boot time but can only be set on kernel images. This adds one new construct to glance (the ability to set kernel-args on glance images with type 'aki') and one new construct to nova (the ability to see which images have the kernel-args property set and use it during boot time).
Thoughts? There might be other use cases I'm not thinking about,
More information about the OpenStack-dev