Open Stack

On 11/05/2016 01:15 AM, Steve Martinelli wrote:
> The keystone team has a new spec being proposed for the Ocata release,
> it essentially boils down to adding properties / metadata for projects
> (for now) [1].

Yes, I'd seen that particular spec review and found it interesting in a 
couple ways.

> We have somewhat had support for this, we have an "extras" column
> defined in our database schema, whatever a user puts in a request that
> doesn't match up with our API, those key-values are dumped into the
> "extras" column. It's not a pleasant user experience, since you can't
> really "unset" the data easily, or grab it, or update it. There's
> actually been patches to keystoneclient for getting around this, but its
> rather hacky and hardcodes a lot of values [2] [3]

"not a pleasant user experience" would be an understatement :)

In addition to the unpleasant user experience, there is the additional 
problem that jamming such information into a JSON BLOB and storing it in 
a TEXT field in a relational database means none of the information 
stored in the field can be indexed which means there's no ability to 
search on particular key or value information.

> I've added nova and cinder here since the APIs that are being proposed
> are more or less carbon copies of what is available through their APIs
> (for server and volumes, respectively). What has been your project's
> experience with handling metadata / properties? I assume that its been
> there a while and you can't remove it. If you could go back and redo
> things, would you do it another way? Would you take a more purist stance
> and enforce more strict APIs, metadata be damned?

Yes. I would get rid of the server metadata API that is in the Compute 
API. I believe the server tags API in the Compute API is appropriate for 
user-defined taxonomy of servers. For non user-defined things like 
system metadata, I prefer to have schema-defined attributes that are 
standardize and typed but a structured "properties" API can be useful as 
long as the key and value fields are indexable and reasonably sized.

> I also added horizon because i'm curious about the impact this causes
> when representing a resource.
>
> Personally, I am for the idea, we've had numerous requests from
> operators about providing this support and I like to make them happy.

I am most concerned actually about the resistance from some in the 
Keystone contributor community to storing quota *limits* [1] for users 
and projects. Right now, every service project needs to store 
information about quota limits for all users and projects, and the 
services each do this annoyingly differently. Keystone is the thing that 
stores attributes of a user or a project. Limits of various quantitative 
resources in the system are an attribute of a user or a project. This 
information belongs in Keystone, IMHO, with a good REST API that other 
services can use to grab this information.

Best,
-jay

[1] limits, not usages.