Open Stack

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.

Michael

-- 
Rackspace Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150724/3fc215af/attachment.html>