openstack team mailing list archive

[Andy Smith <andyster@xxxxxxxxx>]

A few points:

(1) I agree with Todd and others that having flags localized to where they
are used is good idea.

(2) We should do some work to re-localize many of the flags, there has been
a lot of kludge over time that just needs a little re-organization. This
will solve the "which flags are common" and which flags are specific issue
(common flags will be in a common area, specific flags in more specific
areas). Right now we have too many flags in a common area and it bogs down
the help output.

(3) We should also do some work to standardize the names, as suggested, as
that will help keep the brain storage down to a minimum.

(4) I did some work on a sphinx plugin that was never finished to
automatically document the flags, I can put some effort into finishing that
if we want it. It basically added the docs for the flags per module and
could be expanded to generate a master list of flags document also.

For #2 and #3 I feel pretty comfortable getting those started, I understand
the systems well and have access to people like Vish in shouting distance
for when I run into flags that I don't immediately have a place/name for.
For #4, I can take a look again and see how hard it will be to get that code
working. For #1 I think we can agree to keep things localized for now and I
am open to starting a separate conversation (in a different thread) about
the benefits of that if people are concerned.

--andy

On Tue, Feb 22, 2011 at 11:24 AM, Todd Willey <todd@xxxxxxxxxxxx> wrote:

> The separation of flag definitions into the modules that consume them
> is a good practice, IMO.  This is especially true with a system as
> configurable/pluggable as nova, as you don't want flags for unused
> modules polluting your help output, etc.  It also goes most of the way
> into creating the logical boundaries you'd need to speak to when
> documenting configurations.
>
> -todd[1]
>
> 2011/2/22 Brian Schott <bschott@xxxxxxx>:
> > +1
> >
> > We are also struggling with the various and sundry deployment options.
>  Getting bit by the multiple mechanisms to install and launch openstack.
> >
> > ---
> > Brian Schott, Project Leader
> > USC Information Sciences Institute
> > http://www.east.isi.edu/~bschott
> > ph: 703-812-3722 fx: 703-812-3712
> >
> >
> >
> > On Feb 22, 2011, at 10:07 AM, Diego Parrilla Santamaría wrote:
> >
> >> I have counted 160 configuration parameters in Nova, and only about 15
> >> are documented. This is clearly one of the areas of improvement in the
> >> project.
> >>
> >> I have been fighting with Nova Bexar in not-so-standard configurations
> >> and deployments and believe me, I would appreciate more information
> >> about what they do.
> >>
> >> Something that took me a lot of time to figure out was what are
> >> 'common' flags for all the components in nova, and what are 'specific'
> >> flags for each component. If you are setting up an environment with
> >> specialized nodes
> >> (compute,network,volume,api,objectstore,scheduler...) this is a must
> >> if you want to have more than a couple of servers running Nova.
> >>
> >> Diego
> >> -
> >> Diego Parrilla
> >> nubeblog.com | nubeblog@xxxxxxxxxxxx | twitter.com/nubeblog
> >> +34 649 94 43 29
> >>
> >>
> >>
> >>
> >> On Tue, Feb 22, 2011 at 3:29 PM, Jay Pipes <jaypipes@xxxxxxxxx> wrote:
> >>> <can of worms>
> >>> Just use optparse/argparse. paste.deploy handles configuration files
> >>> already, which is where most "flags" should really be... gflags adds
> >>> unneeded complexity for no real gains, IMHO. Swift and Glance do just
> >>> fine without gflags, as do the vast majority of Python projects. As
> >>> for documentation of program options, the most common practice in the
> >>> open source world is to document configuration options in the example
> >>> configuration files that ship with your project, and document command
> >>> line options "inline" to show up in --help output.
> >>> </can of worms>
> >>>
> >>> On Tue, Feb 22, 2011 at 1:37 AM, Christian Berendt
> >>> <berendt@xxxxxxxxxxxxx> wrote:
> >>>> Hi.
> >>>>
> >>>> At the moment we're using a lot of flags spread all over the code.
> >>>>
> >>>> a) we should create a useful documentation including all flags
> >>>>
> >>>> b) we should introduce a naming convention for new flags and we should
> >>>> rename existing flags
> >>>>
> >>>> example:
> >>>>
> >>>> all flags related to default values are starting with "default_", all
> >>>> flags related to a path are starting with "path_".
> >>>>
> >>>> Looks like most of the flags have good names at the moment, but I
> think
> >>>> we should write it down in the wiki or the developer documentation to
> >>>> reduce the possibility of bad names in the future.
> >>>>
> >>>> c) if it's possible we should collect all flags in one file
> >>>>
> >>>> At the moment the flags are defined in the files where they are used.
> I
> >>>> think it would be nice to have on file, for example nova/flags.py,
> >>>> including all flags used all over the code.
> >>>>
> >>>> Bye, Christian.
> >>>>
> >>>> --
> >>>> Christian Berendt
> >>>> Linux / Unix Consultant & Developer
> >>>> Tel.: +49-171-5542175
> >>>> Mail: berendt@xxxxxxxxxxxxx
> >>>>
> >>>> B1 Systems GmbH
> >>>> Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
> >>>> GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
> >>>>
> >>>> _______________________________________________
> >>>> Mailing list: https://launchpad.net/~openstack
> >>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> >>>> Unsubscribe : https://launchpad.net/~openstack
> >>>> More help   : https://help.launchpad.net/ListHelp
> >>>>
> >>>>
> >>>
> >>> _______________________________________________
> >>> Mailing list: https://launchpad.net/~openstack
> >>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> >>> Unsubscribe : https://launchpad.net/~openstack
> >>> More help   : https://help.launchpad.net/ListHelp
> >>>
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~openstack
> >> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~openstack
> >> More help   : https://help.launchpad.net/ListHelp
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp
> >
> >
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>