On Sat, Nov 5, 2016 at 6:15 PM, Jay Pipes <jaypi...@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 )
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev