Bug 1565126
| Summary: | OVN - CI Fails because DVR router does not expose in ovn "distributed | True" | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Eran Kuris <ekuris> |
| Component: | python-neutron-tests-tempest | Assignee: | Arie Bregman <abregman> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Ofer Blaut <oblaut> |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 13.0 (Queens) | CC: | abregman, amuller, apevec, dalvarez, jlibosva, lhh, majopela, vkhanna, whayutin |
| Target Milestone: | --- | Keywords: | Triaged, ZStream |
| Target Release: | 13.0 (Queens) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-03-29 10:17:15 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Assigning to Miguel for triaging. Yes, networking-ovn doesn't either show: * ha * distributed flags on the router, because it doesn't implement either the ha or the distributed extensions of the API: https://github.com/openstack/networking-ovn/blob/df880435d3a7e98aaa8a0ba3a0a9b81286129586/networking_ovn/common/extensions.py#L30 It's all a global admin site decision for "distributed" via the: https://github.com/openstack/networking-ovn/blob/df880435d3a7e98aaa8a0ba3a0a9b81286129586/networking_ovn/common/config.py#L115 enable_distributed_floating_ip flag, which we even considered not providing, and making it automatic. It was an architectural, simpler UX decision, we can open an RFE for that. The tempest test should check that the "distributed" extension is enabled on the extension list before attempting to use the distributed flag, with the ml2/ovs version it works, but, that's because they expose those API flags, and they also support mixing all types of routers on a deployment, which is also a design descission, which also makes their code and user experience more complicated. I'd clone this bz to neutron tempest plugin to make such test conditional on the flag. Eran, if you have an dvr ovn deployment I can give it a try for looking into a better way of implementing the test which would be compatible with both ml2/ovs and ml2/ovn. As discussed, we should skip these tests in tempest when the extensions are not enabled. *** Bug 1566118 has been marked as a duplicate of this bug. *** Ok, so those tests are actually good (they skip if "dvr" extension is not implemented/enabled, which we don't) looking at tempest.conf: [network-feature-enabled] ipv6_subnet_attributes = true api_extensions = dvr We should make sure that infrared/tripleo disables the api_extensions (l3-ha/dvr) on network features for tempest. @arie, I see that you manually skipped NetworkDvrTest.test_vm_reachable_through_compute but, we should probably disable via removing the "dvr" api extension which we don't implement. But I guess that comes from director, right? @weshay Could you orient me on how does director/tripleo configure tempest on the undercloud? I want to see where the [network-feature-enabled] api_extensions = dvr is configured to be able to disable it for the case of deploying ovn. I don't want customers running tempest and finding out that there are failing tests (which may not be ran for OVN): https://bugzilla.redhat.com/show_bug.cgi?id=1565126#c8 @abregman we need to remove the DVR extension from all ovn/dvr jobs, can you handle that? Still we may want to make sure TripleO provides a good deployer input to Still we may want to make sure TripleO provides a good deployer input to the tempest conf, by letting us disable [network-feature-enabled] api_extensions = dvr on tempest conf. @Wes, can you point me to where's that handled in tripleo? Looks like it's removed this way in oooq? http://git.openstack.org/cgit/openstack/tripleo-quickstart-extras/tree/roles/validate-tempest/defaults/main.yml#n60 Probably we should modify this parameter and remove http://git.openstack.org/cgit/openstack/puppet-openstack-integration/tree/manifests/tempest.pp#n139 Ant this is how it's done in packstack: http://git.openstack.org/cgit/openstack/packstack/tree/packstack/puppet/modules/packstack/manifests/provision/tempest.pp#n101 *** Bug 1590551 has been marked as a duplicate of this bug. *** Agreeing with amuller on IRC, I believe we can close this. May be we should track that the deployment tooling (director) will generate good tempest.conf files for OVN? (if it does deploy tempest conf in any form). @dalvarez do you know who could we ask about this? |
Description of problem:parameter "distributed | True" When we are creating router on DVR setup it created with parameter "distributed | False" instead of "distributed | True" It's API issue that we need to fix for user indication that the router is DVR (overcloud) [stack@undercloud-0 ~]$ openstack router show Router_eNet_dvr +-------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Field | Value | +-------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | admin_state_up | UP | | availability_zone_hints | None | | availability_zones | None | | created_at | 2018-04-09T10:39:15Z | | description | | | distributed | False | | external_gateway_info | {"network_id": "72f821d8-6b44-4aec-9c82-c27873b6417f", "enable_snat": true, "external_fixed_ips": [{"subnet_id": "4d671580-9d6e-4c1b-94e4-c6fcc4c400b5", "ip_address": "10.0.0.214"}]} | | flavor_id | None | | ha | False | | id | c680caad-64f5-49b9-bce1-0ebbc0cac982 | | interfaces_info | [{"subnet_id": "6d1d19a3-59b9-45b4-a1f0-66ef9197ceda", "ip_address": "10.0.5.1", "port_id": "955693db-82ac-4cb2-8558-59ef4ddb11f9"}] | | name | Router_eNet_dvr | | project_id | c1531cce9ec7440e83230168cdf3f022 | | revision_number | 3 | | routes | | | status | ACTIVE | | tags | | | updated_at | 2018-04-09T10:41:53Z | Version-Release number of selected component (if applicable): osp13 ha- dvr ovn cat core_puddle_version 2018-04-03.3 # rpm -qa | grep ovn openvswitch-ovn-central-2.9.0-15.el7fdp.x86_64 openvswitch-ovn-common-2.9.0-15.el7fdp.x86_64 python-networking-ovn-4.0.1-0.20180315174741.a57c70e.el7ost.noarch openvswitch-ovn-host-2.9.0-15.el7fdp.x86_64 openstack-nova-novncproxy-17.0.2-0.20180323024604.0390d5f.el7ost.noarch novnc-0.6.1-1.el7ost.noarch python-networking-ovn-metadata-agent-4.0.1-0.20180315174741.a57c70e.el7ost.noarch puppet-ovn-12.3.1-0.20180221062110.4b16f7c.el7ost.noarch How reproducible: always Steps to Reproduce: 1.deploy dvr setup 2.create router 3. Actual results: Expected results: Additional info: