Open Stack

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.


-jOrGe W.