<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 06/11/16 13:17, Steve Martinelli wrote:<br>
<span class="gmail-"></span>
<blockquote
cite="mid:CAHc_MXHQ_iaHXd-aDu1YOmsWawuObKZmJOieU_YN+iU_k0TX0g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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
moz-do-not-send="true"
href="http://developer.openstack.org/api-ref/compute/">http://developer.openstack.org/api-ref/compute/</a>
<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
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:
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
"Each server can have up to 50 tags."<br>
<br>
The examples currently that we use (or would like to use if we could
limit access to certain roles):<br>
<br>
Project (in extra):<br>
<br>
created_at: <datetime as string><br>
created_by: <username>@<domain><br>
terminated_at: <datetime of account termination><br>
terminated_by: : <username>@<domain><br>
terminated_reason: <reason for termination><br>
sign_up_type: <"individual" or "organisation"><br>
organisation: <if organisation signup, name of organisation><br>
partner_id: <id of organisation/person in ERP system><br>
<br>
User (in extra):<br>
<br>
created_at: <datetime as string><br>
created_by: <username>@<domain><br>
invited_by: <username>@<domain> of person who sent
invitation.<br>
terminated_at: <datetime of account termination><br>
terminated_by: : <username>@<domain><br>
terminated_reason: <reason for termination><br>
<br>
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.<br>
<br>
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).<br>
<br>
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.<br>
<br>
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:<br>
projects where properties have "terminated_at" and property
updated_at >= <some timedate>;<br>
<br>
<br>
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.<br>
<br>
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.<br>
<br>
So not Swift I think.<br>
<br>
<blockquote
cite="mid:CAHc_MXHQ_iaHXd-aDu1YOmsWawuObKZmJOieU_YN+iU_k0TX0g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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">
</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 moz-do-not-send="true"
href="https://etherpad.openstack.org/p/ocata-keystone-unconference">https://etherpad.openstack.org/p/ocata-keystone-unconference</a>
)</div>
<br>
</div>
</div>
</div>
</blockquote>
<br>
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!<br>
<br>
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?<br>
</body>
</html>