[openstack-dev] [Nova][Docker] Environment variables
john at johngarbutt.com
Thu Dec 19 14:23:20 UTC 2013
On 17 December 2013 12:53, Daniel P. Berrange <berrange at redhat.com> wrote:
> 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.
+1 it seems a fairly nice mapping for kernel args and environment variables.
Cloud-Init could add the environment variable inside VMs if we felt
that way inclined.
Discoverability isn't awesome though.
>> 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.
Going further, we set PV vs HVM via image properties. It would be nice
to override that on a per boot basis that matches these other cases.
Some generic way of setting a "per-boot" equivalent of an image
property might be the best approach? Going back to glance protected
properties, we would need a Nova equivalent. But prehaps a whitelist
of properties you can override on boot would be best?
More information about the OpenStack-dev