[ovs-dev] Info - 08.10.2018
Hallo Herr / Frau, Wir stellen Mittel für Investitionszwecke in Form von Krediten an Kreditsuchende , Menschen, Unternehmensverbände, Firmen etc. Investitionen werden wie gemacht: * Projektfinanzierung * Business-Darlehen * Persönliche Darlehen * Schuldenkonsolidierung * Haus Darlehen * Auto-Darlehen * Kombination Darlehen Wir geben Kredite an Privatpersonen und Unternehmen mit 3% Zinssatz jährlich aus. Es gibt keine Gebühren im Voraus für unseren Service, und nur qualifizierte Suchende wird für die Finanzierung in Betracht gezogen werden. Wenn Sie ein Investor oder Darlehen benötigen, kontaktieren Sie mich für weitere Informationen. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 1/2] ovn-ctl: Allow passing ssl certs when starting OVN DBs in ssl mode.
Hi Han:
Have added the man section for ssl in v3. PTAL.
Thanks,
On Mon, Oct 8, 2018 at 6:49 PM aginwala aginwala wrote:
> Sure. I will add ssl usage example with some brief in the ovn-ctl.8.xml
> and send v3 for this patch . Does that sound good?
>
> On Mon, Oct 8, 2018 at 5:32 PM Han Zhou wrote:
>
>>
>>
>> On Mon, Oct 8, 2018 at 4:55 PM aginwala aginwala
>> wrote:
>> >
>> >
>> >
>> > On Mon, Oct 8, 2018 at 10:47 AM Han Zhou wrote:
>> >>
>> >>
>> >>
>> >> On Fri, Oct 5, 2018 at 6:48 PM aginwala aginwala
>> wrote:
>> >> >
>> >> > Thanks for the review Han. Please find the comments inline below:
>> >> > On Thu, Oct 4, 2018 at 9:58 AM Han Zhou wrote:
>> >> >>
>> >> >> Thanks Ali, please see my comments below
>> >> >>
>> >> >> On Fri, Sep 21, 2018 at 5:34 PM wrote:
>> >> >> >
>> >> >> > For OVN DBs to work with SSL in HA, we need to have capability to
>> >> >> > pass ssl certs when starting OVN DBs. Say when starting OVN DBs
>> in active
>> >> >> > passive mode, in order for the standby DBs to sync from master
>> node, it
>> >> >> > cannot sync because the required ssl certs are not passed when
>> standby DBs
>> >> >> > are initialized. Hence, we need to have this option.
>> >> >> >
>> >> >> > e.g. start nb db with ssl certs as below:
>> >> >> > /usr/share/openvswitch/scripts/ovn-ctl
>> --ovn-nb-db-ssl-key=/etc/openvswitch/ovnnb-privkey.pem \
>> >> >> > --ovn-nb-db-ssl-cert=/etc/openvswitch/ovnnb-cert.pem \
>> >> >> > --ovn-nb-db-ssl-ca-cert=/etc/openvswitch/cacert.pem \
>> >> >> > --db-nb-create-insecure-remote=no start_nb_ovsdb
>> >> >> >
>> >> >> > Certs can be generated based on ovs ssl docs:
>> >> >> > http://docs.openvswitch.org/en/latest/howto/ssl/
>> >> >> >
>> >> >> > Signed-off-by: aginwala
>> >> >> > ---
>> >> >> > ovn/utilities/ovn-ctl | 50
>> +++---
>> >> >> > 1 file changed, 43 insertions(+), 7 deletions(-)
>> >> >> >
>> >> >> > diff --git a/ovn/utilities/ovn-ctl b/ovn/utilities/ovn-ctl
>> >> >> > index 3ff0df6..4f45f3d 100755
>> >> >> > --- a/ovn/utilities/ovn-ctl
>> >> >> > +++ b/ovn/utilities/ovn-ctl
>> >> >> > @@ -116,6 +116,9 @@ start_ovsdb__() {
>> >> >> > local addr
>> >> >> > local active_conf_file
>> >> >> > local use_remote_in_db
>> >> >> > +local ovn_db_ssl_key
>> >> >> > +local ovn_db_ssl_cert
>> >> >> > +local ovn_db_ssl_cacert
>> >> >> > eval pid=\$DB_${DB}_PID
>> >> >> > eval cluster_local_addr=\$DB_${DB}_CLUSTER_LOCAL_ADDR
>> >> >> > eval cluster_local_port=\$DB_${DB}_CLUSTER_LOCAL_PORT
>> >> >> > @@ -137,6 +140,9 @@ start_ovsdb__() {
>> >> >> > eval addr=\$DB_${DB}_ADDR
>> >> >> > eval active_conf_file=\$ovn${db}_active_conf_file
>> >> >> > eval use_remote_in_db=\$DB_${DB}_USE_REMOTE_IN_DB
>> >> >> > +eval ovn_db_ssl_key=\$OVN_${DB}_DB_SSL_KEY
>> >> >> > +eval ovn_db_ssl_cert=\$OVN_${DB}_DB_SSL_CERT
>> >> >> > +eval ovn_db_ssl_cacert=\$OVN_${DB}_DB_SSL_CA_CERT
>> >> >> >
>> >> >> > # Check and eventually start ovsdb-server for DB
>> >> >> > if pidfile_is_running $pid; then
>> >> >> > @@ -182,17 +188,32 @@ $cluster_remote_port
>> >> >> >
>> >> >> > if test X"$use_remote_in_db" != Xno; then
>> >> >> > set "$@" --remote=db:$schema_name,$table_name,connections
>> >> >> > +if test X"$create_insecure_remote" = Xno; then
>> >> >> > +set "$@" --remote=pssl:$port:$addr
>> >> >> > +elif test X"$create_insecure_remote" = Xyes; then
>> >> >> > +set "$@" --remote=ptcp:$port:$addr
>> >> >> > +fi
>> >> >> Why moving the logic here? This if block only says if the
>> connection settings in DB table should be used. Whether insecure mode is
>> allowed was supposed to be independent with this condition. Could you
>> explain the reason behind the change?
>> >> >> >> I moved it because remote=db is needed if ovsdb is running as a
>> standalone node or an active ovsdb server node. For standby nodes in case
>> of active_passive mode, remote=db will not be there because it uses
>> --sync-from. Hope its clear.
>> >>
>> >> As discussed, $use_remote_in_db and $create_insecure_remote were
>> independent. Moving $create_insecure_remote logic here make it useful only
>> when $use_remote_in_db is "yes", which is not how it was supposed to be.
>> >>
>> >> I understand that for standby node, we will set $use_remote_in_db as
>> "no". Is this a problem?
>> >>
>> > >> Just verified and have kept the logic intact as even for ssl, we
>> have connection table set for 0.0.0.0 for LB use case and it works fine.
>> Hence, have updated it in v2. Please take a look and let me know.
>> >>
>> >> --sync-from has nothing to do with "remote".
>> >> >
>> >> >
>> >> >>
>> >> >> > fi
>> >> >> > -set "$@" --private-key=db:$schema_name,SSL,private_key
>> >> >> > -set "$@" --certificate=db:$schema_name,SSL,certificate
>> >> >> > -set "$@" --ca-cert=db:$schema_name,SSL,ca_cert
>> >> >> > -set "$@"
Re: [ovs-dev] Issue with OVS lacp-fallback-ab option
Ben,
I was able to test it out, and you were right - disabling the recirculation
fixed the problem! Since I’m on OVS 2.5.2, the patch I tried was slightly
different:
diff --git a/ofproto/bond.c b/ofproto/bond.c
old mode 100644
new mode 100755
index 9c6079f..118a7d6
--- a/ofproto/bond.c
+++ b/ofproto/bond.c
@@ -914,6 +914,9 @@ bond_may_recirc(const struct bond *bond, uint32_t
*recirc_id,
uint32_t *hash_bias)
{
if (bond->balance == BM_TCP && bond->recirc_id) {
+if (bond->lacp_fallback_ab && bond->lacp_status == LACP_CONFIGURED) {
+return false;
+}
if (recirc_id) {
*recirc_id = bond->recirc_id;
}
Could you elaborate on what the underlying issue with recirculation and lacp
bonding?
Thanks
-Arun
On 10/8/18, 1:57 PM, "Arun Navasivasakthivelsamy"
mailto:arunkum.nava...@nutanix.com>> wrote:
Thanks Ben. Let me try it out this week and report back.
On 10/8/18, 1:15 PM, "Ben Pfaff" mailto:b...@ovn.org>> wrote:
I think I see a problem in the implementation of bonding when
recirculation is available. Are you able to try out a patch? If so,
try the following. It is not a good way to solve the issue, but it
should illustrate whether recirculation is the problem.
diff --git a/ofproto/bond.c b/ofproto/bond.c
index f87cdba7908f..bb6a80411de5 100644
--- a/ofproto/bond.c
+++ b/ofproto/bond.c
@@ -927,7 +928,7 @@ bond_recirculation_account(struct bond *bond)
static bool
bond_may_recirc(const struct bond *bond)
{
-return bond->balance == BM_TCP && bond->recirc_id;
+return bond->balance == BM_TCP && bond->recirc_id && false;
}
static void
On Fri, Oct 05, 2018 at 04:45:21AM +, Arun Navasivasakthivelsamy
wrote:
Also, ofproto/trace is suggesting that the packet will be hashed to a
slave (instead of just to the active port) with lacp-fallback-ab option.
This is with active-backup bond mode:
[root@frankfurter02-4 ~]# ovs-appctl ofproto/trace br0
in_port=6,dl_dst=28:99:3a:08:7a:cf
Bridge: br0
Flow:
in_port=6,vlan_tci=0x,dl_src=00:00:00:00:00:00,dl_dst=28:99:3a:08:7a:
cf,dl_type=0x
Rule: table=0 cookie=0 priority=0
OpenFlow actions=NORMAL
forwarding to learned port
Final flow: unchanged
Megaflow:
recirc_id=0,in_port=6,vlan_tci=0x/0x1fff,dl_src=00:00:00:00:00:00,dl_
dst=28:99:3a:08:7a:cf,dl_type=0x
Datapath actions: 5
This is with balance-tcp with lacp-fallback-ab mode (LACP is not
negotiated):
[root@frankfurter02-4 ~]# ovs-appctl ofproto/trace br0
in_port=6,dl_dst=28:99:3a:08:7a:cf
Bridge: br0
Flow:
in_port=6,vlan_tci=0x,dl_src=00:00:00:00:00:00,dl_dst=28:99:3a:08:7a:
cf,dl_type=0x
Rule: table=0 cookie=0 priority=0
OpenFlow actions=NORMAL
forwarding to learned port
Final flow: unchanged
Megaflow:
recirc_id=0,in_port=6,vlan_tci=0x/0x1fff,dl_src=00:00:00:00:00:00,dl_
dst=28:99:3a:08:7a:cf,dl_type=0x
Datapath actions: hash(hash_l4(0)),recirc(0x1)
From: Arunkumar Navasiva
mailto:arunkum.nava...@nutanix.com>>
Date: Thursday, October 4, 2018 at 4:18 PM
To:
"ovs-dev@openvswitch.org"
mailto:ovs-dev@openvswitch.org>>
Subject: Issue with OVS lacp-fallback-ab option
Hello folks,
We¹re seeing an issue with lacp-fallback-ab option on ovs 2.5/2.6/2.8.
It looks like when LACP is not enabled on the TOR switch ports, OVS on
the centos server is not falling back cleanly to active-backup, and
continues to send some portions of the traffic through the backup
interface (we¹ve seen this occur with various TOR vendor switches).
Please see the attached screenshot which shows that some traffic still
hashes to backup interface. We looked at the TOR forwarding table, and
MAC addresses of VMs running on this server flaps between the two
corresponding TOR switch ports of the bond . I¹m still in the early
stages of debugging this, but wanted to reach out to you to see if this
is already a known issue? If not, any help on how to debug this further
will be helpful.
Thanks
-Arun
___
dev mailing list
d...@openvswitch.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org
_mailman_listinfo_ovs-2Ddev=DwIDaQ=s883GpUCOChKOHiocYtGcg=3XXybm-J2
6tdZghk4AB2Q6VwG-xD4UIstn2FwmI-3DQ=yn0Qe0gUppRi3JbdHCjsoa21myUOJTO9tU5M
s6ysj7s=iZmArQ2KxmCSrUeNKdCcJndIqugchI9rhK4s9iq4TrA=
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] (no subject)
Start-up-Kapital für Ihr neues Geschäft oder Finanzierung für die Erweiterung Ihres Geschäfts. Wir bieten auch persönliche und Firmenkredite. Kontaktieren Sie uns jetzt für weitere Informationen E-Mail: Start up capital for your new business or financing for expanding your business. We also provide personal and company loan. Contact us now for more information email: ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH 2/2] odp-util: Handle returning when parse_odp_key_mask_attr handles ufid
When parse_odp_key_mask_attr runs into ufid, it returns length of ufid
without appending data into ofpbufs. This commit adds additional
checking for this case.
Found this bug when debugging
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10850,
but not certain it is related.
Signed-off-by: Yifeng Sun
---
lib/odp-util.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/lib/odp-util.c b/lib/odp-util.c
index d482d5bcf968..f53530db40aa 100644
--- a/lib/odp-util.c
+++ b/lib/odp-util.c
@@ -2216,9 +2216,10 @@ parse_odp_action(const char *s, const struct simap
*port_names,
struct nlattr mask[1024 / sizeof(struct nlattr)];
struct ofpbuf maskbuf = OFPBUF_STUB_INITIALIZER(mask);
struct nlattr *nested, *key;
-size_t size;
+size_t size, old_size;
start_ofs = nl_msg_start_nested(actions, OVS_ACTION_ATTR_SET);
+old_size = actions->size;
retval = parse_odp_key_mask_attr(s + 4, port_names, actions, );
if (retval < 0) {
ofpbuf_uninit();
@@ -2233,7 +2234,7 @@ parse_odp_action(const char *s, const struct simap
*port_names,
key = nested + 1;
size = nl_attr_get_size(mask);
-if (size == nl_attr_get_size(key)) {
+if (old_size != actions->size && size == nl_attr_get_size(key)) {
/* Change to masked set action if not fully masked. */
if (!is_all_ones(mask + 1, size)) {
/* Remove padding of eariler key payload */
--
2.7.4
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH 1/2] odp-util: Fix a bug that causes stack overflow
ofpbuf_put_hex doesn't know buf's length and only checks buf's content
to process. This is dangerous. This patch fixes it.
Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10865
Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10863
Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10855
Signed-off-by: Yifeng Sun
---
lib/odp-util.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/odp-util.c b/lib/odp-util.c
index 7705bb30ae21..d482d5bcf968 100644
--- a/lib/odp-util.c
+++ b/lib/odp-util.c
@@ -2107,6 +2107,7 @@ parse_odp_push_nsh_action(const char *s, struct ofpbuf
*actions)
if (ovs_scan_len(s, , "md2=0x%511[0-9a-fA-F]", buf)) {
ofpbuf_use_stub(, metadata,
NSH_CTX_HDRS_MAX_LEN);
+buf[n - 6] = '\0';
ofpbuf_put_hex(, buf, );
/* Pad metadata to 4 bytes. */
padding = PAD_SIZE(mdlen, 4);
--
2.7.4
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v3 2/2] ovndb-servers.ocf: Add ssl support for managing OVN DB resources with pacemaker using LB VIP.
When starting OVN DBs in HA using pacemaker with ssl, we need to pass ssl
certs for starting standby DBs. Hence, we need this change.
Signed-off-by: aginwala
Acked-by: Han Zhou
---
ovn/utilities/ovndb-servers.ocf | 72 -
1 file changed, 71 insertions(+), 1 deletion(-)
diff --git a/ovn/utilities/ovndb-servers.ocf b/ovn/utilities/ovndb-servers.ocf
index 52141c7..1031330 100755
--- a/ovn/utilities/ovndb-servers.ocf
+++ b/ovn/utilities/ovndb-servers.ocf
@@ -10,6 +10,12 @@
: ${MANAGE_NORTHD_DEFAULT="no"}
: ${INACTIVE_PROBE_DEFAULT="5000"}
: ${LISTEN_ON_MASTER_IP_ONLY_DEFAULT="yes"}
+: ${NB_SSL_KEY_DEFAULT="/etc/openvswitch/ovnnb-privkey.pem"}
+: ${NB_SSL_CERT_DEFAULT="/etc/openvswitch/ovnnb-cert.pem"}
+: ${NB_SSL_CACERT_DEFAULT="/etc/openvswitch/cacert.pem"}
+: ${SB_SSL_KEY_DEFAULT="/etc/openvswitch/ovnsb-privkey.pem"}
+: ${SB_SSL_CERT_DEFAULT="/etc/openvswitch/ovnsb-cert.pem"}
+: ${SB_SSL_CACERT_DEFAULT="/etc/openvswitch/cacert.pem"}
CRM_MASTER="${HA_SBIN_DIR}/crm_master -l reboot"
CRM_ATTR_REPL_INFO="${HA_SBIN_DIR}/crm_attribute --type crm_config --name
OVN_REPL_INFO -s ovn_ovsdb_master_server"
@@ -21,6 +27,13 @@
SB_MASTER_PORT=${OCF_RESKEY_sb_master_port:-${SB_MASTER_PORT_DEFAULT}}
SB_MASTER_PROTO=${OCF_RESKEY_sb_master_protocol:-${SB_MASTER_PROTO_DEFAULT}}
MANAGE_NORTHD=${OCF_RESKEY_manage_northd:-${MANAGE_NORTHD_DEFAULT}}
INACTIVE_PROBE=${OCF_RESKEY_inactive_probe_interval:-${INACTIVE_PROBE_DEFAULT}}
+NB_PRIVKEY=${OCF_RESKEY_ovn_nb_db_privkey:-${NB_SSL_KEY_DEFAULT}}
+NB_CERT=${OCF_RESKEY_ovn_nb_db_cert:-${NB_SSL_CERT_DEFAULT}}
+NB_CACERT=${OCF_RESKEY_ovn_nb_db_cacert:-${NB_SSL_CACERT_DEFAULT}}
+SB_PRIVKEY=${OCF_RESKEY_ovn_sb_db_privkey:-${SB_SSL_KEY_DEFAULT}}
+SB_CERT=${OCF_RESKEY_ovn_sb_db_cert:-${SB_SSL_CERT_DEFAULT}}
+SB_CACERT=${OCF_RESKEY_ovn_sb_db_cacert:-${SB_SSL_CACERT_DEFAULT}}
+
# In order for pacemaker to work with LB, we can set LISTEN_ON_MASTER_IP_ONLY
# to false and pass LB vip IP while creating pcs resource.
@@ -132,6 +145,54 @@ ovsdb_server_metadata() {
+
+
+ OVN NB DB private key absolute path for ssl setup.
+
+ OVN NB DB private key file
+
+
+
+
+
+ OVN NB DB certificate absolute path for ssl setup.
+
+ OVN NB DB cert file
+
+
+
+
+
+ OVN NB DB CA certificate absolute path for ssl setup.
+
+ OVN NB DB cacert file
+
+
+
+
+
+ OVN SB DB private key absolute path for ssl setup.
+
+ OVN SB DB private key file
+
+
+
+
+
+ OVN SB DB certificate absolute path for ssl setup.
+
+ OVN SB DB cert file
+
+
+
+
+
+ OVN SB DB CA certificate absolute path for ssl setup.
+
+ OVN SB DB cacert file
+
+
+
@@ -326,6 +387,16 @@ ovsdb_server_start() {
set $@ --db-sb-addr=${MASTER_IP} --db-sb-port=${SB_MASTER_PORT}
fi
+if [ "x${NB_MASTER_PROTO}" = xssl ]; then
+set $@ --ovn-nb-db-ssl-key=${NB_PRIVKEY}
+set $@ --ovn-nb-db-ssl-cert=${NB_CERT}
+set $@ --ovn-nb-db-ssl-ca-cert=${NB_CACERT}
+fi
+if [ "x${SB_MASTER_PROTO}" = xssl ]; then
+set $@ --ovn-sb-db-ssl-key=${SB_PRIVKEY}
+set $@ --ovn-sb-db-ssl-cert=${SB_CERT}
+set $@ --ovn-sb-db-ssl-ca-cert=${SB_CACERT}
+fi
if [ "x${present_master}" = x ]; then
# No master detected, or the previous master is not among the
# set starting.
@@ -343,7 +414,6 @@ ovsdb_server_start() {
set $@ --db-nb-sync-from-addr=${INVALID_IP_ADDRESS}
--db-sb-sync-from-addr=${INVALID_IP_ADDRESS}
elif [ ${present_master} != ${host_name} ]; then
-# TODO: for using LB vip, need to test for ssl.
if [ "x${LISTEN_ON_MASTER_IP_ONLY}" = xyes ]; then
if [ "x${NB_MASTER_PROTO}" = xtcp ]; then
set $@ --db-nb-create-insecure-remote=yes
--
1.9.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v3 1/2] ovn-ctl: Allow passing ssl certs when starting OVN DBs in ssl mode.
For OVN DBs to work with SSL in HA, we need to have capability to pass ssl
certs when starting OVN DBs. Say when starting OVN DBs in active passive mode,
in order for the standby DBs to sync from master node, it cannot sync
because the required ssl certs are not passed when standby DBs are initialized.
Hence, we need to have this option.
e.g. start nb db with ssl certs as below:
/usr/share/openvswitch/scripts/ovn-ctl
--ovn-nb-db-ssl-key=/etc/openvswitch/ovnnb-privkey.pem \
--ovn-nb-db-ssl-cert=/etc/openvswitch/ovnnb-cert.pem \
--ovn-nb-db-ssl-ca-cert=/etc/openvswitch/cacert.pem \
--db-nb-create-insecure-remote=no start_nb_ovsdb
When certs are passed in the command line, it will read certs from the path
mentioned instead of default db configs.
Certs can be generated based on ovs ssl docs:
http://docs.openvswitch.org/en/latest/howto/ssl/
Signed-off-by: aginwala
---
ovn/utilities/ovn-ctl | 41 ++---
ovn/utilities/ovn-ctl.8.xml | 14 ++
2 files changed, 52 insertions(+), 3 deletions(-)
diff --git a/ovn/utilities/ovn-ctl b/ovn/utilities/ovn-ctl
index 3ff0df6..d71071a 100755
--- a/ovn/utilities/ovn-ctl
+++ b/ovn/utilities/ovn-ctl
@@ -116,6 +116,9 @@ start_ovsdb__() {
local addr
local active_conf_file
local use_remote_in_db
+local ovn_db_ssl_key
+local ovn_db_ssl_cert
+local ovn_db_ssl_cacert
eval pid=\$DB_${DB}_PID
eval cluster_local_addr=\$DB_${DB}_CLUSTER_LOCAL_ADDR
eval cluster_local_port=\$DB_${DB}_CLUSTER_LOCAL_PORT
@@ -137,6 +140,9 @@ start_ovsdb__() {
eval addr=\$DB_${DB}_ADDR
eval active_conf_file=\$ovn${db}_active_conf_file
eval use_remote_in_db=\$DB_${DB}_USE_REMOTE_IN_DB
+eval ovn_db_ssl_key=\$OVN_${DB}_DB_SSL_KEY
+eval ovn_db_ssl_cert=\$OVN_${DB}_DB_SSL_CERT
+eval ovn_db_ssl_cacert=\$OVN_${DB}_DB_SSL_CA_CERT
# Check and eventually start ovsdb-server for DB
if pidfile_is_running $pid; then
@@ -183,9 +189,23 @@ $cluster_remote_port
if test X"$use_remote_in_db" != Xno; then
set "$@" --remote=db:$schema_name,$table_name,connections
fi
-set "$@" --private-key=db:$schema_name,SSL,private_key
-set "$@" --certificate=db:$schema_name,SSL,certificate
-set "$@" --ca-cert=db:$schema_name,SSL,ca_cert
+
+if test X"$ovn_db_ssl_key" != X; then
+set "$@" --private-key=$ovn_db_ssl_key
+else
+set "$@" --private-key=db:$schema_name,SSL,private_key
+fi
+if test X"$ovn_db_ssl_cert" != X; then
+set "$@" --certificate=$ovn_db_ssl_cert
+else
+set "$@" --certificate=db:$schema_name,SSL,certificate
+fi
+if test X"$ovn_db_ssl_cacert" != X; then
+set "$@" --ca-cert=$ovn_db_ssl_cacert
+else
+set "$@" --ca-cert=db:$schema_name,SSL,ca_cert
+fi
+
set "$@" --ssl-protocols=db:$schema_name,SSL,ssl_protocols
set "$@" --ssl-ciphers=db:$schema_name,SSL,ssl_ciphers
@@ -481,6 +501,15 @@ set_defaults () {
OVN_NORTHD_SB_DB="unix:$DB_SB_SOCK"
DB_NB_USE_REMOTE_IN_DB="yes"
DB_SB_USE_REMOTE_IN_DB="yes"
+
+OVN_NB_DB_SSL_KEY=""
+OVN_NB_DB_SSL_CERT=""
+OVN_NB_DB_SSL_CA_CERT=""
+
+OVN_SB_DB_SSL_KEY=""
+OVN_SB_DB_SSL_CERT=""
+OVN_SB_DB_SSL_CA_CERT=""
+
}
set_option () {
@@ -536,6 +565,12 @@ Options:
--ovn-controller-ssl-cert=CERT OVN Southbound SSL certificate file
--ovn-controller-ssl-ca-cert=CERT OVN Southbound SSL CA certificate file
--ovn-controller-ssl-bootstrap-ca-cert=CERT Bootstrapped OVN Southbound SSL
CA certificate file
+ --ovn-nb-db-ssl-key=KEY OVN Northbound DB SSL private key file
+ --ovn-nb-db-ssl-cert=CERT OVN Northbound DB SSL certificate file
+ --ovn-nb-db-ssl-ca-cert=CERT OVN Northbound DB SSL CA certificate file
+ --ovn-sb-db-ssl-key=KEY OVN Southbound DB SSL private key file
+ --ovn-sb-db-ssl-cert=CERT OVN Southbound DB SSL certificate file
+ --ovn-sb-db-ssl-ca-cert=CERT OVN Southbound DB SSL CA certificate file
--ovn-manage-ovsdb=yes|noWhether or not the OVN databases should be
automatically started and stopped along
with ovn-northd. The default is "yes". If
diff --git a/ovn/utilities/ovn-ctl.8.xml b/ovn/utilities/ovn-ctl.8.xml
index 3b0e67a..c5294d7 100644
--- a/ovn/utilities/ovn-ctl.8.xml
+++ b/ovn/utilities/ovn-ctl.8.xml
@@ -198,4 +198,18 @@
start_northd
+
+Passing ssl keys when starting OVN dbs will supercede the default ssl
values in db
+Starting standalone ovn db server passing SSL certificates
+
+
+# ovn-ctl --ovn-nb-db-ssl-key=/etc/openvswitch/ovnnb-privkey.pem
+ --ovn-nb-db-ssl-cert=/etc/openvswitch/ovnnb-cert.pem
+ --ovn-nb-db-ssl-ca-cert=/etc/openvswitch/cacert.pem
+ --ovn-sb-db-ssl-key=/etc/openvswitch/ovnsb-privkey.pem
+ --ovn-sb-db-ssl-cert=/etc/openvswitch/ovnsb-cert.pem
+
Re: [ovs-dev] [PATCH] ovn-trace: Fix tracing when ip.dst has to go via a gateway router
Looks good to me.
Acked-by: Mark Michelson
On 10/09/2018 09:11 AM, nusid...@redhat.com wrote:
From: Numan Siddique
ovn-trace does not trace past an l3gateway port type. This patch
fixes it.
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1626080
Suggested-by: Dan Williams
Signed-off-by: Numan Siddique
---
ovn/utilities/ovn-trace.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/ovn/utilities/ovn-trace.c b/ovn/utilities/ovn-trace.c
index 2446b3f76..40a79ceea 100644
--- a/ovn/utilities/ovn-trace.c
+++ b/ovn/utilities/ovn-trace.c
@@ -645,6 +645,15 @@ read_ports(void)
} else if (!strcmp(sbpb->type, "l3gateway")) {
/* Treat all gateways as local for our purposes. */
dp->has_local_l3gateway = true;
+const char *peer_name = smap_get(>options, "peer");
+if (peer_name) {
+struct ovntrace_port *peer
+= shash_find_data(, peer_name);
+if (peer) {
+port->peer = peer;
+port->peer->peer = port;
+}
+}
}
}
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] IPv6: Add support for match and set nd_options_type and reserved fields.
On Tue, Oct 09, 2018 at 10:28:28AM +, Ashvin Lakshmikantha wrote:
>In this specific case, it appears that the original design of
> the data structure is inconsistent with RFC 4861. The RFC 4861 mandates the
> ND message to be of the following type:
>
>
>
> [cid:image005.jpg@01D45FE8.E7EB35B0]
>
>
>
>
>
> Continuing, the options field have the following data structure:
>
>
>
> [cid:image006.jpg@01D45FE8.E7EB35B0]
>
>
>
>
>
> However, if we look at the ovs_nd_key data structure, it appears like this:
>
>
>
> struct ovs_key_nd {
>
>__be32 nd_target[4];
>
>__u8 nd_sll[ETH_ALEN];
>
>__u8 nd_tll[ETH_ALEN];
>
> };
>
>
>
> A ND message DOES NOT have both ND_SLL and ND_TLL fields. It most commonly
> has only one of them. Also, a ND message has a RESERVED field (4 Bytes) and
> Type/Length of Options (2 Bytes).
>
>
>
> In the original design, the author has removed RESERVED/Type/Length fields
> from ovs_nd_key and replaced it with an extra ND_TLL field. This is incorrect.
>
>
>
> Our proposal fixes the original design and in addition provides a new
> capability to modify RESERVED field and Type Field.
The "key" structures do not exactly mirror the headers themselves.
No matter what you want, you can't break the existing ABI. Period.
Find another way.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] dpif-netdev bug regarding packet matches or ufids?
Thank you very much! I think you found the exact problem. I applied
this to master and backported as far as branch-2.7.
On Tue, Oct 09, 2018 at 07:21:24PM +0300, Ilya Maximets wrote:
> Hi Ben.
> Thanks for your report and the really useful script.
> I spent a few hours debugging the issue and came up with the following patch:
> https://patchwork.ozlabs.org/patch/981408/
> Please, take a look.
> Additionally we may add ufid lookup support in flow_put_on_pmd()
> as a separate fix. This, probably, will speed up the operation.
>
> Will wait for your opinion.
>
> Best regards, Ilya Maximets.
>
> > Hi Ian (or others), do you have any thoughts about this?
> >
> > On Fri, Sep 28, 2018 at 04:24:33PM -0700, Ben Pfaff wrote:
> >> I have been playing with the OFTest framework off and on over the last
> >> few months and I believe it's caught an actual bug with its
> >> DirectVlanPackets test. I'm appending a script that demonstrates it.
> >> To see it, run "make sandbox" then execute the script inside it.
> >>
> >> At some level at least, the problem is in dpif-netdev, which during the
> >> test logs messages like this indicating that a datapath flow can't be
> >> found and therefore can't be modified:
> >>
> >> WARN|dummy at ovs-dummy: failed to put[modify] (No such file or
> >> directory) ufid:b2fe59af-26bd-4aa0-960e-fd559dc10c54
> >>
> >> skb_priority(0/0),skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),recirc_id(0),dp_hash(0/0),in_port(1),packet_type(ns=0,id=0),eth(src=00:06:07:08:09:0a,dst=00:01:02:03:04:05),eth_type(0x8100),vlan(vid=1000/0x0,pcp=5/0x0),encap(eth_type(0x0800),ipv4(src=127.0.0.1/0.0.0.0,dst=127.0.0.1/0.0.0.0,proto=0/0,tos=0/0,ttl=64/0,frag=no)),
> >>
> >> actions:userspace(pid=0,controller(reason=7,dont_send=0,continuation=0,recirc_id=1,rule_cookie=0,controller_id=0,max_len=65535))
> >>
> >> It's possible that the caller is screwing up by providing a flow match
> >> different from one in the datapath flow table. I have not looked at
> >> that question. But the really strange thing here is that the caller is
> >> providing a ufid and dpif-netdev is ignoring it. When I make it honor
> >> the ufid, like the following, then the test suddenly starts working.
> >> This seems like a bug to me.
> >>
> >> (The following patch is not actually the real fix because the code
> >> should still look at the key if no ufid was provided.)
> >>
> >> Any thoughts?
> >>
> >> Thanks,
> >>
> >> Ben.
> >>
> >> diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
> >> index e322f5553fa8..4855cc08f7b7 100644
> >> --- a/lib/dpif-netdev.c
> >> +++ b/lib/dpif-netdev.c
> >> @@ -3273,7 +3273,7 @@ dp_netdev_flow_add(struct dp_netdev_pmd_thread *pmd,
> >>
> >> static int
> >> flow_put_on_pmd(struct dp_netdev_pmd_thread *pmd,
> >> -struct netdev_flow_key *key,
> >> +struct netdev_flow_key *key OVS_UNUSED,
> >> struct match *match,
> >> ovs_u128 *ufid,
> >> const struct dpif_flow_put *put,
> >> @@ -3287,7 +3287,7 @@ flow_put_on_pmd(struct dp_netdev_pmd_thread *pmd,
> >> }
> >>
> >> ovs_mutex_lock(>flow_mutex);
> >> -netdev_flow = dp_netdev_pmd_lookup_flow(pmd, key, NULL);
> >> +netdev_flow = dp_netdev_pmd_find_flow(pmd, ufid, NULL, 0);
> >> if (!netdev_flow) {
> >> if (put->flags & DPIF_FP_CREATE) {
> >> if (cmap_count(>flow_table) < MAX_FLOWS) {
> >>
> >>
> >>
> >> --8<--cut here-->8--
> >>
> >> #! /bin/sh -ex
> >>
> >> # Create a bridge and add port p1 on port 1, p2 on port 2
> >> ovs-appctl vlog/set netdev_dummy dpif
> >> ovs-vsctl --if-exists del-br br0 \
> >>-- add-br br0 \
> >>-- add-port br0 p1 -- set interface p1 ofport_request=1
> >> options:tx_pcap=p1-tx.pcap options:rxq_pcap=p1-rx.pcap \
> >>-- add-port br0 p2 -- set interface p2 ofport_request=2
> >> options:tx_pcap=p2-tx.pcap options:rxq_pcap=p2-rx.pcap
> >>
> >> # Add a flow that directs some packets received on p1 to p2 and the
> >> # rest back out p1.
> >> #
> >> # Then inject a packet of the form that should go to p2. Dump the
> >> # datapath flow to see that it goes to p2 ("actions:2"). Trace the
> >> # same packet for good measure, to also see that it should go to p2.
> >> packet=00010203040500060708090a8100a3e808004514000140007ce77f017f01
> >> ovs-ofctl add-flow br0
> >> priority=1,ip,in_port=1,dl_src=00:06:07:08:09:0a,dl_dst=00:01:02:03:04:05,actions=output:2
> >> ovs-ofctl add-flow br0 priority=0,in_port=1,actions=IN_PORT
> >> ovs-appctl netdev-dummy/receive p1 $packet
> >> ovs-appctl ofproto/trace br0 in_port=p1 $packet
> >> ovs-appctl dpif/dump-flows br0
> >>
> >> # Delete the flows, then add new flows that would not match the same
> >> # packet as before.
> >> ovs-ofctl del-flows br0
> >> ovs-ofctl add-flow br0
> >>
Re: [ovs-dev] [PATCH 2/2 v2] Work around Python/C JSON unicode differences
On Tue, Oct 9, 2018 at 5:33 PM Terry Wilson wrote:
>
> The OVS C-based JSON parser operates on bytes, so the parser_feed
> function returns the number of bytes that are processed. The pure
> Python JSON parser currently operates on unicode, so it expects
> that Parser.feed() returns a number of characters. This difference
> leads to parsing errors when unicode characters are passed to the
> C JSON parser from Python.
>
> Signed-off-by: Terry Wilson
> ---
> python/ovs/jsonrpc.py | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/python/ovs/jsonrpc.py b/python/ovs/jsonrpc.py
> index 4873cff..1323ba7 100644
> --- a/python/ovs/jsonrpc.py
> +++ b/python/ovs/jsonrpc.py
> @@ -272,7 +272,8 @@ class Connection(object):
> # data, so we convert it here as soon as possible.
> if data and not error:
> try:
> -data = decoder.decode(data)
> +if six.PY3 or ovs.json.PARSER == ovs.json.PARSER_PY:
> +data = decoder.decode(data)
> except UnicodeError:
> error = errno.EILSEQ
> if error:
> @@ -298,7 +299,11 @@ class Connection(object):
> else:
> if self.parser is None:
> self.parser = ovs.json.Parser()
> -self.input = self.input[self.parser.feed(self.input):]
> +if six.PY3 and ovs.json.PARSER == ovs.json.PARSER_C:
> +self.input = self.input.encode('utf-8')[
> +self.parser.feed(self.input):].decode()
> +else:
> +self.input = self.input[self.parser.feed(self.input):]
> if self.parser.is_done():
> msg = self.__process_msg()
> if msg:
> --
> 1.8.3.1
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Acked-By: Lucas Alvares Gomes
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 2/2 v2] Work around Python/C JSON unicode differences
On Tue, Oct 9, 2018 at 11:28 AM Terry Wilson wrote: > > Anyone have time to look at these? Huh, apparently they hadn't shown up due to being marked as spam or something. Re-sent. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH 2/2 v2] Work around Python/C JSON unicode differences
The OVS C-based JSON parser operates on bytes, so the parser_feed
function returns the number of bytes that are processed. The pure
Python JSON parser currently operates on unicode, so it expects
that Parser.feed() returns a number of characters. This difference
leads to parsing errors when unicode characters are passed to the
C JSON parser from Python.
Signed-off-by: Terry Wilson
---
python/ovs/jsonrpc.py | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/python/ovs/jsonrpc.py b/python/ovs/jsonrpc.py
index 4873cff..1323ba7 100644
--- a/python/ovs/jsonrpc.py
+++ b/python/ovs/jsonrpc.py
@@ -272,7 +272,8 @@ class Connection(object):
# data, so we convert it here as soon as possible.
if data and not error:
try:
-data = decoder.decode(data)
+if six.PY3 or ovs.json.PARSER == ovs.json.PARSER_PY:
+data = decoder.decode(data)
except UnicodeError:
error = errno.EILSEQ
if error:
@@ -298,7 +299,11 @@ class Connection(object):
else:
if self.parser is None:
self.parser = ovs.json.Parser()
-self.input = self.input[self.parser.feed(self.input):]
+if six.PY3 and ovs.json.PARSER == ovs.json.PARSER_C:
+self.input = self.input.encode('utf-8')[
+self.parser.feed(self.input):].decode()
+else:
+self.input = self.input[self.parser.feed(self.input):]
if self.parser.is_done():
msg = self.__process_msg()
if msg:
--
1.8.3.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH 1/2 v2] Test the Python C JSON extension
The C JSON parser was added quite a while ago, but unless you configure with --enable-shared and have the Python 2/3 development libraries installed, and the resulting python-ovs module installed, 'make check' won't actually test it. This patch changes Python-based tests to run from the $builddir/python directory and makes the tests configurable to use both JSON backends. There are some unicode failures in the C JSON extension that I left unfixed in this patch to make it easy to show run the new tests on broken code. The next patch in this set works around the issue. Signed-off-by: Terry Wilson --- python/automake.mk | 11 python/ovs/json.py | 10 ++-- tests/atlocal.in| 4 +- tests/json.at | 35 +++- tests/ovsdb-idl.at | 149 tests/ovsdb.at | 36 - tests/test-json.py | 14 - tests/test-ovsdb.py | 22 +++- 8 files changed, 199 insertions(+), 82 deletions(-) diff --git a/python/automake.mk b/python/automake.mk index 5a1e1da..21547f7 100644 --- a/python/automake.mk +++ b/python/automake.mk @@ -92,6 +92,17 @@ python-sdist: $(srcdir)/python/ovs/version.py $(ovs_pyfiles) python/ovs/dirs.py pypi-upload: $(srcdir)/python/ovs/version.py $(ovs_pyfiles) python/ovs/dirs.py (cd python/ && $(PYTHON) setup.py sdist upload) + +ALL_LOCAL += python-build +python-build:$(lib_LTLIBRARIES) + (cd $(srcdir)/python/ && $(PYTHON) setup.py build_py -d $(abs_top_builddir)/python && $(PYTHON) setup.py build_ext -b $(abs_top_builddir)/python -I$(abs_top_srcdir)/include:$(abs_top_builddir)/include -L$(abs_top_builddir)/lib/.libs) +if HAVE_PYTHON3 + (cd $(srcdir)/python/ && $(PYTHON3) setup.py build_py -d $(abs_top_builddir)/python && $(PYTHON3) setup.py build_ext -b $(abs_top_builddir)/python -I$(abs_top_srcdir)/include:$(abs_top_builddir)/include -L$(abs_top_builddir)/lib/.libs) + +CLEAN_LOCAL += python-clean +python-clean: + rm -rf $(abs_top_builddir)/python +endif else ovs-install-data-local: @: diff --git a/python/ovs/json.py b/python/ovs/json.py index e84063f..f06204e 100644 --- a/python/ovs/json.py +++ b/python/ovs/json.py @@ -21,10 +21,13 @@ import sys import six +PARSER_C = 'C' +PARSER_PY = 'PYTHON' try: import ovs._json +PARSER = PARSER_C except ImportError: -pass +PARSER = PARSER_PY __pychecker__ = 'no-stringiter' @@ -91,10 +94,9 @@ class Parser(object): MAX_HEIGHT = 1000 def __new__(cls, *args, **kwargs): -try: +if PARSER == PARSER_C: return ovs._json.Parser(*args, **kwargs) -except NameError: -return super(Parser, cls).__new__(cls) +return super(Parser, cls).__new__(cls) def __init__(self, check_trailer=False): self.check_trailer = check_trailer diff --git a/tests/atlocal.in b/tests/atlocal.in index abfc1ac..3b3af84 100644 --- a/tests/atlocal.in +++ b/tests/atlocal.in @@ -22,8 +22,10 @@ if test x"$PYTHON3" = x; then export PYTHONCOERCECLOCALE fi -PYTHONPATH=$abs_top_srcdir/python:$abs_top_builddir/tests:$PYTHONPATH +PYTHONPATH=$abs_top_builddir/python:$abs_top_builddir/tests:$PYTHONPATH export PYTHONPATH +LD_LIBRARY_PATH=$abs_top_builddir/lib/.libs +export LD_LIBRARY_PATH PYTHONIOENCODING=utf_8 export PYTHONIOENCODING diff --git a/tests/json.at b/tests/json.at index bfe0f19..32a55f7 100644 --- a/tests/json.at +++ b/tests/json.at @@ -9,15 +9,16 @@ m4_define([JSON_CHECK_POSITIVE_C], AT_CLEANUP]) # JSON_CHECK_POSITIVE_PY(TITLE, INPUT, OUTPUT, TEST-JSON-ARGS, -#PYTHON-CHCEK, PYTHON-BIN) +#PYTHON-CHCEK, PYTHON-BIN, JSON-PARSER = python) # m4_define([JSON_CHECK_POSITIVE_PY], [AT_SETUP([$1]) AT_KEYWORDS([json positive Python]) AT_SKIP_IF([test $5 = no]) + AT_SKIP_IF([test $7 = C && ! $6 -c "import ovs._json" 2>/dev/null]) AT_CHECK([printf %s "AS_ESCAPE([$2])" > input]) AT_CAPTURE_FILE([input]) - AT_CHECK([$6 $srcdir/test-json.py $4 input], [0], [stdout], []) + AT_CHECK([$6 $srcdir/test-json.py -j m4_default([$7], python) $4 input], [0], [stdout], []) AT_CHECK([cat stdout], [0], [$3 ]) AT_CLEANUP]) @@ -37,16 +38,17 @@ m4_define([JSON_CHECK_POSITIVE_UCS4PY], m4_define([JSON_CHECK_POSITIVE], [JSON_CHECK_POSITIVE_C([$1 - C], [$2], [$3], [$4]) - JSON_CHECK_POSITIVE_PY([$1 - Python2], [$2], [$3], [$4], - [$HAVE_PYTHON2], [$PYTHON2]) - JSON_CHECK_POSITIVE_PY([$1 - Python3], [$2], [$3], [$4], - [$HAVE_PYTHON3], [$PYTHON3])]) + JSON_CHECK_POSITIVE_PY23([$1], [$2], [$3], [$4])]) m4_define([JSON_CHECK_POSITIVE_PY23], - [JSON_CHECK_POSITIVE_PY([$1 - Python2], [$2], [$3], [$4], + [JSON_CHECK_POSITIVE_PY([$1 - Python2(pyjson)], [$2], [$3], [$4], [$HAVE_PYTHON2], [$PYTHON2]) - JSON_CHECK_POSITIVE_PY([$1 - Python3], [$2], [$3], [$4], -
Re: [ovs-dev] [PATCH 2/2 v2] Work around Python/C JSON unicode differences
Anyone have time to look at these?
On Mon, Oct 1, 2018 at 11:24 AM Terry Wilson wrote:
>
> The OVS C-based JSON parser operates on bytes, so the parser_feed
> function returns the number of bytes that are processed. The pure
> Python JSON parser currently operates on unicode, so it expects
> that Parser.feed() returns a number of characters. This difference
> leads to parsing errors when unicode characters are passed to the
> C JSON parser from Python.
>
> Signed-off-by: Terry Wilson
> ---
> python/ovs/jsonrpc.py | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/python/ovs/jsonrpc.py b/python/ovs/jsonrpc.py
> index 4873cff..1323ba7 100644
> --- a/python/ovs/jsonrpc.py
> +++ b/python/ovs/jsonrpc.py
> @@ -272,7 +272,8 @@ class Connection(object):
> # data, so we convert it here as soon as possible.
> if data and not error:
> try:
> -data = decoder.decode(data)
> +if six.PY3 or ovs.json.PARSER == ovs.json.PARSER_PY:
> +data = decoder.decode(data)
> except UnicodeError:
> error = errno.EILSEQ
> if error:
> @@ -298,7 +299,11 @@ class Connection(object):
> else:
> if self.parser is None:
> self.parser = ovs.json.Parser()
> -self.input = self.input[self.parser.feed(self.input):]
> +if six.PY3 and ovs.json.PARSER == ovs.json.PARSER_C:
> +self.input = self.input.encode('utf-8')[
> +self.parser.feed(self.input):].decode()
> +else:
> +self.input = self.input[self.parser.feed(self.input):]
> if self.parser.is_done():
> msg = self.__process_msg()
> if msg:
> --
> 1.8.3.1
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] dpif-netdev bug regarding packet matches or ufids?
Hi Ben.
Thanks for your report and the really useful script.
I spent a few hours debugging the issue and came up with the following patch:
https://patchwork.ozlabs.org/patch/981408/
Please, take a look.
Additionally we may add ufid lookup support in flow_put_on_pmd()
as a separate fix. This, probably, will speed up the operation.
Will wait for your opinion.
Best regards, Ilya Maximets.
> Hi Ian (or others), do you have any thoughts about this?
>
> On Fri, Sep 28, 2018 at 04:24:33PM -0700, Ben Pfaff wrote:
>> I have been playing with the OFTest framework off and on over the last
>> few months and I believe it's caught an actual bug with its
>> DirectVlanPackets test. I'm appending a script that demonstrates it.
>> To see it, run "make sandbox" then execute the script inside it.
>>
>> At some level at least, the problem is in dpif-netdev, which during the
>> test logs messages like this indicating that a datapath flow can't be
>> found and therefore can't be modified:
>>
>> WARN|dummy at ovs-dummy: failed to put[modify] (No such file or
>> directory) ufid:b2fe59af-26bd-4aa0-960e-fd559dc10c54
>>
>> skb_priority(0/0),skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),recirc_id(0),dp_hash(0/0),in_port(1),packet_type(ns=0,id=0),eth(src=00:06:07:08:09:0a,dst=00:01:02:03:04:05),eth_type(0x8100),vlan(vid=1000/0x0,pcp=5/0x0),encap(eth_type(0x0800),ipv4(src=127.0.0.1/0.0.0.0,dst=127.0.0.1/0.0.0.0,proto=0/0,tos=0/0,ttl=64/0,frag=no)),
>>
>> actions:userspace(pid=0,controller(reason=7,dont_send=0,continuation=0,recirc_id=1,rule_cookie=0,controller_id=0,max_len=65535))
>>
>> It's possible that the caller is screwing up by providing a flow match
>> different from one in the datapath flow table. I have not looked at
>> that question. But the really strange thing here is that the caller is
>> providing a ufid and dpif-netdev is ignoring it. When I make it honor
>> the ufid, like the following, then the test suddenly starts working.
>> This seems like a bug to me.
>>
>> (The following patch is not actually the real fix because the code
>> should still look at the key if no ufid was provided.)
>>
>> Any thoughts?
>>
>> Thanks,
>>
>> Ben.
>>
>> diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
>> index e322f5553fa8..4855cc08f7b7 100644
>> --- a/lib/dpif-netdev.c
>> +++ b/lib/dpif-netdev.c
>> @@ -3273,7 +3273,7 @@ dp_netdev_flow_add(struct dp_netdev_pmd_thread *pmd,
>>
>> static int
>> flow_put_on_pmd(struct dp_netdev_pmd_thread *pmd,
>> -struct netdev_flow_key *key,
>> +struct netdev_flow_key *key OVS_UNUSED,
>> struct match *match,
>> ovs_u128 *ufid,
>> const struct dpif_flow_put *put,
>> @@ -3287,7 +3287,7 @@ flow_put_on_pmd(struct dp_netdev_pmd_thread *pmd,
>> }
>>
>> ovs_mutex_lock(>flow_mutex);
>> -netdev_flow = dp_netdev_pmd_lookup_flow(pmd, key, NULL);
>> +netdev_flow = dp_netdev_pmd_find_flow(pmd, ufid, NULL, 0);
>> if (!netdev_flow) {
>> if (put->flags & DPIF_FP_CREATE) {
>> if (cmap_count(>flow_table) < MAX_FLOWS) {
>>
>>
>>
>> --8<--cut here-->8--
>>
>> #! /bin/sh -ex
>>
>> # Create a bridge and add port p1 on port 1, p2 on port 2
>> ovs-appctl vlog/set netdev_dummy dpif
>> ovs-vsctl --if-exists del-br br0 \
>>-- add-br br0 \
>>-- add-port br0 p1 -- set interface p1 ofport_request=1
>> options:tx_pcap=p1-tx.pcap options:rxq_pcap=p1-rx.pcap \
>>-- add-port br0 p2 -- set interface p2 ofport_request=2
>> options:tx_pcap=p2-tx.pcap options:rxq_pcap=p2-rx.pcap
>>
>> # Add a flow that directs some packets received on p1 to p2 and the
>> # rest back out p1.
>> #
>> # Then inject a packet of the form that should go to p2. Dump the
>> # datapath flow to see that it goes to p2 ("actions:2"). Trace the
>> # same packet for good measure, to also see that it should go to p2.
>> packet=00010203040500060708090a8100a3e808004514000140007ce77f017f01
>> ovs-ofctl add-flow br0
>> priority=1,ip,in_port=1,dl_src=00:06:07:08:09:0a,dl_dst=00:01:02:03:04:05,actions=output:2
>> ovs-ofctl add-flow br0 priority=0,in_port=1,actions=IN_PORT
>> ovs-appctl netdev-dummy/receive p1 $packet
>> ovs-appctl ofproto/trace br0 in_port=p1 $packet
>> ovs-appctl dpif/dump-flows br0
>>
>> # Delete the flows, then add new flows that would not match the same
>> # packet as before.
>> ovs-ofctl del-flows br0
>> ovs-ofctl add-flow br0
>> priority=1,in_port=1,dl_src=00:06:07:08:09:0a,dl_dst=00:01:02:03:04:05,dl_type=0x0801,actions=output:2
>> ovs-ofctl add-flow br0 priority=0,in_port=1,actions=IN_PORT
>>
>> # Give the datapath a few seconds to revalidate.
>> sleep 2
>>
>> # Now inject the same packet again. It should go to p1 because it
>> # only matches the priority-0 flow, as shown by the trace. However, instead,
>> # the original datapath flow is still there and its
[ovs-dev] [PATCH] dpif-netdev: Add vlan to mask for flow_put operation.
Datapath flows in dpif-netdev classifier always has exact match
mask set for vlan. We have to enable it for flow_put operation
too in order to avoid flow modification failure due to
classifier lookup with wrong hash.
CC: Jan Scheurich
Fixes: beb75a40fdc2 ("userspace: Switching of L3 packets in L2 pipeline")
Reported-by: Ben Pfaff
Reported-at:
https://mail.openvswitch.org/pipermail/ovs-dev/2018-September/352579.html
Signed-off-by: Ilya Maximets
---
lib/dpif-netdev.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index e322f5553..5df4129fb 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -3374,6 +3374,16 @@ dpif_netdev_flow_put(struct dpif *dpif, const struct
dpif_flow_put *put)
dpif_flow_hash(dpif, , sizeof match.flow, );
}
+/* The Netlink encoding of datapath flow keys cannot express
+ * wildcarding the presence of a VLAN tag. Instead, a missing VLAN
+ * tag is interpreted as exact match on the fact that there is no
+ * VLAN. Unless we refactor a lot of code that translates between
+ * Netlink and struct flow representations, we have to do the same
+ * here. This must be in sync with 'match' in handle_packet_upcall(). */
+if (!match.wc.masks.vlans[0].tci) {
+match.wc.masks.vlans[0].tci = htons(0x);
+}
+
/* Must produce a netdev_flow_key for lookup.
* Use the same method as employed to create the key when adding
* the flow to the dplcs to make sure they match. */
@@ -6089,7 +6099,7 @@ handle_packet_upcall(struct dp_netdev_pmd_thread *pmd,
* tag is interpreted as exact match on the fact that there is no
* VLAN. Unless we refactor a lot of code that translates between
* Netlink and struct flow representations, we have to do the same
- * here. */
+ * here. This must be in sync with 'match' in dpif_netdev_flow_put(). */
if (!match.wc.masks.vlans[0].tci) {
match.wc.masks.vlans[0].tci = htons(0x);
}
--
2.17.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 2/2] ovndb-servers.ocf: Add ssl support for managing OVN DB resources with pacemaker using LB VIP.
Thanks Numan for review. Just to update that V3 will only have changes for ovn-ctl as per Han's suggestion to add details in help section there. ocf script will remain unchanged. That is why I have added acked-by on this patch. :) On Mon, Oct 8, 2018 at 11:59 PM Numan Siddique wrote: > > > On Tue, Oct 9, 2018 at 6:11 AM Han Zhou wrote: > >> >> >> >> Giving a second thought, it seems there is still a problem. >> >> >> >> There should be two sets of SSL related parameters we should consider >> in >> the active-standby scenario. >> >> - One set of parameters is for the server side. For ipaddr2 use case, >> both active and standby nodes will need them. For LB use case, where only >> the active node should listen on the port, only the active node should >> need >> these parameters. >> >> - Another set of parameters is for the client side, together with the >> --sync-from parameter, so that the standby node can connect to the active >> node as a client using SSL. These parameters are needed in standby node >> only. >> >> >> >> I didn't see how is this addressed. Did I miss anything? >> >> >> >> For the server side SSL parameters, it should be valid to use DB >> settings instead of command line options. (For client side, it may not be >> possible to use DB settings since the standby nodes need to get the SSL >> parameters before connecting to the (active) DB). >> > >> > >> Just to clarify, for active-standby scenario, since we dont know who >> will became active server any time, it is safe to use same certs on all >> central nodes irrespective of which node is client or server. >> >> Ok, thanks. It is clarified after discussion that we are combining the >> server side and client side ssl keys/certs to the same value for all >> central nodes in the active-standby setup. I didn't know that same >> settings >> actually work for both server and client, so it sounds good for me. >> > > From the pacemaker Resource script perspective, it looks good to me. I > will take > another look when you post v3. > > Thanks > Numan > > ___ >> dev mailing list >> d...@openvswitch.org >> https://mail.openvswitch.org/mailman/listinfo/ovs-dev >> > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] GLUCKWUNSCHE { Ihre E-Mail einfach trotzdem $4, 500, 000.00 USD }
--
UNITED STATES OF AMERICA LOTTO INC.
ADRESSE: OSTWESTLANDSTRASSE 1325
STADT: SILBERNER FRUHLING
STATE/PROVINCE: MARYLAND
POSTCODE: 20110
LAND: USA
INC.
** **
REF NO:. 3837498934
STAPEL NR: 97394898532/0938
** **
LOTTO GEWINNER
THEMA:. Seien letzte Notifikation
Herzlichen Glückwunsch!
GLÜCKWÜNSCHE!
United States International Lottery Inc hiermit teilt Ihnen die
Ergebnisse vom E-Mail-Adresse Stimmzettellotterie internationalem
Programm mit.
Die endgültigen Züge wurden auf dem 08 October 2018 gehalten.Ihr
E-Mailkonto ist als ein Gewinner für den Geldpreis vom $4,500,000.00 USD
gewählt worden. Dies Ergebnis ist jetzt zu Ihnen heute Samstag am 09
October 2018 freigegeben und Ihre E-Mail-Adresse, die in derbEiner
Kategorie befestigt wird,hat $4,500,000.00 USD gewonnen.
Alle E-Mail-Adressen wurden automatisch durch ein
Computerstimmzettelsystem ausgewählt, in den Ihre E-Mail-Adresse
alsbeiner der DREI glücklichen Gewinner ausgewählt wurde.
Alle E-mail Adressen wurde von den Europa Einwohner und Internet
Benutzer Databanken aus das ganze Europa ausgewählt.
Ihre Glückszahl lautet:-2475434 .und Bonusballzahl .9 Sie werden
geraten, Ihre siegreichen Informationen vertraulich {SEHR GEHEIM} zu
behalten, bis Ihre Ansprüche und Ihr Geld bearbeitet worden sind, das zu
Ihnen überweisen werden wird.
Dies ist Teil von unseremSicherheitsprotokoll,um Doppelbeanspruchen und
ungerechtfertigten Missbrauch von diesem Programm durch Schwindel zu
vermeiden.
Sie müssen Ihr Gewinn nicht später als am 21 November 2018 beansprucht
werden. Nach diesem Datum, wird alle unbeanspruchten Fonds zu unserem
Zentralebüro (als nicht beansprucht) zurückgekehrt werden .
Bitte merken Sie, um unnötige Verspätungen und Komplikationen zu
vermeiden,erinnern Sie sich immer an Ihre REF NO:. 3837498934 in allen
von Ihren Korrespondenz mit uns zu zitieren.
Wir drängen Sie daher,die Bundes Republik Deutschland Bezahlungszentrum
zu kontaktieren:
UNITED STATES LOTTERIE
BUNDESREPUBLIK DEUTSCHLAND PAYMENT CENTER
Ansprechpartner: Dr. Ulrich Dorkowski
E-mail: natwestbank...@gmail.com
E-mail: natwestbank...@gmail.com
Für die Verarbeitung und Bestätigung von Ihrem Gewinn ,füllen Sie sofort
die unten Form und reichen Sie es zu Ihrer Anspruchagentin,bei der
Bundesrepublik Deutschland Zahlungszentrum durch E-mail
ein:natwestbank...@gmail.com
United States!
{United States LOTTO GEWINNER ANMELDEFORMULAR FUER ZAHLUNG}.
***
VORNAME:
GEBURTSDATUM:
NACHNAME:
GESCHLECHT:
ADRESSE:
NATIONALITAET:
BERUF:
TELEFONNUMMER:
FAXNUMMER:
BETRAG GEWONNEN:
REF NO:. 3837498934
STAPEL NR: 97394898532/0938
GENEHMIGT FUER ZAHLUNG
Glückwünsche vom Personal des United States International Lotto
Programm,während wir hoffen, dass Sie Teil von Ihrem Gewinn benutzen
werden, sich an unserem Ende von Jahr United States Mega Lotto zu
beteiligen, wo Sie eine Chance haben werden,EUR50,000,000.00 {Fünfzig
Millionen Euros} zu gewinnen.
Für United States International Lotto Programm,
PROFESSOR DR. SARAH McCULLOUGH,
CHEFIN, AUSLANDANGELEGENHEIT ABTEILUNG.
United States!
N.B. BEANTWORTEN SIE NICHT ZU DIESER EMAIL,SONDERN WENDEN SIE SICH AN
DER BUNDESREPUBLIK DEUTSCHLAND ZAHLUNGSZENTRUM DURCH E-MAIL MIT IHREN
DATEN!
*NOTIZ**
UNTEN SIND BILDER VON DEN LETZTEN JAHR GEWINNERN VON United States
LOTTERY PROGRAMM IN DEN AMERIKA KONTINENT{NORD-AMERIKA UND
SUED-AMERIKA}.
Registereintragung:
Amtsgericht Hamburg BDW 9283
Vorsitzender des Aufsichtsrats:
Dipl.-Ing. Dr.-Ing. E.h.
Josef Krahforst
Vorstand:
Werner Kalka
(Vorsitzender)
Alfred Langer
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] ovn-trace: Fix tracing when ip.dst has to go via a gateway router
From: Numan Siddique
ovn-trace does not trace past an l3gateway port type. This patch
fixes it.
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1626080
Suggested-by: Dan Williams
Signed-off-by: Numan Siddique
---
ovn/utilities/ovn-trace.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/ovn/utilities/ovn-trace.c b/ovn/utilities/ovn-trace.c
index 2446b3f76..40a79ceea 100644
--- a/ovn/utilities/ovn-trace.c
+++ b/ovn/utilities/ovn-trace.c
@@ -645,6 +645,15 @@ read_ports(void)
} else if (!strcmp(sbpb->type, "l3gateway")) {
/* Treat all gateways as local for our purposes. */
dp->has_local_l3gateway = true;
+const char *peer_name = smap_get(>options, "peer");
+if (peer_name) {
+struct ovntrace_port *peer
+= shash_find_data(, peer_name);
+if (peer) {
+port->peer = peer;
+port->peer->peer = port;
+}
+}
}
}
--
2.17.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v10 00/14] Support multi-segment mbufs
On 08/10/2018 18:04, Ilya Maximets wrote: > Current patch-set breaks a lot of STP unit tests: Thanks for pointing that out, I've fixed them now. I wasn't aware that those tests were running as part of that testsuite, so I'll start running that as well from now on. > > ## --- ## > ## openvswitch 2.10.90 test suite. ## > ## --- ## > > ofproto-dpif > > 1149: ofproto-dpif - MPLS handlingFAILED > (ofproto-dpif.at:2068) > 1164: ofproto-dpif - VLAN+MPLS handling FAILED > (ofproto-dpif.at:3921) > > Spanning Tree Protocol unit tests > > 2534: STP example from IEEE 802.1D-1998 FAILED (stp.at:18) > 2535: STP example from IEEE 802.1D-2004 figures 17.4 and 17.5 FAILED > (stp.at:61) > 2536: STP example from IEEE 802.1D-2004 figure 17.6 FAILED (stp.at:87) > 2537: STP example from IEEE 802.1D-2004 figure 17.7 FAILED (stp.at:116) > 2538: STP.io.1.1: Link FailureFAILED (stp.at:155) > 2539: STP.io.1.2: Repeated NetworkFAILED (stp.at:181) > 2540: STP.io.1.4: Network Initialization FAILED (stp.at:205) > 2541: STP.io.1.5: Topology Change FAILED (stp.at:258) > 2545: STP.op.3.3: Root Bridge Selection: Bridge ID Values FAILED (stp.at:337) > 2546: STP.op.3.3: Root Bridge Selection: Bridge ID Values FAILED (stp.at:360) > > ## - ## > ## Test results. ## > ## - ## > > ERROR: All 12 tests were run, > 12 failed unexpectedly. > ## -- ## > ## testsuite.log was created. ## > ## -- ## > > Please send `tests/testsuite.log' and all information you think might help: > >To: >Subject: [openvswitch 2.10.90] testsuite: 1149 1164 2534 2535 2536 2537 > 2538 2539 2540 2541 2545 2546 failed > > -- > > Meanwhile, I still have a few concerns about this patch-set > in general: > > 1. Most of dp_packet APIs are now able to fail. >But callers doesn't check results in most cases. Could you be a bit more specific here? Or do you mean the dp_packet *layer* APIs, such as dp_packet_l3() and variants? As I understand, while it is true that they may now return NULL in new cases where it wouldn't happen before, it will happen very rarely (not only your headers would have to exceed the 1920B, but you'd have to opt-in and use multi-seg mbufs). Thus, I would rather fix this on a case by case basis than polluting the code with NULL checks. As a good example there's OVN, where the packets processed are always linear, and thus placing NULL checks is almost pointless. What are your thoughts? > > 2. Many drivers has its own restrictions on the number of segments >they able to handle in a single packet. For example, igb driver >supports only up to 8 segments. I think, that we have to call >tx preparation API and check the result before sending segmented >packets. It's unclear, what to do with such packets. Will we >have to have large sized mempool anyway for this case? > > 2.1 OVS will migrate to DPDK 18.11 as soon as it will be released, > but there are few PMDs that doesn't support segmented packets > at all (octeontx and axgbe, for example). Maybe it'll be better > to work on this patch set on top of ovs/dpdk-latest branch and > include all the required checks for DEV_TX_OFFLOAD_MULTI_SEGS > flag in order to not block upgrade to 18.11 ? I wouldn't oppose to that, depending on the timelines it could work. But my understanding is that one can do that already on v17.11 with the "old" `ETH_TXQ_FLAGS_NOMULTSEGS` flag. It is a valid point that the `tx_offload_capa` of each device is not being checked at the moment though. > > One code specific thing (I did not review the whole code. This just > one thing that I noticed accidentally.): > > 3. dp_packet_equal should not fail in case of different memory >layout, but equal data. Sure. Done. I'll send that in the next iteration. Tiago. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v3] ovn-nbctl: Add basic port group commands.
This adds the following commands:
pg-add: Add a new port group, optionally adding switch ports at
creation.
pg-set-ports: Sets the logical switch ports on a port group
pg-del: Remove a port group.
The main motivation for these commands is that it allows for adding
logical switch ports by name rather than UUID.
Signed-off-by: Mark Michelson
---
v2 -> v3
Removed unnecessary change from tests/ovn.at
Updated usage message in ovn-nbctl to include port group commands
v1 -> v2
Moved tests to tests/ovn-nbctl.at. This revealed issues when listing
database information in ovn-nbctl daemon mode. These issues are fixed in
series https://patchwork.ozlabs.org/project/openvswitch/list/?series=69636
Therefore this patch is dependent on the linked series.
---
ovn/utilities/ovn-nbctl.8.xml | 22 +
ovn/utilities/ovn-nbctl.c | 76 +++
tests/ovn-nbctl.at| 34 ++-
3 files changed, 131 insertions(+), 1 deletion(-)
diff --git a/ovn/utilities/ovn-nbctl.8.xml b/ovn/utilities/ovn-nbctl.8.xml
index 5e18fa7c0..14cc02f53 100644
--- a/ovn/utilities/ovn-nbctl.8.xml
+++ b/ovn/utilities/ovn-nbctl.8.xml
@@ -881,6 +881,28 @@
+Port Group commands
+
+
+ pg-add group [port]...
+
+Creates a new port group in the Port_Group table named
+group with optional ports added to the group.
+
+
+ pg-set-ports group port...
+
+Sets ports on the port group named group. It
+is an error if group does not exist.
+
+
+ pg-del group
+
+Deletes port group group. It is an error if
+group does not exist.
+
+
+
Database Commands
These commands query and modify the contents of ovsdb
tables.
They are a slight abstraction of the ovsdb interface and
diff --git a/ovn/utilities/ovn-nbctl.c b/ovn/utilities/ovn-nbctl.c
index bff6d1380..798c97276 100644
--- a/ovn/utilities/ovn-nbctl.c
+++ b/ovn/utilities/ovn-nbctl.c
@@ -686,6 +686,10 @@ SSL commands:\n\
del-ssl delete the SSL configuration\n\
set-ssl PRIV-KEY CERT CA-CERT [SSL-PROTOS [SSL-CIPHERS]] \
set the SSL configuration\n\
+Port group commands:\n\
+ pg-add PG [PORTS] Create port group PG with optional PORTS\n\
+ pg-set-ports PG PORTS Set PORTS on port group PG\n\
+ pg-del PG Delete port group PG\n\
\n\
%s\
%s\
@@ -4655,6 +4659,73 @@ cmd_set_ssl(struct ctl_context *ctx)
nbrec_nb_global_set_ssl(nb_global, ssl);
}
+static char *
+set_ports_on_pg(struct ctl_context *ctx, const struct nbrec_port_group *pg,
+char **new_ports, size_t num_new_ports)
+{
+struct nbrec_logical_switch_port **lports;
+lports = xmalloc(sizeof *lports * num_new_ports);
+
+size_t i;
+char *error = NULL;
+for (i = 0; i < num_new_ports; i++) {
+const struct nbrec_logical_switch_port *lsp;
+error = lsp_by_name_or_uuid(ctx, new_ports[i], true, );
+if (error) {
+goto out;
+}
+lports[i] = (struct nbrec_logical_switch_port *) lsp;
+}
+
+nbrec_port_group_set_ports(pg, lports, num_new_ports);
+
+out:
+free(lports);
+return error;
+}
+
+static void
+cmd_pg_add(struct ctl_context *ctx)
+{
+const struct nbrec_port_group *pg;
+
+pg = nbrec_port_group_insert(ctx->txn);
+nbrec_port_group_set_name(pg, ctx->argv[1]);
+if (ctx->argc > 2) {
+ctx->error = set_ports_on_pg(ctx, pg, ctx->argv + 2, ctx->argc - 2);
+}
+}
+
+static void
+cmd_pg_set_ports(struct ctl_context *ctx)
+{
+const struct nbrec_port_group *pg;
+
+char *error;
+error = pg_by_name_or_uuid(ctx, ctx->argv[1], true, );
+if (error) {
+ctx->error = error;
+return;
+}
+
+ctx->error = set_ports_on_pg(ctx, pg, ctx->argv + 2, ctx->argc - 2);
+}
+
+static void
+cmd_pg_del(struct ctl_context *ctx)
+{
+const struct nbrec_port_group *pg;
+
+char *error;
+error = pg_by_name_or_uuid(ctx, ctx->argv[1], true, );
+if (error) {
+ctx->error = error;
+return;
+}
+
+nbrec_port_group_delete(pg);
+}
+
static const struct ctl_table_class tables[NBREC_N_TABLES] = {
[NBREC_TABLE_DHCP_OPTIONS].row_ids
= {{_logical_switch_port_col_name, NULL,
@@ -5123,6 +5194,11 @@ static const struct ctl_command_syntax nbctl_commands[]
= {
"PRIVATE-KEY CERTIFICATE CA-CERT [SSL-PROTOS [SSL-CIPHERS]]",
pre_cmd_set_ssl, cmd_set_ssl, NULL, "--bootstrap", RW},
+/* Port Group Commands */
+{"pg-add", 1, INT_MAX, "", NULL, cmd_pg_add, NULL, "", RW },
+{"pg-set-ports", 2, INT_MAX, "", NULL, cmd_pg_set_ports, NULL, "", RW },
+{"pg-del", 1, 1, "", NULL, cmd_pg_del, NULL, "", RW },
+
{NULL, 0, 0, NULL, NULL, NULL, NULL, "", RO},
};
diff --git a/tests/ovn-nbctl.at b/tests/ovn-nbctl.at
index 3f89874ba..25414b8bd 100644
--- a/tests/ovn-nbctl.at
+++ b/tests/ovn-nbctl.at
@@ -1518,7 +1518,6 @@
Re: [ovs-dev] [PATCH v7 4/4] Replace router internal MAC with gateway MAC for reply packets
On Fri, Sep 28, 2018 at 12:36 AM Guru Shetty wrote:
>
>
> On Mon, 24 Sep 2018 at 03:10, Miguel Angel Ajo Pelayo
> wrote:
>
>>
>>
>> No worries Guru, I understand your feeling, I worked with Anil on
>> developing this feature, and it's indeed rather complex (we are actually
>> replacing keepalived + VRRP with openflow and BFD).
>>
>> I'm happy to work on a more detailed documentation, I guess that Numan,
>> Anil and I could team up to help that put documentation in shape where [1]
>> should be a good starting point for the admin side, and may be after that
>> Numan can give it a thought for making the code simpler where there's room
>> for that. It's easier to have others help simplify once we have good
>> documentation.
>>
>> I agree with Numans that, may be we should take also this opportunity
>> (this patch Anil has been working on to make VLAN private networks possible
>> with l3ha) to also support SR-IOV, since it's actually not far from there
>> at all.
>>
>> Guru, what's your biggest concern, the design documentation? the user
>> side ? both?. My worry with design documentaiton is that tends to rot when
>> new patches comes, do we have any example of internals documentation that
>> talk about code in tree?
>>
>
> My biggest concern is that reading the code does not give out a story.
> Everything in ovn-northd can be understood by just reading the code. But
> when it comes to gateway redirect, it is hard.
>
> For e.g., I am pasting a snippet of code from one of the patches in this
> series.
>
> ++if (op->peer && op->peer->od->localnet_port &&+
> op->od->l3dgw_port && op->od->l3redirect_port &&+(op !=
> op->od->l3redirect_port) &&+(op != op->od->l3dgw_port)) {+
> ds_put_format(, " && is_chassis_resident(%s)",+
> op->od->l3redirect_port->json_key);+ds_put_format(, ";
> flags.rcv_from_vlan = 1");+}
>
> You need to go back and read the first patches of the feature (gateway
> redirect) and its commit messages to understand the implications of the
> above if condition. The primary reason why it is hard is because, we try to
> move back and forth with packet flow and force it to move in non-natural
> directions.
>
> I feel that writing a documentation (A hybrid of man pages of
> ovn-architecture and ovn-northd) would make it easy to follow. For e.g., we
> follow a packet when it leaves the VM and heads to the gateway and gets
> SNATted. Similarly, we follow the packet for DNAT. We can then enhance it
> with other use cases (for e.g this patch series).
>
> On a larger note, OVN is a network virtualization project. We implement
> the functionality of a router, switch, firewall etc and then when we
> interconnect them, things just work well. Code around Switches, routers,
> load-balancers etc are easy to understand because they are all in logical
> space. But gateways transcend the logical boundary to physical boundary.
> The reason why the "gateway redirect" code is hard to understand is because
> we are trying to implement it in the same router that is also used in
> logical space. A clean separation of boundaries does not exist. I tried to
> implement the clean separation with gateway routers, wherein the there is a
> separate router that connects to the physical world and is chassis bound.
> But OpenStack-OVN as a client did not want to handle the complication of
> maintaining 2 routers.
>
>
I was involved in moving away from the Gateway router to a distributed
gateway router port once Mickey Spiegel added the redirect chassis. It's
true that we didn't want to maintain 2 logical routers in networking-ovn.
But we moved mainly because we were co relating with the default neutron
reference implementation and wanted to bridge gaps between it (with various
agents ) and neutron + OVN. With the new redirect chassis support, we could
add the floating ip support for the VMs with distributed routing (instead
of centralized routing) and also later- HA support for centralized routing.
I have submitted a patch series as an alternate solution to solve this
issue. Can you please take a look at it -
https://patchwork.ozlabs.org/project/openvswitch/list/?series=69280 and
provide your comments.
I will also work on having a documentation as you have suggested above.
Thanks
Numan
>
>
>
>
>>
>> [1]
>> https://github.com/openvswitch/ovs/blob/master/Documentation/topics/high-availability.rst
>>
>>
>>
>> On Fri, Sep 21, 2018 at 9:28 PM Numan Siddique
>> wrote:
>>
>>> On Fri, Sep 21, 2018 at 11:06 PM Guru Shetty wrote:
>>>
>>> > >
>>> > >
>>> > > I have tried to make sense of this patch series a few times. I think
>>> > > adding increasing complications like this will make gateway code
>>> > > unmaintainable. The whole gateway redirect chassis already makes it
>>> > > un-understandable and now this will mean that no one will be able to
>>> > > understand it as we go forward. [/rant off]
>>> > >
>>> >
>>> > Sorry about the "rant" if it came out as
Re: [ovs-dev] [PATCH v6] ovn: Support configuring the BFD params for the tunnel interfaces
On Tue, Oct 9, 2018 at 2:18 PM wrote:
> From: Numan Siddique
>
> With this commit the users can override the default values of
> the BFD params - min_rx, min_tx, decay_min_rx and mult if desired.
> This can be useful to debug any issues related to BFD (like
> frequent BFD state changes).
>
> A new column 'options' is added in NB_Global and SB_Global tables
> of OVN_Northbound and OVN_Southbound schemas respectively. CMS
> can define the options 'bfd-min-rx', 'bfd-min-tx',
> 'bfd-decay-min-rx' and 'bfd-mult' in the options column of
> NB_Global table row. ovn-northd copies these options from
> NB_Global to SB_Global. ovn-controller configures these
> options to the tunnel interfaces when enabling BFD.
>
> When BFD is disabled, this patch now clears the 'bfd' column
> of the interface row, instead of setting 'enable_bfd=false'.
>
If this patch is fine, can you please update from 'enable_bfd=false' to
'enable=false' in the last line of the commit message before applying.
Thanks
Numan
>
> Signed-off-by: Numan Siddique
> ---
>
> v5 -> v6
>
> * Addressed the review comments from Ben
> - changed the config options from "bfd:min-rx" to "bfd-min-rx"
> - when disabling the bfd, instead of setting the option
> "enable_bfd=false", now clears the bfd column of the interface row
>
> v4 -> v5
> ---
> * Addressed a couple of check_patch util warnings - Line exceeding 80
> char
> which was introduced in the v4.
>
> v3 -> v4
>
> * As per the suggestion from Ben - provided the option to
> centrally configuring the BFD params
>
> v2 -> v3
>
> * Added the test case for mult option
>
> v1 -> v2
> ---
> * Addressed review comments by Miguel - added the option 'mult' to
> configure.
>
> ovn/controller/bfd.c| 66 +++--
> ovn/controller/bfd.h| 3 ++
> ovn/controller/ovn-controller.c | 4 +-
> ovn/northd/ovn-northd.c | 2 +
> ovn/ovn-nb.ovsschema| 9 +++--
> ovn/ovn-nb.xml | 35 +
> ovn/ovn-sb.ovsschema| 9 +++--
> ovn/ovn-sb.xml | 38 +++
> tests/ovn.at| 31 +++-
> 9 files changed, 168 insertions(+), 29 deletions(-)
>
> diff --git a/ovn/controller/bfd.c b/ovn/controller/bfd.c
> index 051781f38..94dad236e 100644
> --- a/ovn/controller/bfd.c
> +++ b/ovn/controller/bfd.c
> @@ -38,24 +38,6 @@ bfd_register_ovs_idl(struct ovsdb_idl *ovs_idl)
> ovsdb_idl_add_column(ovs_idl, _interface_col_bfd_status);
> }
>
> -
> -static void
> -interface_set_bfd(const struct ovsrec_interface *iface, bool bfd_setting)
> -{
> -const char *new_setting = bfd_setting ? "true":"false";
> -const char *current_setting = smap_get(>bfd, "enable");
> -if (current_setting && !strcmp(current_setting, new_setting)) {
> -/* If already set to the desired setting we skip setting it again
> - * to avoid flapping to bfd initialization state */
> -return;
> -}
> -const struct smap bfd = SMAP_CONST1(, "enable", new_setting);
> -ovsrec_interface_verify_bfd(iface);
> -ovsrec_interface_set_bfd(iface, );
> -VLOG_INFO("%s BFD on interface %s", bfd_setting ? "Enabled" :
> "Disabled",
> -iface->name);
> -}
> -
> void
> bfd_calculate_active_tunnels(const struct ovsrec_bridge *br_int,
> struct sset *active_tunnels)
> @@ -267,6 +249,7 @@ bfd_run(struct ovsdb_idl_index *sbrec_chassis_by_name,
> const struct ovsrec_interface_table *interface_table,
> const struct ovsrec_bridge *br_int,
> const struct sbrec_chassis *chassis_rec,
> +const struct sbrec_sb_global_table *sb_global_table,
> const struct hmap *local_datapaths)
> {
>
> @@ -292,15 +275,58 @@ bfd_run(struct ovsdb_idl_index
> *sbrec_chassis_by_name,
> }
> }
>
> +const struct sbrec_sb_global *sb
> += sbrec_sb_global_table_first(sb_global_table);
> +struct smap bfd = SMAP_INITIALIZER();
> +smap_add(, "enable", "true");
> +
> +if (sb) {
> +const char *min_rx = smap_get(>options, "bfd-min-rx");
> +const char *decay_min_rx = smap_get(>options,
> "bfd-decay-min-rx");
> +const char *min_tx = smap_get(>options, "bfd-min-tx");
> +const char *mult = smap_get(>options, "bfd-mult");
> +if (min_rx) {
> +smap_add(, "min_rx", min_rx);
> +}
> +if (decay_min_rx) {
> +smap_add(, "decay_min_rx", decay_min_rx);
> +}
> +if (min_tx) {
> +smap_add(, "min_tx", min_tx);
> +}
> +if (mult) {
> +smap_add(, "mult", mult);
> +}
> +}
> +
> /* Enable or disable bfd */
> const struct ovsrec_interface *iface;
> OVSREC_INTERFACE_TABLE_FOR_EACH (iface, interface_table) {
> if (sset_contains(, iface->name)) {
> -
Re: [ovs-dev] [PATCH v4] ovn: Support configuring the BFD params for the tunnel interfaces
On Mon, Oct 8, 2018 at 11:53 PM Ben Pfaff wrote: > On Sat, Oct 06, 2018 at 08:04:09PM +0530, nusid...@redhat.com wrote: > > From: Numan Siddique > > > > With this commit the users can override the default values of > > the BFD params - min_rx, min_tx, decay_min_rx and mult if desired. > > This can be useful to debug any issues related to BFD (like > > frequent BFD state changes). > > > > A new column 'options' is added in NB_Global and SB_Global tables > > of OVN_Northbound and OVN_Southbound schemas respectively. CMS > > can define the options 'bfd:min-rx', 'bfd:min-tx', > > 'bfd:decay-min-rx' and 'bfd:mult' in the options column of > > NB_Global table row. ovn-northd copies these options from > > NB_Global to SB_Global. ovn-controller configures these > > options to the tunnel interfaces when enabling BFD. > > > > Signed-off-by: Numan Siddique > > Thank you for working to make OVN easier to debug and troubleshoot. > > Using : in the bfd option names makes it difficult to set them using > ovn-nbctl. It is necessary to understand how to escape the :, as shown > in the test, e.g.: > > ovn-nbctl --wait=hv set NB_Global . options:"bfd\:min-rx"=2000 > > Do you think it would be a good idea to use - instead of : for this > reason? > > Thanks for the review. I agree. I changed it to '-' in v6. > When bfd_run() decides to disable bfd on an interface, it looks like it > will still add any user-specified BFD settings. Is that intentional? > > It was intentional. But I think it's better to clear the bfd column instead of setting "enabled=false" and having the rest of the other bfd options. I updated the patch and submitted v6 with this - https://patchwork.ozlabs.org/patch/981098/ > The function interface_set_bfd() is now trivial, so it might make sense > to inline it into the caller. > > Done. > Thanks, > > Ben. > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v6] ovn: Support configuring the BFD params for the tunnel interfaces
From: Numan Siddique
With this commit the users can override the default values of
the BFD params - min_rx, min_tx, decay_min_rx and mult if desired.
This can be useful to debug any issues related to BFD (like
frequent BFD state changes).
A new column 'options' is added in NB_Global and SB_Global tables
of OVN_Northbound and OVN_Southbound schemas respectively. CMS
can define the options 'bfd-min-rx', 'bfd-min-tx',
'bfd-decay-min-rx' and 'bfd-mult' in the options column of
NB_Global table row. ovn-northd copies these options from
NB_Global to SB_Global. ovn-controller configures these
options to the tunnel interfaces when enabling BFD.
When BFD is disabled, this patch now clears the 'bfd' column
of the interface row, instead of setting 'enable_bfd=false'.
Signed-off-by: Numan Siddique
---
v5 -> v6
* Addressed the review comments from Ben
- changed the config options from "bfd:min-rx" to "bfd-min-rx"
- when disabling the bfd, instead of setting the option
"enable_bfd=false", now clears the bfd column of the interface row
v4 -> v5
---
* Addressed a couple of check_patch util warnings - Line exceeding 80 char
which was introduced in the v4.
v3 -> v4
* As per the suggestion from Ben - provided the option to
centrally configuring the BFD params
v2 -> v3
* Added the test case for mult option
v1 -> v2
---
* Addressed review comments by Miguel - added the option 'mult' to configure.
ovn/controller/bfd.c| 66 +++--
ovn/controller/bfd.h| 3 ++
ovn/controller/ovn-controller.c | 4 +-
ovn/northd/ovn-northd.c | 2 +
ovn/ovn-nb.ovsschema| 9 +++--
ovn/ovn-nb.xml | 35 +
ovn/ovn-sb.ovsschema| 9 +++--
ovn/ovn-sb.xml | 38 +++
tests/ovn.at| 31 +++-
9 files changed, 168 insertions(+), 29 deletions(-)
diff --git a/ovn/controller/bfd.c b/ovn/controller/bfd.c
index 051781f38..94dad236e 100644
--- a/ovn/controller/bfd.c
+++ b/ovn/controller/bfd.c
@@ -38,24 +38,6 @@ bfd_register_ovs_idl(struct ovsdb_idl *ovs_idl)
ovsdb_idl_add_column(ovs_idl, _interface_col_bfd_status);
}
-
-static void
-interface_set_bfd(const struct ovsrec_interface *iface, bool bfd_setting)
-{
-const char *new_setting = bfd_setting ? "true":"false";
-const char *current_setting = smap_get(>bfd, "enable");
-if (current_setting && !strcmp(current_setting, new_setting)) {
-/* If already set to the desired setting we skip setting it again
- * to avoid flapping to bfd initialization state */
-return;
-}
-const struct smap bfd = SMAP_CONST1(, "enable", new_setting);
-ovsrec_interface_verify_bfd(iface);
-ovsrec_interface_set_bfd(iface, );
-VLOG_INFO("%s BFD on interface %s", bfd_setting ? "Enabled" : "Disabled",
-iface->name);
-}
-
void
bfd_calculate_active_tunnels(const struct ovsrec_bridge *br_int,
struct sset *active_tunnels)
@@ -267,6 +249,7 @@ bfd_run(struct ovsdb_idl_index *sbrec_chassis_by_name,
const struct ovsrec_interface_table *interface_table,
const struct ovsrec_bridge *br_int,
const struct sbrec_chassis *chassis_rec,
+const struct sbrec_sb_global_table *sb_global_table,
const struct hmap *local_datapaths)
{
@@ -292,15 +275,58 @@ bfd_run(struct ovsdb_idl_index *sbrec_chassis_by_name,
}
}
+const struct sbrec_sb_global *sb
+= sbrec_sb_global_table_first(sb_global_table);
+struct smap bfd = SMAP_INITIALIZER();
+smap_add(, "enable", "true");
+
+if (sb) {
+const char *min_rx = smap_get(>options, "bfd-min-rx");
+const char *decay_min_rx = smap_get(>options, "bfd-decay-min-rx");
+const char *min_tx = smap_get(>options, "bfd-min-tx");
+const char *mult = smap_get(>options, "bfd-mult");
+if (min_rx) {
+smap_add(, "min_rx", min_rx);
+}
+if (decay_min_rx) {
+smap_add(, "decay_min_rx", decay_min_rx);
+}
+if (min_tx) {
+smap_add(, "min_tx", min_tx);
+}
+if (mult) {
+smap_add(, "mult", mult);
+}
+}
+
/* Enable or disable bfd */
const struct ovsrec_interface *iface;
OVSREC_INTERFACE_TABLE_FOR_EACH (iface, interface_table) {
if (sset_contains(, iface->name)) {
-interface_set_bfd(
-iface, sset_contains(_ifaces, iface->name));
+if (sset_contains(_ifaces, iface->name)) {
+/* We need to enable BFD for this interface. Configure the
+ * BFD params if
+ * - If BFD was disabled earlier
+ * - Or if CMS has updated BFD config options.
+ */
+if (!smap_equal(>bfd, )) {
+
[ovs-dev] [PATCH] ovsdb idl: API to get the idl session
Added an API in ovsdb-idl to get the idl->session. This API is useful in
the
ovsdb client code as the session information returned by this API would be
used to get the details about the remote session.
Signed-off-by: Arunkumar R G
---
lib/ovsdb-idl.c | 6 ++
lib/ovsdb-idl.h | 3 +++
2 files changed, 9 insertions(+)
diff --git a/lib/ovsdb-idl.c b/lib/ovsdb-idl.c
index 6a19b07..01e00f2 100644
--- a/lib/ovsdb-idl.c
+++ b/lib/ovsdb-idl.c
@@ -976,6 +976,12 @@ ovsdb_idl_is_connected(const struct ovsdb_idl *idl)
return idl->session && jsonrpc_session_is_connected(idl->session);
}
+struct jsonrpc_session *
+ovsdb_idl_get_session(const struct ovsdb_idl *idl)
+{
+return idl->session;
+}
+
/* Returns the last error reported on a connection by 'idl'. The return
value
* is 0 only if no connection made by 'idl' has ever encountered an error
and
* a negative response to a schema request has never been received. See
diff --git a/lib/ovsdb-idl.h b/lib/ovsdb-idl.h
index 8a168eb..201ba1e 100644
--- a/lib/ovsdb-idl.h
+++ b/lib/ovsdb-idl.h
@@ -55,6 +55,7 @@ struct ovsdb_idl_row;
struct ovsdb_idl_column;
struct ovsdb_idl_table_class;
struct uuid;
+struct jsonrpc_session;
struct ovsdb_idl *ovsdb_idl_create(const char *remote,
const struct ovsdb_idl_class *,
@@ -76,6 +77,8 @@ bool ovsdb_idl_is_lock_contended(const struct ovsdb_idl
*);
const struct uuid * ovsdb_idl_get_monitor_id(const struct ovsdb_idl *);
unsigned int ovsdb_idl_get_seqno(const struct ovsdb_idl *);
+struct jsonrpc_session *ovsdb_idl_get_session(const struct ovsdb_idl *);
+
bool ovsdb_idl_has_ever_connected(const struct ovsdb_idl *);
void ovsdb_idl_enable_reconnect(struct ovsdb_idl *);
void ovsdb_idl_force_reconnect(struct ovsdb_idl *);
--
1.8.3.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ovn-ctl: Fix the wrong pidfile argument passed to ovsdb-servers
Thanks Numan!
On Tue, Oct 9, 2018 at 9:17 AM wrote:
> From: Numan Siddique
>
> When OVN db servers are started usinb ovn-ctl, if the pid files
> (/var/run/openvswitch/ovnnb_db.pid for example) are already
> present, then ovn-ctl passes "--pidfile=123" if the pid file has
> '123' stored in it. Later on when OVN pacemaker RA script calls
> status_ovnnb/status_ovnsb() functions, these returns "not running".
>
> The shell function 'pidfile_is_running()' stores the contents of
> the pid file as "pid=`cat "$pidfile"`". If the caller also
> uses the same variable "pid" to store the file name, it gets
> overriden.
>
> This patch fixes this issue by renaming the local variable "pid"
> in the "start_ovsdb__()" shell function to "db_file_name".
>
> Signed-off-by: Numan Siddique
> ---
> ovn/utilities/ovn-ctl | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/ovn/utilities/ovn-ctl b/ovn/utilities/ovn-ctl
> index 3ff0df68e..950467c4e 100755
> --- a/ovn/utilities/ovn-ctl
> +++ b/ovn/utilities/ovn-ctl
> @@ -95,7 +95,7 @@ promote_ovnsb() {
>
> start_ovsdb__() {
> local DB=$1 db=$2 schema_name=$3 table_name=$4
> -local pid
> +local db_pid_file
> local cluster_local_addr
> local cluster_local_port
> local cluster_local_proto
> @@ -116,7 +116,7 @@ start_ovsdb__() {
> local addr
> local active_conf_file
> local use_remote_in_db
> -eval pid=\$DB_${DB}_PID
> +eval db_pid_file=\$DB_${DB}_PID
> eval cluster_local_addr=\$DB_${DB}_CLUSTER_LOCAL_ADDR
> eval cluster_local_port=\$DB_${DB}_CLUSTER_LOCAL_PORT
> eval cluster_local_proto=\$DB_${DB}_CLUSTER_LOCAL_PROTO
> @@ -139,7 +139,7 @@ start_ovsdb__() {
> eval use_remote_in_db=\$DB_${DB}_USE_REMOTE_IN_DB
>
> # Check and eventually start ovsdb-server for DB
> -if pidfile_is_running $pid; then
> +if pidfile_is_running $db_pid_file; then
> return
> fi
>
> @@ -169,7 +169,7 @@ $cluster_remote_port
>
> set ovsdb-server
> set "$@" $log --log-file=$logfile
> -set "$@" --remote=punix:$sock --pidfile=$pid
> +set "$@" --remote=punix:$sock --pidfile=$db_pid_file
> set "$@" --unixctl=ovn${db}_db.ctl
>
> [ "$OVS_USER" != "" ] && set "$@" --user "$OVS_USER"
> --
> 2.17.1
>
> Acked-by: Daniel Alvarez
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] ovn-ctl: Fix the wrong pidfile argument passed to ovsdb-servers
From: Numan Siddique
When OVN db servers are started usinb ovn-ctl, if the pid files
(/var/run/openvswitch/ovnnb_db.pid for example) are already
present, then ovn-ctl passes "--pidfile=123" if the pid file has
'123' stored in it. Later on when OVN pacemaker RA script calls
status_ovnnb/status_ovnsb() functions, these returns "not running".
The shell function 'pidfile_is_running()' stores the contents of
the pid file as "pid=`cat "$pidfile"`". If the caller also
uses the same variable "pid" to store the file name, it gets
overriden.
This patch fixes this issue by renaming the local variable "pid"
in the "start_ovsdb__()" shell function to "db_file_name".
Signed-off-by: Numan Siddique
---
ovn/utilities/ovn-ctl | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/ovn/utilities/ovn-ctl b/ovn/utilities/ovn-ctl
index 3ff0df68e..950467c4e 100755
--- a/ovn/utilities/ovn-ctl
+++ b/ovn/utilities/ovn-ctl
@@ -95,7 +95,7 @@ promote_ovnsb() {
start_ovsdb__() {
local DB=$1 db=$2 schema_name=$3 table_name=$4
-local pid
+local db_pid_file
local cluster_local_addr
local cluster_local_port
local cluster_local_proto
@@ -116,7 +116,7 @@ start_ovsdb__() {
local addr
local active_conf_file
local use_remote_in_db
-eval pid=\$DB_${DB}_PID
+eval db_pid_file=\$DB_${DB}_PID
eval cluster_local_addr=\$DB_${DB}_CLUSTER_LOCAL_ADDR
eval cluster_local_port=\$DB_${DB}_CLUSTER_LOCAL_PORT
eval cluster_local_proto=\$DB_${DB}_CLUSTER_LOCAL_PROTO
@@ -139,7 +139,7 @@ start_ovsdb__() {
eval use_remote_in_db=\$DB_${DB}_USE_REMOTE_IN_DB
# Check and eventually start ovsdb-server for DB
-if pidfile_is_running $pid; then
+if pidfile_is_running $db_pid_file; then
return
fi
@@ -169,7 +169,7 @@ $cluster_remote_port
set ovsdb-server
set "$@" $log --log-file=$logfile
-set "$@" --remote=punix:$sock --pidfile=$pid
+set "$@" --remote=punix:$sock --pidfile=$db_pid_file
set "$@" --unixctl=ovn${db}_db.ctl
[ "$OVS_USER" != "" ] && set "$@" --user "$OVS_USER"
--
2.17.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 2/2] ovndb-servers.ocf: Add ssl support for managing OVN DB resources with pacemaker using LB VIP.
On Tue, Oct 9, 2018 at 6:11 AM Han Zhou wrote: > >> > >> Giving a second thought, it seems there is still a problem. > >> > >> There should be two sets of SSL related parameters we should consider in > the active-standby scenario. > >> - One set of parameters is for the server side. For ipaddr2 use case, > both active and standby nodes will need them. For LB use case, where only > the active node should listen on the port, only the active node should need > these parameters. > >> - Another set of parameters is for the client side, together with the > --sync-from parameter, so that the standby node can connect to the active > node as a client using SSL. These parameters are needed in standby node > only. > >> > >> I didn't see how is this addressed. Did I miss anything? > >> > >> For the server side SSL parameters, it should be valid to use DB > settings instead of command line options. (For client side, it may not be > possible to use DB settings since the standby nodes need to get the SSL > parameters before connecting to the (active) DB). > > > > >> Just to clarify, for active-standby scenario, since we dont know who > will became active server any time, it is safe to use same certs on all > central nodes irrespective of which node is client or server. > > Ok, thanks. It is clarified after discussion that we are combining the > server side and client side ssl keys/certs to the same value for all > central nodes in the active-standby setup. I didn't know that same settings > actually work for both server and client, so it sounds good for me. > >From the pacemaker Resource script perspective, it looks good to me. I will take another look when you post v3. Thanks Numan ___ > dev mailing list > d...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
