Re: [ovs-dev] [PATCH] netlink-socket: return correct error code when connect fails

Hi, On Mon, Feb 15, 2016 at 03:13:30PM -0200, Thadeu Lima de Souza Cascardo wrote: > When connect and other calls fail after get_socket_rcvbuf, the return code > would > be the rcvbuf size, not errno from the last call. > > Signed-off-by: Thadeu Lima de Souza Cascardo

Re: [ovs-dev] [PATCH] netdev-linux: fix warning message

Hi, On Mon, Feb 15, 2016 at 03:14:21PM -0200, Thadeu Lima de Souza Cascardo wrote: > Instead of reading > > "error receiving Ethernet packet on Permission denied: ens3", > > it should read > > "error receiving Ethernet packet on ens3: Permission denied". It seems to me that the aim of this

[ovs-dev] [PATCH] rhel: provide our own SELinux custom policy package

From: Ansis Atteka CentOS, RHEL and Fedora distributions ship with their own Open vSwitch SELinux policy that is too strict and prevents Open vSwitch to work normally out of the box. As a solution, this patch introduces a new package which will "loosen" up "openvswitch_t"

Re: [ovs-dev] [PATCH v5] ovn-controller: Assign zone-id consistently

> > > Unfortunately, I thought of another issue that complicates this whole > approach. A single interface does not necessarily map to a single > logical port and zone ID. We support sub-ports, initially aimed at > modelling containers in VMs. That means we need to track N different > zone IDs

Re: [ovs-dev] [PATCH 3/3] Handle tunnel set changes for BUM traffic in the vtep emulator

On 02/12/2016 08:12 PM, Darrell Ball wrote: > Signed-off-by: Darrell Ball > --- > vtep/ovs-vtep | 20 ++-- > 1 file changed, 18 insertions(+), 2 deletions(-) > > diff --git a/vtep/ovs-vtep b/vtep/ovs-vtep > index 46a5692..54bf0db 100755 > --- a/vtep/ovs-vtep >

Re: [ovs-dev] [PATCH 1/3] VTEP Schema - Support mcast macs remote table updates

I imagine Justin is doing the in depth review on this one, but I wanted to mention some minor things. On 02/12/2016 08:12 PM, Darrell Ball wrote: > Signed-off-by: Darrell Ball The patch author email address and Signed-off-by don't match. It seems like you have git configured

Re: [ovs-dev] [PATCH v5] ovn-controller: Assign zone-id consistently

On 02/15/2016 03:46 PM, Ramu Ramamurthy wrote: > Currently, ovn-controller does not record the > lport->zoneid map, and so, after ovn-controller restart, > zone-ids may get set inconsistently on lports, resulting > in possible hits to already established connections. > > Set zone-id as an

Re: [ovs-dev] OVN: Floating IP Support - Proposal

On Mon, Feb 15, 2016 at 2:02 PM, Russell Bryant wrote: > On 02/01/2016 01:19 PM, Amitabha Biswas wrote: >> This is a proposal regarding how Floating IP will be supported in >> OpenStack using OVN. >> >> The complete proposal can also be found at >>

[ovs-dev] [PATCH v5] ovn-controller: Assign zone-id consistently

Currently, ovn-controller does not record the lport->zoneid map, and so, after ovn-controller restart, zone-ids may get set inconsistently on lports, resulting in possible hits to already established connections. Set zone-id as an external-id of the interface record, and recover the zone-id from

Re: [ovs-dev] [ovs-dev,V5] Add Passive TCP connection to IDL.

On 02/15/2016 09:28 AM, Russell Bryant wrote: > On 02/14/2016 07:10 AM, Ofer Ben-Yacov wrote: >> >> >> The make check failed after git pull, but not in ovsdb tests, they >> passed ok: >> >> ... >> 483: unixctl server - Python FAILED >> (unixctl-py.at:96

[ovs-dev] [PATCH v4] ovn-controller: Assign zone-id consistently

Currently, ovn-controller does not record the lport->zoneid map, and so, after ovn-controller restart, zone-ids may get set inconsistently on lports, resulting in possible hits to already established connections. Set zone-id as an external-id of the interface record, and recover the zone-id from

Re: [ovs-dev] OVN: Floating IP Support - Proposal

On 02/01/2016 01:19 PM, Amitabha Biswas wrote: > This is a proposal regarding how Floating IP will be supported in > OpenStack using OVN. > > The complete proposal can also be found at > https://review.openstack.org/#/c/274274/. > > The additions proposed to the OVN Northbound Schema and

Re: [ovs-dev] OVN implementation of the NAT/FIP architecture

First of all, thank you very much for sharing your thoughts. I really appreciate your perspective on how things are going with OVN. On 02/11/2016 07:41 PM, Matt Kassawara wrote: > So, what do we do? Suggest a hybrid architecture with the following aspects: > > 1) Instances that require access

Re: [ovs-dev] [OVS-dev]: OVN: RFC re: logical and physical endpoint separation proposal

On Fri, Jan 29, 2016 at 8:36 PM, Darrell Lu wrote: > The following is a proposal regarding how to allow logical > and physical endpoint contexts for OVN to stay separated, from > a CMS POV. > > A logical endpoint has the form: ls1-port1. > A physical endpoint has the general

[ovs-dev] [PATCH] netdev-linux: fix warning message

