Open Stack

On Thu, 2017-03-09 at 00:15 +0000, Kato, Tomoyuki wrote:
> > 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/maste
> > > > > r/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.

OK, the patch to enable that is available here:

  https://review.openstack.org/#/c/442623

I'll work on updating the guide tomorrow.

Stephen