Open Stack

Seconded (in the generic form, not just for kernel arguments; I'm sure
there are other things that we might want to tweak about the machine
pre-boot in the longer term, as we already do with such things as config
disks and file injection).  You may want to have a property in glance that
indicates that, for a given image, you should respect the kernel args
parameter, though.

Your proposal is libvirt specific.  There's no real reason for it to be.


On 6 February 2013 16:30, Daniel P. Berrange <berrange at redhat.com> wrote:

> On Wed, Jan 30, 2013 at 02:13:29PM +0000, Daniel P. Berrange 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.
>
> Does anyone else have an opinion on the design of this proposal ?
>
> 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:|
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130208/e7542c71/attachment.html>