This is an excellent point, Mark, I'd forgotten about the quota system for user-defined (and nova-ignored) "metadata" items. That does throw a bit of a wrench into the mix. Perhaps a small edit to the instance_metadata table to add a column for is_user_added that can be used to segregate metadata items that Nova itself uses to track certain things?
-jay On Thu, Apr 14, 2011 at 10:01 AM, Mark Washenberger <mark.washenber...@rackspace.com> wrote: >> 1) Continue to add fields to the instances table (or compute_nodes >> table) for these main attributes like cpu_arch, etc. >> 2) Use the custom key/value table (instance_metadata) to store these >> attribute names and their values >> 3) Do both 1) and 2) > > I've no particular preference here, but if we start adding attributes to > instance_metadata that nova code specifically knows about, we need to ensure > there is a good way to tell the difference between "nova" metadata and "user" > metadata. I do not believe key prefixes will provide this difference cleanly. > > Currently, instance_metadata is for user-provided attributes only and nova is > agnostic to their contents. In the api, they are presented as such, and there > are quotas on the number of metadata items the user can set. This would all > break if we start adding "nova" metadata without further api and db (small) > changes. > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
