Open Stack

On Wed, 2017-03-08 at 11:54 +0100, Andreas Jaeger wrote:
> On 2017-03-08 11:26, sfinucan at redhat.com wrote:
> > The openstack-manuals [1] project contains a number of
> > configuration
> > guides, which are autogenerated using tooling found in the
> > openstack-
> > doc-tools [2] project.
> > 
> > This tooling makes use of 'flagmapping' files [3], which map
> > various
> > config options to different categories. These files must be
> > manually
> > maintained, which doesn't appear to be happening for some projects
> > (nova). Given the names of the files, I'm led to believe they are a
> > hangover from the days before oslo.config where OpenStack used per-
> > project "flags". Given that oslo.config provides not only opts but
> > also
> > groups, I don't see any reason to keep this functionality around.
> > 
> > I've submitted some changes which will drop support for these
> > flagmapping files [4][5] along with the flagmapping files
> > themselves
> > [6], and rely instead of the Opt.group property to categorize
> > options.
> > If anyone knows of a good reason to keep these features around, I'd
> > ask
> > that you comment on the review. If not, I'd appreciate support for
> > stripping out these unnecessary features.
> > 
> > Cheers,
> > Stephen
> > 
> > [1] https://github.com/openstack/openstack-manuals/
> > [2] https://github.com/openstack/openstack-doc-tools
> > [3] https://github.com/openstack/openstack-manuals/tree/master/tool
> > s/au
> > togenerate-config-flagmappings
> > [4] https://review.openstack.org/#/c/442622/
> > [5] https://review.openstack.org/#/c/442623/
> > [6] https://review.openstack.org/#/c/442639/
> 
> I fear this is too early to do - it needs changes in other repos as
> well.
> 
> We use this grouping currently to have a table per hardware driver,
> check for example all the cinder drivers. Looking at the cinder repo,
> a
> grep "git grep OptGroup" does not return any line.
> 
> So, you approach might work for one project - but not others yet.

You mean we care about more than nova? Shock-horror :D (I kid)

> Another challenge is that the flagmappings also allow showing the
> same
> option in multiple tables - like the san_ip option in cinder. How
> would
> we handle that?

Sadly, I've no answer for this yet. The nova opts use groups for both
hypervisor- and service-specific options, thus there's no reason to do
anything like cinder does. I do feel this is something that we should
be using oslo.config for, but I'm not enough of a masochist to offer to
implement opt-group support in cinder.

> So, looking at your change, the approach seems to work for nova - but
> with my comments above, I fear it will not work today for cinder.
> Note
> that these are the only two repos I checked.
> 
> I'm happy to see us move to OptGroup once all obstacles are removed.

If it's not possible to remove this for all projects, could we make it
configurable on a per-project basis? Perhaps if no flagmapping file
exists for a project, we start falling back to using option groups
only? This way we could just drop the nova.flagmapping file but keep
cinder et al as they are.

FWIW, the main reason I'm trying to do this now is that I *really*
don't want to have to update the flagmapping file for nova nor do I
want to force some other poor soul to do it. We've made a *lot* of
(well documented) changes to opts in Ocata and this is going to be a
significant and seemingly needless block of work.

> Thanks for looking into this!

Happy to help :)

Stephen