On 11/4/2016 7:15 PM, 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].
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]
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?
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.
[1] https://review.openstack.org/#/c/388886/
[2] https://review.openstack.org/#/c/375239/
[3] https://review.openstack.org/#/c/296246/
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
If you're going to do it, restrict the case and characters in the keys
because if you don't you can get fits in the backend database wrinkles.
See this nova spec for details:
https://specs.openstack.org/openstack/nova-specs/specs/newton/approved/lowercase-metadata-keys.html
--
Thanks,
Matt Riedemann
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
