Dean, thanks for pointing out this issue and for the thoughtful reply.
I forgot to point out that the initial Tempest config is created after [built-in services started] because some of its config options are derived from the running services. This means any swaps that need to be done prior to [built-in services started] won't affect Tempest.
To solve this bug, Tempest just needs the current F to come after G. The 2 solutions that come to mind are:
1. Swap F and G
2. Introduce a phase H for local.conf overrides after extras.d handler for 'extra'
#1 is the simplest solution here, however, if other extras (Savanna?) are already depending on F coming before G, then they'll have to rewrite.
#2 works and doesn't require changes in extras scripts but may add extra complexity/maintenance to devstack.
I'm rooting for #2 because it is a simple change but if either of the above don't work out, I'm okay with having extras.d scripts make their own calls to merge_config_group().
Dean, thanks for pointing out this issue and for the thoughtful reply.
I forgot to point out that the initial Tempest config is created after [built-in services started] because some of its config options are derived from the running services. This means any swaps that need to be done prior to [built-in services started] won't affect Tempest.
To solve this bug, Tempest just needs the current F to come after G. The 2 solutions that come to mind are:
1. Swap F and G
2. Introduce a phase H for local.conf overrides after extras.d handler for 'extra'
#1 is the simplest solution here, however, if other extras (Savanna?) are already depending on F coming before G, then they'll have to rewrite.
#2 works and doesn't require changes in extras scripts but may add extra complexity/ maintenance to devstack.
I'm rooting for #2 because it is a simple change but if either of the above don't work out, I'm okay with having extras.d scripts make their own calls to merge_config_ group() .