Oooh, that would be great to make work. I'm so lazy, to start VMs when
doing dev and light testing. :)
On Fri, Mar 11, 2016 at 9:20 AM, Russell Bryant wrote:
> On Thu, Mar 10, 2016 at 5:43 PM, Ben Pfaff wrote:
>
> > Has anyone tried building OVS on Mac OS X? If it built there, then we
> > coul
On Fri, Mar 11, 2016 at 12:55 AM, Dan Mihai Dumitriu
wrote:
> Great writeup Ben.
>
> The NB DB does need HA and ACID transactions, but it has few clients, so
> it's probably not a very hard problem - could even use BDB with log
> shipping -
> http://www.oracle.com/techne
Great writeup Ben.
The NB DB does need HA and ACID transactions, but it has few clients, so
it's probably not a very hard problem - could even use BDB with log
shipping -
http://www.oracle.com/technetwork/database/database-technologies/berkeleydb/overview/index-085366.html
.
However, one more pot
These are great points Liran. These points are also very closely related to
one another.
I agree that the SB DB could be entirely in memory - of course, for high
availability of course it should be replicated. As a bonus, replication of
an in-memory data structure is easier than of a durable data
On Wed, Mar 9, 2016 at 1:31 AM, Ben Pfaff wrote:
> On Tue, Mar 08, 2016 at 08:29:56AM -0500, Russell Bryant wrote:
> > It would be nice to see a write up of detailed requirements and how those
> > line up with alternatives.
>
> That's my goal for Thursday.
>
Looking forward to it Ben!
__
On Tue, Mar 8, 2016 at 10:29 PM, Russell Bryant wrote:
> On Tue, Mar 8, 2016 at 3:15 AM, Amitabha Biswas
> wrote:
>
>> I see a couple of distinct discussions occurring on this thread, maybe
>> it’s time to deal with them independently.
>>
>>
>>- The Security/ACL aspect of the protocol - Is t
also advantages for doing upgrades, and just
generally for decoupling the ovn-controller implementation from the db
backend.
On Mon, Mar 7, 2016 at 11:34 PM, Russell Bryant wrote:
> On Mon, Mar 7, 2016 at 9:29 AM, Russell Bryant wrote:
>
>> On Sun, Mar 6, 2016 at 11:40 PM, Dan Mi
Hi Russell,
Nice writeup of the issues and potential solutions. We have been thinking
along the same lines.
Cheers,
Dan
On Mon, Mar 7, 2016 at 11:29 PM, Russell Bryant wrote:
> On Sun, Mar 6, 2016 at 11:40 PM, Dan Mihai Dumitriu
> wrote:
>
>> I'd argue for the approach
ou mention it, there
> is a degree of freedom there, if we were for example to write a proxy
> that runs in the cluster.
>
> Do you want to argue for or against this approach?
>
> On Sun, Mar 06, 2016 at 02:13:58PM +0900, Dan Mihai Dumitriu wrote:
> > Understood Ben.
> >
> work,
> > which is important to get a much better HA story (or I suspect we'll have
> > to replace ovsdb). I'll let him comment further on intentions and
> status,
> > though.
> >
> > On Fri, Mar 4, 2016 at 10:14 AM, Dan Mihai Dumitriu
> >
Cool, see you there.
On Mar 5, 2016 20:38, "Russell Bryant" wrote:
> Yes, we have a weekly OVN IRC meeting in #openvswitch on Freenode on
> Thursdays at 10:15 Pacific / 1:15 Eastern.
>
> On Saturday, March 5, 2016, Dan Mihai Dumitriu wrote:
>
>> Thanks for the e
; http://docs.openstack.org/developer/networking-ovn/faq.html
>
> Ben has mentioned that he might pick up the distributed ovsdb-server work,
> which is important to get a much better HA story (or I suspect we'll have
> to replace ovsdb). I'll let him comment further on intentions and
Hi Ben,
What's the current thinking around the OVSDB HA and scale solution?
Needless to say, the single SB DB to which all ovn-controllers connect
could be a liability in various production scenarios.
Cheers,
Dan
On Mar 4, 2016 00:48, "Ben Pfaff" wrote:
> Here's my OVN report for the week, sinc
Cool, thanks for the confirmation.
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
On Tuesday, April 3, 2012 at 6:17 AM, Jesse Gross wrote:
> On Sun, Apr 1, 2012 at 5:45 PM, Dan Mihai Dumitriu (mailto:d...@midokura.com)> wrote:
> > Hi all,
> >
> > I was wond
Hi all,
I was wondering if anyone else had problems with gre, or capwap, tunnels over
the loopback interface. (We're doing some automated tests which test tunnels.)
What I'm seeing is that one packets gets through, and subsequent packets are
dropped, somewhere before the gre_rcv is called.
H
ing
> on it. There's some discussion here:
> http://openvswitch.org/pipermail/dev/2012-February/014685.html
>
> On Thu, Feb 16, 2012 at 7:10 AM, Dan Mihai Dumitriu (mailto:d...@midokura.com)> wrote:
> > Understood, thanks!
> >
> >
> >
> >
Understood, thanks!
On Thursday, February 16, 2012, Justin Pettit wrote:
> On Feb 15, 2012, at 8:37 PM, Dan Mihai Dumitriu wrote:
>
>> That is true, such usage would definitely not be standard compliant.
>>
>> Incidentally, are OVS CAPWAP tunnels actually being us
at 12:12 PM, Jesse Gross wrote:
> On Wed, Feb 15, 2012 at 6:53 PM, Dan Mihai Dumitriu (mailto:d...@midokura.com)> wrote:
> > Howdy OVS-ers.
> >
> > We are using OVS with tunneling, over a multipath IP network, but our
> > switches don't read the GRE header,
Howdy OVS-ers.
We are using OVS with tunneling, over a multipath IP network, but our switches
don't read the GRE header, and thus don't use the GRE key when computing the
ECMP hashing. Is there any reason to not set the CAPWAP source port based on
the flow hash, as in the not yet merged VXLAN
19 matches
Mail list logo
