Description of problem: A new ovn osp16.2 vxlan job has been created to validate this functionality. Some tests failed on this job, such as test_bw_limit_east_west (see [1]). IMPORTANT: this test verifies qos bw limit functionality, but the test failed before any qos rule was created - it failed with no bw limit configured yet. We reproduced the issue on an osp virt setup, using two servers connected to a tenant network with icmp, tcp and udp traffic allowed between them (required sec group rules had been created): - icmp traffic works fine between the two servers - iperf3 was installed on the servers and both udp and tcp traffic is limited between them - the traffic is not 100% blocked but high packet loss is observed - same with http traffic between servers - on the other side, both http and iperf3 from the undercloud (north-south traffic) worked perfectly Ongoing: running these tests on ovn 16.2 geneve job at [2] [1] https://rhos-ci-staging-jenkins.lab.eng.tlv2.redhat.com/view/DFG/view/network/view/networking-ovn/job/DFG-network-networking-ovn-16.2_director-rhel-virthost-3cont_2comp-ipv4-vxlan/2/ [2] https://rhos-ci-jenkins.lab.eng.tlv2.redhat.com/view/DFG/view/network/view/networking-ovn/job/DFG-network-networking-ovn-16.2_director-rhel-virthost-3cont_2comp-ipv4-geneve/96/ Version-Release number of selected component (if applicable): RHOS-16.2-RHEL-8-20210310.n.1 How reproducible: 100% Steps to Reproduce: 1. create vxlan tenant network 2. create two rhel servers connected to it and add security groups allowing http traffic 3. start httpd on one of them 4. try to download a file from the other one - it fails (awaiting response forever)
From an email thread: Looks like we don't set external-ids:ovn-encap-type anywhere in tripleo-heat-templates, and it defaults to geneve as per puppet-ovn README. We do set ovn::controller::ovn_encap_ip to "get_param:[ServiceNetMap, NeutronTenantNetwork]" in ./deployment/ovn/ovn-controller-container-puppet.yaml though. So probably what's missing is setting ovn-encap-type to something like: ovn::controller::ovn_encap_type: {get_param: NeutronNetworkType} though I am not sure if in this environment, NeutronNetworkType is multi-value comma-separated or just 'vxlan' as ovn-controller would expect. If it's multi-value, we may need to convert/strip the value before writing into tripleo config. So this is probably a tripleo-heat-templates bug where the fix is to set / allow-to-set ovn::controller::ovn_encap_type via a heat option.
According to our records, this should be resolved by openstack-tripleo-heat-templates-11.5.1-2.20210603174830.el8ost.10. This build is available now.