Bug 1565481

Steps to Reproduce:
1. deploy OSP13 OVN HA (without DVR)
2. set router & instances  with external access 
3. run stack update to enable dvr 
in overcloud_deploy.sh  change it with  dvr yaml file : /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-ovn-dvr-ha.yaml 

check the compute node you can see that br-ex does not create.

To add some more details, OVN stack was deployed with the environment file - https://github.com/openstack/tripleo-heat-templates/blob/stable/queens/environments/services-docker/neutron-ovn-ha.yaml#L29

In this file, we set
ComputeParameters:
    NeutronBridgeMappings: ""


So on controller nodes, the hiera variable - "ovn::controller::ovn_bridge_mappings" is set to "datacentre:br-ex"
and on compute nodes its - "ovn::controller::ovn_bridge_mappings"="".

When we do a stack update with neutron-ovn-dvr.yaml (https://github.com/openstack/tripleo-heat-templates/blob/stable/queens/environments/services-docker/neutron-ovn-dvr.yaml), we DONT set -

ComputeParameters:
    NeutronBridgeMappings: ""

So we were expecting,  "ovn::controller::ovn_bridge_mappings"="datacentre:br-ex" even in the compute nodes, but still it was empty.

Pushing this out to 13z seeing as how it's about a stack update and not a fresh deploy.

I had a chat with Steven Hardy and Saravanan KR on irc and below is the summary

Issue 1 - Changing the nic configs during stack update.
-------------

<shardy> numans_: We don't modify nic config on update by default, because it can cause pacemaker to fence nodes
<shardy> so if you added e.g an external network on update, you'd need to pass a parameter to enable the nic config to be updated:
<skramaja> NetworkDeploymentActions: ['CREATE', 'UPDATE']
<shardy> https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/role.role.j2.yaml#L108
<shardy> Yeah or in recent releases ComputeNetworkDeploymentActions
<shardy> if it's only for the Compute role
<numans_> shardy, ok. 
<numans_> skramaja, how to add those actions (sorry for my ignorance :))
<skramaja> add this as a parameter to enable it to run for update..
<shardy> numans_: you add it to the parameter_defaults in one of your environment files
<shardy> or add a new -e enable_net_update.yaml one


Issue 2 - NeutronBridgeMappings not getting updated for compute roles during stack update
--------------------

<shardy> numans_: did you explicitly set NeutronBridgeMappings: br-ex on update for the Compute role after setting NeutronBridgeMappings="" ?
<shardy> numans_: parameter_defaults are "sticky" because we always use PATCH updates to heat
<shardy> so if you set something once, the template defaults will be ignored afterwards
<shardy> on update
<numans_> shardy, no
<numans_> shardy, we did not set explicitly. 
<numans_> shardy, ok. 
<shardy> numans_: Ok, that may be the problem - you can check via openstack stack environment show overcloud | grep NeutronBridgeMappings
<shardy> I think you'll find it's still ""
<skramaja> shardy: role parameters mering should take the default value if the role specific value is not set
<numans_> shardy, i will check
<shardy> skramaja: that doesn't consider the template default for a parameter though?
<shardy> only global vs role specific parameter overrides?
<shardy> I may be mistaken but I still think you'll need to re-set the parameter explicitly
<skramaja> no. inside the service template the global prameter will have the default valye set. unless the role specific param is still persistent, it should work with default..
<numans_> shardy, skramaja (undercloud) [stack@undercloud-0 ~]$ openstack stack environment show overcloud | grep NeutronBridgeMappings -C2
<numans_>   ComputeHostnameFormat: compute-%index%
<numans_>   ComputeParameters:
<numans_>     NeutronBridgeMappings: ''
<numans_>   ComputeServices:
<numans_>   - OS::TripleO::Services::Aide
<numans_> --
<numans_>   NetworkerParameters:
<numans_>     OVNCMSOptions: enable-chassis-as-gw
<numans_>   NeutronBridgeMappings: datacentre:br-ex,tenant:br-isolated
<numans_>   NeutronEnableDHCPAgent: false
<numans_>   NeutronEnableDVR: true
<shardy> skramaja: can you link where that happens please?
<numans_> shardy, so yeah. for compute it is still empty
<skramaja> https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/services/ovn-controller.yaml#L92 shardy
<skramaja> numans_:  it is clear that the ComputeParameters is still retained..
<skramaja> any other source for this param? or may be plan-environment params are not flused on update?
<numans_> skramaja, yes. so you think it should be fixed in t-h-t ? or the env file should take care of it
<shardy> skramaja: it's the same problem, PATCH updates
<shardy> you'll need to pass e.g ComputeParameters: {}
<shardy> just removing it isn't enough
<skramaja> shardy: understood. but i was assuming that the whole plan-environment parameter_default will be reset during update/..
<shardy> skramaja: no that's never been the case, we always do PATCH update to heat
<shardy> early in TripleO it was decided that was less risky than potentially destroying a cloud when someone forgets an -e option
<shardy> but in this case it can cause some confusion
<numans_> shardy, skramaja so during stack update we should set  ComputeParameters: NeutronBridgeMappings: datacentre:br-ex in some env file to resolve this issue ?
<shardy> numans_: yes that will solve it
<skramaja> yes
<shardy> or if you want the template default you could probably also do ComputeParameters: {}
<skramaja> the problem may be that it will need to be used for all the compute roles by the user..
<numans_> shardy, but that would also reset other compute role params ?
<numans_> shardy, skramaja you think this can be addressed (or fixed) in tripleo ultimately ? or you think that something cannot be done.
<shardy> numans_: I think it's just a known issue
<shardy> IMHO we don't want to fix it because this has been the behavior for many releases now
<shardy> although perhaps we should document/validate this case better
<shardy> numans_: the problem is if we change/fix it folks relying on the additive patch updates will be broken, so it's kind of tricky
<skramaja> shardy: agree, i will add a caution to the role-specific params update doc..
<numans_> shardy, agree. we have a BZ here - https://bugzilla.redhat.com/show_bug.cgi?id=1565481 i will update it with the discussion we had.
<shardy> numans_: ack thanks, let me know if you need any more info from me on the bz - hopefully it's a simple workaround

Ok, it sounds like as per comment 9, with DVR we need to always make sure the Compute NeutronBridgeMappings is set and that this is a documentation issue. I'm not sure if this has been addressed in the docs yet or not as this is a pretty old bug.

Changing non-dvr to dvr or vice-versa won't work in Neutron because existing workloads won't get re-configured. We'd need to backport this patch: https://review.opendev.org/c/openstack/neutron/+/735613

I don't think the switch is supported. I suggest to close this bug as NOTABUG or change it to RFE in order to do the backports, updated documentation and test it.

Please feel free to re-open if you think this should be supported operation.