Open Stack

On Thu, Oct 6, 2016 at 3:44 PM Jay Pipes <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/b7704f5f/attachment.html>