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 dsned...@redhat.com | redhat.com/openstack dsneddon:irc | @dxs:twitter __________________________________________________________________________ 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