Open Stack

On Wed, Mar 02, 2011 at 01:31:27PM -0500, Brian Lamar wrote:
> Wait, are we all in agreement that we need user-defined metadata and service-specific metadata? I do agree that the data store isn't conducive to adding arbitrary metadata due to the rigidness of our DB, but how often are we going to be adding new attributes?
> 
> I guess my main question is where is the line between a new metadata attribute and an instance-specific property? I suppose you could say then I'm all for your third and final example.

The line is no core code in nova will ever look at user-metadata. If it
does need to, it should either be service-metadata or simply an object
property. There is a need for some deployments to define metadata
that can be used in the pluggable scheduler (as Justin mentioned,
things like GPU tags), but this should not be in the same namespace as
user-metadata or count against the user-metadata quota. Do we want to
require deployments to alter the DB schema, provide a service-metadata
table, or use reserved prefixes in the same table as user-metadata?

I'm split between the last two.

-Eric

> 
> -----Original Message-----
> From: "Eric Day" <eday at oddments.org>
> Sent: Wednesday, March 2, 2011 12:43pm
> To: "Mark Washenberger" <mark.washenberger at rackspace.com>
> Cc: "openstack at lists.launchpad.net" <openstack at lists.launchpad.net>
> Subject: Re: [Openstack] server affinity
> 
> 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
> 
> _______________________________________________
> 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
>