| Thread Previous • Date Previous • Date Next • Thread Next |
On 07/17/2012 11:18 AM, Everett Toews wrote:
On Mon, Jul 16, 2012 at 7:20 PM, Adam Young <ayoung@xxxxxxxxxx <mailto:ayoung@xxxxxxxxxx>> 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/quotasThe SQL implementation is at https://github.com/everett-toews/keystone/blob/quotas/keystone/identity/backends/sql.pyEverett
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/BosonI 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.
| Thread Previous • Date Previous • Date Next • Thread Next |
