[openstack-dev] [keystone][nova][cinder][horizon][all] properties / metadata for resources

Matt Riedemann mriedem at linux.vnet.ibm.com
Mon Nov 7 00:25:32 UTC 2016

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: OpenStack-dev-request at lists.openstack.org?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:




Matt Riedemann

More information about the OpenStack-dev mailing list