Open Stack

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.

+1

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?

John