Open Stack

On Wed, Jan 30, 2013 at 04:10:44PM +0000, Brian Lamar wrote:
> 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'
> > time.
> > 
> >  https://blueprints.launchpad.net/nova/+spec/custom-kernel-args
> >  http://wiki.openstack.org/LibvirtCustomKernelArgs
> > 
> > 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.
> 
> 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?

As I mention in the blueprint, I think it is reasonable for glance to
hold a list of kernel-args against any kernel image that is uploaded.

This on its own though is insufficient. Some kernel args are going to
be inherantly different for each instance launched and we do not want
to have to store many copies of the same kernel with different args
in glance. eg if we're using kernel args to pass custom data into an
OS installer for provisioning an OS install.

> 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).

This doesn't even need anything done in glance - we can just use the
generic 'properties' dict to store this metadata. Well, ok, it is a
docs issue to detail what "well known" properties we allow. Codewise,
only the nova virt drivers need updating. This is what I describe in
the blueprint above.

Daniel
-- 
|: 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 :|