Out of curiosity, why prefer keystone for centrally managing quota groups rather than an admin api in nova? From my perspective, a nova admin api would save a data migration and preserve nova-manage backwards compatibility. Also, since quota clearly isn't an auth-n thing, is keystone way more auth-z than I realized? "Day, Phil" <philip.day at hp.com> said: > +1 > > And make the whole combine quota/limits module pluggable - so that all of these > "per-user" configuration items can be managed in a central system (e.g keystone) > > -----Original Message----- > From: openstack-bounces+philip.day=hp.com at lists.launchpad.net > [mailto:openstack-bounces+philip.day=hp.com at lists.launchpad.net] On Behalf Of Jay > Pipes > Sent: 17 March 2012 16:25 > To: openstack at lists.launchpad.net > Subject: Re: [Openstack] Quota classes > > On 03/16/2012 07:02 PM, Jesse Andrews wrote: >> There is the concept of "limits" that are very similar. Should we >> align quotas& limits? > > Oh, yes please! :) > > And make it configurable via a REST API, since editing config files ain't the most > admin-friendly thang ;) > > /me waits for Jorge to bring up Repose... > > best, > -jay > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack at lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack at lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp >