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

Steve Martinelli s.martinelli at gmail.com
Sun Nov 6 00:17:31 UTC 2016

On Sat, Nov 5, 2016 at 6:15 PM, Jay Pipes <jaypipes at gmail.com> wrote:

> 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.

Please comment on it :)

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.

Interesting, I'll add this to the review and see how some if the folks
proposing the new APIs would find that as suitable for their use cases. For
reference: http://developer.openstack.org/api-ref/compute/

> 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.

Actually, this summit was the first I've heard of it (more so than just a
passing idea with no one up for doing the work). We talked about it at our
unconference session and Boris Bobrov (breton) has a few TODOs on the topic
(post to ML and create a spec
https://etherpad.openstack.org/p/ocata-keystone-unconference )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161105/584f3fd7/attachment.html>

More information about the OpenStack-dev mailing list