On 07/17/2012 11:18 AM, Everett Toews wrote:
On Mon, Jul 16, 2012 at 7:20 PM, Adam Young <ayo...@redhat.com
<mailto:ayo...@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.
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
