<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Oct 6, 2016 at 3:44 PM Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 10/06/2016 03:46 AM, Jerome Tollet (jtollet) wrote:<br class="gmail_msg">
> Hey Kevin,<br class="gmail_msg">
><br class="gmail_msg">
> Thanks for your interest in this project.<br class="gmail_msg">
><br class="gmail_msg">
> We found etcd very convenient to store desired states as well as<br class="gmail_msg">
> operational states. It made the design easy to provide production grade<br class="gmail_msg">
> features (e.g. agent restart, mechanical driver restart, …) in a very<br class="gmail_msg">
> concise code. In addition to that, debugging is simple to do using<br class="gmail_msg">
> simple “etcdwatch” commands. Please note that etcd is not an alternative<br class="gmail_msg">
> to rabbitmq even though communication protocol is HTTP/JSON.<br class="gmail_msg">
<br class="gmail_msg">
It's probably worth mentioning that the etcd code used in networking-vpp<br class="gmail_msg">
came from networking-calico?<br class="gmail_msg"></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
When I chatted with Ian about this, I actually asked the same question<br class="gmail_msg">
and Ian told me the code came from networking-calico pretty much as-is.<br class="gmail_msg"></blockquote><div><div><br></div><div>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.<br><br></div><div>Happy to be corrected if that's not quite right, of course!<br></div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We can discuss at length about using etcd as the state data store<br class="gmail_msg">
instead of the Neutron database and using etcd watches as the mechanism<br class="gmail_msg">
for state change communication, but that will likely end up in lots of<br class="gmail_msg">
bike-shedding. There's certainly advantages and disadvantages to each<br class="gmail_msg">
approach.<br class="gmail_msg"></blockquote><div><br></div><div>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.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
Best,<br class="gmail_msg">
-jay<br class="gmail_msg"></blockquote><div><br></div><div>Regards,<br></div><div>     Neil</div><br></div></div>