On Tue, Jul 9, 2019 at 11:05 AM Han Zhou wrote:
>
>
> On Fri, Jun 21, 2019 at 12:31 AM Han Zhou wrote:
> >
> >
> >
> > On Thu, Jun 20, 2019 at 11:42 PM Numan Siddique
> wrote:
> > >
> > >
> > >
> > > On Fri, Jun 21, 2019, 11:47 AM Han Zhou wrote:
> > >>
> > >>
> > >>
> > >> On Tue, Jun 11, 201
On Fri, Jun 21, 2019 at 12:31 AM Han Zhou wrote:
>
>
>
> On Thu, Jun 20, 2019 at 11:42 PM Numan Siddique
wrote:
> >
> >
> >
> > On Fri, Jun 21, 2019, 11:47 AM Han Zhou wrote:
> >>
> >>
> >>
> >> On Tue, Jun 11, 2019 at 9:16 AM Daniel Alvarez Sanchez <
dalva...@redhat.com> wrote:
> >> >
> >> > Th
On Mon, Jul 08, 2019 at 06:19:23PM -0700, Han Zhou wrote:
> On Thu, Jun 27, 2019 at 6:44 AM Ben Pfaff wrote:
> >
> > On Tue, Jun 25, 2019 at 01:05:21PM +0200, Daniel Alvarez Sanchez wrote:
> > > Lately we've been trying to solve certain issues related to stale
> > > entries in the MAC_Binding tabl
Hi Ben：
I have read the "userspace tunnel" document for several times, but I still
have no clue how could the tunnel pkt get parsed in rx direction. In my first
mail, I have found the "tnl_port_receive" should only be called during upcall
process, but for userspace upcall process ,after min
On Thu, Jun 27, 2019 at 6:44 AM Ben Pfaff wrote:
>
> On Tue, Jun 25, 2019 at 01:05:21PM +0200, Daniel Alvarez Sanchez wrote:
> > Lately we've been trying to solve certain issues related to stale
> > entries in the MAC_Binding table (e.g. [0]). On the other hand, for
> > the OpenStack + Octavia (Lo
On Mon, Jul 8, 2019 at 5:43 PM Ben Pfaff wrote:
>
> Would you mind formally submitting this? It seems like the best
> immediate solution.
Will do, thanks a lot Ben!
>
> On Mon, Jul 08, 2019 at 02:27:31PM +0200, Daniel Alvarez Sanchez wrote:
> > I tried a simple patch and it fixes the issue (see
Would you mind formally submitting this? It seems like the best
immediate solution.
On Mon, Jul 08, 2019 at 02:27:31PM +0200, Daniel Alvarez Sanchez wrote:
> I tried a simple patch and it fixes the issue (see below). The
> question now is, do we want to do this? I think it makes sense to drop
> *
ovn-controller is in fact change-aware, but the _Server database doesn't
report whether a particular database is read-only or read/write. I
guess that was an oversight when I designed that schema. That means
that there's no way for clients to monitor whether a particular database
changes between
Native tunneling and userspace tunneling are the same thing.
The mechanism should be symmetric: configuration for sending packets out
should also work for parsing them on the way back in.
On Mon, Jul 08, 2019 at 03:57:46PM +0800, txfh2007 wrote:
> Hi Ben:
> Thanks for your reply ! I didn't fi
I tried a simple patch and it fixes the issue (see below). The
question now is, do we want to do this? I think it makes sense to drop
*all* the connections when the role changes but I'm curious to see
what other people think:
diff --git a/ovsdb/jsonrpc-server.c b/ovsdb/jsonrpc-server.c
index 4dda6
I *think* that it may not a bug in ovsdb-server but a problem with
ovn-controller as it doesn't seem to be a DB change aware client.
When the role changes from master to backup or viceversa, connections
are expected to be reestablished for all clients except those that are
not aware of db changes
Hi,
Thanks for reporting, Daniel.
On Mon, Jul 8, 2019 at 11:22 AM Daniel Alvarez Sanchez
wrote:
>
> Hi folks,
>
> While working with an OpenStack environment running OVN and
> ovsdb-server in A/P configuration with Pacemaker we hit an issue that
> has been probably around for a long time. The bu
On Mon, Jul 8, 2019 at 3:52 PM Daniel Alvarez Sanchez
wrote:
> Hi folks,
>
> While working with an OpenStack environment running OVN and
> ovsdb-server in A/P configuration with Pacemaker we hit an issue that
> has been probably around for a long time. The bug itself seems to be
> related with ov
Hi folks,
While working with an OpenStack environment running OVN and
ovsdb-server in A/P configuration with Pacemaker we hit an issue that
has been probably around for a long time. The bug itself seems to be
related with ovsdb-server not updating the read-only flag properly.
With a 3 nodes clust
Hi Ben:
Thanks for your reply ! I didn't find the "native tunneling" document in
OpenvSwitch repository. Did you mean the document "userspace-tunneling.rst".
this document just tells us the br-phy can send tunnel pkt out, but when dpdk
type port receives pkts with tunnel hdr, how could I con
15 matches
Mail list logo
