Description of problem: puppet-ovn (or Director in general) misconfigures this value on the controllers: [root@overcloud-controller-0 ~]# grep service_plugin /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf #service_plugins = service_plugins=qos,router,trunk It should be qos,ovn-router,trunk This leads to issues when trying to ping routers in OVN DVR environments. Version-Release number of selected component (if applicable): I deployed the environment 2 days ago, hence fairly new RPMs How reproducible: templates attached Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
It's supposedly the order of inclusion for octavia vs OVN: <ggrimaux> [07:15] <numans> it is about the order in which you pass the environment files to the deployment command - "openstack overcloud deploy ... -e ENV1 -e ENV2 ...." <ggrimaux> [07:16] <numans> if ENV1 file defines a tripleo heat param "foo=bar" and ENV2 also defines but with a different value "foo=newbar", ENV2 overrides the first one <ggrimaux> [07:17] <numans> so i think in your case, it is first including ovn env file -- -e /usr/share/..../environments/services/neutron-ovn-ha.yaml and then -e /usr/share../../octavia.yaml" and unfortunately octavia env file redefines NeutronServicesPlugin env file But if this is the case, then I consider this a bug. Our RH provided templates should allow inclusion in any order. User defined templates should be included later. If nothing helps, them I suggest that we create a file octavia-ovn.yaml which can be included before or after the neutron-ovn-ha.yaml file. Otherwise, this will create too much confusion with end users.
So it seems that the problems lies in: openstack overcloud deploy --templates --force-postconfig \ -e ${template_base_dir}/overcloud_images.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-ovn-dvr-ha.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/octavia.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/low-memory-usage.yaml \ -e ${template_base_dir}/network-environment.yaml \ --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage \ --control-scale $control_scale --compute-scale $compute_scale --ceph-storage-scale $ceph_scale \ --ntp-server $ntpserver \ vs: openstack overcloud deploy --templates --force-postconfig \ -e ${template_base_dir}/overcloud_images.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/octavia.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-ovn-dvr-ha.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/low-memory-usage.yaml \ -e ${template_base_dir}/network-environment.yaml \ --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage \ --control-scale $control_scale --compute-scale $compute_scale --ceph-storage-scale $ceph_scale \ --ntp-server $ntpserver \ I hope that it's clear that such nuances should not exist within the RH provided environment files. I do understand the principle of order of inclusion with the env files, but for the sake of usability, I'd prefer something like: ~~~ (...) -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/ovn-octavia.yaml \ (...) ~~~ where the order of inclusion wrt neutron-ovn-dvr-ha doesn't matter.
Hi, > I hope that it's clear that such nuances should not exist within the RH > provided environment files. I do understand the principle of order of > inclusion with the env files, but for the sake of usability, I'd prefer > something like: > ~~~ > (...) > -e > /usr/share/openstack-tripleo-heat-templates/environments/services-docker/ovn- > octavia.yaml \ > (...) > ~~~ > where the order of inclusion wrt neutron-ovn-dvr-ha doesn't matter. Yes, I agree that depending on the order in which the templates are passed to the "openstack overcloud deploy" command is not ideal.I'm reassigning this ticket to the DFG and component where such changes should be made. Now for this particular problem with OVN + Octavia, the patch [0] should fix it. [0] https://review.openstack.org/#/c/591765/ Hope that helps, Lucas
(In reply to Lucas Alvares Gomes from comment #4) > Hi, > > > I hope that it's clear that such nuances should not exist within the RH > > provided environment files. I do understand the principle of order of > > inclusion with the env files, but for the sake of usability, I'd prefer > > something like: > > ~~~ > > (...) > > -e > > /usr/share/openstack-tripleo-heat-templates/environments/services-docker/ovn- > > octavia.yaml \ > > (...) > > ~~~ > > where the order of inclusion wrt neutron-ovn-dvr-ha doesn't matter. > > Yes, I agree that depending on the order in which the templates are passed > to the "openstack overcloud deploy" command is not ideal.I'm reassigning > this ticket to the DFG and component where such changes should be made. > > Now for this particular problem with OVN + Octavia, the patch [0] should fix > it. > > [0] https://review.openstack.org/#/c/591765/ > > Hope that helps, > Lucas You have a patch that fixes this issue so this is not for DFG:DF. The issue is with the mappings in these networking related environment files and the patch you linked fixes the problem. There's nothing for DFG:DF to do here.
(In reply to James Slagle from comment #5) > (In reply to Lucas Alvares Gomes from comment #4) > > Hi, > > > > > I hope that it's clear that such nuances should not exist within the RH > > > provided environment files. I do understand the principle of order of > > > inclusion with the env files, but for the sake of usability, I'd prefer > > > something like: > > > ~~~ > > > (...) > > > -e > > > /usr/share/openstack-tripleo-heat-templates/environments/services-docker/ovn- > > > octavia.yaml \ > > > (...) > > > ~~~ > > > where the order of inclusion wrt neutron-ovn-dvr-ha doesn't matter. > > > > Yes, I agree that depending on the order in which the templates are passed > > to the "openstack overcloud deploy" command is not ideal.I'm reassigning > > this ticket to the DFG and component where such changes should be made. > > > > Now for this particular problem with OVN + Octavia, the patch [0] should fix > > it. > > > > [0] https://review.openstack.org/#/c/591765/ > > > > Hope that helps, > > Lucas > > You have a patch that fixes this issue so this is not for DFG:DF. The issue > is with the mappings in these networking related environment files and the > patch you linked fixes the problem. There's nothing for DFG:DF to do here. Fair enough, this bug is specific to the OVN + Octavia conflict. My bad. If the author thinks its valuable, we could perhaps get a new ticket for the ordering problem (generically).
James please see: https://bugs.launchpad.net/tripleo/+bug/1716391 Kamil and Brent from the Network DFG are trying to handle the general issue here - which is that certain values (Like Neutron service plugins in this case) should be additive instead of overriding each other, to provide a less surprising operator experience. Like Andreas pointed out, some operators expect to be able to add in any env file and "just have it work". Whether that's realistic or not is debatable but we should do what we can to move in that direction.
(In reply to Assaf Muller from comment #9) > James please see: > https://bugs.launchpad.net/tripleo/+bug/1716391 > > Kamil and Brent from the Network DFG are trying to handle the general issue > here - which is that certain values (Like Neutron service plugins in this > case) should be additive instead of overriding each other, to provide a less > surprising operator experience. Like Andreas pointed out, some operators > expect to be able to add in any env file and "just have it work". Whether > that's realistic or not is debatable but we should do what we can to move in > that direction. I have seen that. Would be good for that to be brought up as an RFE. The launchpad mentions that this could work the similar to how firewall_rules work. firewall_rules is implemented via hieradata and puppet-tripleo, whereas it this bug is about Heat parameter usage. The neutron services here could be updated to set hieradata like we do for firewall_rule, and then puppet-neutron be updated to read that data and merge the drivers, which would match how firewall_rules are handled.
You may also look into parameter_merge_strategies, which can be set per-parameter in Heat environment files. I don't think we have an existing uses of this in TripleO though.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:0068