> 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 [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
