<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 13, 2016 at 4:28 AM, Dan Sneddon <span dir="ltr"><<a href="mailto:dsneddon@redhat.com" target="_blank">dsneddon@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I recently evaluated our needs for testing coverage for TripleO<br>
isolated networking. I wanted to post my thoughts on the matter for<br>
discussion, which will hopefully lead to a shared understanding of what<br>
improvements we need to make. I think we can cover the majority of<br>
end-user requirements by testing the following minimum scenarios:<br>
<br>
1. single-nic-vlans (one nic, all VLANs trunked, great for virt and POCs)<br>
<br>
2. Provisioning + bond (to test basic bonding functionality)<br>
<br>
3. Bonded provisioning (perhaps one bond with all VLANs)<br>
<br>
4. Spine and leaf (in the near future)<br>
<br></blockquote><div><br></div><div>Is linux bridges, in the list?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Within those four scenarios, we should ensure that we are testing both<br>
IPv4 and IPv6, and both traditional Neutron SNAT/Floating IPs and DVR.<br>
<br>
The first scenario is well covered. I think scenario 2 is covered by a<br>
review posted by Ben Nemec recently [1].<br>
<br>
I would very much like to see us testing scenario 3 with a resilient<br>
bond for the provisioning interface as well. This used to require LACP<br>
and fallback to a single link, but I believe recent changes to the PXE<br>
boot images may allow this over links without special switch<br>
configuration. I'm currently doing testing in my lab, I hope I can work<br>
with the TripleO CI team to help make this happen upstream.<br>
<br>
Spine and leaf (routed networks) support may require specific<br>
configuration of the routing hardware in order to support PXE booting<br>
across router boundaries. Specifically, a DHCP proxy needs to be<br>
configured in order to forward DHCP requests from a remote VLAN to the<br>
Undercloud. If this is not possible in our bare-metal CI environments,<br>
then we may need to develop a method of testing this in OVB.<br>
<br>
I'm very interested in finding out about whether it may be possible to<br>
have DHCP proxy (or "DHCP helper-address") configured on the router<br>
hardware for CI VLANs. If we can deploy this in bare metal, I think it<br>
will save us a lot of time and effort over recreating a routed<br>
environment in OVB. I believe we could use use Open Daylight or another<br>
OpenFlow controller to simulate routers in virtual environments, or<br>
perhaps use dnsmasq in DHCP proxy mode on the OVB host to forward<br>
requests from the various bridges representing remote VLANs to the<br>
Undercloud br-ctlplane bridge. But it would be a fair amount of work to<br>
put that together.<br>
<br>
I don't believe we currently test IPv6 or DVR (please correct me if I'm<br>
mistaken). Do we have plans in the works to add these to any jobs?<br>
<br>
Finally, I wonder if we need to test any exotic configurations, such as<br>
OVS+DPDK, OpenDaylight, etc.<br>
<br></blockquote><div><br></div><div>We have SR-IOV as well, which requires specific nics. </div><div>Could Tripleo be a good candidate to have different sets of 3rd party CI, </div><div>wherein we can run the specific test cases. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
OVS+DPDK would require compatible hardware. I'm interested in hearing<br>
feedback about how critical this would be in the grand scheme of<br>
things. It isn't yet clear to me that OVS+DPDK is going to have<br>
widespread adoption, but I do recognize that there are some NFV users<br>
that depend on this technology.<br>
<br>
OpenDaylight does not require hardware changes AFAIK, but the drivers<br>
and network interface config differs significantly from ML2+OVS. I'm<br>
helping some ODL developers make changes that will allow deployment via<br>
TripleO, but these changes won't be tested by CI.<br>
<br>
Of course, there are elements of OVS+DPDK and ODL that get tested as<br>
part of Neutron CI, but now we are implementing TripleO-based<br>
deployment of these technologies, I wonder if we should endeavor to<br>
test them in CI. I suppose that begs the question, if we are testing<br>
those, then why not Contrail, etc.? I don't know where we draw the<br>
line, but it seems that we might want to at least periodically test<br>
deploying some other Neutron drivers via TripleO.<br>
<br></blockquote><div><br></div><div>Adding OVN to the list as well. </div><div><br></div><div>regards</div><div>/sanjay</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
[1] - <a href="https://review.openstack.org/#/c/385562" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/385562</a><br>
<span class="gmail-HOEnZb"><font color="#888888"><br>
--<br>
Dan Sneddon | Senior Principal OpenStack Engineer<br>
<a href="mailto:dsneddon@redhat.com">dsneddon@redhat.com</a> | <a href="http://redhat.com/openstack" rel="noreferrer" target="_blank">redhat.com/openstack</a><br>
dsneddon:irc | @dxs:twitter<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</font></span></blockquote></div><br></div></div>