On 12/16/2016 04:36 PM, Matt Riedemann wrote:
On 12/16/2016 2:20 PM, Jay Pipes wrote:
For problems with placing data like this as configuration options, see
the hassle we went through in making the allocation_ratio options into
fields stored in the DB...
Better long-term to have all this kind of configuration live in a data
store (not a config file) and be exposed via an HTTP API.
So, we could do that, we already have the quota_classes table and the
os-quota-class-sets REST API, and as mentioned the only usable thing
that goes in there is overriding global default quota.
Would you suggest we drop the global quota limit configuration options
and simply populate the quota_classes table with a 'default' quota class
and the limits from the config in a DB migration, then drop the config
options?
Yeah, I think that's the best long-term strategerization.
-jay
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