Instead of reading "error receiving Ethernet packet on Permission denied: ens3", it should read "error receiving Ethernet packet on ens3: Permission denied". Signed-off-by: Thadeu Lima de Souza Cascardo --- lib/netdev-linux.c | 2 +- 1 file changed, 1 insertion(+), 1

[ovs-dev] [PATCH] netlink-socket: return correct error code when connect fails

When connect and other calls fail after get_socket_rcvbuf, the return code would be the rcvbuf size, not errno from the last call. Signed-off-by: Thadeu Lima de Souza Cascardo --- lib/netlink-socket.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/netlink-socket.c

[ovs-dev] [PATCH v2 5/6] match: color output of match conditions for ovs-ofctl dump-flows

Add color output for flow match conditions for ovs-ofctl dump-flows command utility, by calling ds_put_color() instead of ds_put_format() in the functions responsible for printing the actions. This also causes the option to be propagated upward to the other callers of those functions (partially

[ovs-dev] [PATCH v2 4/6] ovs-ofctl: add output colors for flow attributes

This commit adds colors to the “left part” of printed flows (to flow properties that are always present: `cookie`, `table`, timeouts, etc.). It uses the functions previously defined in dynamic-string.{c,h} to insert color markers around the names of the properties. Signed-off-by: Quentin Monnet

[ovs-dev] [PATCH v2 6/6] ofp-actions: color output of flow actions for ovs-ofctl dump-flows

Add color output for flow actions for ovs-ofctl dump-flows command utility, by calling ds_put_color() instead of ds_put_format() in the functions responsible for printing the actions. This also causes the option to be propagated upward to the other callers of those functions (partially

[ovs-dev] [PATCH v2 2/6] ovs-ofctl: declare / set up colors for command output

OVS_COLORS environment variable is parsed to extract user-defined preferences regarding colors (this is used to set up a color theme, not to replace the `--color` option for activating color output). The string should be of a format similar to LS_COLORS or GREP_COLORS, with available colors being

[ovs-dev] [PATCH v2 3/6] dynamic-string: define functions to print colored output

Define three functions, respectively used for: * printing a new color marker before text to colorize * printing end color marker * wrapping the two previous functions into a substitute to ds_put_format(), with colors Signed-off-by: Quentin Monnet ---

[ovs-dev] [PATCH v2 1/6] ovs-ofctl: add option for color output to dump-flows command

Add an option to ovs-ofctl utility so as to obtain colorized output in tty, for easier reading. Currently, only the dump-flows command supports colors. A new `--color` option has been added to ovs-ofctl so as to indicate whether color markers should be used or not. It can be set to `always`

[ovs-dev] [PATCH v2 0/6] Add color output to `ovs-ofctl dump-flows` command

Proposal: add an option to ovs-ofctl utility so as to obtain colorized output in tty, for easier reading. Currently, only the dump-flows command supports colors. A new `--color` option has been added to ovs-ofctl so as to indicate whether color markers should be used or not. It can be set to

[ovs-dev] [PATCH] lib: Fix netbsd compilation error

NetBSD requires to be included before . Without this fix we have: In file included from lib/netdev-vport.c:25:0: /usr/include/netinet/ip6.h:82:18: error: field 'ip6_src' has incomplete type /usr/include/netinet/ip6.h:83:18: error: field 'ip6_dst' has incomplete type Signed-off-by: Lance

Re: [ovs-dev] [PATCH] [ovn-controller] Add logical flow incremental processing

Russell Bryant wrote on 02/12/2016 01:59:27 PM: > From: Russell Bryant > To: Ryan Moats/Omaha/IBM@IBMUS, dev@openvswitch.org > Date: 02/12/2016 01:59 PM > Subject: Re: [ovs-dev] [PATCH] [ovn-controller] Add logical flow > incremental processing > > On

Re: [ovs-dev] [ovs-dev,V5] Add Passive TCP connection to IDL.

On 02/14/2016 07:10 AM, Ofer Ben-Yacov wrote: > > > The make check failed after git pull, but not in ovsdb tests, they > passed ok: > > ... > 483: unixctl server - Python FAILED > (unixctl-py.at:96 ) > ... > 1529. monitor delete only

Re: [ovs-dev] [PATCH v9 5/6] netdev-dpdk: Check dpdk-extra when reading db

> -Original Message- > From: Aaron Conole [mailto:acon...@redhat.com] > Sent: Thursday, February 11, 2016 8:16 PM > To: dev@openvswitch.org > Cc: Flavio Leitner ; Panu Matilainen ; > Traynor, Kevin ; Wojciechowicz, RobertX >

[ovs-dev] Bug#813116: /usr/sbin/ovs-vswitchd: segfault when push_mpls flow action is applied

I can confirm this bug. ovs-vswitchd crashes when push_mpls flow action is required and output port is veth type. However, if output port is a tap device, it works correctly. -- --.++-++---+--+-+-+-+++-+++--+--+-+++---+++--+-++-+- Juan Carlos Fabero Jiménez

[ovs-dev] jvhvrryoicdyzosce

The message was not delivered due to the following reason(s): Your message was not delivered because the destination computer was not reachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configura- tion parameters. Most likely

Re: [ovs-dev] How OVN do SNAT/DNAT/VPN

Thanks Russell. Sorry for my late response. What is the plan about SNAT? I think the SNAT is more complicated. Will you create another type of external network in neutron and allocate a separate IP address for each (router, compute node) tuple for SNAT? 2016-02-05 23:47 GMT+08:00 Russell