openstack team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

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.washenberger@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>