Open Stack

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161107/4ee802d1/attachment.html>