[openstack-dev] [Nova][Docker] Environment variables

Daniel P. Berrange berrange at redhat.com
Tue Dec 17 12:53:55 UTC 2013

On Mon, Dec 16, 2013 at 01:04:33PM -0800, Dan Smith wrote:
> > eg use a 'env_' prefix for glance image attributes
> > 
> > We've got a couple of cases now where we want to overrides these
> > same things on a per-instance basis. Kernel command line args
> > is one other example. Other hardware overrides like disk/net device
> > types are another possibility
> > 
> > Rather than invent new extensions for each, I think we should
> > have a way to pass arbitrary attributes alon with the boot
> > API call, that a driver would handle in much  the same way as
> > they do for glance image properties. Basically think of it as
> > a way to custom any image property per instance created.
> Personally, I think having a bunch of special case magic namespaces
> (even if documented) is less desirable than a proper API to do something
> like this. Especially a namespace that someone else could potentially
> use legitimately that would conflict.
> To me, this feels a lot like what I'm worried this effort will turn
> into, which is making containers support in Nova look like a bolt-on
> thing with a bunch of specialness required to make it behave.

NB I'm not saying that everything related to containers should be done
with metadata properties. I just feel that this is appropriate for
setting of environment variables and some other things like kernel
command line args, since it gives a consistent approach to use for
setting those per-image vs per-instance.

> Anyone remember this bolt-on gem?
> nova boot --block-device-mapping
> vda=965453c9-02b5-4d5b-8ec0-3164a89bf6f4:::0 --flavor=m1.tiny
> --image=6415797a-7c03-45fe-b490-f9af99d2bae0 BFV
> I found that one amidst hundreds of forum threads of people confused
> about what incantation of magic they were supposed to do to make it
> actually boot from volume.

Everything about the way you use block device mapping is plain
awful - even the bits that were done as "proper" API extensions.
I don't think the design failures there apply in this case.

If we do env variables as metadata properties, then you may well
not end up even needing to pass them to 'nova boot' in the common
case, since it'll likely be sufficient to have them just set against
the image in glance most of the time.

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

More information about the OpenStack-dev mailing list