Hi Blairo, Like you mention, I think one of the major reasons for have properties set at the image level is that certain properties depend on an OS which support the features involved. In this regard, being able to say that an image "supports" a particular feature, and then being able to set it on a per instance basis, would be useful.
On the other hand, having properties set at the image level makes sense, since you could configure the OS to support or require the feature in question, and then attach that feature to the image so that it was always there for instances booted with that image. Have properties set at the image level also aligns with the general idea of not specifying too many special things about a VM at boot time -- you specify a flavor, an image, and an SSH key pair (or use the default). Instead of having to say "what's the appropriate boot setup for the XYZ app", you just say "use the XYZ image" and you're all set (although this could be an argument for using Heat templates as well). Best Regards, Solly Ross ----- Original Message ----- > From: "Blair Bethwaite" <blair.bethwa...@gmail.com> > To: firstname.lastname@example.org > Sent: Tuesday, November 25, 2014 5:15:37 AM > Subject: [openstack-dev] [nova][glance] why do image properties control > per-instance settings? > > Hi all, > > I've just been doing some user consultation and pondering a case for > use of the Qemu Guest Agent in order to get quiesced backups. > > In doing so I found myself wondering why on earth I need to set an > image property in Glance (hw_qemu_guest_agent) to toggle such a thing > for any particular instance, it doesn't make any sense that what > should be an instance boot parameter (or possibly even runtime > dynamic) is controlled through the cloud's image registry. There is no > shortage of similar metadata properties, probably everything prefixed > "hw_" for a start. It looks like this has even come up on reviews > before, e.g. > https://review.openstack.org/#/c/43513/ > The last comment from DanielB is: > "For setting per-instance, rather than doing something that only works > for passing kernel command line, it would be desirable to have a way > to pass in arbitrary key,value attribute pairs to the 'boot' API call, > because I can see this being useful for things beyond just the kernel > command line." > > In some cases I imagine image properties could be useful to indicate > that the image has a certain *capability*, which could be used as a > step to verify it can support some requested feature (e.g., qemu-ga) > for any particular instance launch. > > Is there similar work underway? Would it make sense to build such > functionality via the existing instance metadata API? > > -- > Cheers, > ~Blairo > > _______________________________________________ > OpenStack-dev mailing list > OpenStackemail@example.com > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev