Open Stack

Well said Jorge. I think we're all in agreement that we need a way
to add both user-defined metadata and service-specific metadata (and
possibly deployment-specific metadata). I think Justin was working
on the metadata mechanisms assuming it would support both based on
prefix. If we don't want to overload metadata and use prefixes to
differentiate between users, providers, and so forth, we should add
another collection to resources. For example:

metadata = [
  "user:comment": "This is Eric's dev server"
  "openstack:affinity_id": "rack4.dc2.east.rackspace.com"]

Would become:

user_metadata = ["comment": "This is Eric's dev server"]
service_metadata = ["openstack:affinity_id": "rack4.dc2.east.rackspace.com"]

Or don't use metadata for service metadata at all and put directly
in the instance object/record:

instance.id = 100
instance.network = 42
instance.affinity_id = rack4.dc2.east.rackspace.com
# instance.metadata is user-defined metadata only.
instance.metadata = ["comment": "This is Eric's dev server"]

Now the arguments stated by many folks is that "service_metadata"
is really instance properties or instance attributes and should
instead be part of the instance object/record directly (like size,
flavor id, etc. are). I don't disagree, but unfortunately there is
a little more overhead since we're using a structured data store,
and this requires an alter table for every change at this point. It's
more difficult to introduce, test, and remove service attributes. If
we want deployments to be able to define service-specific metadata
and use that in pluggable schedulers, a DB schema change is not a
very elegant way to support this.

So the questions are:

Do we need to support variable service metadata? If so, where should
it go?

If in a key/value list, should existing instance properties be moved
into this format as well?

If in a key/value list, should it just be a prefix in a general
metadata list (and user metadata has a 'user' prefix)?

-Eric

On Wed, Mar 02, 2011 at 08:59:09AM -0500, Mark Washenberger wrote:
> > [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 :-)
> > 
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp