Open Stack

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>