this issue isn't only for networking ovn, please note that it happens with a flew other vendor plugins (like nsx), at least this is something we have found in downstream certifications. <div><br></div><div>Cheers, <br><br><div class="gmail_quote"><div dir="ltr">On Sat, Apr 7, 2018, 12:36 AM Daniel Alvarez <<a href="mailto:dalvarez@redhat.com">dalvarez@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On 6 Apr 2018, at 19:04, Sławek Kapłoński <<a href="mailto:slawek@kaplonski.pl" target="_blank">slawek@kaplonski.pl</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> Another idea is to modify test that it will:<br>
> 1. Check how many ports are in tenant,<br>
> 2. Set quota to actual number of ports + 1 instead of hardcoded 1 as it is now,<br>
> 3. Try to add 2 ports - exactly as it is now,<br>
><br>
Cool, I like this one :-)<br>
Good idea.<br>
<br>
> I think that this should be still backend agnostic and should fix this problem.<br>
><br>
>> Wiadomość napisana przez Sławek Kapłoński <<a href="mailto:slawek@kaplonski.pl" target="_blank">slawek@kaplonski.pl</a>> w dniu 06.04.2018, o godz. 17:08:<br>
>><br>
>> Hi,<br>
>><br>
>> I don’t know how networking-ovn is working but I have one question.<br>
>><br>
>><br>
>>> Wiadomość napisana przez Daniel Alvarez Sanchez <<a href="mailto:dalvarez@redhat.com" target="_blank">dalvarez@redhat.com</a>> w dniu 06.04.2018, o godz. 15:30:<br>
>>><br>
>>> Hi,<br>
>>><br>
>>> Thanks Lucas for writing this down.<br>
>>><br>
>>> On Thu, Apr 5, 2018 at 11:35 AM, Lucas Alvares Gomes <<a href="mailto:lucasagomes@gmail.com" target="_blank">lucasagomes@gmail.com</a>> wrote:<br>
>>> 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.admin.test_quotas_negative.QuotasAdminNegativeTestJSON.test_create_port_when_quotas_is_full<br>
>>> neutron_tempest_plugin.api.test_routers.RoutersIpV6Test.test_router_interface_status<br>
>>> neutron_tempest_plugin.api.test_routers.RoutersTest.test_router_interface_status<br>
>>> neutron_tempest_plugin.api.test_subnetpools.SubnetPoolsTest.test_create_subnet_from_pool_with_prefixlen<br>
>>> neutron_tempest_plugin.api.test_subnetpools.SubnetPoolsTest.test_create_subnet_from_pool_with_quota<br>
>>> neutron_tempest_plugin.api.test_subnetpools.SubnetPoolsTest.test_create_subnet_from_pool_with_subnet_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_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>
>>><br>
>>> With ML2/OVS we would run into the same Quota problem if DHCP would be<br>
>>> enabled for the created subnets. This means that if we modify the current tests<br>
>>> to enable DHCP on them and we account this extra port it would be valid for<br>
>>> all networking-ovn as well. Does it sound good or we still want to isolate quotas?<br>
>><br>
>> If DHCP will be enabled for networking-ovn, will it use one more port also or not? If so then You will still have the same problem with DHCP as in ML2/OVS You will have one port created and for networking-ovn it will be 2 ports.<br>
>> If it’s not like that then I think that this solution, with some comment in test code why DHCP is enabled should be good IMO.<br>
>><br>
>>><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>
>>><br>
>>> IMHO, we don't want to do this as metadata is likely to be enabled in all the<br>
>>> clouds either using ML2/OVS or OVN so it's good to keep exercising<br>
>>> this part.<br>
>>><br>
>>><br>
>>> 3. Same as 1. but also create similar tempest tests specific for OVN<br>
>>> somewhere else (in the networking-ovn tree?!)<br>
>>><br>
>>> As we discussed on IRC I'm keen on doing this instead of getting bits in<br>
>>> tempest to do different things depending on the backend used. Unless<br>
>>> we want to enable DHCP on the subnets that these tests create :)<br>
>>><br>
>>><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/networking-ovn/blob/f3f5257fc465bbf44d589cc16e9ef7781f6b5b1d/networking_ovn/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/neutron-tempest-plugin/blob/35bf37d1830328d72606f9c790b270d4fda2b854/neutron_tempest_plugin/api/admin/test_quotas_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/networking-ovn/latest/contributor/design/metadata_api.html#overview-of-proposed-approach</a><br>
>>> [3] <a href="https://review.openstack.org/#/c/558792/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/558792/</a><br>
>>> [4] <a href="https://bugs.launchpad.net/networking-ovn/+bug/1713835" rel="noreferrer" target="_blank">https://bugs.launchpad.net/networking-ovn/+bug/1713835</a><br>
>>><br>
>>> Cheers,<br>
>>> Lucas<br>
>>><br>
>>> Thanks,<br>
>>> Daniel<br>
>>><br>
>>> __________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>>> __________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>> —<br>
>> Best regards<br>
>> Slawek Kaplonski<br>
>> <a href="mailto:slawek@kaplonski.pl" target="_blank">slawek@kaplonski.pl</a><br>
>><br>
>> __________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> —<br>
> Best regards<br>
> Slawek Kaplonski<br>
> <a href="mailto:slawek@kaplonski.pl" target="_blank">slawek@kaplonski.pl</a><br>
><br>
><br>
><br>
><br>
> __________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div>