Open Stack

On 10/06/2016 11:39 AM, Neil Jerram wrote:
> On Thu, Oct 6, 2016 at 3:44 PM Jay Pipes <jaypipes at gmail.com
> <mailto:jaypipes at gmail.com>> 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