Bug 1552541
Summary: | ovn ci failure: testtools.matchers._impl.MismatchError: 'd1' != u'' | ||
---|---|---|---|
Product: | Red Hat OpenStack | Reporter: | Eran Kuris <ekuris> |
Component: | python-neutron-tests-tempest | Assignee: | Lucas Alvares Gomes <lmartins> |
Status: | CLOSED ERRATA | QA Contact: | Eran Kuris <ekuris> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 13.0 (Queens) | CC: | abregman, apevec, bcafarel, dalvarez, ekuris, lhh, majopela, nusiddiq, nyechiel, sclewis, tfreger |
Target Milestone: | rc | Keywords: | AutomationBlocker, Reopened, Triaged |
Target Release: | 13.0 (Queens) | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | python-neutron-tests-tempest-0.0.1-0.20180416200225.c515df4.el7ost | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2018-06-27 13:35:05 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: |
Description
Eran Kuris
2018-03-07 10:11:45 UTC
The issue is seen because the CI job is not setting the t-h-t param - "NeutronDnsDomain". Since it is not setting, the param "dns_domain" in neutron.conf is not set and the default value "openstacklocal" is used by neutron-server and because of this wheb dns_name is passed while creating the port, the "dns_name" attribute is not set by neutron-server. In the test output we can confirm that "openstacklocal" is used. **************************** 2018-03-31 11:33:19,632 29935 DEBUG [tempest.lib.common.rest_client] Request - Headers: {'Content-Type': 'application/json', 'Accept': 'application/json', 'X-Auth-Token': '<omitted>'} Body: {"port": {"network_id": "dbb31073-109a-4cc6-b3a4-dc8d3b8294b2", "dns_name": "d1"}} Response - Headers: {'status': '201', u'content-length': '845', 'content-location': 'http://10.0.0.109:9696/v2.0/ports', u'date': 'Sat, 31 Mar 2018 15:33:19 GMT', u'content-type': 'application/json', u'connection': 'close', u'x-openstack-request-id': 'req-8c4107e4-a3eb-46ae-aa24-a5d8150c3a0d'} Body: {"port":{"allowed_address_pairs":[],..."dns_assignment":[{"hostname":"host-10-100-0-6","ip_address":"10.100.0.6","fqdn":"host-10-100-0-6.openstacklocal."}],..."network_id":"dbb31073-109a-4cc6-b3a4-dc8d3b8294b2","dns_name":"","created_at":"2018-03-31T15:33:17Z","binding:vnic_type":"normal","tenant_id":"c83a602d6980400b82028e4126443ccf"}} }}} ************** The solution is when deploying OVN, the CI job should set the t-h-t param "NeutronDnsDomain" to some value (other than "openstacklocal"). Looks like the sos report doesn't copy the folder "/var/lib/config-data/puppet-generated/neutron/" because of which I couldn't check the value of "dns_domain" in neutron.conf and verify myself. However, on my devstack setup, I set "dns_domain=ovn.test" in neutron.conf and created a port $openstack port create --network priv tmp1 --dns-name d1 +-----------------------+--------------------------------------------------------------------------+ | Field | Value | +-----------------------+--------------------------------------------------------------------------+ | admin_state_up | UP | | allowed_address_pairs | | | binding_host_id | | | binding_profile | | | binding_vif_details | | | binding_vif_type | unbound | | binding_vnic_type | normal | | created_at | 2018-04-02T14:43:08Z | | data_plane_status | None | | description | | | device_id | | | device_owner | | | dns_assignment | fqdn='d1.ovn.test.', hostname='d1', ip_address='30.0.0.13' | | dns_domain | None | | dns_name | d1 | | extra_dhcp_opts | | | fixed_ips | ip_address='30.0.0.13', subnet_id='2464a745-19b3-460b-9073-2a4dc43e2c21' | | id | f7f733c9-5b22-4be0-8f45-6915743da3eb | | ip_address | None | | mac_address | fa:16:3e:e8:fb:26 | | name | tmp1 | | network_id | b88a4839-1e46-4436-a7a7-edbc0e23d1a4 | | option_name | None | | option_value | None | | port_security_enabled | True | | project_id | b306153543c0457480bd0139340baeec | | qos_policy_id | None | | revision_number | 7 | | security_group_ids | 94ddef58-4032-411f-b91e-5ba87cce478f | | status | DOWN | | subnet_id | None | | tags | | | trunk_details | None | | updated_at | 2018-04-02T14:43:08Z | +-----------------------+--------------------------------------------------------------------------+ Below is the output when I created a port with "dns_domain" NOT set in mysetup. $openstack port create --network priv tmp1 --dns-name d1 +-----------------------+---------------------------------------------------------------------------------------+ | Field | Value | +-----------------------+---------------------------------------------------------------------------------------+ | admin_state_up | UP | | allowed_address_pairs | | | binding_host_id | | | binding_profile | | | binding_vif_details | | | binding_vif_type | unbound | | binding_vnic_type | normal | | created_at | 2018-04-02T14:45:55Z | | data_plane_status | None | | description | | | device_id | | | device_owner | | | dns_assignment | fqdn='host-30-0-0-5.openstacklocal.', hostname='host-30-0-0-5', ip_address='30.0.0.5' | | dns_domain | None | | dns_name | | | extra_dhcp_opts | | | fixed_ips | ip_address='30.0.0.5', subnet_id='2464a745-19b3-460b-9073-2a4dc43e2c21' | | id | 0d2ab298-2387-4ca5-ac72-e06bdc56b066 | | ip_address | None | | mac_address | fa:16:3e:76:96:2d | | name | tmp1 | | network_id | b88a4839-1e46-4436-a7a7-edbc0e23d1a4 | | option_name | None | | option_value | None | | port_security_enabled | True | | project_id | b306153543c0457480bd0139340baeec | | qos_policy_id | None | | revision_number | 6 | | security_group_ids | 94ddef58-4032-411f-b91e-5ba87cce478f | | status | DOWN | | subnet_id | None | | tags | | | trunk_details | None | | updated_at | 2018-04-02T14:45:55Z | +-----------------------+---------------------------------------------------------------------------------------+ I am reopening this bug, since we still need to decide how to resolve it. As a first step we must skip it, as we do in neutron - https://rhos-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/DFG-network-neutron-12_director-rhel-virthost-3cont_2comp_1net-ipv4-vxlan-composable/176/testReport/neutron.tests.tempest.api.test_ports/PortsTestJSON/ Second step we need to enable it and to add DNS server in order to test it since I agree with Numan, we will support this feature eventually. Thanks, Toni I was able to reproduce the problem. As other people pointed out, configuring the dns_domain to something other than "openstacklocal" (and making sure the driver_extensions ml2 config also contains "dns") would make the tests pass. The quota problem that was pointed out later in this BZ should already be fixed by: https://code.engineering.redhat.com/gerrit/#/c/135778. @Eran, can you try it again with those configs/fixes in place ? ... As to networking-ovn upstream, the DNS tests were being skipped cause DNS wasn't properly configured. I have pushed a patch upstream to enable it now: https://review.openstack.org/#/c/562527/ (In reply to Lucas Alvares Gomes from comment #24) > I was able to reproduce the problem. As other people pointed out, > configuring the dns_domain to something other than "openstacklocal" (and > making sure the driver_extensions ml2 config also contains "dns") would make > the tests pass. > > The quota problem that was pointed out later in this BZ should already be > fixed by: https://code.engineering.redhat.com/gerrit/#/c/135778. > > @Eran, can you try it again with those configs/fixes in place ? > > ... > > As to networking-ovn upstream, the DNS tests were being skipped cause DNS > wasn't properly configured. I have pushed a patch upstream to enable it now: > https://review.openstack.org/#/c/562527/ I will do my best to try that. I have a backlog of tests that I need to cover. 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/RHEA-2018:2086 |