Bug 1565481 - tripleO does not configure compute nodes with br-ex during stack update [NEEDINFO]
Summary: tripleO does not configure compute nodes with br-ex during stack update
Keywords:
Status: ON_DEV
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: documentation
Version: 13.0 (Queens)
Hardware: Unspecified
OS: Unspecified
high
urgent
Target Milestone: ---
: ---
Assignee: James Smith
QA Contact: RHOS Documentation Team
URL:
Whiteboard: docs-accepted
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-10 06:16 UTC by Eran Kuris
Modified: 2020-12-03 09:54 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:
dmacpher: needinfo? (jamsmith)


Attachments (Terms of Use)

Description Eran Kuris 2018-04-10 06:16:20 UTC
Description of problem:
For OVN there is default parameter for NeutronBridgeMappings: datacentre:br-ex

when deploying setup and not specify this parameter we expected that default value would be set.
For some reason, the default value does not configure. 
It is a blocker for DVR feature 
 /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-ovn-dvr-ha.yaml 
Version-Release number of selected component (if applicable):
OSP13 OVN HA+ DVR 2018-04-03.3

openstack-tripleo-image-elements-8.0.0-2.el7ost.noarch
openstack-tripleo-ui-8.3.1-2.el7ost.noarch
openstack-tripleo-heat-templates-8.0.2-0.20180327213843.f25e2d8.el7ost.noarch
openstack-tripleo-common-containers-8.5.1-0.20180326153322.91f52e9.el7ost.noarch
openstack-tripleo-common-8.5.1-0.20180326153322.91f52e9.el7ost.noarch
puppet-tripleo-8.3.2-0.20180327181745.40b702f.el7ost.noarch
ansible-tripleo-ipsec-8.1.1-0.20180308133440.8f5369a.el7ost.noarch
python-tripleoclient-9.2.0-2.el7ost.noarch
openstack-tripleo-validations-8.4.0-1.el7ost.noarch
openstack-tripleo-puppet-elements-8.0.0-1.el7ost.noarch

How reproducible:
always

Steps to Reproduce:
1. deploy OSP13 OVN HA with DVR (don't need to set external bridge under compute parameter  NeutronBridgeMappings: datacentre:br-ex)
2. check ovs-vsctl show in compute node
3.

Comment 1 Eran Kuris 2018-04-10 10:35:02 UTC
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.

Comment 2 Numan Siddique 2018-04-10 10:39:22 UTC
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.

Comment 3 Assaf Muller 2018-04-18 13:37:12 UTC
Pushing this out to 13z seeing as how it's about a stack update and not a fresh deploy.

Comment 9 Numan Siddique 2018-06-28 09:15:29 UTC
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

Comment 16 Terry Wilson 2020-02-14 16:39:33 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.