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. -----Original Message----- From: "Eric Day" <e...@oddments.org> Sent: Wednesday, March 2, 2011 12:43pm To: "Mark Washenberger" <mark.washenber...@rackspace.com> Cc: "openstack@lists.launchpad.net" <openstack@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.willi...@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@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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
