Open Stack

Excerpts from Michael Still's message of 2015-07-24 13:15:15 -0500:
> On Fri, Jul 24, 2015 at 3:55 AM, Daniel P. Berrange <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.

One idea I've tossed around a bit is having options defined in data
files that ship with the code, rather than being inside the Python
code itself. Maybe a first pass at that would be to offload the
help to a separate file? If that seems interesting, I could experiment
with adding some features to oslo.config to support it.

Doug