Open Stack

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.

> 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.

>> 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