Open Stack

On 07/24/2015 02:15 PM, Michael Still wrote:
> On Fri, Jul 24, 2015 at 3:55 AM, Daniel P. Berrange <berrange at redhat.com
> <mailto:berrange at redhat.com>> wrote:
> 
>     On Thu, Jul 23, 2015 at 11:57:01AM -0500, Michael Still wrote:
>     > In fact, I did an example of what I thought it would look like already:
>     >
>     >     https://review.openstack.org/#/c/205154/
>     >
>     > I welcome discussion on this, especially from people who couldn't make
>     > it to the mid-cycle. Its up to y'all if you do that on this thread or
>     > in that review.
> 
>     I think this kind of thing needs to have a spec proposed for it, so we
>     can go through the details of the problem and the design considerations
>     for it. This is especially true considering this proposal comes out of
>     a f2f meeting where the majority of the community was not present to
>     participate in the discussion.
> 
>  
> So, I think discussion is totally fair here -- I want to be clear that
> what is in the review was a worked example of what we were thinking
> about, not a finished product. For example, I hit circular dependancy
> issues which caused the proposal to change.
> 
> However, we weren't trying to solve all issues with flags ever here.
> Specifically what we were trying to address was ops feedback that the
> help text for our config options was unhelpfully terse, and that docs
> weren't covering the finer details that ops need to understand. Adding
> more help text is fine, but we were working through how to avoid having
> hundreds of lines of help text at the start of code files.
> 
> I don't personally think that passing configuration options around as
> arguments really buys us much apart from an annoying user interface
> though. We already have to declare where we use a flag (especially if we
> move the flag definitions "out of the code"). That gives us a framework
> to enforce the interdependencies better, which in fact we partially do
> already via hacking rules.

I think there is also a trade off here. Config options can be close to
the code they are used in, or close to other config options. And
locality is going to impact things.

Right now with config options being local to code we get the incentive
to grow up lots of little config options to tweak everything under the
sun, and they end up buried away from a global view of if that makes
sense. But config is global, for better or worse, and it's an interface
to our operators. Pulling it all together as an interface into a
dedicated part of the code might make it simpler to keep it consistent,
and realize how big a scope of the problem is of conf sprawl.

Because it would be nice to get detailed help into config options,
instead of randomly in our heads, or having to read the code. It would
also be nice to actually do the thing that markmc propose a long time
ago of categorizing config options being the ones that you expect to
change, the ones that are really only for debug, the ones that open up
experimental stuff, etc.

	-Sean

-- 
Sean Dague
http://dague.net