Open Stack

> 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