[Openstack] server affinity
eday at oddments.org
Wed Mar 2 19:39:58 UTC 2011
On Wed, Mar 02, 2011 at 10:27:33AM -0800, Justin Santa Barbara wrote:
> I'm not wedded to the idea of putting "service metadata" into the same
> collection as "user metadata"; it just seems like a reasonable approach to
> me. *But it's more important to me that we agree on something, than that
> we agree on the "best" thing!
Hopefully the two are the same. :)
> > If in a key/value list, should existing instance properties be
> moved*into this format as well?
> -1 (for now): We'd still have to support the separate properties for the
> front end APIs. *We'd probably not want to refactor the database schema.
> *However, the code can internally harmonize all the properties into a
> single collection, which might make routing & processing requests easier.
> *We could also support passing e.g. the instance types through the
> key/value collection instead of the 'legacy' explicit parameter method in
> the OpenStack API. However, I don't think we should change anything here
> yet, until we have a clear rationale for doing so. *(Though this rationale
> might arise quickly, e.g. multi-cluster-in-a-region)
Yeah, this is nasty and probably won't or shouldn't happen, but I
thought I'd mention it. We may want to define 'core-properties' as
those already in the instance table (along with others worthy of it)
and 'service-metadata' as things not referenced directly in the core
code, but used in plugin hooks like the scheduler. User-metadata is
never referenced by nova code.
> >*If in a key/value list, should it just be a prefix in a general*metadata
> list (and user metadata has a 'user' prefix)?
> +1, but I don't think that we should require user metadata to be prefixed
> (at least externally!) *We should reserve the "aws:" and "openstack:"
> prefixes asap. *I'm going to propose a doc change to reserve the "aws:"
> prefix - I think we have no choice in the matter, and I haven't seen any
To clarify, the user would not need to apply the prefix or
ever see it, that's just an internal thing we add/remove when
processing requests. Without an internal prefix, a user could add
'openstack:...=...' and possibly confuse things, so always having an
internal prefix allows our metadata handling methods remain simple.
More information about the Openstack