----- Original Message ----- > From: "Andrey Danin" <ada...@mirantis.com> > To: openstack-dev@lists.openstack.org, "fuel-dev" > <fuel-...@lists.launchpad.net> > Sent: Tuesday, February 11, 2014 11:42:46 AM > Subject: [openstack-dev] [Fuel][TripleO] NIC bonding for OpenStack > > Hi Openstackers, > > We are working on link aggregation support in Fuel. We wonder what are the > most desirable types of bonding now in datacenters. We had some issues (see > below) with OVS bond in LACP mode, and it turned out that standard Linux > bonding (attached to OVS bridges) was a better option in our setup. > > I want to hear your opinion, guys. What types of bonding do you think are > better now in terms of stability and performance, so that we can properly > support them for OpenStack installations. > > Also, we are wondering if there any plans to support bonding in TripleO, > and how you guys would like to see it be implemented? What is the general > approach for such complex network configurations for TripleO?
The OVS bonded approach could work quite well with TripleO since we already use an OVS bridge to provide network access. Right now we do most of our OVS network configuration via the ensure-bridge script/tool. It takes care of creating the OVS bridge and moving our physical NIC onto the bridge so that instances have network connectivity in our flat network. I recently re-factored this tool so that it uses persistent network configuration files: https://review.openstack.org/#/c/69918/ Once we get that in we could simply add in the extra OVSBonding config as outlined here and I think we'd have it: https://github.com/osrg/openvswitch/blob/master/rhel/README.RHEL#L108 ---- As for standard linux bonding we could do that too... perhaps via another tool that runs before ensure-bridge does its thing as we'd still want the ability to put the bonded interface on an OVS bridge. Dan > We would love to extract this piece from Fuel and make it fully independent, > so that the > larger community can use it and we could work collaboratively on it. Right > now it is actually already granular and can be reused in other projects, > and implemented as a separated puppet module: > https://github.com/stackforge/fuel-library/tree/master/deployment/puppet/l23network > . > > Some links with our design considerations: > > https://etherpad.openstack.org/p/fuel-bonding-design > > https://blueprints.launchpad.net/fuel/+spec/nics-bonding-enabled-from-ui > > <https://blueprints.launchpad.net/fuel/+spec/nics-bonding-enabled-from-ui> > > UI mockups: > > https://drive.google.com/file/d/0Bw6txZ1qvn9CaDdJS0ZUcW1DeDg/edit?usp=sharing > > Description of the problem with LACP we ran into: > https://etherpad.openstack.org/p/LACP_issue > > Thanks, > > > -- > Andrey Danin > ada...@mirantis.com > skype: gcon.monolake > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
