Open Stack

I don't necessarily agree that rewriting test is the solution here.

May be for some extreme cases that could be fine, but from the maintenance
point of view doesn't sound very practical IMHO.

In some cases it can be just a parametrization of tests as they are, or
simply accounting for
a bit of extra headroom in quotas (when of course the purpose of such
specific tests is not
to verify the quota behaviour, for example).



On Sun, Apr 8, 2018 at 3:52 PM Gary Kotton <gkotton at vmware.com> wrote:

> Hi,
>
> There are some tempest tests that check realization of resources on the
> networking platform and connectivity. Here things are challenging as each
> networking platform may be more restrictive than the upstream ML2 plugin.
> My thinking here is that we should leverage the tempest plugins for each
> networking platform and they can overwrite the problematic tests and
> address them as suitable for the specific plugin.
>
> Thanks
>
> Gary
>
>
>
> *From: *Miguel Angel Ajo Pelayo <majopela at redhat.com>
> *Reply-To: *OpenStack List <openstack-dev at lists.openstack.org>
> *Date: *Saturday, April 7, 2018 at 8:56 AM
> *To: *OpenStack List <openstack-dev at lists.openstack.org>
> *Subject: *Re: [openstack-dev] [neutron] [OVN] Tempest API / Scenario
> tests and OVN metadata
>
>
>
> 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 <dalvarez at redhat.com> wrote:
>
>
>
> > On 6 Apr 2018, at 19:04, Sławek Kapłoński <slawek at 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 <slawek at 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 <dalvarez at 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 <
> lucasagomes at 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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_networking-2Dovn_blob_f3f5257fc465bbf44d589cc16e9ef7781f6b5b1d_networking-5Fovn_common_ovn-5Fclient.py-23L1154&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw&m=4VaXLNjn4Hbb_BkGbVUEwA5UkdTG3HvNMfMQkSJ1zYw&s=f1Z1XwmRFOtm4fcJMp4rAdTgY9oQCx82CvGkfuEfeYE&e=>
> >>> [1]
> https://github.com/openstack/neutron-tempest-plugin/blob/35bf37d1830328d72606f9c790b270d4fda2b854/neutron_tempest_plugin/api/admin/test_quotas_negative.py#L66
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_neutron-2Dtempest-2Dplugin_blob_35bf37d1830328d72606f9c790b270d4fda2b854_neutron-5Ftempest-5Fplugin_api_admin_test-5Fquotas-5Fnegative.py-23L66&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw&m=4VaXLNjn4Hbb_BkGbVUEwA5UkdTG3HvNMfMQkSJ1zYw&s=gO0ljd0wsJjszEhKt42hd9LEf07Ii84EizehxLAZmkc&e=>
> >>> [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-request at 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-request at lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >> —
> >> Best regards
> >> Slawek Kaplonski
> >> slawek at kaplonski.pl
> >>
> >>
> __________________________________________________________________________
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > —
> > Best regards
> > Slawek Kaplonski
> > slawek at kaplonski.pl
> >
> >
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180409/f54cb25d/attachment.html>