The etcd handling code is unique to networking-vpp. In our model, the server code uses neutron DB to store port states and has journaling mechanisms to map this to the etcd DB. So even in our design (as it should be), the neutronDB as the primary source of truth. When data is published to etcd, the corresponding compute agents receive a notification and they drop the vhostuser and tap interfaces into VPP and report the state back to the server. A return thread on the server watches for this state update from the agents and sends port bound events to nova.
Regards, Naveen From: Neil Jerram <[email protected]<mailto:[email protected]>> Reply-To: openstack-dev <[email protected]<mailto:[email protected]>> Date: Thursday, October 6, 2016 at 8:39 AM To: openstack-dev <[email protected]<mailto:[email protected]>> Subject: Re: [openstack-dev] [neutron][networking-vpp]Introducing networking-vpp On Thu, Oct 6, 2016 at 3:44 PM Jay Pipes <[email protected]<mailto:[email protected]>> wrote: On 10/06/2016 03:46 AM, Jerome Tollet (jtollet) wrote: > Hey Kevin, > > Thanks for your interest in this project. > > We found etcd very convenient to store desired states as well as > operational states. It made the design easy to provide production grade > features (e.g. agent restart, mechanical driver restart, ...) in a very > concise code. In addition to that, debugging is simple to do using > simple "etcdwatch" commands. Please note that etcd is not an alternative > to rabbitmq even though communication protocol is HTTP/JSON. It's probably worth mentioning that the etcd code used in networking-vpp came from networking-calico? When I chatted with Ian about this, I actually asked the same question and Ian told me the code came from networking-calico pretty much as-is. To clarify (or check my own understanding of!) that statement: it's certainly true that networking-calico also uses etcd as its mechanism for communicating between the ML2 driver and the agents. However, from a quick look at the networking-vpp code, it appears to me that it doesn't use any detailed etcd handling code from networking-calico, or use the same etcd data model as Calico (i.e. the definition of how information is structured and named in the etcd tree). So I think the statement above just means that networking-vpp uses a similar architecture as networking-calico, in particular as regards using etcd for communication. Happy to be corrected if that's not quite right, of course! We can discuss at length about using etcd as the state data store instead of the Neutron database and using etcd watches as the mechanism for state change communication, but that will likely end up in lots of bike-shedding. There's certainly advantages and disadvantages to each approach. Another clarification here, I think you should say 'as the transport instead of Neutron RPC', not 'as the state data store instead of the Neutron database'. With networking-calico the Neutron DB is still the primary source of truth, and the etcd DB is just a mapping of that; and I would guess (tentatively) that that is true for networking-vpp as well. Best, -jay Regards, Neil
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
