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 <berra...@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 __________________________________________________________________________ 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