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