Open Stack

> [W]e
> shouldn't be overloading that functionality by performing some action based on
> user-defined metadata.

That is exactly what I've been trying to say, but you have stated it much more succinctly. Thanks!

My specific concern is with quotas. If the current osapi metadata is overloaded with api functionality, then it muddies the concept of quotas. Admins who run nova probably don't want the server affinity feature to count against the general metadata quota.

Because of this, I don't think server affinity should be part of the metadata (specifically defined as the metadata attribute in nova.compute.api.API::create). 

This doesn't really have any effect on which of Jorge's options we choose, though, so /unhijack.

"Jorge Williams" <jorge.williams at rackspace.com> said:

> Metadata in the OpenStack Compute/Cloud Servers  API is meant to describe user
> defined properties.  That's it.  So in that case, I agree with Brian that we
> shouldn't be overloading that functionality by performing some action based on
> user-defined metadata.
> 
> Speaking more generally though, any attribute that you associate with a resource
> can be thought of as metadata as well.  Isn't the name of an instance metadata
> about the instance?  Should operators be able to define arbitrary metadata and
> then be able to act on it in some way?  I think so, that's a very powerful
> feature. That said,  I would be cautious about exposing this as an arbitrary set
> of name value pairs because it provides a means by which you can bypass the
> contract and that will cause grief for our clients.  Additionally, there's the
> possibility of clashing metadata names between deployments.  The idea behind
> extensions is that you can define arbitrary metadata about a resource, while
> maintaining a contract and while avoiding conflicts with other
> operators/deployments/implementations.  I should note that the approach really
> isn't that different from AWS in that essentially as an operator you use a prefix
> to separate your metadata from customer metadata...the prefix is simply defined by
> the extension and  you can present your metadata in a separate attribute or
> element in the message.
> 
> Given that, I'm still a little fuzzy about whether we've reached a decision as to
> whether affinity id:
> 
> 1) Should be part of the core Compute API
> 2) Should be a more general concept that may span different services, as Eric Day
> proposes
> 3) Should be introduced as an extension, which can later be promoted to the
> core...or not :-)
>