On 17 December 2013 12:53, Daniel P. Berrange <[email protected]> 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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
