<div class="gmail_quote">On Mon, Jul 16, 2012 at 7:20 PM, Adam Young <span dir="ltr"><<a 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 href="http://markmail.org/message/vlk6otl2yggjeouc">http://markmail.org/message/vlk6otl2yggjeouc</a> and <a 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 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 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>