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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
