Re: [ovs-dev] Mac OS X?

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

Re: [ovs-dev] RFC: OVN database options

On Fri, Mar 11, 2016 at 12:55 AM, Dan Mihai Dumitriu <dm...@cornell.edu> 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://ww

Re: [ovs-dev] RFC: OVN database options

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

Re: [ovs-dev] RFC: OVN database options

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

Re: [ovs-dev] weekly OVN report

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

Re: [ovs-dev] weekly OVN report

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

Re: [ovs-dev] weekly OVN report

> On Sun, Mar 6, 2016 at 11:40 PM, Dan Mihai Dumitriu <dm...@cornell.edu> >> wrote: >> >>> I'd argue for the approach of keeping the OVSDB protocol in place, >>> because the SB schema is already there, well understood, and making the >>> central DB a

Re: [ovs-dev] weekly OVN report

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 <russ...@ovn.org> wrote: > On Sun, Mar 6, 2016 at 11:40 PM, Dan Mihai Dumitriu <dm...@cornell.edu> > wro

Re: [ovs-dev] weekly OVN report

w that you 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. > &

Re: [ovs-dev] weekly OVN report

ork, > > 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 <dm...@cornell.edu> >

Re: [ovs-dev] weekly OVN report

Cool, see you there. On Mar 5, 2016 20:38, "Russell Bryant" <russ...@ovn.org> 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 <dm...@

Re: [ovs-dev] weekly OVN report

d status, > though. > > On Fri, Mar 4, 2016 at 10:14 AM, Dan Mihai Dumitriu <dm...@cornell.edu> > wrote: > >> 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-controlle

Re: [ovs-dev] loopback tunnel not delivering

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 d...@midokura.com (mailto:d...@midokura.com) wrote: Hi all, I was wondering

[ovs-dev] loopback tunnel not delivering

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.

Re: [ovs-dev] CAPWAP and ECMP (UDP source port hash)

Understood, thanks! On Thursday, February 16, 2012, Justin Pettit jpet...@nicira.com 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 used to connect to non

[ovs-dev] CAPWAP and ECMP (UDP source port hash)

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

Re: [ovs-dev] CAPWAP and ECMP (UDP source port hash)

at 12:12 PM, Jesse Gross wrote: On Wed, Feb 15, 2012 at 6:53 PM, Dan Mihai Dumitriu d...@midokura.com (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, and thus don't use the GRE