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.
Cheers, On Sat, Apr 7, 2018, 12:36 AM Daniel Alvarez <dalva...@redhat.com> wrote: > > > > On 6 Apr 2018, at 19:04, Sławek Kapłoński <sla...@kaplonski.pl> wrote: > > > > Hi, > > > > Another idea is to modify test that it will: > > 1. Check how many ports are in tenant, > > 2. Set quota to actual number of ports + 1 instead of hardcoded 1 as it > is now, > > 3. Try to add 2 ports - exactly as it is now, > > > Cool, I like this one :-) > Good idea. > > > I think that this should be still backend agnostic and should fix this > problem. > > > >> Wiadomość napisana przez Sławek Kapłoński <sla...@kaplonski.pl> w dniu > 06.04.2018, o godz. 17:08: > >> > >> Hi, > >> > >> I don’t know how networking-ovn is working but I have one question. > >> > >> > >>> Wiadomość napisana przez Daniel Alvarez Sanchez <dalva...@redhat.com> > w dniu 06.04.2018, o godz. 15:30: > >>> > >>> Hi, > >>> > >>> Thanks Lucas for writing this down. > >>> > >>> On Thu, Apr 5, 2018 at 11:35 AM, Lucas Alvares Gomes < > lucasago...@gmail.com> wrote: > >>> Hi, > >>> > >>> The tests below are failing in the tempest API / Scenario job that > >>> runs in the networking-ovn gate (non-voting): > >>> > >>> > neutron_tempest_plugin.api.admin.test_quotas_negative.QuotasAdminNegativeTestJSON.test_create_port_when_quotas_is_full > >>> > neutron_tempest_plugin.api.test_routers.RoutersIpV6Test.test_router_interface_status > >>> > neutron_tempest_plugin.api.test_routers.RoutersTest.test_router_interface_status > >>> > neutron_tempest_plugin.api.test_subnetpools.SubnetPoolsTest.test_create_subnet_from_pool_with_prefixlen > >>> > neutron_tempest_plugin.api.test_subnetpools.SubnetPoolsTest.test_create_subnet_from_pool_with_quota > >>> > neutron_tempest_plugin.api.test_subnetpools.SubnetPoolsTest.test_create_subnet_from_pool_with_subnet_cidr > >>> > >>> Digging a bit into it I noticed that with the exception of the two > >>> "test_router_interface_status" (ipv6 and ipv4) all other tests are > >>> failing because the way metadata works in networking-ovn. > >>> > >>> Taking the "test_create_port_when_quotas_is_full" as an example. The > >>> reason why it fails is because when the OVN metadata is enabled, > >>> networking-ovn will metadata port at the moment a network is created > >>> [0] and that will already fulfill the quota limit set by that test > >>> [1]. > >>> > >>> That port will also allocate an IP from the subnet which will cause > >>> the rest of the tests to fail with a "No more IP addresses available > >>> on network ..." error. > >>> > >>> With ML2/OVS we would run into the same Quota problem if DHCP would be > >>> enabled for the created subnets. This means that if we modify the > current tests > >>> to enable DHCP on them and we account this extra port it would be > valid for > >>> all networking-ovn as well. Does it sound good or we still want to > isolate quotas? > >> > >> 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. > >> 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. > >> > >>> > >>> This is not very trivial to fix because: > >>> > >>> 1. Tempest should be backend agnostic. So, adding a conditional in the > >>> tempest test to check whether OVN is being used or not doesn't sound > >>> correct. > >>> > >>> 2. Creating a port to be used by the metadata agent is a core part of > >>> the design implementation for the metadata functionality [2] > >>> > >>> So, I'm sending this email to try to figure out what would be the best > >>> approach to deal with this problem and start working towards having > >>> that job to be voting in our gate. Here are some ideas: > >>> > >>> 1. Simple disable the tests that are affected by the metadata approach. > >>> > >>> 2. Disable metadata for the tempest API / Scenario tests (here's a > >>> test patch doing it [3]) > >>> > >>> IMHO, we don't want to do this as metadata is likely to be enabled in > all the > >>> clouds either using ML2/OVS or OVN so it's good to keep exercising > >>> this part. > >>> > >>> > >>> 3. Same as 1. but also create similar tempest tests specific for OVN > >>> somewhere else (in the networking-ovn tree?!) > >>> > >>> As we discussed on IRC I'm keen on doing this instead of getting bits > in > >>> tempest to do different things depending on the backend used. Unless > >>> we want to enable DHCP on the subnets that these tests create :) > >>> > >>> > >>> What you think would be the best way to workaround this problem, any > >>> other ideas ? > >>> > >>> As for the "test_router_interface_status" tests that are failing > >>> independent of the metadata, there's a bug reporting the problem here > >>> [4]. So we should just fix it. > >>> > >>> [0] > https://github.com/openstack/networking-ovn/blob/f3f5257fc465bbf44d589cc16e9ef7781f6b5b1d/networking_ovn/common/ovn_client.py#L1154 > >>> [1] > https://github.com/openstack/neutron-tempest-plugin/blob/35bf37d1830328d72606f9c790b270d4fda2b854/neutron_tempest_plugin/api/admin/test_quotas_negative.py#L66 > >>> [2] > https://docs.openstack.org/networking-ovn/latest/contributor/design/metadata_api.html#overview-of-proposed-approach > >>> [3] https://review.openstack.org/#/c/558792/ > >>> [4] https://bugs.launchpad.net/networking-ovn/+bug/1713835 > >>> > >>> Cheers, > >>> Lucas > >>> > >>> Thanks, > >>> Daniel > >>> > >>> > __________________________________________________________________________ > >>> OpenStack Development Mailing List (not for usage questions) > >>> Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>> > >>> > __________________________________________________________________________ > >>> OpenStack Development Mailing List (not for usage questions) > >>> Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> — > >> Best regards > >> Slawek Kaplonski > >> sla...@kaplonski.pl > >> > >> > __________________________________________________________________________ > >> OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > — > > Best regards > > Slawek Kaplonski > > sla...@kaplonski.pl > > > > > > > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev