<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>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.</div>
<div>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</div>
<div>the agents and sends port bound events to nova.</div>
<div><br>
</div>
<div>Regards,</div>
<div>Naveen</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Neil Jerram <<a href="mailto:neil@tigera.io">neil@tigera.io</a>><br>
<span style="font-weight:bold">Reply-To: </span>openstack-dev <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>Thursday, October 6, 2016 at 8:39 AM<br>
<span style="font-weight:bold">To: </span>openstack-dev <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [openstack-dev] [neutron][networking-vpp]Introducing networking-vpp<br>
</div>
<div><br>
</div>
<div>
<div>
<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>
</div>
</div>
</span>
</body>
</html>