Open Stack

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)

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.

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.

[1] - https://review.openstack.org/#/c/385562

-- 
Dan Sneddon         |  Senior Principal OpenStack Engineer
dsneddon at redhat.com |  redhat.com/openstack
dsneddon:irc        |  @dxs:twitter