Open Stack

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 <neil at tigera.io<mailto:neil at tigera.io>>
Reply-To: openstack-dev <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Thursday, October 6, 2016 at 8:39 AM
To: openstack-dev <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron][networking-vpp]Introducing networking-vpp

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.


Best,
-jay

Regards,
     Neil

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161006/4108284f/attachment.html>