On Mar 2, 2011, at 3:54 PM, Eric Day wrote: > On Wed, Mar 02, 2011 at 09:48:27PM +0000, Jorge Williams wrote: >> On Mar 2, 2011, at 11:43 AM, Eric Day wrote: >>> 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. >> >> How you store the data internally and how you present it in the API are two >> different issues. You don't necessarily have to store extension data where >> you store standard attributes in order to present things as instance >> properties. You can store this data in a completely different table or in a >> flat file, or in memory, whatever. You can have middle ware that inserts it >> into the object before you present it to the user. In fact this is a big >> plus because it makes extensions plug-able and because it allows each one to >> map it's data as it sees fit. > > Agreed, but we're talking about how to actually store both in > nova. Justin added a metadata table in the nova.db SQL schema, but > we're trying to decide if that should be user only (and add another > table) or both user and service with prefixes. The 1.1 API spec won't > change either way. > > -Eric
Got it :-) _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
