[openstack-dev] [nova][glance] why do image properties control per-instance settings?
sross at redhat.com
Tue Nov 25 16:16:51 UTC 2014
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).
----- Original Message -----
> From: "Blair Bethwaite" <blair.bethwaite at gmail.com>
> To: openstack-dev at lists.openstack.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.
> 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?
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev