Open Stack

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
>    objections.

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.

-Eric