<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 07/17/2012 11:18 AM, Everett Toews
wrote:<br>
</div>
<blockquote
cite="mid:CAH6jzwvcrA3A9-anWCAnhUf6Fem-2Na1tbjSXYGJ9RzP4CaeaA@mail.gmail.com"
type="cite">
<div class="gmail_quote">On Mon, Jul 16, 2012 at 7:20 PM, Adam
Young <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
</div>
Usually a Quota is a limitation on a resource. I suspect that
the problem here is we have not nailed down the resource
objects that you would then apply a quota to. If, for
example, we were talking about disk quotas, we could look at
the LDAP schema's that are in place for disks, automount, and
so forth. For network or CPU quotas, the concepts don't
really exist.<br>
<br>
My immediate thought is that maybe these things are not really
Keystone quantities to manage. Nova has the database that
deals with the actual quantities of disk and so forth. BUt I
know that LDAP is the system of record for Hosts in many
systems, so the Data from LDAP needs to feed into Nova
somehow....<br>
</blockquote>
<div><br>
</div>
<div>I led the session on quotas at the Folsom Summit where the
consensus was that, because this data was tied to Tenants, it
should be stored in Keystone. We've also discussed it on the
mailing list at <a moz-do-not-send="true"
href="http://markmail.org/message/vlk6otl2yggjeouc">http://markmail.org/message/vlk6otl2yggjeouc</a>
and <a moz-do-not-send="true"
href="http://markmail.org/message/7agsnjo3n4il56ar">http://markmail.org/message/7agsnjo3n4il56ar</a>
(where you'll find links to the Summit etherpad, spec, and
blueprint).</div>
<div><br>
</div>
<div>I searched around a bit for an objectclass that handled
generic quotas but couldn't find one. I really wouldn't want
us to write our own objectclass either as it's simply not
flexible enough. I don't think we want to necessarily nail
down the resource objects we want to apply a quota to. Each
OpenStack project is going to need its own quotas and I
suspect there are going to be many additions to those quotas
over the next 2 years so we something that can handle
anything.</div>
<div><br>
</div>
<div>If we just store some JSON in the backend then that will
meet our needs nicely. This is how "metadata" is stored in the
SQL backend. I simply reused that and it was pretty effective.</div>
<div>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Can you post your code to a GIthub repo and send out a link to
the commit so that I could take a look? It would be much more
clear to discuss with actual code in front of me.</blockquote>
<div> </div>
<div>My branch is at <a moz-do-not-send="true"
href="https://github.com/everett-toews/keystone/tree/quotas">https://github.com/everett-toews/keystone/tree/quotas</a></div>
<div>The SQL implementation is at <a moz-do-not-send="true"
href="https://github.com/everett-toews/keystone/blob/quotas/keystone/identity/backends/sql.py">https://github.com/everett-toews/keystone/blob/quotas/keystone/identity/backends/sql.py</a></div>
<div><br>
</div>
<div>Everett</div>
</div>
</blockquote>
<br>
I haven't been thinking about quotas, so bear with me here. A few
thoughts:<br>
<br>
Certain deployments might not be able to touch the LDAP backend. I
am thinking specifically where there is a corporate AD/LDAP server.
I tried to keep the scheme dependency simple enough that it could be
layered onto a read-only scenario. If we put quotas into LDAP, it
might break on those deployments.<br>
<br>
I'm trying to get an approach to Federation and delegation for
Keystone. Imagine where a company has a signing certificate that
allows it validate the users for only their own tenancy. In these
cases, the end user organization then would have the ability to
control their own quotas.<br>
<br>
One reason to do the PKI signed tokens was to minimize the number of
calls going to Keystone. This adds yet another one. The quotas
could be added to the signed auth token, but it is already huge, I'd
hate to cram more data in there.<br>
<br>
A serialized object block defers a lot of problems, but they will
bite us later. For example, there is already a ticket for
"enabled" which does not have the text string normalized. Doing
one for Quotas misses validation of both resource names and the
units used. For example, are disk quotas in bytes, megabytes, or
Gigs? Are all of those acceptable? If so, how do we define which
one to use. I realize you might have nailed this down in your code,
or at least design, but then the code is the contract.<br>
<br>
This design seems to address some of those issues.<br>
<a class="moz-txt-link-freetext" href="http://wiki.openstack.org/Boson">http://wiki.openstack.org/Boson</a><br>
<br>
I can see that we don't want to define them in the Nova database, as
Swift might not have access to that, and swift is going to be one of
the primary consumers of Quotas. I am Assuming Quantum will have
them as well.<br>
<br>
As you are aware, there is no metadata storage in the LDAP driver,
instead it is generated from the tenant and role information on the
fly. There is no place to store metadata in "groupOfNames" which is
the lowest( common denominator) grouping used for Tenants. Probably
the most correct thing to do would be to use a "seeAlso" that
points to where the quota data is stored.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>