On Thu, Oct 6, 2016 at 3:44 PM Jay Pipes <[email protected]> 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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
