[OpenStack-docs] Removing support for flagmappings

Kato, Tomoyuki kato.tomoyuki at jp.fujitsu.com
Thu Mar 9 00:15:26 UTC 2017


> On 2017-03-08 12:38, sfinucan at redhat.com wrote:
> > 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.
> 
> Yes, that's definitely an option.
> 
> Brian and Kato are involved with tools and config reference. I'd like to
> hear what they propose and follow their lead.

I don't have answer, too.
Generally speaking, however, I agree to migrate into olso.config-based tool.

> > 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.
> 
> I was considering this for Pike.
> 
> But if this would be a nova only change, we could do it for Ocata as well.

+1 to nova only for Ocata.

Kato

> 
> >> Thanks for looking into this!
> >
> > Happy to help :)
> 
> Thanks,
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>    GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>        HRB 21284 (AG Nürnberg)
>     GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
> 
> 
> _______________________________________________
> OpenStack-docs mailing list
> OpenStack-docs at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs


More information about the OpenStack-docs mailing list