Open Stack

On 12/16/2016 05:03 PM, Jay Pipes wrote:
> 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.

Why would someone need to change the defaults via REST API calls? I agree
that we should plan for that now if we think that will eventually be
needed, but I'm not seeing why it would be needed. And if we're not sure
this is needed now, we could still always do this later... at which point
we could do it a lot better than the current implementation being able to
start from scratch. Perhaps as part of the implementation of a new API that
allows you to change *any* mutable config option?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170106/2ae6f5a2/attachment.html>