On 06/11/16 13:17, Steve Martinelli wrote: > > 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/
For our use case, I need key:value pairings, so something like the tags system wouldn't quite work. That said, I kind of like the hardcoded limit of: "Each server can have up to 50 tags." The examples currently that we use (or would like to use if we could limit access to certain roles): Project (in extra): created_at: <datetime as string> created_by: <username>@<domain> terminated_at: <datetime of account termination> terminated_by: : <username>@<domain> terminated_reason: <reason for termination> sign_up_type: <"individual" or "organisation"> organisation: <if organisation signup, name of organisation> partner_id: <id of organisation/person in ERP system> User (in extra): created_at: <datetime as string> created_by: <username>@<domain> invited_by: <username>@<domain> of person who sent invitation. terminated_at: <datetime of account termination> terminated_by: : <username>@<domain> terminated_reason: <reason for termination> Chances are we will be adding more as well. Right now part of the problem is that a user can do project get for their own project, and will see values in extra, which means we can't store anything in there we don't want the clients or their users to see. I will point out though that some of this stuff we keep in our ERP system as well, but it is far less flexible than OpenStack and much of that info we'd like to keep synced in both places so that it is easy to query from either direction. This makes audit trails easier and allows a "project show" to tell us what we need to know about a project without going to the ERP system as well (which not everyone has access to anyway). Also worth noting is that the reason most of this works, and is actually enforced, is that we don't use Keystone directly for project/user creation/management. We have a service that handles the automation of admin tasks and automates most of this via the Keystoneclient. We do still have people with actual admin access who do occasionally change things manually, but we are doing more and more via this service both for consistency, and to track who did what when. Doing all of the above via the proposed new API would be easy, and while the timedate values won't themselves be queryable, the "created_at"/"updated_at" values on the property will be. So I can do a query along the lines of: projects where properties have "terminated_at" and property updated_at >= <some timedate>; Doing this via swift is... I guess I could store a list of each property in a file, and then parse the contents. For straightforward tags, that would be fine, but not for key:value pairs where the contents of the value will be different. I could probably do it by making the files instead be more of a reverse mapping, where I make a container for each resource type and have the file name as "<key>_<value>" (eg "terminated_by_<username>@<domain>") with the file itself containing a list of resource ids. That would at least make things less awful to search for, but it would still be MUCH slower than if these were proper Keystone database entries. Not to mention doing it in swift would make it hard to expose to anything but the project where the swift data is stored in. I'd need to build a service to handle these queries for me, and it would need to be built in a service project so it has access to swift, but exposes its API to OpenStack. So not Swift I think. > > 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 ) > Storing limits (quotas) in Keystone feels wrong, although I can't place my finger on why. While yes they are sort of attributes of a project, they aren't exactly identity or access attributes. I do think we need to centralise them, I just don't know if Keystone is exactly the place for it, although I agree that there isn't a better place right now. Plus centralising them might actually mean we can do hierarchical quotas! As odd as it may sound, what if we considered that limits are a form of dynamic policy? And migrate to treating resource limits as such. Combine that with a general shift to centralised dynamic policies in Keystone, and then it sort of feels better. It would be a massive effort, but it could mean per user resource limits, per project per user, or even per user per host limits. If we do it right we could do role based limits too. Has this kind of approach been considered before?
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
