← Back to team overview

openstack team mailing list archive

Re: documentation of flags, introducing of a naming convention for flags

 

I forgot to add something to my 'wishlist' ;-)

Changing the way we configure Nova should be a process announced in
advanced. One or two releases in advance, to give enough time to teams
doing deployments and upgrades of Nova to be prepared. Changes that
can impact in the upgrade of the product (database schema changes,
ldap schema changes, deprecated/new properties should be informed in
advance).

I understand this is very complicated... but this is the kind of
things that sysadmins love.

-
Diego Parrilla
nubeblog.com | nubeblog@xxxxxxxxxxxx | twitter.com/nubeblog
+34 649 94 43 29




On Wed, Feb 23, 2011 at 9:44 AM, Thierry Carrez <thierry@xxxxxxxxxxxxx> wrote:
> Andy Smith wrote:
>> (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.
>
> That sounds great !
>
> Ideally each flag would be a bit more documented in code (not just a
> short desc and a default value) and the plugin would pick those comments up.
>
> Then it can serve as a basis to write the flags chapter in the user
> documentation ("OpenStack manuals"). This one needs a bit more human
> editing (logical groupings of flags, explanation of several flags at the
> same time...) but would use the Sphinx-plugin-generated doc as raw material.
>
> --
> Thierry Carrez (ttx)
> Release Manager, OpenStack
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>



References