<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Nov 5, 2016 at 6:15 PM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 11/05/2016 01:15 AM, Steve Martinelli wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The keystone team has a new spec being proposed for the Ocata release,<br>
it essentially boils down to adding properties / metadata for projects<br>
(for now) [1].<br>
</blockquote>
<br></span>
Yes, I'd seen that particular spec review and found it interesting in a couple ways.</blockquote><div><br></div><div>Please comment on it :)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I've added nova and cinder here since the APIs that are being proposed<br>
are more or less carbon copies of what is available through their APIs<br>
(for server and volumes, respectively). What has been your project's<br>
experience with handling metadata / properties? I assume that its been<br>
there a while and you can't remove it. If you could go back and redo<br>
things, would you do it another way? Would you take a more purist stance<br>
and enforce more strict APIs, metadata be damned?<br>
</blockquote>
<br></span>
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.<span class="gmail-"><br></span></blockquote><div><br></div><div>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: <a href="http://developer.openstack.org/api-ref/compute/">http://developer.openstack.org/api-ref/compute/</a> </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I also added horizon because i'm curious about the impact this causes<br>
when representing a resource.<br>
<br>
Personally, I am for the idea, we've had numerous requests from<br>
operators about providing this support and I like to make them happy.<br>
</blockquote>
<br></span>
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.<br></blockquote><div><br></div><div>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 <a href="https://etherpad.openstack.org/p/ocata-keystone-unconference">https://etherpad.openstack.org/p/ocata-keystone-unconference</a> )</div><div><br></div></div></div></div>