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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
