Open Stack

On 07/17/2012 11:18 AM, Everett Toews wrote:
> On Mon, Jul 16, 2012 at 7:20 PM, Adam Young <ayoung at redhat.com 
> <mailto:ayoung at redhat.com>> wrote:
>
>
>     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.
>
>     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....
>
>
> 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 
> http://markmail.org/message/vlk6otl2yggjeouc and 
> http://markmail.org/message/7agsnjo3n4il56ar (where you'll find links 
> to the Summit etherpad, spec, and blueprint).
>
> 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.
>
> 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.
>
>     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.
>
> My branch is at https://github.com/everett-toews/keystone/tree/quotas
> The SQL implementation is at 
> https://github.com/everett-toews/keystone/blob/quotas/keystone/identity/backends/sql.py
>
> Everett

I haven't been thinking about quotas, so bear with me here. A few thoughts:

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.

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.

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.

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.

This design seems to address some of those issues.
http://wiki.openstack.org/Boson

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.

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.









-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120717/b502df95/attachment.html>