On 10/06/2016 11:39 AM, Neil Jerram wrote:
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.
Sorry, no, I was definitely referring to the data store for state change in networking-vpp, which deliberately sidesteps the Neutron DB as the state store.
From the README.rst file, under the "How does it implement binding section?":
"etcd then contains the desired state of each host agent, and the agents monitor etcd for changes relevant to them and update their state."
and under the "Why didn't you use the ML2 agent framework for this driver?" section:
"Neutron's agent framework is based on communicating via RabbitMQ. This can lead to issues of scale when there are more than a few compute hosts involved, and RabbitMQ is not as robust as it could be, plus RabbitMQ is trying to be a fully reliable messaging system - all of which work against a robust and scalable SDN control system.
We didn't want to start down that path, so instead we've taken a different approach, that of a 'desired state' database with change listeners. etcd stores the data of how the network should be and the agents try to achieve that (and also report their status back via etcd)"
Best, -jay __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
