On Wed, Oct 19, 2016 at 4:30 AM Ian Wells wrote:
> Sorry to waken an old thread, but I chose a perfect moment to go on
> holiday...
>
> So yes: I don't entirely trust the way we use RabbitMQ, and that's largely
> because what we're doing with it - distributing state, or copies of state,
> or info
On 6 October 2016 at 10:43, Jay Pipes wrote:
> On 10/06/2016 11:58 AM, Naveen Joy (najoy) wrote:
>
>> It’s primarliy because we have seen better stability and scalability
>> with etcd over rabbitmq.
>>
>
> Well, that's kind of comparing apples to oranges. :)
>
> One is a distributed k/v store. Th
Was not comaparing it in the way you imply below. My point was that
eventhough they are fundamentally different systems, they play
a similar role in the way we use them - the primary purpose being
to facilitate communications between the components of a distributed
system.
We have found etcd to be
On 10/06/2016 11:58 AM, Naveen Joy (najoy) wrote:
It’s primarliy because we have seen better stability and scalability
with etcd over rabbitmq.
Well, that's kind of comparing apples to oranges. :)
One is a distributed k/v store. The other is a message queue broker.
The way that we (IMHO) over
On 10/06/2016 11:39 AM, Neil Jerram wrote:
On Thu, Oct 6, 2016 at 3:44 PM Jay Pipes mailto:jaypi...@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 st
Jerram mailto:n...@tigera.io>>
Reply-To: openstack-dev
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, October 6, 2016 at 8:39 AM
To: openstack-dev
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron][networking-vpp]Introducing networking-
To: openstack-dev
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron][networking-vpp]Introducing networking-vpp
Cool. Always like to see more drivers.
I'm curious about the choice of etcd instead of rabbitmq as the communication
mechanism between the mech dr
On Thu, Oct 6, 2016 at 3:44 PM Jay Pipes 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 pro
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 re
tobre 2016 00:27
À : "OpenStack Development Mailing List (not for usage questions)"
Objet : Re: [openstack-dev] [neutron][networking-vpp]Introducing networking-vpp
Cool. Always like to see more drivers.
I'm curious about the choice of etcd instead of rabbitmq as the communicati
Cool. Always like to see more drivers.
I'm curious about the choice of etcd instead of rabbitmq as the
communication mechanism between the mech driver and the agents since it
introduces a new dependency into the deployment. Is this because the agent
is written to work with other things like Kubern
We'd like to introduce the VPP mechanism driver, networking-vpp[1], to the
developer community.
networking-vpp is an ML2 mechanism driver to control DPDK-based VPP
user-space forwarders on OpenStack compute nodes. The code does what
mechanism drivers do - it connects VMs to each other and to othe
12 matches
Mail list logo
