Open Stack

On Thu, Oct 13, 2016 at 4:28 AM, Dan Sneddon <dsneddon at redhat.com> wrote:

> I recently evaluated our needs for testing coverage for TripleO
> isolated networking. I wanted to post my thoughts on the matter for
> discussion, which will hopefully lead to a shared understanding of what
> improvements we need to make. I think we can cover the majority of
> end-user requirements by testing the following minimum scenarios:
>
> 1. single-nic-vlans (one nic, all VLANs trunked, great for virt and POCs)
>
> 2. Provisioning + bond (to test basic bonding functionality)
>
> 3. Bonded provisioning (perhaps one bond with all VLANs)
>
> 4. Spine and leaf (in the near future)
>
>
Is linux bridges, in the list?

Within those four scenarios, we should ensure that we are testing both
> IPv4 and IPv6, and both traditional Neutron SNAT/Floating IPs and DVR.
>
> The first scenario is well covered. I think scenario 2 is covered by a
> review posted by Ben Nemec recently [1].
>
> I would very much like to see us testing scenario 3 with a resilient
> bond for the provisioning interface as well. This used to require LACP
> and fallback to a single link, but I believe recent changes to the PXE
> boot images may allow this over links without special switch
> configuration. I'm currently doing testing in my lab, I hope I can work
> with the TripleO CI team to help make this happen upstream.
>
> Spine and leaf (routed networks) support may require specific
> configuration of the routing hardware in order to support PXE booting
> across router boundaries. Specifically, a DHCP proxy needs to be
> configured in order to forward DHCP requests from a remote VLAN to the
> Undercloud. If this is not possible in our bare-metal CI environments,
> then we may need to develop a method of testing this in OVB.
>
> I'm very interested in finding out about whether it may be possible to
> have DHCP proxy (or "DHCP helper-address") configured on the router
> hardware for CI VLANs. If we can deploy this in bare metal, I think it
> will save us a lot of time and effort over recreating a routed
> environment in OVB. I believe we could use use Open Daylight or another
> OpenFlow controller to simulate routers in virtual environments, or
> perhaps use dnsmasq in DHCP proxy mode on the OVB host to forward
> requests from the various bridges representing remote VLANs to the
> Undercloud br-ctlplane bridge. But it would be a fair amount of work to
> put that together.
>
> I don't believe we currently test IPv6 or DVR (please correct me if I'm
> mistaken). Do we have plans in the works to add these to any jobs?
>
> Finally, I wonder if we need to test any exotic configurations, such as
> OVS+DPDK, OpenDaylight, etc.
>
>
We have SR-IOV as well, which requires specific nics.
Could Tripleo be a good candidate to have different sets of 3rd party CI,
wherein we can run the specific test cases.


> OVS+DPDK would require compatible hardware. I'm interested in hearing
> feedback about how critical this would be in the grand scheme of
> things. It isn't yet clear to me that OVS+DPDK is going to have
> widespread adoption, but I do recognize that there are some NFV users
> that depend on this technology.
>
> OpenDaylight does not require hardware changes AFAIK, but the drivers
> and network interface config differs significantly from ML2+OVS. I'm
> helping some ODL developers make changes that will allow deployment via
> TripleO, but these changes won't be tested by CI.
>
> Of course, there are elements of OVS+DPDK and ODL that get tested as
> part of Neutron CI, but now we are implementing TripleO-based
> deployment of these technologies, I wonder if we should endeavor to
> test them in CI. I suppose that begs the question, if we are testing
> those, then why not Contrail, etc.? I don't know where we draw the
> line, but it seems that we might want to at least periodically test
> deploying some other Neutron drivers via TripleO.
>
>
Adding OVN to the list as well.

regards
/sanjay


> [1] - https://review.openstack.org/#/c/385562
>
> --
> Dan Sneddon         |  Senior Principal OpenStack Engineer
> dsneddon at redhat.com |  redhat.com/openstack
> dsneddon:irc        |  @dxs:twitter
>
> __________________________________________________________________________
> 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/20161013/90354f61/attachment-0001.html>