Cool. Always like to see more drivers. I'm curious about the choice of etcd instead of rabbitmq as the communication mechanism between the mech driver and the agents since it introduces a new dependency into the deployment. Is this because the agent is written to work with other things like Kubernetes, Docker, etc as well?
On Wed, Oct 5, 2016 at 12:01 PM, Ian Wells <[email protected]> wrote: > We'd like to introduce the VPP mechanism driver, networking-vpp[1], to the > developer community. > > networking-vpp is an ML2 mechanism driver to control DPDK-based VPP > user-space forwarders on OpenStack compute nodes. The code does what > mechanism drivers do - it connects VMs to each other and to other > Neutron-provided network services like routers. It also does it with care > - we aim to make sure this is a robust design that can withstand common > cloud problems and failures - and with clarity - so that it's > straightforward to see what it's chosen to do and what it's thinking. > > To give some background: > > VPP is an open source network forwarder originally developed by Cisco and > now part of the Linux Foundation FD.io project for fast dataplanes. It's > very very good at moving packets around, and has demonstrated performance > up to and well beyond 10Gbps - of tiny packets: ten times the number of > packets iperf uses to fill a 10Gbps link. This makes it especially useful > for NFV use cases. It's a user space forwarder, which has other benefits > versus kernel packet forwarding: it can be stopped and upgraded without > rebooting the host, and (in the worst case) it can crash without bringing > down the whole system. > > networking-vpp is its driver for OpenStack. We've written about 3,000 > lines of code, consisting of a mechanism driver and an agent to program VPP > through its Python API, and we use etcd to be a robust datastore and > communication channel living between the two. > > > The code, at the moment, is in a fairly early stage, so please play with > it and fix or report any problems you find. It will move packets between > VLANs and flat networks and VMs, and will connect to DHCP servers, routers > and the metadata server in your cloud, so for basic uses it will work just > the way you expect. However, we certainly don't support every feature of > Neutron just yet. In particular, we haven't tested some things like LBaaS > and VPNaaS with it - they should work, we just haven't tried - and, most > obviously, security groups are not yet implemented - that's on the way. > However, we'd like to get it into your hands so that you can have a go with > it, see what you like and don't like about it, and help us file down the > rough edges if you feel like joining us. Enjoy! > > [1] > https://github.com/openstack/networking-vpp for all your code needs > https://review.openstack.org/#/q/status:open+project:opensta > ck/networking-vpp to help > https://launchpad.net/networking-vpp for bugs > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
