<div dir="ltr">Hi,<div><br></div><div>Thanks Lucas for writing this down.<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 5, 2018 at 11:35 AM, Lucas Alvares Gomes <span dir="ltr"><<a href="mailto:lucasagomes@gmail.com" target="_blank">lucasagomes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
The tests below are failing in the tempest API / Scenario job that<br>
runs in the networking-ovn gate (non-voting):<br>
<br>
neutron_tempest_plugin.api.<wbr>admin.test_quotas_negative.<wbr>QuotasAdminNegativeTestJSON.<wbr>test_create_port_when_quotas_<wbr>is_full<br>
neutron_tempest_plugin.api.<wbr>test_routers.RoutersIpV6Test.<wbr>test_router_interface_status<br>
neutron_tempest_plugin.api.<wbr>test_routers.RoutersTest.test_<wbr>router_interface_status<br>
neutron_tempest_plugin.api.<wbr>test_subnetpools.<wbr>SubnetPoolsTest.test_create_<wbr>subnet_from_pool_with_<wbr>prefixlen<br>
neutron_tempest_plugin.api.<wbr>test_subnetpools.<wbr>SubnetPoolsTest.test_create_<wbr>subnet_from_pool_with_quota<br>
neutron_tempest_plugin.api.<wbr>test_subnetpools.<wbr>SubnetPoolsTest.test_create_<wbr>subnet_from_pool_with_subnet_<wbr>cidr<br>
<br>
Digging a bit into it I noticed that with the exception of the two<br>
"test_router_interface_status" (ipv6 and ipv4) all other tests are<br>
failing because the way metadata works in networking-ovn.<br>
<br>
Taking the "test_create_port_when_quotas_<wbr>is_full" as an example. The<br>
reason why it fails is because when the OVN metadata is enabled,<br>
networking-ovn will metadata port at the moment a network is created<br>
[0] and that will already fulfill the quota limit set by that test<br>
[1].<br>
<br>
That port will also allocate an IP from the subnet which will cause<br>
the rest of the tests to fail with a "No more IP addresses available<br>
on network ..." error.<br></blockquote><div><br></div><div>With ML2/OVS we would run into the same Quota problem if DHCP would be</div><div>enabled for the created subnets. This means that if we modify the current tests</div><div>to enable DHCP on them and we account this extra port it would be valid for</div><div>all networking-ovn as well. Does it sound good or we still want to isolate quotas?</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
This is not very trivial to fix because:<br>
<br>
1. Tempest should be backend agnostic. So, adding a conditional in the<br>
tempest test to check whether OVN is being used or not doesn't sound<br>
correct.<br>
<br>
2. Creating a port to be used by the metadata agent is a core part of<br>
the design implementation for the metadata functionality [2]<br>
<br>
So, I'm sending this email to try to figure out what would be the best<br>
approach to deal with this problem and start working towards having<br>
that job to be voting in our gate. Here are some ideas:<br>
<br>
1. Simple disable the tests that are affected by the metadata approach.<br>
<br>
2. Disable metadata for the tempest API / Scenario tests (here's a<br>
test patch doing it [3])<br></blockquote><div> </div><div>IMHO, we don't want to do this as metadata is likely to be enabled in all the</div><div>clouds either using ML2/OVS or OVN so it's good to keep exercising</div><div>this part.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
3. Same as 1. but also create similar tempest tests specific for OVN<br>
somewhere else (in the networking-ovn tree?!)<br></blockquote><div> </div><div>As we discussed on IRC I'm keen on doing this instead of getting bits in</div><div>tempest to do different things depending on the backend used. Unless</div><div>we want to enable DHCP on the subnets that these tests create :)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
What you think would be the best way to workaround this problem, any<br>
other ideas ?<br>
<br>
As for the "test_router_interface_status" tests that are failing<br>
independent of the metadata, there's a bug reporting the problem here<br>
[4]. So we should just fix it.<br>
<br>
[0] <a href="https://github.com/openstack/networking-ovn/blob/f3f5257fc465bbf44d589cc16e9ef7781f6b5b1d/networking_ovn/common/ovn_client.py#L1154" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>networking-ovn/blob/<wbr>f3f5257fc465bbf44d589cc16e9ef7<wbr>781f6b5b1d/networking_ovn/<wbr>common/ovn_client.py#L1154</a><br>
[1] <a href="https://github.com/openstack/neutron-tempest-plugin/blob/35bf37d1830328d72606f9c790b270d4fda2b854/neutron_tempest_plugin/api/admin/test_quotas_negative.py#L66" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>neutron-tempest-plugin/blob/<wbr>35bf37d1830328d72606f9c790b270<wbr>d4fda2b854/neutron_tempest_<wbr>plugin/api/admin/test_quotas_<wbr>negative.py#L66</a><br>
[2] <a href="https://docs.openstack.org/networking-ovn/latest/contributor/design/metadata_api.html#overview-of-proposed-approach" rel="noreferrer" target="_blank">https://docs.openstack.org/<wbr>networking-ovn/latest/<wbr>contributor/design/metadata_<wbr>api.html#overview-of-proposed-<wbr>approach</a><br>
[3] <a href="https://review.openstack.org/#/c/558792/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/558792/</a><br>
[4] <a href="https://bugs.launchpad.net/networking-ovn/+bug/1713835" rel="noreferrer" target="_blank">https://bugs.launchpad.net/<wbr>networking-ovn/+bug/1713835</a><br>
<br>
Cheers,<br>
Lucas<br></blockquote><div><br></div><div>Thanks,</div><div>Daniel </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</blockquote></div><br></div></div></div></div>