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

Daniel Kuffner daniel.kuffner at gmail.com
Tue Dec 17 12:46:15 UTC 2013

Actually Daniel P. Barrange comment is interesting. He states that a
configuration per instance would also be beneficial for Cinder. The
configuration is essentially needed to change the bootstrap of the
image. If you look at a docker image in abstract way then that is the
same thing - a configuration to bootstrap the image differently.

>From user point of view it could look like:
     nova boot --image-meta <key=value>


On Mon, Dec 16, 2013 at 10:04 PM, Dan Smith <dms at danplanet.com> 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.
> 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.
> Just MHO.
> --Dan
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list