[grpc-io]  Important Update: gRPCConf 2024 CFP Deadline Extended!

['Terry Wilson' via grpc.io]

Dear gRPC Community,

We're thrilled to announce that the Call for Proposals (CFP) deadline for 
gRPConf 2024 has been extended to May 29th, 2024!

We've heard your feedback and want to give everyone more time to submit 
their talks. Whether you're a seasoned gRPC expert or a newcomer to the 
community, we encourage you to share your knowledge and experiences with us.

This is your chance to be part of the premier gRPC event of the year and 
connect with fellow gRPC enthusiasts from the community.

Submit your proposal today and help us make gRPConf 2024 the best one yet!

To submit your proposal or register for the event,, please visit 
events.linuxfoundation.org/grpconf/program/cfp/.

We can't wait to see what you come up with!

Sincerely,

The gRPConf Team

events.linuxfoundation.org/grpconf/ 

Follow us on Youtube @gRPCio 


-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/f82d35d5-a318-4f21-9f4e-faa483eff39dn%40googlegroups.com.

[grpc-io] Re: Inquiry on Monitoring Deserialization Time of Protobuf Requests in gRPC

['Terry Wilson' via grpc.io]

This was also asked in https://github.com/grpc/grpc-java/issues/11217 and 
I've provided a reply there.

On Sunday, May 12, 2024 at 5:32:51 AM UTC-7 YACHEN ZHANG wrote:

> Dear Team,
>
> I am currently utilizing gRPC for our project and I have a specific 
> requirement that I need assistance with.
>
> I am interested in *measuring the time it takes to deserialize Protobuf 
> requests on the server side*. Could you please inform me if there is any 
> built-in monitoring capability in gRPC for this purpose? Alternatively, 
> could you advise which function I might use to log the time taken for this 
> process?
>
> Thank you in advance for your support and guidance.
>
> Best regards
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/707ae263-06a2-4075-a922-9d32a6bda450n%40googlegroups.com.

[grpc-io] gRPC-Java v1.64.0 Released

['Terry Wilson' via grpc.io]

The v1.64.0 release  
of gRPC-Java is now available!


API Changes
   
   - compiler: the option jakarta_omit was renamed @generated=omit (#11086 
   ) (8a21afc 
   

   )

New Features
   
   - New API LoadBalancer.getChannelTarget() (4561bb5 
   

   )
   - opentelemetry: Publish new module grpc-opentelemetry (5ba1a55 
   
).
 
   The feature is still missing documentation and an example. It only supports 
   metrics; tracing and logs will be future enhancements. See gRFC A66 
   
   - bazel: Add support for bzlmod (#11046 
   ) (d1890c0 
   

   )
   - bazel: Replace usages of the old compatibility maven targets with 
   @maven targets (0064991 
   

   )
   - okhttp: Support serverBuilder.maxConcurrentCallsPerConnection (Fixes 
   #11062 ). (#11063 
   ) (8050723 
   

   )
   - xds: Experimental metrics recording in WRR LB (06df25b 
   

   , 35a171b 
   

   , 2897b39 
   
),
 
   to be exported by grpc-opentelemetry if explicitly enabled in 
   GrpcOpenTelemetry. See gRFC A78 
   
   - rls: Experimental metrics recording in RLS LB (a9fb272 
   

   , a1d1932 
   

   , 8133318 
   
),
 
   to be exported by grpc-opentelemetry if explicitly enabled in 
   GrpcOpenTelemetry

Improvements
   
   - examples: support bazel build for retry policy example (58de563 
   

   )
   - netty: Allow deframer errors to close stream with a status code, as 
   long as headers have not yet been sent (e036b1b 
   
).
 
   This will greatly improve the debuggability of certain server errors in 
   particular cases. Instead of the client seeing “CANCELLED: RST_STREAM 
   closed stream. HTTP/2 error code: CANCEL”, they could see 
   “RESOURCE_EXHAUSTED: gRPC message exceeds maximum size 4194304: 6144592”
   - netty: Improve handling of unexpected write queue promise failures (
   #11016 )
   - servlet: Avoid unnecessary FINEST hex string conversion by checking 
   log level. Fixes #11031 . 
   (f7ee5f3 
   

   )
   - StatusException/StatusRuntimeException hide stack trace in a simpler 
   way (#11064 ) (e36f099 
   

   )
   - util: Status desc for outlier detection ejection (#11036 
   ) (10cb4a3 
   

   )
   - binder: Helper class to allow in process servers to use peer uids in 
   test (#11014 ) (537dbe8 
   

   )
   - Add load() statements for the Bazel builtin top-level java symbols (
   #11105 ) (add8c37 
   

   )
   - Add StatusProto.toStatusException overload to accept Throwable (#11083 
   ) (5c9b492 
   

   )

Bug fixes
   
   - Fix retry race condition that can lead to double decrementing 
   inFlightSubStreams and so miss calling closed (#11026 
   

[grpc-io] Call for Speakers! 10 Days left to submit a gRPConf 2024 proposal

['Terry Wilson' via grpc.io]

Hello gRPC Community,


We still have slots available for speakers to join us at gRPConf 2024. If  
you have a gRPC story to tell, an innovative use case to share, or a 
burning question to answer, we invite you to submit a proposal by May 19th!

Submit a Proposal 

Why you should speak:

   - 
   
   Share your gRPC knowledge
   - 
   
   Become a recognized expert
   - 
   
   Connect with fellow gRPC users
   
We want to hear about:

   - 
   
   How you're using gRPC
   - 
   
   Tips and tricks you've learned
   - 
   
   New ideas for gRPC projects
   
Keep an eye on the official gRPC website and social media channels for 
updates. If you’re not interested in speaking, but still want to join us 
you can Register Now! 

We can't wait to see you at gRPConf 2024!

The gRPConf Team

events.linuxfoundation.org/grpconf/ 
Follow us on Youtube @gRPCio 


-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/4388e8e4-98f6-47c9-86b9-101ad580de06n%40googlegroups.com.

[ovs-dev] [PATCH v2 2/2] python: ovsdb-idl: Use monitor_cond for _Server DB.

[Terry Wilson]

Unlike the C IDL code, the Python version still monitors the
_Server DB with "monitor" instead of "monitor_cond". This results
in receiving an entire Database row every time the "index" value
is updated which includes the 'schema' column. Using "monitor_cond"
will result in "update2" notifications which just include the
changed "index" value.

Unlike the C IDL, the Python IDL requires a SchemaHelper object
to instanitate the IDL, leaving it to the user of the library to
call "get_schema" themselves. Since the Python IDL did not have
support for retrieving the schema automatically and did not have
a state for doing so, instead of transitioning on an error response
from retrieving the _Server schema to requesting the "data" schema,
this moves directly to monitoring the "data" DB.

Signed-off-by: Terry Wilson 
---
 python/ovs/db/idl.py | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/python/ovs/db/idl.py b/python/ovs/db/idl.py
index a80da84e7..c1341fc2a 100644
--- a/python/ovs/db/idl.py
+++ b/python/ovs/db/idl.py
@@ -35,9 +35,9 @@ ROW_CREATE = "create"
 ROW_UPDATE = "update"
 ROW_DELETE = "delete"
 
-OVSDB_UPDATE = 0
-OVSDB_UPDATE2 = 1
-OVSDB_UPDATE3 = 2
+OVSDB_UPDATE = "update"
+OVSDB_UPDATE2 = "update2"
+OVSDB_UPDATE3 = "update3"
 
 CLUSTERED = "clustered"
 RELAY = "relay"
@@ -77,7 +77,7 @@ class ColumnDefaultDict(dict):
 return item in self.keys()
 
 
-class Monitor(enum.IntEnum):
+class Monitor(enum.Enum):
 monitor = OVSDB_UPDATE
 monitor_cond = OVSDB_UPDATE2
 monitor_cond_since = OVSDB_UPDATE3
@@ -465,23 +465,18 @@ class Idl(object):
 self.__parse_update(msg.params[2], OVSDB_UPDATE3)
 self.last_id = msg.params[1]
 elif (msg.type == ovs.jsonrpc.Message.T_NOTIFY
-and msg.method == "update2"
-and len(msg.params) == 2):
-# Database contents changed.
-self.__parse_update(msg.params[1], OVSDB_UPDATE2)
-elif (msg.type == ovs.jsonrpc.Message.T_NOTIFY
-and msg.method == "update"
+and msg.method in (OVSDB_UPDATE, OVSDB_UPDATE2)
 and len(msg.params) == 2):
 # Database contents changed.
 if msg.params[0] == str(self.server_monitor_uuid):
-self.__parse_update(msg.params[1], OVSDB_UPDATE,
+self.__parse_update(msg.params[1], msg.method,
 tables=self.server_tables)
 self.change_seqno = previous_change_seqno
 if not self.__check_server_db():
 self.force_reconnect()
 break
 else:
-self.__parse_update(msg.params[1], OVSDB_UPDATE)
+self.__parse_update(msg.params[1], msg.method)
 elif self.handle_monitor_canceled(msg):
 break
 elif self.handle_monitor_cancel_reply(msg):
@@ -540,7 +535,7 @@ class Idl(object):
 # Reply to our "monitor" of _Server request.
 try:
 self._server_monitor_request_id = None
-self.__parse_update(msg.result, OVSDB_UPDATE,
+self.__parse_update(msg.result, OVSDB_UPDATE2,
 tables=self.server_tables)
 self.change_seqno = previous_change_seqno
 if self.__check_server_db():
@@ -579,6 +574,11 @@ class Idl(object):
 elif msg.type == ovs.jsonrpc.Message.T_NOTIFY and msg.id == "echo":
 # Reply to our echo request.  Ignore it.
 pass
+elif (msg.type == ovs.jsonrpc.Message.T_ERROR and
+  self.state == self.IDL_S_SERVER_MONITOR_REQUESTED and
+  msg.id == self._server_monitor_request_id):
+self._server_monitor_request_id = None
+self.__send_monitor_request()
 elif (msg.type == ovs.jsonrpc.Message.T_ERROR and
   self.state == (
   self.IDL_S_DATA_MONITOR_COND_SINCE_REQUESTED) and
@@ -912,7 +912,7 @@ class Idl(object):
 monitor_request = {"columns": columns}
 monitor_requests[table.name] = [monitor_request]
 msg = ovs.jsonrpc.Message.create_request(
-'monitor', [self._server_db.name,
+'monitor_cond', [self._server_db.name,
  str(self.server_monitor_uuid),
  monitor_requests])
 self._server_monitor_request_id = msg.id
-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v2 1/2] ovsdb-idl: Add C IDL test for "monitor" fallback.

[Terry Wilson]

There was a Python-only test for ensuring that the library would
work when connecting to an older ovsdb-server that did not support
monitor_cond. This adds a C IDL version of that test.

Signed-off-by: Terry Wilson 
---
 tests/ovsdb-idl.at | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/tests/ovsdb-idl.at b/tests/ovsdb-idl.at
index c9e36d678..97162707e 100644
--- a/tests/ovsdb-idl.at
+++ b/tests/ovsdb-idl.at
@@ -1119,6 +1119,19 @@ OVSDB_CHECK_IDL_FETCH_COLUMNS([simple idl, initially 
populated],
 003: done
 ]])
 
+m4_define([OVSDB_CHECK_IDL_WO_MONITOR_COND_C],
+  [AT_SETUP([$1 - C])
+   AT_KEYWORDS([ovsdb server idl monitor $4])
+   OVSDB_START_IDLTEST
+   AT_CHECK([ovs-appctl -t ovsdb-server ovsdb-server/disable-monitor-cond])
+
+   AT_CHECK([test-ovsdb '-vPATTERN:console:test-ovsdb|%c|%m' -vjsonrpc -t10 
idl unix:socket $2],
+[0], [stdout], [ignore])
+   AT_CHECK([sort stdout | uuidfilt]m4_if([$5],,, [[| $5]]),
+[0], [$3])
+   OVSDB_SERVER_SHUTDOWN
+   AT_CLEANUP])
+
 m4_define([OVSDB_CHECK_IDL_WO_MONITOR_COND_PY],
   [AT_SETUP([$1 - Python3])
AT_KEYWORDS([ovsdb server idl Python monitor $4])
@@ -1132,7 +1145,8 @@ m4_define([OVSDB_CHECK_IDL_WO_MONITOR_COND_PY],
AT_CLEANUP])
 
 m4_define([OVSDB_CHECK_IDL_WO_MONITOR_COND],
-   [OVSDB_CHECK_IDL_WO_MONITOR_COND_PY($@)])
+   [OVSDB_CHECK_IDL_WO_MONITOR_COND_C($@)
+OVSDB_CHECK_IDL_WO_MONITOR_COND_PY($@)])
 
 
 OVSDB_CHECK_IDL_WO_MONITOR_COND([simple idl disable monitor-cond],
-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH 0/2] python: ovsdb-idl Use monitor_cond for _Server DB.

[Terry Wilson]

Using "monitor" for _Server means that every bump to Database.index
sends a large "update"  notification containing a lot of data
including the Database schema text. This updates the Python IDL to
use "monitor_cond" as the C IDL does.

There is a difference in logic between the two IDL implementations.
Python IDL's Idl takes a SchemaHelper object as a required object
for instantiation, while the C IDL will transition through calling
"get_schema" on first the _Server DB and data DB if that errors out.
Although the Python version calls get_schema for _Server, it has
never called it on data, presumably because the schema is passed at
instantiation.

This implementation instead of adding support for getting and using
the schema via "get_schema" on the data db, transitions from an
error retreiving the schema from _Server to directly monitoring the
data DB (since we already were passed a schema at instantiation).

It would be good to, in the future, add support for not having to
specify the schema at Idl creation, but that kind of API change
should be done on its own (hopefully in a backward-compatible way).

Terry Wilson (2):
  ovsdb-idl: Add C IDL test for "monitor" fallback
  python: ovsdb-idl: Use monitor_cond for _Server DB

 python/ovs/db/idl.py | 28 ++--
 tests/ovsdb-idl.at   | 16 +++-
 2 files changed, 29 insertions(+), 15 deletions(-)

-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH 2/2] python: ovsdb-idl: Use monitor_cond for _Server DB

[Terry Wilson]

Unlike the C IDL code, the Python version still monitors the
_Server DB with "monitor" instead of "monitor_cond". This results
in receiving an entire Database row every time the "index" value
is updated which includes the 'schema' column. Using "monitor_cond"
will result in "update2" notifications which just include the
changed "index" value.

Unlike the C IDL, the Python IDL requires a SchemaHelper object
to instanitate the IDL, leaving it to the user of the library to
call "get_schema" themselves. Since the Python IDL did not have
support for retrieving the schema automatically and did not have
a state for doing so, instead of transitioning on an error response
from retrieving the _Server schema to requesting the "data" schema,
this moves directly to monitoring the "data" DB.

Signed-off-by: Terry Wilson 
---
 python/ovs/db/idl.py | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/python/ovs/db/idl.py b/python/ovs/db/idl.py
index a80da84e7..c1341fc2a 100644
--- a/python/ovs/db/idl.py
+++ b/python/ovs/db/idl.py
@@ -35,9 +35,9 @@ ROW_CREATE = "create"
 ROW_UPDATE = "update"
 ROW_DELETE = "delete"
 
-OVSDB_UPDATE = 0
-OVSDB_UPDATE2 = 1
-OVSDB_UPDATE3 = 2
+OVSDB_UPDATE = "update"
+OVSDB_UPDATE2 = "update2"
+OVSDB_UPDATE3 = "update3"
 
 CLUSTERED = "clustered"
 RELAY = "relay"
@@ -77,7 +77,7 @@ class ColumnDefaultDict(dict):
 return item in self.keys()
 
 
-class Monitor(enum.IntEnum):
+class Monitor(enum.Enum):
 monitor = OVSDB_UPDATE
 monitor_cond = OVSDB_UPDATE2
 monitor_cond_since = OVSDB_UPDATE3
@@ -465,23 +465,18 @@ class Idl(object):
 self.__parse_update(msg.params[2], OVSDB_UPDATE3)
 self.last_id = msg.params[1]
 elif (msg.type == ovs.jsonrpc.Message.T_NOTIFY
-and msg.method == "update2"
-and len(msg.params) == 2):
-# Database contents changed.
-self.__parse_update(msg.params[1], OVSDB_UPDATE2)
-elif (msg.type == ovs.jsonrpc.Message.T_NOTIFY
-and msg.method == "update"
+and msg.method in (OVSDB_UPDATE, OVSDB_UPDATE2)
 and len(msg.params) == 2):
 # Database contents changed.
 if msg.params[0] == str(self.server_monitor_uuid):
-self.__parse_update(msg.params[1], OVSDB_UPDATE,
+self.__parse_update(msg.params[1], msg.method,
 tables=self.server_tables)
 self.change_seqno = previous_change_seqno
 if not self.__check_server_db():
 self.force_reconnect()
 break
 else:
-self.__parse_update(msg.params[1], OVSDB_UPDATE)
+self.__parse_update(msg.params[1], msg.method)
 elif self.handle_monitor_canceled(msg):
 break
 elif self.handle_monitor_cancel_reply(msg):
@@ -540,7 +535,7 @@ class Idl(object):
 # Reply to our "monitor" of _Server request.
 try:
 self._server_monitor_request_id = None
-self.__parse_update(msg.result, OVSDB_UPDATE,
+self.__parse_update(msg.result, OVSDB_UPDATE2,
 tables=self.server_tables)
 self.change_seqno = previous_change_seqno
 if self.__check_server_db():
@@ -579,6 +574,11 @@ class Idl(object):
 elif msg.type == ovs.jsonrpc.Message.T_NOTIFY and msg.id == "echo":
 # Reply to our echo request.  Ignore it.
 pass
+elif (msg.type == ovs.jsonrpc.Message.T_ERROR and
+  self.state == self.IDL_S_SERVER_MONITOR_REQUESTED and
+  msg.id == self._server_monitor_request_id):
+self._server_monitor_request_id = None
+self.__send_monitor_request()
 elif (msg.type == ovs.jsonrpc.Message.T_ERROR and
   self.state == (
   self.IDL_S_DATA_MONITOR_COND_SINCE_REQUESTED) and
@@ -912,7 +912,7 @@ class Idl(object):
 monitor_request = {"columns": columns}
 monitor_requests[table.name] = [monitor_request]
 msg = ovs.jsonrpc.Message.create_request(
-'monitor', [self._server_db.name,
+'monitor_cond', [self._server_db.name,
  str(self.server_monitor_uuid),
  monitor_requests])
 self._server_monitor_request_id = msg.id
-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH 1/2] ovsdb-idl: Add C IDL test for "monitor" fallback

[Terry Wilson]

There was a Python-only test for ensuring that the library would
work when connecting to an older ovsdb-server that did not support
monitor_cond. This adds a C IDL version of that test.

Signed-off-by: Terry Wilson 
---
 tests/ovsdb-idl.at | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/tests/ovsdb-idl.at b/tests/ovsdb-idl.at
index fb568dd82..a8df11ac4 100644
--- a/tests/ovsdb-idl.at
+++ b/tests/ovsdb-idl.at
@@ -1119,6 +1119,19 @@ OVSDB_CHECK_IDL_FETCH_COLUMNS([simple idl, initially 
populated],
 003: done
 ]])
 
+m4_define([OVSDB_CHECK_IDL_WO_MONITOR_COND_C],
+  [AT_SETUP([$1 - C])
+   AT_KEYWORDS([ovsdb server idl monitor $4])
+   OVSDB_START_IDLTEST
+   AT_CHECK([ovs-appctl -t ovsdb-server ovsdb-server/disable-monitor-cond])
+
+   AT_CHECK([test-ovsdb '-vPATTERN:console:test-ovsdb|%c|%m' -vjsonrpc -t10 
idl unix:socket $2],
+[0], [stdout], [ignore])
+   AT_CHECK([sort stdout | uuidfilt]m4_if([$5],,, [[| $5]]),
+[0], [$3])
+   OVSDB_SERVER_SHUTDOWN
+   AT_CLEANUP])
+
 m4_define([OVSDB_CHECK_IDL_WO_MONITOR_COND_PY],
   [AT_SETUP([$1 - Python3])
AT_KEYWORDS([ovsdb server idl Python monitor $4])
@@ -1132,7 +1145,8 @@ m4_define([OVSDB_CHECK_IDL_WO_MONITOR_COND_PY],
AT_CLEANUP])
 
 m4_define([OVSDB_CHECK_IDL_WO_MONITOR_COND],
-   [OVSDB_CHECK_IDL_WO_MONITOR_COND_PY($@)])
+   [OVSDB_CHECK_IDL_WO_MONITOR_COND_C($@)
+OVSDB_CHECK_IDL_WO_MONITOR_COND_PY($@)])
 
 
 OVSDB_CHECK_IDL_WO_MONITOR_COND([simple idl disable monitor-cond],
-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH 0/2] python: ovsdb-idl Use monitor_cond for _Server DB

[Terry Wilson]

Using "monitor" for _Server means that every bump to Database.index
sends a large "update"  notification containing a lot of data
including the Database schema text. This updates the Python IDL to
use "monitor_cond" as the C IDL does.

There is a difference in logic between the two IDL implementations.
Python IDL's Idl takes a SchemaHelper object as a required object
for instantiation, while the C IDL will transition through calling
"get_schema" on first the _Server DB and data DB if that errors out.
Although the Python version calls get_schema for _Server, it has
never called it on data, presumably because the schema is passed at
instantiation.

This implementation instead of adding support for getting and using
the schema via "get_schema" on the data db, transitions from an
error retreiving the schema from _Server to directly monitoring the
data DB (since we already were passed a schema at instantiation).

It would be good to, in the future, add support for not having to
specify the schema at Idl creation, but that kind of API change
should be done on its own (hopefully in a backward-compatible way).

Terry Wilson (2):
  ovsdb-idl: Add C IDL test for "monitor" fallback
  python: ovsdb-idl: Use monitor_cond for _Server DB

 python/ovs/db/idl.py | 28 ++--
 tests/ovsdb-idl.at   | 16 +++-
 2 files changed, 29 insertions(+), 15 deletions(-)

-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v2] python: ovsdb-idl: Add custom transaction operations.

[Terry Wilson]

It can be useful to be able to send raw transaction operations
through the Idl's connection. For example, to clean up MAC_Binding
entries for floating IPs without having to monitor the MAC_Binding
table which can be quite large.

Signed-off-by: Terry Wilson 
---
 NEWS |  2 ++
 python/ovs/db/idl.py | 18 ++-
 tests/ovsdb-idl.at   | 27 ++
 tests/test-ovsdb.py  | 55 
 4 files changed, 101 insertions(+), 1 deletion(-)

diff --git a/NEWS b/NEWS
index b92cec532..f30b859fd 100644
--- a/NEWS
+++ b/NEWS
@@ -7,6 +7,8 @@ Post-v3.3.0
- The primary development branch has been renamed from 'master' to 'main'.
  The OVS tree remains hosted on GitHub.
  https://github.com/openvswitch/ovs.git
+   - Python:
+ * Add custom transaction support to the Idl via add_op().
 
 
 v3.3.0 - 16 Feb 2024
diff --git a/python/ovs/db/idl.py b/python/ovs/db/idl.py
index a80da84e7..1220e4cc6 100644
--- a/python/ovs/db/idl.py
+++ b/python/ovs/db/idl.py
@@ -1703,6 +1703,8 @@ class Transaction(object):
 
 self._inserted_rows = {}  # Map from UUID to _InsertedRow
 
+self._operations = []
+
 def add_comment(self, comment):
 """Appends 'comment' to the comments that will be passed to the OVSDB
 server when this transaction is committed.  (The comment will be
@@ -1838,7 +1840,7 @@ class Transaction(object):
"rows": [rows]})
 
 # Add updates.
-any_updates = False
+any_updates = bool(self._operations)
 for row in self._txn_rows.values():
 if row._changes is None:
 if row._table.is_root:
@@ -1977,6 +1979,7 @@ class Transaction(object):
 if self.dry_run:
 operations.append({"op": "abort"})
 
+operations += self._operations
 if not any_updates:
 self._status = Transaction.UNCHANGED
 else:
@@ -1991,6 +1994,19 @@ class Transaction(object):
 self.__disassemble()
 return self._status
 
+def add_op(self, op):
+"""Add a raw OVSDB operation to the transaction
+
+This can be useful for re-using the existing Idl connection to take
+actions that are difficult or expensive to do with the Idl itself. e.g.
+deleting a bunch of rows on the server that you don't want to store
+in memory.
+
+:param op: An "op" for an OVSDB "transact" request (rfc 7047 Sec 5.2)
+:type op:   dict
+"""
+self._operations.append(op)
+
 def commit_block(self):
 """Attempts to commit this transaction, blocking until the commit
 either succeeds or fails.  Returns the final commit status, which may
diff --git a/tests/ovsdb-idl.at b/tests/ovsdb-idl.at
index fb568dd82..487545a13 100644
--- a/tests/ovsdb-idl.at
+++ b/tests/ovsdb-idl.at
@@ -2758,6 +2758,33 @@ OVSDB_CHECK_IDL_PERS_UUID_INSERT([simple idl, persistent 
uuid insert],
   [['This UUID would duplicate a UUID already present within the table or 
deleted within the same transaction']])
 
 
+OVSDB_CHECK_IDL_PY([simple idl, python, add_op],
+  [],
+  [['insert 1, insert 2, insert 3, insert 1' \
+'add_op {"op": "delete", "table": "simple", "where": [["i", "==", 1]]}' \
+'add_op {"op": "insert", "table": "simple", "row": {"i": 2}}, delete 3' \
+'insert 2, add_op {"op": "update", "table": "simple", "row": {"i": 1}, 
"where": [["i", "==", 2]]}'
+  ]],
+  [[000: empty
+001: commit, status=success
+002: table simple: i=1 r=0 b=false s= u=<0> ia=[] ra=[] ba=[] sa=[] ua=[] 
uuid=<1>
+002: table simple: i=1 r=0 b=false s= u=<0> ia=[] ra=[] ba=[] sa=[] ua=[] 
uuid=<2>
+002: table simple: i=2 r=0 b=false s= u=<0> ia=[] ra=[] ba=[] sa=[] ua=[] 
uuid=<3>
+002: table simple: i=3 r=0 b=false s= u=<0> ia=[] ra=[] ba=[] sa=[] ua=[] 
uuid=<4>
+003: commit, status=success
+004: table simple: i=2 r=0 b=false s= u=<0> ia=[] ra=[] ba=[] sa=[] ua=[] 
uuid=<3>
+004: table simple: i=3 r=0 b=false s= u=<0> ia=[] ra=[] ba=[] sa=[] ua=[] 
uuid=<4>
+005: commit, status=success
+006: table simple: i=2 r=0 b=false s= u=<0> ia=[] ra=[] ba=[] sa=[] ua=[] 
uuid=<3>
+006: table simple: i=2 r=0 b=false s= u=<0> ia=[] ra=[] ba=[] sa=[] ua=[] 
uuid=<5>
+007: commit, status=success
+008: table simple: i=1 r=0 b=false s= u=<0> ia=[] ra=[] ba=[] sa=[] ua=[] 
uuid=<3>
+008: table simple: i=1 r=0 b=false s= u=<0> ia=[] ra=[] ba=[] sa=[] ua=[] 
uuid=<5>
+008: table simple: i=1 r=0 b=false s= u=<0> ia=[] ra=[] ba=[] sa=[] ua=

Re: [ovs-dev] [PATCH 2/3] python: ovsdb-idl: Make IndexedRows mirror hmap.

[Terry Wilson]

I tried to get this to thread under the "ovsdb-idl: potential issues
with the persistent UUID implementation" thread, but failed. This is
one potential solution to that which mirrors the current C IDL
implementation which seems to work for the most part, but relying on
the fact that hmaps allow duplicate keys wasn't necessarily intended
there. Reading that thread is definitely a prerequisite for
understanding why this patch exists. And it may be better to solve
this some other way, but it seems difficult to do for the case of
"inserting a UUID that already exists" w/o creating a race condition
with multiple IDL clients.

Terry

On Wed, Apr 10, 2024 at 4:39 PM Terry Wilson  wrote:
>
> The Python IDL code very closely mirrors the C IDL code, which uses
> an hmap to store table rows. hmap code allows duplicate keys, while
> IndexedRows, which is derived from DictBase does not.
>
> The persistent UUID code can attempt to temporarily add a Row with
> a duplicate UUID to table.rows, so IndexedRows is modified to
> behave similarly to the C IDL's hmap implementation.
>
> Fixes: 55b9507e6824 ("ovsdb-idl: Add the support to specify the uuid for row 
> insert.")
> Signed-off-by: Terry Wilson 
> ---
>  python/ovs/db/custom_index.py | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/python/ovs/db/custom_index.py b/python/ovs/db/custom_index.py
> index 587caf5e3..3fa03d3c9 100644
> --- a/python/ovs/db/custom_index.py
> +++ b/python/ovs/db/custom_index.py
> @@ -90,14 +90,21 @@ class IndexedRows(DictBase, object):
>  index = self.indexes[name] = MultiColumnIndex(name)
>  return index
>
> +def __getitem__(self, key):
> +return self.data[key][-1]
> +
>  def __setitem__(self, key, item):
> -self.data[key] = item
> +try:
> +self.data[key].append(item)
> +except KeyError:
> +self.data[key] = [item]
>  for index in self.indexes.values():
>  index.add(item)
>
>  def __delitem__(self, key):
> -val = self.data[key]
> -del self.data[key]
> +val = self.data[key].pop()
> +if len(self.data[key]) == 0:
> +del self.data[key]
>  for index in self.indexes.values():
>  index.remove(val)
>
> --
> 2.34.3
>

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH 3/3] python: ovsdb-idl: Convert new_uuid insert() arg to UUID.

[Terry Wilson]

The argument to insert() should be a uuid.UUID object. If it isn't
then a Row is created with a string uuid attribute and that row is
added to table.rows with a string key instead of a UUID key.

Fixes: 55b9507e6824 ("ovsdb-idl: Add the support to specify the uuid for row 
insert.")
Signed-off-by: Terry Wilson 
---
 python/ovs/db/idl.py | 2 +-
 tests/test-ovsdb.py  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/python/ovs/db/idl.py b/python/ovs/db/idl.py
index a80da84e7..0e201366b 100644
--- a/python/ovs/db/idl.py
+++ b/python/ovs/db/idl.py
@@ -1854,7 +1854,7 @@ class Transaction(object):
 if row._data is None:
 op["op"] = "insert"
 if row._persist_uuid:
-op["uuid"] = row.uuid
+op["uuid"] = str(row.uuid)
 else:
 op["uuid-name"] = _uuid_name_from_uuid(row.uuid)
 
diff --git a/tests/test-ovsdb.py b/tests/test-ovsdb.py
index 48f8ee2d7..6307aa2bd 100644
--- a/tests/test-ovsdb.py
+++ b/tests/test-ovsdb.py
@@ -434,7 +434,7 @@ def idl_set(idl, commands, step):
 sys.stderr.write('"set" command requires 2 argument\n')
 sys.exit(1)
 
-s = txn.insert(idl.tables["simple"], new_uuid=args[0],
+s = txn.insert(idl.tables["simple"], new_uuid=uuid.UUID(args[0]),
persist_uuid=True)
 s.i = int(args[1])
 elif name == "delete":
-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH 2/3] python: ovsdb-idl: Make IndexedRows mirror hmap.

[Terry Wilson]

The Python IDL code very closely mirrors the C IDL code, which uses
an hmap to store table rows. hmap code allows duplicate keys, while
IndexedRows, which is derived from DictBase does not.

The persistent UUID code can attempt to temporarily add a Row with
a duplicate UUID to table.rows, so IndexedRows is modified to
behave similarly to the C IDL's hmap implementation.

Fixes: 55b9507e6824 ("ovsdb-idl: Add the support to specify the uuid for row 
insert.")
Signed-off-by: Terry Wilson 
---
 python/ovs/db/custom_index.py | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/python/ovs/db/custom_index.py b/python/ovs/db/custom_index.py
index 587caf5e3..3fa03d3c9 100644
--- a/python/ovs/db/custom_index.py
+++ b/python/ovs/db/custom_index.py
@@ -90,14 +90,21 @@ class IndexedRows(DictBase, object):
 index = self.indexes[name] = MultiColumnIndex(name)
 return index
 
+def __getitem__(self, key):
+return self.data[key][-1]
+
 def __setitem__(self, key, item):
-self.data[key] = item
+try:
+self.data[key].append(item)
+except KeyError:
+self.data[key] = [item]
 for index in self.indexes.values():
 index.add(item)
 
 def __delitem__(self, key):
-val = self.data[key]
-del self.data[key]
+val = self.data[key].pop()
+if len(self.data[key]) == 0:
+del self.data[key]
 for index in self.indexes.values():
 index.remove(val)
 
-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH 1/3] ovsdb-idl: Add python keyword to persistent UUID test.

[Terry Wilson]

The Python persistent UUID tests should have the keyword "python"
added so that TESTSUITEFLAGS="-k python" will not miss testing
them.

Fixes: 55b9507e6824 ("ovsdb-idl: Add the support to specify the uuid for row 
insert.")
Signed-off-by: Terry Wilson 
---
 tests/ovsdb-idl.at | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/ovsdb-idl.at b/tests/ovsdb-idl.at
index fb568dd82..c9e36d678 100644
--- a/tests/ovsdb-idl.at
+++ b/tests/ovsdb-idl.at
@@ -2713,7 +2713,7 @@ m4_define([OVSDB_CHECK_IDL_PERS_UUID_INSERT_C],
 
 m4_define([OVSDB_CHECK_IDL_PERS_UUID_INSERT_PY],
   [AT_SETUP([$1 - Python3])
-   AT_KEYWORDS([idl persistent uuid insert])
+   AT_KEYWORDS([idl python persistent uuid insert])
OVSDB_START_IDLTEST([], ["$abs_srcdir/idltest.ovsschema"])
AT_CHECK([$PYTHON3 $srcdir/test-ovsdb.py  -t10 idl 
$srcdir/idltest.ovsschema unix:socket $2],
 [0], [stdout], [stderr])
-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] ovsdb-idl: potential issues with the persistent UUID implementation

[Terry Wilson]

There was a patch in OVS 3.1 that added support to the IDL code for
specifying the permanent UUID of a row when inserting [1]. There are
both C and Python implementations. Initially, I was adding support to
ovsdbapp for this feature and noticed that the Python tests for this
feature passed `new_uuid` to `insert()` as a string:

elif name == "insert_uuid":
...
s = txn.insert(idl.tables["simple"], new_uuid=args[0],
   persist_uuid=True)

when the existing code in `insert()` treats `new_uuid` as a `uuid.UUID` or None.

def insert(self, table, new_uuid=None, persist_uuid=False):
...

if new_uuid is None:
new_uuid = uuid.uuid4()
row = Row(self.idl, table, new_uuid, None, persist_uuid=persist_uuid)
table.rows[row.uuid] = row
self._txn_rows[row.uuid] = row
return row

It creates a `Row` with `row.uuid` of type string in this case instead
of a `uuid.UUID` and then stores it in `table.rows` under a string
key. This `Row` is fairly short-lived in that it gets deleted once we
send the request to the ovsdb-server and call
`Transaction.__disassemble()`. Then, when we get the OVSDB update
notification, the `Row` is created normally and stored in
`table.rows`. So at this point there's no real problem except that
from an interface perspective, new_uuid is the wrong type. In client
code, this can probably be problem having the returned `Row` having a
string for `uuid`.

This starts to get interesting when you try to simply fix this type
issue. For the case where `new_uuid` already exists in the DB, If you
pass `new_uuid=uuid.uuid4()` and fix the code in commit

op["op"] = "insert"
if row._persist_uuid:
op["uuid"] = row.uuid

to convert `row.uuid` to a string for the JSONRPC request, the code in
insert that does `table.rows[row.uuid] = row` will then *overwrite*
the existing row, then when the transaction is disassembled, that row
will be deleted. Since the row exists in the server, the txn will
fail. So your insert() call ends up deleting the row instead of adding
a new one. The existing test case will catch this issue. The tests
currently depend on getting a response from ovsdb-server regarding the
duplicate UUID. So fixing it just in the Python implementation by
checking locally `insert()` if the UUID was already stored in
`table.rows` would be a behavior difference between the two. Trying to
just pass the old row to the transaction, since `Row._data` would no
longer be `None` would convert the insert request to an update.

Knowing that the C IDL and Python IDL are very similar, I went to
compare what they were doing. It was essentially the same. The C code
does take a `const struct uuid *` as an argument to
`ovsdb_idl_txn_insert()` like one would expect, and insert the new row
into `table->rows`. The difference is, that `table->rows` is an hmap
and hmaps allow duplicate keys. So the C IDL version is storing two
copies of the same row in the DB after `ovsdb_idl_txn_insert()` and
the one that is inserted, having been inserted into
`txn->txn_rows` is looked up in `ovsdb_idl_txn_disassemble` and
deleted directly with `hmap_remove()`. So things, perhaps
accidentally, end up working fine in practice there. One caveat would
be that any operation that tried to find the row while the transaction
was active with something like `HMAP_FOR_EACH_WITH_HASH()` which
`ovsdb_idl_get_row()`, will get the first one that is iterated over
based on the hmap implementation.

So my questions are:

Do we really mean to be storing two identical rows in the C version?

If not, should we also do local checks for the row client-side in both
versions of the IDL code and fail early? It would be an API change to
either assert or return NULL/None in the insert methods. One possible
issue with this is that it would enable a race condition: Imagine two
requests for deleting and then recreating an object with a persistent
UUID and they are routed to different worker IDLs. The recreate could
fail if it doesn't receive the update notification from ovsdb-server
with the delete in time, and one of the reasons we want to use this
feature is to avoid this kind of issue.

If we actually intend to store multiple rows with the same UUID
temporarily in the in-memory tables, then how do we want to do that in
the Python code? table.rows technically isn't a dict, it's a custom
class that subclasses dict, so if we absolutely needed to we could
override `__setitem__`, `__delitem__`, and `__getitem__` to handle
duplicates by storing/retrieving them from a list.

Ultimately, it seems like we need to a) always send the insert
transactions for persistent uuids (as the current code does) and b) do
that without passing the wrong type in the Python code or
inadvertently causing issues with blindly storing multiple rows with
the same key in the table.rows hmap in the C code. Ideas?

[1] 
https://github.com/openvswitch/ovs/commit/55b9507e6824b935ffa0205fc7c7bebfe4e54279

[Yahoo-eng-team] [Bug 2056366] [NEW] Neutron ml2/ovn does not exit when killed with SIGTERM

[Terry Wilson]

Public bug reported:

When Neutron is killed with SIGTERM (like via systemctl), when using
ML2/OVN neutron workers do not exit and instead are eventually killed
with SIGKILL when the graceful timeout is reached (often around 1
minute).

This is happening due to the signal handlers for SIGTERM. There are
multiple issues.

1) oslo_service, ml2/ovn mech_driver, and ml2/ovo_rpc.py all call 
signal.signal(signal.SIGTERM, ...) overwriting each others signal handlers.
2) SIGTERM is handled in the main thread, and running blocking code there 
causes AssertionErrors in eventlet
3) The ml2/ovn cleanup code doesn't cause the process to end, so it interrupts 
the killing of the process

oslo_service has a singleton SignalHandler class that solves all of
these issues and we should use that instead of calling signal.signal()
ourselves.

** Affects: neutron
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2056366

Title:
  Neutron ml2/ovn does not exit when killed with SIGTERM

Status in neutron:
  New

Bug description:
  When Neutron is killed with SIGTERM (like via systemctl), when using
  ML2/OVN neutron workers do not exit and instead are eventually killed
  with SIGKILL when the graceful timeout is reached (often around 1
  minute).

  This is happening due to the signal handlers for SIGTERM. There are
  multiple issues.

  1) oslo_service, ml2/ovn mech_driver, and ml2/ovo_rpc.py all call 
signal.signal(signal.SIGTERM, ...) overwriting each others signal handlers.
  2) SIGTERM is handled in the main thread, and running blocking code there 
causes AssertionErrors in eventlet
  3) The ml2/ovn cleanup code doesn't cause the process to end, so it 
interrupts the killing of the process

  oslo_service has a singleton SignalHandler class that solves all of
  these issues and we should use that instead of calling signal.signal()
  ourselves.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2056366/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[grpc-io] Save the Date - gRPConf 2024!

['Terry Wilson' via grpc.io]

Hello gRPC Community,

Mark your calendars for the premier gRPC event of the year! gRPConf 2024 
will land on the Google Cloud Campus in Sunnyvale, California, on August 
27th, 2024.

Get ready to:

   - 
   
   Dive into the latest gRPC developments
   - 
   
   Network with fellow gRPC users and experts
   - 
   
   Learn best practices and innovative use cases
   
More details, including registration and a Call for Proposals, will be 
coming soon. For now, block off August 27th, 2024, and stay tuned for 
updates!

Best regards,

The gRPConf Team

Follow us on YouTube @gRPCio  


-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/795cf320-355d-47dd-862d-f7fd42ce9986n%40googlegroups.com.

[grpc-io] Re: Is hedgingPolicy supported in C++

['Terry Wilson' via grpc.io]

Sorry, I don't believe C++ has implemented hedging.

On Monday, January 22, 2024 at 6:29:21 AM UTC-8 Leonid Lazarev wrote:

> Hello,
>
> Does "hedgingPolicy" is suported for C++ grpc or not?
>
> I see description for hedging in proposal, https://
> github.innominds.com/grpc/proposal/blob/master/A6-client-retries.md, but 
> I do not see that the configuration parameters for hedgind are parsed in 
> the code. 
>
> I use grpc 1.54.2
>
> Best Regards Leonid Lazarev
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/2c66f4f6-d304-4cbb-a439-44bd780cb22an%40googlegroups.com.

Re: [ovs-dev] [PATCH 20/22] ovsdb-server: Allow user-provided config files.

[Terry Wilson]

On Mon, Jan 8, 2024 at 8:17 AM Ilya Maximets  wrote:
>
> On 1/5/24 21:26, Terry Wilson wrote:
> > On Wed, Dec 13, 2023 at 7:05 PM Ilya Maximets  wrote:
> >
> >> -/* Clears and replaces 'remotes' and 'dbnames' by a configuration read 
> >> from
> >> - * 'config_file', which must have been previously written by 
> >> save_config(). */
> >> -static void
> >> +/* Clears and replaces 'remotes' and 'db_conf' by a configuration read 
> >> from
> >> + * 'config_file', which must have been previously written by save_config()
> >> + * or provided by the user with --config-file.
> >> + * Returns 'true', if parsing was successful, 'false' otherwise. */
> >> +static bool
> >>  load_config(FILE *config_file, struct shash *remotes,
> >>  struct shash *db_conf, char **sync_from,
> >>  char **sync_exclude, bool *is_backup)
> >> @@ -2890,17 +3117,34 @@ load_config(FILE *config_file, struct shash 
> >> *remotes,
> >>  struct json *json;
> >
> > I'm wondering if having an argument for everything we parse out of a
> > config file might get a little unwieldy down the road. Say we add
> > configuration of SSL stuff, etc. Maybe it's something we could modify
> > as it becomes an issue, but it might be nice to have something for
> > config options that is similar to what we have for registering unixctl
> > commands or struct ctl_command_syntax. Documentation could be added as
> > part of the registration/definition of the config option, there could
> > be a .get() that parses the values out of the json, and a .run() that
> > gets called after all of the parsing is shown to succeed.
> >
> > Terry
> >
>
> Hi, Terry.  Yes, I agree that the current interface is far from being
> ideal, and I actually tried to rework it multiple times while working
> on this patch set.  That's one of the reasons it took so long. :)
> Unfortunately it ended up with a huge amount of refactoring every time.
> The main reason for that, I think, is the fact that the same function
> is used for loading the legacy internal configuration file and the new
> user-provided file.  And the code around legacy internal configuration
> is not easy to adapt.
>
> I think, it would be much easier to do this kind of refactoring once
> we deprecate and remove all the appctl commands that can change the
> server configuration.  For now I decided to keep the interface as it is
> without this patch set to avoid making the patch set even bigger.
> I hope that makes sense.
>
> The idea of registering the options with a common parsing logic sounds
> interesting though and definitely worth exploring in the future.
>
> Best regards, Ilya Maximets.

Yeah, I'm all for merging as-is and prettying up as needed.

In case you have entirely too much free time on your hands (ha!),
here's an ini-style config loading/reloading framework I wrote many
many years ago (Warning: I'd only been programming professionally for
~3 years or so at that point). Asterisk was very modular and had over
100 different config files, and many of them used ini files in
completely different ways so it's definitely more generic and overkill
for what we are needing, but there may be some useful ideas [1-5] if
you ignore all of the macro/varargs magic. ;)

The general idea was a per-module `aco_info` structure that defined
the information that was obtained from configs, `aco_type` structures
that defined what parts of the config file matched up to what fields
of the `aco_info` struc, and aco_option_register() which would define
the specific options set under each [category], how they were matched,
what fields in a struct they set, etc. aco_option_register_custom()
just used custom callback functions to handle setting things up.
aco_process_config() would be called on load/reload and would parse
the config file and create an internal 'pending' representation of the
user-defined aco_info and then if parsing succeeded would then
atomically swap the pending and live aco_info pointers. There were
also pre_apply and post_apply callbacks so modules could do special
things if needed during reloads, etc. Prior to the patch modules would
often just modify their internal structures as the config file was
being processed, so if there was a parse error things would just be
left in a state where configs were partially applied.

Anyway, it may or may not be interesting and certainly isn't something
we need to worry about right now. Just food for thought.

Terry

[1] 
https://github.com/asterisk/asterisk/blob/master/include/asterisk/config_options.h
[2] https://github.com/asterisk/asterisk/blob/master/main/config_options.c
[3] 
https://github.com/asterisk/asterisk/blob/master/configs/samples/app_ske

Re: [ovs-dev] [PATCH 20/22] ovsdb-server: Allow user-provided config files.

[Terry Wilson]

On Wed, Dec 13, 2023 at 7:05 PM Ilya Maximets  wrote:

> -/* Clears and replaces 'remotes' and 'dbnames' by a configuration read from
> - * 'config_file', which must have been previously written by save_config(). 
> */
> -static void
> +/* Clears and replaces 'remotes' and 'db_conf' by a configuration read from
> + * 'config_file', which must have been previously written by save_config()
> + * or provided by the user with --config-file.
> + * Returns 'true', if parsing was successful, 'false' otherwise. */
> +static bool
>  load_config(FILE *config_file, struct shash *remotes,
>  struct shash *db_conf, char **sync_from,
>  char **sync_exclude, bool *is_backup)
> @@ -2890,17 +3117,34 @@ load_config(FILE *config_file, struct shash *remotes,
>  struct json *json;

I'm wondering if having an argument for everything we parse out of a
config file might get a little unwieldy down the road. Say we add
configuration of SSL stuff, etc. Maybe it's something we could modify
as it becomes an issue, but it might be nice to have something for
config options that is similar to what we have for registering unixctl
commands or struct ctl_command_syntax. Documentation could be added as
part of the registration/definition of the config option, there could
be a .get() that parses the values out of the json, and a .run() that
gets called after all of the parsing is shown to succeed.

Terry

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v2] python: idl: Handle monitor_canceled

[Terry Wilson]

On Fri, Jan 5, 2024 at 9:56 AM Simon Horman  wrote:
>
> On Mon, Dec 18, 2023 at 05:31:24PM -0600, Terry Wilson wrote:
> > Currently python-ovs claims to be "db change aware" but does not
> > parse the "monitor_canceled" notification. Transactions can continue
> > being made, but the monitor updates will not be sent. This handles
> > monitor_cancel similarly to how ovsdb-cs currently does.
> >
> > Signed-off-by: Terry Wilson 
>
> Hi Terry,
>
> is it possible to add a test to tests/ovsdb-idl.at for this feature?

It might be, but it seems like it'd be a bit of work and I'm not sure
if I'll have the time to look at it for a while. I'm just trying to
bring the functionality up to what the C IDL has and from what I can
tell this feature isn't tested in the C IDL either. What I'm doing to
manually test is to run this:

import logging
import ovs

import ovsdbapp.schema.ovn_northbound.impl_idl as nb_idl
from ovsdbapp.backend.ovs_idl import connection, vlog

print(f"Using OVS {ovs.__file__}")
logging.basicConfig(level=logging.DEBUG)
vlog.use_python_logger()
LOG = logging.getLogger(__name__)

remote = "unix:///home/twilson/src/ovn/tutorial/sandbox/nb1.ovsdb"

def get_idl():
   """Connection getter."""

   idl = connection.OvsdbIdl.from_server(remote, "OVN_Northbound",
 leader_only=False)
   return nb_idl.OvnNbApiIdlImpl(connection.Connection(idl, 100))

idl = get_idl()
LOG.info(f"monitor_id: {str(idl.idl.uuid)}")
LOG.info(f"server_monitor_id: {str(idl.idl.server_monitor_uuid)}")
input(" Press Enter ")
idl.ls_add("test").execute(check_error=True)

and then in another window running:
ovsdb-client convert
unix:/home/twilson/src/ovn/tutorial/sandbox/nb1.ovsdb
/home/twilson/src/ovn/ovn-nb.ovsschema

and then pressing enter in the original window. Without the patch,
after running the ovsdb-client convert, you get:
DEBUG:ovsdbapp.backend.ovs_idl.vlog:unix:///home/twilson/src/ovn/tutorial/sandbox/nb1.ovsdb:
received unexpected notification message
and then ovsdbapp starts throwing exceptions. With the patch, things
work as one would expect.

The problem with testing is that the client connection needs to be
active during the monitor_canceled that happens when ovsdb-client
convert is called. The tests in ovsdb-idl.at use ovsdb-client transact
for doing everything, so it's not easy to do the convert between
connection and transaction execution.

Maybe something could be added test test-ovsdb.py stuff.

Terry




Terry

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v2] python: idl: Handle monitor_canceled

[Terry Wilson]

Currently python-ovs claims to be "db change aware" but does not
parse the "monitor_canceled" notification. Transactions can continue
being made, but the monitor updates will not be sent. This handles
monitor_cancel similarly to how ovsdb-cs currently does.

Signed-off-by: Terry Wilson 
---
 python/ovs/db/idl.py | 32 
 1 file changed, 32 insertions(+)

diff --git a/python/ovs/db/idl.py b/python/ovs/db/idl.py
index 9fc2159b0..be6ae2ca4 100644
--- a/python/ovs/db/idl.py
+++ b/python/ovs/db/idl.py
@@ -299,6 +299,7 @@ class Idl(object):
 self._server_schema_request_id = None
 self._server_monitor_request_id = None
 self._db_change_aware_request_id = None
+self._monitor_cancel_request_id = None
 self._server_db_name = '_Server'
 self._server_db_table = 'Database'
 self.server_tables = None
@@ -481,6 +482,10 @@ class Idl(object):
 break
 else:
 self.__parse_update(msg.params[1], OVSDB_UPDATE)
+elif self.handle_monitor_canceled(msg):
+break
+elif self.handle_monitor_cancel_reply(msg):
+break
 elif (msg.type == ovs.jsonrpc.Message.T_REPLY
   and self._monitor_request_id is not None
   and self._monitor_request_id == msg.id):
@@ -615,6 +620,33 @@ class Idl(object):
 
 return initial_change_seqno != self.change_seqno
 
+def handle_monitor_canceled(self, msg):
+if msg.type != msg.T_NOTIFY:
+return False
+if msg.method != "monitor_canceled":
+return False
+
+if msg.params[0] == str(self.uuid):
+params = [str(self.server_monitor_uuid)]
+elif msg.params[0] == str(self.server_monitor_uuid):
+params = [str(self.uuid)]
+else:
+return False
+
+mc_msg = ovs.jsonrpc.Message.create_request("monitor_cancel", params)
+self._monitor_cancel_request_id = mc_msg.id
+self.send_request(mc_msg)
+self.restart_fsm()
+return True
+
+def handle_monitor_cancel_reply(self, msg):
+if msg.type != msg.T_REPLY:
+return False
+if msg.id != self._monitor_cancel_request_id:
+return False
+self._monitor_cancel_request_id = None
+return True
+
 def compose_cond_change(self):
 if not self.cond_changed:
 return
-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] python: idl: Handle monitor_canceled

[Terry Wilson]

Currently python-ovs claims to be "db change aware" but does not
parse the "monitor_canceled" notification. Transactions can continue
being made, but the monitor updates will not be sent. Adding a
force_reconnect() upon receiving a "monitor_canceled" notification
resolves this issue.

Signed-off-by: Terry Wilson 
---
 python/ovs/db/idl.py | 4 
 1 file changed, 4 insertions(+)

diff --git a/python/ovs/db/idl.py b/python/ovs/db/idl.py
index 16ece0334..cfd81a1ec 100644
--- a/python/ovs/db/idl.py
+++ b/python/ovs/db/idl.py
@@ -481,6 +481,10 @@ class Idl(object):
 break
 else:
 self.__parse_update(msg.params[1], OVSDB_UPDATE)
+elif (msg.type == ovs.jsonrpc.Message.T_NOTIFY
+and msg.method == "monitor_canceled"):
+self.force_reconnect()
+break
 elif (msg.type == ovs.jsonrpc.Message.T_REPLY
   and self._monitor_request_id is not None
   and self._monitor_request_id == msg.id):
-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [OVN RFC 0/7] OVN IC bugfixes & proposals/questions

[Terry Wilson]

On Tue, Jan 24, 2023 at 8:00 AM Ilya Maximets  wrote:
>
> On 1/24/23 14:12, Vladislav Odintsov wrote:
> > Hi Ilya,
> >
> > could you please take a look on this?
> > Maybe you can advice any direction how to investigate this issue?
> >
> > Thanks in advance.
> >
> > Regards,
> > Vladislav Odintsov
> >
> >> On 24 Nov 2022, at 21:10, Anton Vazhnetsov  wrote:
> >>
> >> Hi, Terry!
> >>
> >> In continuation to our yesterday’s conversation [0], we were able to 
> >> reproduce the issue with KeyError. We found that the problem is not 
> >> connected with ovsdb-server load but it appears when the ovsdb-server 
> >> schema is converted online (it even doesn’t matter whether the real ovs 
> >> schema is changed) while the active connection persists.
> >> Please use next commands to reproduce it:
> >>
> >> # in terminal 1
> >>
> >> ovsdb-tool create ./ovs.db /usr/share/ovn/ovn-nb.ovsschema
> >> ovsdb-server --remote punix://$(pwd)/ovs.sock  
> >> $(pwd)/ovs.db -vconsole:dbg
> >>
> >>
> >> # in terminal 2. run python shell
> >> python3
> >> # setup connection
> >> import ovsdbapp.schema.ovn_northbound.impl_idl as nb_idl
> >> from ovsdbapp.backend.ovs_idl import connection
> >>
> >> remote = "unix:///"
> >>
> >> def get_idl():
> >>"""Connection getter."""
> >>
> >>idl = connection.OvsdbIdl.from_server(remote, "OVN_Northbound",
> >>  leader_only=False)
> >>return nb_idl.OvnNbApiIdlImpl(connection.Connection(idl, 100))
> >>
> >> idl = get_idl()
> >>
> >>
> >> # in terminal 1
> >> ovsdb-client convert unix:$(pwd)/ovs.sock /usr/share/ovn/ovn-nb.ovsschema
> >>
> >> # in terminal 2 python shell:
> >> idl.ls_add("test").execute()
> >>
> >>
> >> We get following traceback:
> >>
> >> Traceback (most recent call last):
> >>  File 
> >> "/usr/lib/python3.6/site-packages/ovsdbapp/backend/ovs_idl/connection.py", 
> >> line 131, in run
> >>txn.results.put(txn.do_commit())
> >>  File 
> >> "/usr/lib/python3.6/site-packages/ovsdbapp/backend/ovs_idl/transaction.py",
> >>  line 143, in do_commit
> >>self.post_commit(txn)
> >>  File 
> >> "/usr/lib/python3.6/site-packages/ovsdbapp/backend/ovs_idl/transaction.py",
> >>  line 73, in post_commit
> >>command.post_commit(txn)
> >>  File 
> >> "/usr/lib/python3.6/site-packages/ovsdbapp/backend/ovs_idl/command.py", 
> >> line 94, in post_commit
> >>row = self.api.tables[self.table_name].rows[real_uuid]
> >>  File "/usr/lib64/python3.6/collections/__init__.py", line 991, in 
> >> __getitem__
> >>raise KeyError(key)
> >> KeyError: UUID('0256afa4-6dd0-4c2c-b6a2-686a360ab331')
> >>
> >> In ovsdb-server debug logs we see that update2 or update3 messages are not 
> >> sent from server in response to client’s transaction, just reply with 
> >> result UUID:
> >> 2022-11-24T17:42:36Z|00306|poll_loop|DBG|wakeup due to [POLLIN] on fd 18 
> >> (///root/ovsdb-problem/ovs.sock<->) at lib/stream-fd.c:157
> >> 2022-11-24T17:42:36Z|00307|jsonrpc|DBG|unix#5: received request, 
> >> method="transact", 
> >> params=["OVN_Northbound",{"uuid-name":"row03ef28d6_93f1_43bc_b07a_eae58d4bd1c5","table":"Logical_Switch","op":"insert","row":{"name”:"test"}}],
> >>  id=5
> >> 2022-11-24T17:42:36Z|00308|jsonrpc|DBG|unix#5: send reply, 
> >> result=[{"uuid":["uuid","4eb7c407-beec-46ca-b816-19f942e57721"]}], id=5
> >>
> >> We checked same with ovn-nbctl running in daemon mode and found that the 
> >> problem is not reproduced (ovsdb-server after database conversion sends 
> >> out update3 message to ovn-nbctl daemon process in response to 
> >> transaction, for example ovs-appctl -t  run ls-add 
> >> test-ls):
>
> If the update3 is not sent, it means that the client doesn't monitor
> this table.  You need to look at monitor requests sent and replied
> to figure out the difference.
>
> Since the database conversion is involved, server will close all
> monitors on schema update and notify all clients that are db_change_aware.
> Clients should re-send monitor requests at this point.  If clients
> are not db_change_aware, server will just disconnect them, so they
> can re-connect and see the new schema and send new monitor requests.
>
> On a quick glance I don't see python idl handling 'monitor_canceled'
> notification.  That is most likely a root cause.  Python IDL claims
> to be db_change_aware, but it doesn't seem to be.
>

Reviving a very old thread, but yes this is definitely the issue. I
just tested and see that we get the monitor_canceled and do not do
anything with it. Parsing it and calling self.force_reconnect() seems
to fix the issue. I can send a patch shortly.

Terry


> Best regards, Ilya Maximets.
>
> >> 2022-11-24T17:54:51Z|00623|jsonrpc|DBG|unix#7: received request, 
> >> method="transact", 
> >> params=["OVN_Northbound",{"uuid-name":"rowcdb152ce_a9af_4761_b965_708ad300fcb7","table":"Logical_Switch","op":"insert","row":{"name":"test-ls"}},{"comment":"ovn-nbctl:
> >>  run ls-add test-ls","op":"comment"}], id=5
> >> 

Re: [grpc-io] gRPC client fallback from load-balancer to round robin DNS endpoint on LB outage

['Terry Wilson' via grpc.io]

Krishna,

I'll mention that we also have a short guide on custom LBs 
 that can help you with 
the fundamentals.

On Monday, November 6, 2023 at 3:53:01 PM UTC-8 Larry Safran wrote:

> Yes, you will need a custom NameResolver.  
> You could have your NameResolver do one of the following
> 1)  Extend DnsNameResolver (as is done by the internal GrpcNameResolver) 
> and override the doResolve method
> 2)  Directly extend NameResolver and have a field with a DnsNameResolver 
> created through the DnsNameResolverProvider (which should be gotten from 
> the registry).  
>
> There is already a load balancer that is switching between 2 child load 
> balancers.  It is experimental and can be specified as 
> "priority_experimental".  What it does is to use a specific attribute that 
> must be set by the NameResolver.  Even if you go with your own load 
> balancer, that would be the best way to differentiate which addresses 
> should be used for which child.  If you want to use it as an example, it is 
> https://github.com/grpc/grpc-java/blob/master/xds/src/main/java/io/grpc/xds/PriorityLoadBalancer.java
>
>
>
> On Mon, Nov 6, 2023 at 1:53 PM Krishna Sai Veera Reddy <
> krishnasaiv...@gmail.com> wrote:
>
>> Hey Larry,
>>
>> Thank you for your response! Are there any examples out in the wild on 
>> how to do this? Also the part that is confusing me is the name resolution. 
>> Do we have to add a custom name resolution policy as well so that we get 
>> both the LB and round robin IP addresses in `acceptResolvedAddresses 
>> `
>>  
>> method in the LB policy?
>>
>> On Friday, November 3, 2023 at 12:50:20 PM UTC-7 Larry Safran wrote:
>>
>>> This is a perfect scenario for a custom LB policy.  Since LB policies 
>>> form a tree, you could easily have your policy delegate to either a 
>>> PickFirst or RoundRobin policy depending on whether or not the LB is up.  
>>> Just have your policy define a ForwardingLoadbalanceHelper whose 
>>> updateBalancingState passes the picker from the oppropriate downstream 
>>> policy.
>>>
>>> On Fri, Nov 3, 2023 at 12:29 PM Krishna Sai Veera Reddy <
>>> krishnasaiv...@gmail.com> wrote:
>>>
 Hello All,

 I am working on a gRPC client that connects to a gRPC service fronted 
 by an LB but would like the client to automatically fallback to using 
 round-robin DNS to directly connect to the backend servers when the LB 
 goes 
 down. How do I go about this? Would I need to implement my own custom LB 
 policy? Any help is appreciated and thanks in advance!

 -- 
 You received this message because you are subscribed to the Google 
 Groups "grpc.io" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to grpc-io+u...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/grpc-io/df8f4a85-5020-4c68-bb94-cbea67d7c75an%40googlegroups.com
  
 
 .

>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "grpc.io" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to grpc-io+u...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/grpc-io/2e7b95aa-cd66-40f5-bf41-0484fa12892cn%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/51db24a6-3faa-4f9e-a979-54a0d5368921n%40googlegroups.com.

[grpc-io] gRPC-Java v1.59.0 Released

['Terry Wilson' via grpc.io]

You can now grab the v1.59.0 
 release.

PLANNED ABI BREAKAGE!

This breaks the ABI of the @ExperimentalApi classes listed below.
This does not impact source code (API); it only impacts code compiled with 
a different version of gRPC than it runs with (ABI).

Users that recompiled their code using grpc-java v1.36.0 
 (released on Feb 
23, 2021) and later, ARE NOT AFFECTED.
Users that compiled their source using grpc-java earlier than v1.36.0 may 
need to recompile when upgrading to grpc-java v1.59.0.

See details in #10406 .

*Affected classes*

Class io.grpc.internal.AbstractManagedChannelImplBuilder is deleted, and no 
longer in the class hierarchy of the channel builders:

io.grpc.netty.NettyChannelBuilder
io.grpc.okhttp.OkhttpChannelBuilder
io.grpc.cronet.CronetChannelBuilder
Class io.grpc.internal.AbstractServerImplBuilder is deleted, and no longer 
in the class hierarchy of the server builders:

io.grpc.netty.NettyServerBuilder
io.grpc.inprocess.InProcessServerBuilder

API Changes
core: AbstractManagedChannelImplBuilder and AbstractServerImplBuilder are 
removed (#10530 ). This is 
ABI-breaking, see the warning above. (#10406 
)
core: Removed .class file hack previously introduced in v1.36.0 
 to ease removal of 
internal ABIs. (#10406 )
api: Add ForwardingChannelBuilder2, an ABI-safe version of 
ForwardingChannelBuilder, which will be deprecated in the following 
release. (#10585 , #10406 
)
api: Add LoadBalancer.FixedResultPicker convenience class for load balancer 
implementations. It is a replacement for ErrorPicker and EMPTY_PICKER added 
in 1.58.0
testing: Stabilize TestMethodDescriptors (#10530 
)

Behavior Changes
core: de-expermentalize pick first config parsing (#10531 
)
netty: Respect -Dio.netty.allocator.type=unpooled when getting Netty 
Allocator instead of ignoring it (#10543 
)
netty: Use UNAVAILABLE for connections closed while writing. Previously 
this would result in UNKNOWN
binder: Enable indirect addressing using s. (#10550 
)

Improvements
core: only use reflection to resolve InternalCensusStatsAccessor once 
instead of once per channel
core: enhance error message in the case of DEADLINE_EXCEEDED to indicate 
name resolution delay.
netty: When creating a connection, use java.util.logging formatting instead 
of String.format to avoid work when not logged
netty: Touch ByteBuf when message framing has been decoded. If the buffer 
is leaked, this helps narrow down the source of reference counting bug
java_grpc_library.bzl: Disable Automatic Exec Groups inside grpc libraries (
#10514 ). This improves 
compatibility with future Bazel versions while retaining Bazel 5.x 
compatibility

Bug Fixes
netty: Avoid NettyAdaptiveCumulator incorrectly releasing its input ByteBuf 
twice when reading messages under certain error conditions (#10537 
)
xds: Add fix for xdstp replacement for percent-encoded authorities (#10571 
)

Documentation
API documentation (Javadoc) for Server and Channel builders now correctly 
displays inherited methods and the class hierarchy. (#10406 
)
examples: add an example for OAuth (#10560 
)

Dependencies
Upgrade Netty to 4.1.97.Final

Acknowledgements
John Cormie (@jdcormie)
Stephane Landelle (@slandelle)
@kotlaja

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/64bd646c-5167-4201-9118-b18a8d5bd50dn%40googlegroups.com.

[grpc-io] Re: StreamObservers in multi-thread Java application

['Terry Wilson' via grpc.io]

Yes, you should not have two threads calling onNext() on the same 
StreamObserver. If you do, you can get messages interleaved with each other 
and most likely just produce garbage. 

You need to make sure that your application acquires a lock before calling 
any of the methods on StreamObserver. Note that you CAN concurrently call 
the separate StreamObserver instances you have for incoming an outgoing 
messages. 

On Wednesday, September 6, 2023 at 9:41:25 PM UTC-7 Quyen Pham Ngoc wrote:

> I use grpc in Java multithread application. The documentation says: "Since 
> individual StreamObservers are not thread-safe, if multiple threads will be 
> writing to a StreamObserver concurrently, the application must synchronize 
> calls." 
>
> Is it true that with every onNext request of each StreamObservers I have 
> to be thread-safe? What do I do when using StreamObserver in a multi-thread 
> application environment? What happens if thread-safety is not guaranteed?
>
> Sincerely thank you for your help
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/8129bb36-f694-4002-a224-a468dde883c7n%40googlegroups.com.

[grpc-io] 1 Week Until gRPConf 2023 - Almost Sold Out!

['Terry Wilson' via grpc.io]

Hello gRPC Community!

We are one week away from gRPConf 2023 and tickets are close to selling 
out. If you haven’t had a chance to register yet, please do so soon. 
Tickets are still available for only $99.

We’re also excited to share that we have added a limited number of “Meet a 
Maintainer” Sessions. These sessions are a chance to do an 1on1 meeting 
with one of the maintainers of gRPC in place of watching one of the gRPConf 
talks. You can sign up by completing this form. 
<https://forms.gle/rtyGHeBDVZRmc8zw5>

All the details are below. We’re looking forward to seeing everyone on 
September 20th!

️Register Here 
<https://events.linuxfoundation.org/grpc-conf/register/#grpc-conf-rates> 

️September 20, 2023

Google Cloud Campus - Sunnyvale, CA

⏰Doors open at 8:30AM

藺Meet a Maintainer <https://forms.gle/rtyGHeBDVZRmc8zw5>

View the Schedule 
<https://events.linuxfoundation.org/grpc-conf/program/schedule/>


Thank you,

Terry Wilson and the gRPC Team

gRPConf 2023 Sunnyvale, CA | Register Now <https://youtu.be/pvI9S1O3Mk0>


-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/e3aea7ae-c6d1-4caf-8815-e82f3a0a5194n%40googlegroups.com.

[grpc-io] Last Call: gRPConf 2023 Early Bird Registration Ends Today 

['Terry Wilson' via grpc.io]

Hello gRPC Community!


Today is the last day to take advantage of $50 Early Bird Registration for 
gRPConf 2023. Sign up today and join us for a full day of gRPC talks and 
discussion. Below are all the details you need to know!


✅Register Here 
<https://events.linuxfoundation.org/grpc-conf/register/#grpc-conf-rates>

️September 20, 2023

Google Cloud Campus - Sunnyvale, CA

⏰Doors open at 8:30AM

View the Schedule 
<https://events.linuxfoundation.org/grpc-conf/program/schedule/>


We are only two weeks away from the event and pricing will increase to $99 
starting tomorrow.


Thank you,

Terry Wilson and the gRPC Team

gRPConf 2023 Sunnyvale, CA | Register Now <https://youtu.be/pvI9S1O3Mk0>


-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/25540447-c3dd-4b6d-b4bc-db62aa86eb67n%40googlegroups.com.

[Yahoo-eng-team] [Bug 2033932] [NEW] Add support for OVN MAC_Binding aging

[Terry Wilson]

Public bug reported:

VN added support for aging out MAC_Binding entries [1][2]. Without this
feature, the MAC_Bindings table can grow indefinitely.

[1] 
https://github.com/ovn-org/ovn/commit/1a947dd3073628d2f2655f46ee7d3db62ed15b55
[2] 
https://github.com/ovn-org/ovn/commit/cecac71c0e49f9bfb6595bc03a13f3f7644dd268

** Affects: neutron
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2033932

Title:
  Add support for OVN MAC_Binding aging

Status in neutron:
  New

Bug description:
  VN added support for aging out MAC_Binding entries [1][2]. Without
  this feature, the MAC_Bindings table can grow indefinitely.

  [1] 
https://github.com/ovn-org/ovn/commit/1a947dd3073628d2f2655f46ee7d3db62ed15b55
  [2] 
https://github.com/ovn-org/ovn/commit/cecac71c0e49f9bfb6595bc03a13f3f7644dd268

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2033932/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

Re: [ovs-discuss] ovs pypi package

[Terry Wilson via discuss]

On Wed, Jul 26, 2023 at 8:51 AM Terry Wilson  wrote:
>
> On Fri, Jul 21, 2023 at 3:45 AM Ilya Maximets  wrote:
> >
> > On 7/19/23 09:52, Felix Huettner via discuss wrote:
> > > Hi everyone,
> > >
> > > i noticed that the latest release of the ovs library on pypi is for
> > > 2.17.1 [1]. Would it be possible to pushlish newer versions of the ovs
> > > python lib there as well, or are there reasons speaking against that?
> >
> > The pypi package is maintained by OpenStack folks mostly
> > for their own use.  But, I guess, it should be possible
> > to update to some newer stable release.
> >
> > Terry, what do you think?
> >
> > Best regards, Ilya Maximets.
> >
> > >
> > > [1] https://pypi.org/project/ovs/#history
> > >
> > > Thanks
> > > Felix
>
> I'll go ahead and make a release today. It would be worth discussing
> having ownership of the pypi ovs package include people responsible
> for OVS releases and making releasing there part of the release
> process. One could argue that me owning the package upstream is a
> little...weird. :)
>
> Terry

There are now releases for 2.17.7, 3.0.4, and 3.1.2. rjarry has some
patches coming to update the automake stuff for `make python-sdist`
and `make pypi-upload` to use build/twine instead of setup.py to make
it easy for the release manager to add updating pypi to the normal
release process.

Terry

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovs pypi package

[Terry Wilson via discuss]

On Fri, Jul 21, 2023 at 3:45 AM Ilya Maximets  wrote:
>
> On 7/19/23 09:52, Felix Huettner via discuss wrote:
> > Hi everyone,
> >
> > i noticed that the latest release of the ovs library on pypi is for
> > 2.17.1 [1]. Would it be possible to pushlish newer versions of the ovs
> > python lib there as well, or are there reasons speaking against that?
>
> The pypi package is maintained by OpenStack folks mostly
> for their own use.  But, I guess, it should be possible
> to update to some newer stable release.
>
> Terry, what do you think?
>
> Best regards, Ilya Maximets.
>
> >
> > [1] https://pypi.org/project/ovs/#history
> >
> > Thanks
> > Felix

I'll go ahead and make a release today. It would be worth discussing
having ownership of the pypi ovs package include people responsible
for OVS releases and making releasing there part of the release
process. One could argue that me owning the package upstream is a
little...weird. :)

Terry

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-dev] [PATCH v5] python: Add async DNS support

[Terry Wilson]

This adds a Python version of the async DNS support added in:

771680d96 DNS: Add basic support for asynchronous DNS resolving

The above version uses the unbound C library, and this
implimentation uses the SWIG-wrapped Python version of that.

In the event that the Python unbound library is not available,
a warning will be logged and the resolve() method will just
return None. For the case where inet_parse_active() is passed
an IP address, it will not try to resolve it, so existing
behavior should be preserved in the case that the unbound
library is unavailable.

Intentional differences from the C version are as follows:

  OVS_HOSTS_FILE environment variable can bet set to override
  the system 'hosts' file. This is primarily to allow testing to
  be done without requiring network connectivity.

  Since resolution can still be done via hosts file lookup, DNS
  lookups are not disabled when resolv.conf cannot be loaded.

  The Python socket_util module has fallen behind its C equivalent.
  The bare minimum change was done to inet_parse_active() to support
  sync/async dns, as there is no equivalent to
  parse_sockaddr_components(), inet_parse_passive(), etc. A TODO
  was added to bring socket_util.py up to equivalency to the C
  version.

Signed-off-by: Terry Wilson 
---
 .github/workflows/build-and-test.yml|   4 +-
 Documentation/intro/install/general.rst |   4 +-
 Documentation/intro/install/rhel.rst|   2 +-
 Documentation/intro/install/windows.rst |   2 +-
 NEWS|   3 +
 debian/control.in   |   1 +
 m4/openvswitch.m4   |   8 +-
 python/TODO.rst |   7 +
 python/automake.mk  |   2 +
 python/ovs/dns_resolve.py   | 286 
 python/ovs/socket_util.py   |  21 +-
 python/ovs/stream.py|   2 +-
 python/ovs/tests/test_dns_resolve.py| 280 +++
 python/setup.py |   6 +-
 rhel/openvswitch-fedora.spec.in |   2 +-
 tests/vlog.at   |   2 +
 16 files changed, 615 insertions(+), 17 deletions(-)
 create mode 100644 python/ovs/dns_resolve.py
 create mode 100644 python/ovs/tests/test_dns_resolve.py

diff --git a/.github/workflows/build-and-test.yml 
b/.github/workflows/build-and-test.yml
index f66ab43b0..47d239f10 100644
--- a/.github/workflows/build-and-test.yml
+++ b/.github/workflows/build-and-test.yml
@@ -183,10 +183,10 @@ jobs:
   run:  sudo apt update || true
 - name: install common dependencies
   run:  sudo apt install -y ${{ env.dependencies }}
-- name: install libunbound libunwind
+- name: install libunbound libunwind python3-unbound
   # GitHub Actions doesn't have 32-bit versions of these libraries.
   if:   matrix.m32 == ''
-  run:  sudo apt install -y libunbound-dev libunwind-dev
+  run:  sudo apt install -y libunbound-dev libunwind-dev python3-unbound
 - name: install 32-bit libraries
   if:   matrix.m32 != ''
   run:  sudo apt install -y gcc-multilib
diff --git a/Documentation/intro/install/general.rst 
b/Documentation/intro/install/general.rst
index 42b5682fd..19e360d47 100644
--- a/Documentation/intro/install/general.rst
+++ b/Documentation/intro/install/general.rst
@@ -90,7 +90,7 @@ need the following software:
   If libcap-ng is installed, then Open vSwitch will automatically build with
   support for it.
 
-- Python 3.4 or later.
+- Python 3.6 or later.
 
 - Unbound library, from http://www.unbound.net, is optional but recommended if
   you want to enable ovs-vswitchd and other utilities to use DNS names when
@@ -208,7 +208,7 @@ simply install and run Open vSwitch you require the 
following software:
   from iproute2 (part of all major distributions and available at
   https://wiki.linuxfoundation.org/networking/iproute2).
 
-- Python 3.4 or later.
+- Python 3.6 or later.
 
 On Linux you should ensure that ``/dev/urandom`` exists. To support TAP
 devices, you must also ensure that ``/dev/net/tun`` exists.
diff --git a/Documentation/intro/install/rhel.rst 
b/Documentation/intro/install/rhel.rst
index d1fc42021..f2151d890 100644
--- a/Documentation/intro/install/rhel.rst
+++ b/Documentation/intro/install/rhel.rst
@@ -92,7 +92,7 @@ Once that is completed, remove the file ``/tmp/ovs.spec``.
 If python3-sphinx package is not available in your version of RHEL, you can
 install it via pip with 'pip install sphinx'.
 
-Open vSwitch requires python 3.4 or newer which is not available in older
+Open vSwitch requires python 3.6 or newer which is not available in older
 distributions. In the case of RHEL 6.x and its derivatives, one option is
 to install python34 from `EPEL`_.
 
diff --git a/Documentation/intro/install/windows.rst 
b/Documentation/intro/install/windows.rst
index 78f60f35a..fce099d5d 100644
--- a/Documentation/intro/install/windows.rst
+++ b/Documentation/intro/install/windows.rst

[ovs-dev] [PATCH v4] python: Add async DNS support

[Terry Wilson]

This adds a Python version of the async DNS support added in:

771680d96 DNS: Add basic support for asynchronous DNS resolving

The above version uses the unbound C library, and this
implimentation uses the SWIG-wrapped Python version of that.

In the event that the Python unbound library is not available,
a warning will be logged and the resolve() method will just
return None. For the case where inet_parse_active() is passed
an IP address, it will not try to resolve it, so existing
behavior should be preserved in the case that the unbound
library is unavailable.

Intentional differences from the C version are as follows:

  OVS_HOSTS_FILE environment variable can bet set to override
  the system 'hosts' file. This is primarily to allow testing to
  be done without requiring network connectivity.

  Since resolution can still be done via hosts file lookup, DNS
  lookups are not disabled when resolv.conf cannot be loaded.

  The Python socket_util module has fallen behind its C equivalent.
  The bare minimum change was done to inet_parse_active() to support
  sync/async dns, as there is no equivalent to
  parse_sockaddr_components(), inet_parse_passive(), etc. A TODO
  was added to bring socket_util.py up to equivalency to the C
  version.

Signed-off-by: Terry Wilson 
---
 .github/workflows/build-and-test.yml|   4 +-
 Documentation/intro/install/general.rst |   4 +-
 Documentation/intro/install/rhel.rst|   2 +-
 Documentation/intro/install/windows.rst |   2 +-
 NEWS|   3 +
 debian/control.in   |   1 +
 m4/openvswitch.m4   |   8 +-
 python/TODO.rst |   7 +
 python/automake.mk  |   2 +
 python/ovs/dns_resolve.py   | 286 
 python/ovs/socket_util.py   |  21 +-
 python/ovs/stream.py|   2 +-
 python/ovs/tests/test_dns_resolve.py| 280 +++
 python/setup.py |   6 +-
 rhel/openvswitch-fedora.spec.in |   2 +-
 tests/vlog.at   |   2 +
 16 files changed, 615 insertions(+), 17 deletions(-)
 create mode 100644 python/ovs/dns_resolve.py
 create mode 100644 python/ovs/tests/test_dns_resolve.py

diff --git a/.github/workflows/build-and-test.yml 
b/.github/workflows/build-and-test.yml
index f66ab43b0..47d239f10 100644
--- a/.github/workflows/build-and-test.yml
+++ b/.github/workflows/build-and-test.yml
@@ -183,10 +183,10 @@ jobs:
   run:  sudo apt update || true
 - name: install common dependencies
   run:  sudo apt install -y ${{ env.dependencies }}
-- name: install libunbound libunwind
+- name: install libunbound libunwind python3-unbound
   # GitHub Actions doesn't have 32-bit versions of these libraries.
   if:   matrix.m32 == ''
-  run:  sudo apt install -y libunbound-dev libunwind-dev
+  run:  sudo apt install -y libunbound-dev libunwind-dev python3-unbound
 - name: install 32-bit libraries
   if:   matrix.m32 != ''
   run:  sudo apt install -y gcc-multilib
diff --git a/Documentation/intro/install/general.rst 
b/Documentation/intro/install/general.rst
index 42b5682fd..19e360d47 100644
--- a/Documentation/intro/install/general.rst
+++ b/Documentation/intro/install/general.rst
@@ -90,7 +90,7 @@ need the following software:
   If libcap-ng is installed, then Open vSwitch will automatically build with
   support for it.
 
-- Python 3.4 or later.
+- Python 3.6 or later.
 
 - Unbound library, from http://www.unbound.net, is optional but recommended if
   you want to enable ovs-vswitchd and other utilities to use DNS names when
@@ -208,7 +208,7 @@ simply install and run Open vSwitch you require the 
following software:
   from iproute2 (part of all major distributions and available at
   https://wiki.linuxfoundation.org/networking/iproute2).
 
-- Python 3.4 or later.
+- Python 3.6 or later.
 
 On Linux you should ensure that ``/dev/urandom`` exists. To support TAP
 devices, you must also ensure that ``/dev/net/tun`` exists.
diff --git a/Documentation/intro/install/rhel.rst 
b/Documentation/intro/install/rhel.rst
index d1fc42021..f2151d890 100644
--- a/Documentation/intro/install/rhel.rst
+++ b/Documentation/intro/install/rhel.rst
@@ -92,7 +92,7 @@ Once that is completed, remove the file ``/tmp/ovs.spec``.
 If python3-sphinx package is not available in your version of RHEL, you can
 install it via pip with 'pip install sphinx'.
 
-Open vSwitch requires python 3.4 or newer which is not available in older
+Open vSwitch requires python 3.6 or newer which is not available in older
 distributions. In the case of RHEL 6.x and its derivatives, one option is
 to install python34 from `EPEL`_.
 
diff --git a/Documentation/intro/install/windows.rst 
b/Documentation/intro/install/windows.rst
index 78f60f35a..fce099d5d 100644
--- a/Documentation/intro/install/windows.rst
+++ b/Documentation/intro/install/windows.rst

Re: [ovs-dev] [PATCH v3] python: Add async DNS support

[Terry Wilson]

On Mon, Jul 10, 2023 at 10:32 AM Terry Wilson  wrote:
>
> I accidentally forgot to click reply-to-all.
>
> On Fri, Jun 30, 2023 at 10:27 AM Ilya Maximets  wrote:
> >
> > On 6/30/23 16:54, Adrian Moreno wrote:
> > >
> > >
> > > On 6/30/23 14:35, Ilya Maximets wrote:
> > >> On 6/30/23 14:23, Adrian Moreno wrote:
> > >>>
> > >>>
> > >>> On 6/30/23 13:40, Ilya Maximets wrote:
> > >>>> On 6/30/23 12:39, Adrian Moreno wrote:
> > >>>>>
> > >>>>>
> > >>>>> On 6/14/23 23:07, Terry Wilson wrote:
> > >>>>>> This adds a Python version of the async DNS support added in:
> > >>>>>>
> > >>>>>> 771680d96 DNS: Add basic support for asynchronous DNS resolving
> > >>>>>>
> > >>>>>> The above version uses the unbound C library, and this
> > >>>>>> implimentation uses the SWIG-wrapped Python version of that.
> > >>>>>>
> > >>>>>> In the event that the Python unbound library is not available,
> > >>>>>> a warning will be logged and the resolve() method will just
> > >>>>>> return None. For the case where inet_parse_active() is passed
> > >>>>>> an IP address, it will not try to resolve it, so existing
> > >>>>>> behavior should be preserved in the case that the unbound
> > >>>>>> library is unavailable.
> > >>>>>>
> > >>>>>> Intentional differences from the C version are as follows:
> > >>>>>>
> > >>>>>>  OVS_HOSTS_FILE environment variable can bet set to override
> > >>>>>>  the system 'hosts' file. This is primarily to allow testing to
> > >>>>>>  be done without requiring network connectivity.
> > >>>>>>
> > >>>>>>  Since resolution can still be done via hosts file lookup, DNS
> > >>>>>>  lookups are not disabled when resolv.conf cannot be loaded.
> > >>>>>>
> > >>>>>>  The Python socket_util module has fallen behind its C 
> > >>>>>> equivalent.
> > >>>>>>  The bare minimum change was done to inet_parse_active() to 
> > >>>>>> support
> > >>>>>>  sync/async dns, as there is no equivalent to
> > >>>>>>  parse_sockaddr_components(), inet_parse_passive(), etc. A TODO
> > >>>>>>  was added to bring socket_util.py up to equivalency to the C
> > >>>>>>  version.
> > >>>>>>
> > >>>>>> Signed-off-by: Terry Wilson 
> > >>>>>> ---
> > >>>>>> .github/workflows/build-and-test.yml|   4 +-
> > >>>>>> Documentation/intro/install/general.rst |   4 +-
> > >>>>>> Documentation/intro/install/rhel.rst|   2 +-
> > >>>>>> Documentation/intro/install/windows.rst |   2 +-
> > >>>>>> NEWS|   4 +-
> > >>>>>> debian/control.in   |   1 +
> > >>>>>> m4/openvswitch.m4   |   8 +-
> > >>>>>> python/TODO.rst |   7 +
> > >>>>>> python/automake.mk  |   2 +
> > >>>>>> python/ovs/dns_resolve.py   | 272 
> > >>>>>> +++
> > >>>>>> python/ovs/socket_util.py   |  21 +-
> > >>>>>> python/ovs/stream.py|   2 +-
> > >>>>>> python/ovs/tests/test_dns_resolve.py| 280 
> > >>>>>> 
> > >>>>>> python/setup.py |   6 +-
> > >>>>>> rhel/openvswitch-fedora.spec.in |   2 +-
> > >>>>>> tests/vlog.at   |   2 +
> > >>>>>> 16 files changed, 601 insertions(+), 18 deletions(-)
> > >>>>>> create mode 100644 python/ovs/dns_resolve.py
> > >>>>>> create mode 100644 python/ovs/tests/test_dns_resolve.py
> > &

Re: [ovs-dev] [PATCH v3] python: Add async DNS support

[Terry Wilson]

I accidentally forgot to click reply-to-all.

On Fri, Jun 30, 2023 at 10:27 AM Ilya Maximets  wrote:
>
> On 6/30/23 16:54, Adrian Moreno wrote:
> >
> >
> > On 6/30/23 14:35, Ilya Maximets wrote:
> >> On 6/30/23 14:23, Adrian Moreno wrote:
> >>>
> >>>
> >>> On 6/30/23 13:40, Ilya Maximets wrote:
> >>>> On 6/30/23 12:39, Adrian Moreno wrote:
> >>>>>
> >>>>>
> >>>>> On 6/14/23 23:07, Terry Wilson wrote:
> >>>>>> This adds a Python version of the async DNS support added in:
> >>>>>>
> >>>>>> 771680d96 DNS: Add basic support for asynchronous DNS resolving
> >>>>>>
> >>>>>> The above version uses the unbound C library, and this
> >>>>>> implimentation uses the SWIG-wrapped Python version of that.
> >>>>>>
> >>>>>> In the event that the Python unbound library is not available,
> >>>>>> a warning will be logged and the resolve() method will just
> >>>>>> return None. For the case where inet_parse_active() is passed
> >>>>>> an IP address, it will not try to resolve it, so existing
> >>>>>> behavior should be preserved in the case that the unbound
> >>>>>> library is unavailable.
> >>>>>>
> >>>>>> Intentional differences from the C version are as follows:
> >>>>>>
> >>>>>>  OVS_HOSTS_FILE environment variable can bet set to override
> >>>>>>  the system 'hosts' file. This is primarily to allow testing to
> >>>>>>  be done without requiring network connectivity.
> >>>>>>
> >>>>>>  Since resolution can still be done via hosts file lookup, DNS
> >>>>>>  lookups are not disabled when resolv.conf cannot be loaded.
> >>>>>>
> >>>>>>  The Python socket_util module has fallen behind its C equivalent.
> >>>>>>  The bare minimum change was done to inet_parse_active() to support
> >>>>>>  sync/async dns, as there is no equivalent to
> >>>>>>  parse_sockaddr_components(), inet_parse_passive(), etc. A TODO
> >>>>>>  was added to bring socket_util.py up to equivalency to the C
> >>>>>>  version.
> >>>>>>
> >>>>>> Signed-off-by: Terry Wilson 
> >>>>>> ---
> >>>>>> .github/workflows/build-and-test.yml|   4 +-
> >>>>>> Documentation/intro/install/general.rst |   4 +-
> >>>>>> Documentation/intro/install/rhel.rst|   2 +-
> >>>>>> Documentation/intro/install/windows.rst |   2 +-
> >>>>>> NEWS|   4 +-
> >>>>>> debian/control.in   |   1 +
> >>>>>> m4/openvswitch.m4   |   8 +-
> >>>>>> python/TODO.rst |   7 +
> >>>>>> python/automake.mk  |   2 +
> >>>>>> python/ovs/dns_resolve.py   | 272 
> >>>>>> +++
> >>>>>> python/ovs/socket_util.py   |  21 +-
> >>>>>> python/ovs/stream.py|   2 +-
> >>>>>> python/ovs/tests/test_dns_resolve.py| 280 
> >>>>>> 
> >>>>>> python/setup.py |   6 +-
> >>>>>> rhel/openvswitch-fedora.spec.in |   2 +-
> >>>>>> tests/vlog.at   |   2 +
> >>>>>> 16 files changed, 601 insertions(+), 18 deletions(-)
> >>>>>> create mode 100644 python/ovs/dns_resolve.py
> >>>>>> create mode 100644 python/ovs/tests/test_dns_resolve.py
> >>>>>>
> >>>>>> diff --git a/.github/workflows/build-and-test.yml 
> >>>>>> b/.github/workflows/build-and-test.yml
> >>>>>> index f66ab43b0..47d239f10 100644
> >>>>>> --- a/.github/workflows/build-and-test.yml
> >>>>>> +++ b/.github/workflows/build-and-test.yml
> >>>>>> @@ -183,10 +183,10 @@ jobs:
> >>>>>>   ru

[grpc-io] [Last Call] Come Speak at gRPConf 2023!

['Terry Wilson' via grpc.io]

Hello gRPC Community!


This is the last call to get your proposals in to speak at gRPConf 2023. 
The deadline is July 9th (this Sunday).


Submit your proposals and find more information and tips HERE 
!


Those not interested in speaking are invited to register now 
 for just $50. 


We hope to see you all there.


Thank you,

The gRPC team



-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/3f63a155-1c62-4b3d-bdbc-f27666073f63n%40googlegroups.com.

[grpc-io] 5 Days Left to Submit at Talk for gRPConf 2023

['Terry Wilson' via grpc.io]

Hello gRPC Community!


Time is running out to submit a proposal to speak at gRPConf 2023. The 
deadline is July 9th (this Sunday).


Submit your proposals and find more information HERE 
!

Spots are still available and topics might include:

   - 
   
   gRPC in-production
   - 
   
   User Stories + Case Studies
   - 
   
   Implementation
   - 
   
   Ecosystem + Tooling
   - 
   
   Codelabs
   
Those not interested in speaking can register now 
 for just $50. 


We hope to see you all there!


Thank you,

The gRPC team

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/8dd065f0-0ea0-4baf-ab2b-5ab922880344n%40googlegroups.com.

Re: [ovs-discuss] Scaling OVN/Southbound

[Terry Wilson via discuss]

On Wed, Jul 5, 2023 at 9:59 AM Terry Wilson  wrote:
>
> On Fri, Jun 30, 2023 at 7:09 PM Han Zhou via discuss
>  wrote:
> >
> >
> >
> > On Wed, May 24, 2023 at 12:26 AM Felix Huettner via discuss 
> >  wrote:
> > >
> > > Hi Ilya,
> > >
> > > thank you for the detailed reply
> > >
> > > On Tue, May 23, 2023 at 05:25:49PM +0200, Ilya Maximets wrote:
> > > > On 5/23/23 15:59, Felix Hüttner via discuss wrote:
> > > > > Hi everyone,
> > > >
> > > > Hi, Felix.
> > > >
> > > > >
> > > > > we are currently running an OVN Deployment with 450 Nodes. We run a 3 
> > > > > node cluster for the northbound database and a 3 nodes cluster for 
> > > > > the southbound database.
> > > > > Between the southbound cluster and the ovn-controllers we have a 
> > > > > layer of 24 ovsdb relays.
> > > > > The setup is using TLS for all connections, however the TLS Server is 
> > > > > handled by a traefik reverseproxy to offload this from the ovsdb
> > > >
> > > > The very important part of the system description is what versions
> > > > of OVS and OVN are you using in this setup?  If it's not latest
> > > > 3.1 and 23.03, then it's hard to talk about what/if performance
> > > > improvements are actually needed.
> > > >
> > >
> > > We are currently running ovs 3.1 and ovn 22.12 (in the process of
> > > upgrading to 23.03). `monitor-all` is currently disabled, but we want to
> > > try that as well.
> > >
> > Hi Felix, did you try upgrading and enabling "monitor-all"? How does it 
> > look now?
> >
> > > > > Northd and Neutron is connecting directly to north- and southbound 
> > > > > databases without the relays.
> > > >
> > > > One of the big things that is annoying is that Neutron connects to
> > > > Southbound database at all.  There are some reasons to do that,
> > > > but ideally that should be avoided.  I know that in the past limiting
> > > > the number of metadata agents was one of the mitigation strategies
> > > > for scaling issues.  Also, why can't it connect to relays?  There
> > > > shouldn't be too many transactions flowing towards Southbound DB
> > > > from the Neutron.
> > > >
> > >
> > > Thanks for that suggestion, that definately makes sense.
> > >
> > Does this make a big difference? How many Neutron - SB connections are 
> > there?
> > What rings a bell is that Neutron is using the python OVSDB library which 
> > hasn't implemented the fast-resync feature (if I remember correctly).
>
> python-ovs has supported monitor_cond_since since v2.17.0 (though
> there may have been a bug that was fixed in 2.17.1). If fast resync
> isn't happening, then it should be considered a bug. With that said, I
> remember when I looked it a year or two ago, ovsdb-server didn't
> really use fast resync/monitor_cond_since unless it was running in
> raft cluster mode (it would reply, but with the last-txn-id as 0
> IIRC?). Does the ovsdb-relay code actually return the last-txn-id? I
> can set up an environment and run some tests, but maybe someone else
> already knows.

Looks like ovsdb-relay does support last-txn-id now:
https://github.com/openvswitch/ovs/commit/a3e97b1af1bdcaa802c6caa9e73087df7077d2b1,
but only in v3.0+.

> > At the same time, there is the feature leader-transfer-for-snapshot, which 
> > automatically transfer leader whenever a snapshot is to be written, which 
> > would happen frequently if your environment is very active.
>
> I believe snapshot should only be happening "no less frequently than
> 24 hours, with snapshots if there are more than 100 log entries and
> the log size has doubled, but no more frequently than every 10 mins"
> or something pretty close to that. So it seems like once the system
> got up to its expected size, you would just see updates every 24 hours
> since you obviously can't double in size forever. But it's possible
> I'm reading that wrong.
>
> > When a leader transfer happens, if Neutron set the option "leader-only" 
> > (only connects to leader) to SB DB (could someone confirm?), then when the 
> > leader transfer happens, all Neutron workers would reconnect to the new 
> > leader. With fast-resync, like what's implemented in C IDL and Go, the 
> > client that has cached the data would only request the delta when 
> > reconnecting. But since the python lib do

Re: [ovs-discuss] Scaling OVN/Southbound

[Terry Wilson via discuss]

On Fri, Jun 30, 2023 at 7:09 PM Han Zhou via discuss
 wrote:
>
>
>
> On Wed, May 24, 2023 at 12:26 AM Felix Huettner via discuss 
>  wrote:
> >
> > Hi Ilya,
> >
> > thank you for the detailed reply
> >
> > On Tue, May 23, 2023 at 05:25:49PM +0200, Ilya Maximets wrote:
> > > On 5/23/23 15:59, Felix Hüttner via discuss wrote:
> > > > Hi everyone,
> > >
> > > Hi, Felix.
> > >
> > > >
> > > > we are currently running an OVN Deployment with 450 Nodes. We run a 3 
> > > > node cluster for the northbound database and a 3 nodes cluster for the 
> > > > southbound database.
> > > > Between the southbound cluster and the ovn-controllers we have a layer 
> > > > of 24 ovsdb relays.
> > > > The setup is using TLS for all connections, however the TLS Server is 
> > > > handled by a traefik reverseproxy to offload this from the ovsdb
> > >
> > > The very important part of the system description is what versions
> > > of OVS and OVN are you using in this setup?  If it's not latest
> > > 3.1 and 23.03, then it's hard to talk about what/if performance
> > > improvements are actually needed.
> > >
> >
> > We are currently running ovs 3.1 and ovn 22.12 (in the process of
> > upgrading to 23.03). `monitor-all` is currently disabled, but we want to
> > try that as well.
> >
> Hi Felix, did you try upgrading and enabling "monitor-all"? How does it look 
> now?
>
> > > > Northd and Neutron is connecting directly to north- and southbound 
> > > > databases without the relays.
> > >
> > > One of the big things that is annoying is that Neutron connects to
> > > Southbound database at all.  There are some reasons to do that,
> > > but ideally that should be avoided.  I know that in the past limiting
> > > the number of metadata agents was one of the mitigation strategies
> > > for scaling issues.  Also, why can't it connect to relays?  There
> > > shouldn't be too many transactions flowing towards Southbound DB
> > > from the Neutron.
> > >
> >
> > Thanks for that suggestion, that definately makes sense.
> >
> Does this make a big difference? How many Neutron - SB connections are there?
> What rings a bell is that Neutron is using the python OVSDB library which 
> hasn't implemented the fast-resync feature (if I remember correctly).

python-ovs has supported monitor_cond_since since v2.17.0 (though
there may have been a bug that was fixed in 2.17.1). If fast resync
isn't happening, then it should be considered a bug. With that said, I
remember when I looked it a year or two ago, ovsdb-server didn't
really use fast resync/monitor_cond_since unless it was running in
raft cluster mode (it would reply, but with the last-txn-id as 0
IIRC?). Does the ovsdb-relay code actually return the last-txn-id? I
can set up an environment and run some tests, but maybe someone else
already knows.

> At the same time, there is the feature leader-transfer-for-snapshot, which 
> automatically transfer leader whenever a snapshot is to be written, which 
> would happen frequently if your environment is very active.

I believe snapshot should only be happening "no less frequently than
24 hours, with snapshots if there are more than 100 log entries and
the log size has doubled, but no more frequently than every 10 mins"
or something pretty close to that. So it seems like once the system
got up to its expected size, you would just see updates every 24 hours
since you obviously can't double in size forever. But it's possible
I'm reading that wrong.

> When a leader transfer happens, if Neutron set the option "leader-only" (only 
> connects to leader) to SB DB (could someone confirm?), then when the leader 
> transfer happens, all Neutron workers would reconnect to the new leader. With 
> fast-resync, like what's implemented in C IDL and Go, the client that has 
> cached the data would only request the delta when reconnecting. But since the 
> python lib doesn't have this, the Neutron server would re-download full data 
> when reconnecting ...
> This is a speculation based on the information I have, and the assumptions 
> need to be confirmed.
>
> > > >
> > > > We needed to increase various timeouts on the ovsdb-server and client 
> > > > side to get this to a mostly stable state:
> > > > * inactivity probes of 60 seconds (for all connections between 
> > > > ovsdb-server, relay and clients)
> > > > * cluster election time of 50 seconds
> > > >
> > > > As long as none of the relays restarts the environment is quite stable.
> > > > However we see quite regularly the "Unreasonably long xxx ms poll 
> > > > interval" messages ranging from 1000ms up to 4ms.
> > >
> > > With latest versions of OVS/OVN the CPU usage on Southbound DB
> > > servers without relays in our weekly 500-node ovn-heater runs
> > > stays below 10% during the test phase.  No large poll intervals
> > > are getting registered.
> > >
> > > Do you have more details on under which circumstances these
> > > large poll intervals occur?
> > >
> >
> > It seems to mostly happen on the initial 

Re: [ovs-dev] Scale testing OVN with ovn-heater for OpenStack use cases

[Terry Wilson]

On Fri, Jun 30, 2023 at 2:26 AM Frode Nordahl
 wrote:
>
> Hello all,
>
> On Tue, May 30, 2023 at 5:16 PM Felix Huettner
>  wrote:
> >
> > Hi Dumitru,
> >
> > On Fri, May 26, 2023 at 01:30:54PM +0200, Dumitru Ceara wrote:
> > > On 5/24/23 09:37, Felix Huettner wrote:
> > > > Hi everyone,
> > >
> > > Hi Felix,
> > >
> > > >
> > > > Ilya mentioned to me that you will want to bring openstack examples to
> > > > ovn-heater.
> > > >
> > >
> > > Yes, we're discussing that.
> > >
> > > > I wanted to ask how to best join this effort. It would be great for us
> > >
> > > Everyone is welcome to contribute! :)
> > >
> >
> > Great, we will try that out.
>
> Thank you for your interest in this effort, as promised I'm in the
> process of organizing a community meeting to get this going.
>
> Below are some proposals for dates and times, please respond with a
> prioritized list of what works best for you and we'll try to land on a
> single date/time for a first meeting:
> Wednesday July 5th 13:00 UTC
> Tuesday July 11th 13:30 UTC
> Wednesday July 12th 8:30 UTC

I'd be interested in attending. Of these, Tuesday July 11th @ 13:30
works best for me. 08:30 would be 03:30 for me, which is a little
early. I could do Wed July 5th as well. It's the day after the the
July 4 holiday here, and a lot of people are making it a long weekend.
So there will be the inevitable "catch up" associated with that, but
it is doable.

Terry (otherwiseguy)

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[grpc-io] gRPConf 2023 talk proposal submission deadline now July 9th

['Terry Wilson' via grpc.io]

Hi everyone, we have extended the deadline for submitting gRPConf 2023 
 talk proposals to *July 9th*. 
If you want to reach out to the gRPC community this is a great opportunity! 
You can submit your talk here 
.

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/15a1045a-4659-43d9-beb2-ba9c9cb7af23n%40googlegroups.com.

Re: [ovs-dev] [PATCH v3] python: Add async DNS support

[Terry Wilson]

On Fri, Jun 23, 2023 at 11:20 AM Ilya Maximets  wrote:
>
> On 6/23/23 17:15, Terry Wilson wrote:
> > Just checking in on this. I see a single test failure
> > https://github.com/ovsrobot/ovs/actions/runs/5272193494 'linux clang
> > test asan' but it looks like something related to bfd, so definitely
> > not the python patch here.
>
> This one is unrelated, yes.
>
> > Anything I need to do?
>
> I think, Adrian wanted to take another look at this version.
>
> See a couple of comments inline, but if there will be no other
> comments I can fix these while applying the change.
>
> >
> > On Wed, Jun 14, 2023 at 4:07 PM Terry Wilson  wrote:
> >>
> >> This adds a Python version of the async DNS support added in:
> >>
> >> 771680d96 DNS: Add basic support for asynchronous DNS resolving
> >>
> >> The above version uses the unbound C library, and this
> >> implimentation uses the SWIG-wrapped Python version of that.
> >>
> >> In the event that the Python unbound library is not available,
> >> a warning will be logged and the resolve() method will just
> >> return None. For the case where inet_parse_active() is passed
> >> an IP address, it will not try to resolve it, so existing
> >> behavior should be preserved in the case that the unbound
> >> library is unavailable.
> >>
> >> Intentional differences from the C version are as follows:
> >>
> >>   OVS_HOSTS_FILE environment variable can bet set to override
> >>   the system 'hosts' file. This is primarily to allow testing to
> >>   be done without requiring network connectivity.
> >>
> >>   Since resolution can still be done via hosts file lookup, DNS
> >>   lookups are not disabled when resolv.conf cannot be loaded.
> >>
> >>   The Python socket_util module has fallen behind its C equivalent.
> >>   The bare minimum change was done to inet_parse_active() to support
> >>   sync/async dns, as there is no equivalent to
> >>   parse_sockaddr_components(), inet_parse_passive(), etc. A TODO
> >>   was added to bring socket_util.py up to equivalency to the C
> >>   version.
> >>
> >> Signed-off-by: Terry Wilson 
> >> ---
> >>  .github/workflows/build-and-test.yml|   4 +-
> >>  Documentation/intro/install/general.rst |   4 +-
> >>  Documentation/intro/install/rhel.rst|   2 +-
> >>  Documentation/intro/install/windows.rst |   2 +-
> >>  NEWS|   4 +-
> >>  debian/control.in   |   1 +
> >>  m4/openvswitch.m4   |   8 +-
> >>  python/TODO.rst |   7 +
> >>  python/automake.mk  |   2 +
> >>  python/ovs/dns_resolve.py   | 272 +++
> >>  python/ovs/socket_util.py   |  21 +-
> >>  python/ovs/stream.py|   2 +-
> >>  python/ovs/tests/test_dns_resolve.py| 280 
> >>  python/setup.py |   6 +-
> >>  rhel/openvswitch-fedora.spec.in |   2 +-
> >>  tests/vlog.at   |   2 +
> >>  16 files changed, 601 insertions(+), 18 deletions(-)
> >>  create mode 100644 python/ovs/dns_resolve.py
> >>  create mode 100644 python/ovs/tests/test_dns_resolve.py
> >>
> >> diff --git a/.github/workflows/build-and-test.yml 
> >> b/.github/workflows/build-and-test.yml
> >> index f66ab43b0..47d239f10 100644
> >> --- a/.github/workflows/build-and-test.yml
> >> +++ b/.github/workflows/build-and-test.yml
> >> @@ -183,10 +183,10 @@ jobs:
> >>run:  sudo apt update || true
> >>  - name: install common dependencies
> >>run:  sudo apt install -y ${{ env.dependencies }}
> >> -- name: install libunbound libunwind
> >> +- name: install libunbound libunwind python3-unbound
> >># GitHub Actions doesn't have 32-bit versions of these libraries.
> >>if:   matrix.m32 == ''
> >> -  run:  sudo apt install -y libunbound-dev libunwind-dev
> >> +  run:  sudo apt install -y libunbound-dev libunwind-dev 
> >> python3-unbound
> >>  - name: install 32-bit libraries
> >>if:   matrix.m32 != ''
> >>run:  sudo apt install -y gcc-multilib
> >> diff --git a/Documentation/intro/install/general.rst 
> >> b/Documentation/intro/install/general.rst
> >> index 42b5682

Re: [ovs-dev] [PATCH v3] python: Add async DNS support

[Terry Wilson]

Just checking in on this. I see a single test failure
https://github.com/ovsrobot/ovs/actions/runs/5272193494 'linux clang
test asan' but it looks like something related to bfd, so definitely
not the python patch here. Anything I need to do?

On Wed, Jun 14, 2023 at 4:07 PM Terry Wilson  wrote:
>
> This adds a Python version of the async DNS support added in:
>
> 771680d96 DNS: Add basic support for asynchronous DNS resolving
>
> The above version uses the unbound C library, and this
> implimentation uses the SWIG-wrapped Python version of that.
>
> In the event that the Python unbound library is not available,
> a warning will be logged and the resolve() method will just
> return None. For the case where inet_parse_active() is passed
> an IP address, it will not try to resolve it, so existing
> behavior should be preserved in the case that the unbound
> library is unavailable.
>
> Intentional differences from the C version are as follows:
>
>   OVS_HOSTS_FILE environment variable can bet set to override
>   the system 'hosts' file. This is primarily to allow testing to
>   be done without requiring network connectivity.
>
>   Since resolution can still be done via hosts file lookup, DNS
>   lookups are not disabled when resolv.conf cannot be loaded.
>
>   The Python socket_util module has fallen behind its C equivalent.
>   The bare minimum change was done to inet_parse_active() to support
>   sync/async dns, as there is no equivalent to
>   parse_sockaddr_components(), inet_parse_passive(), etc. A TODO
>   was added to bring socket_util.py up to equivalency to the C
>   version.
>
> Signed-off-by: Terry Wilson 
> ---
>  .github/workflows/build-and-test.yml|   4 +-
>  Documentation/intro/install/general.rst |   4 +-
>  Documentation/intro/install/rhel.rst|   2 +-
>  Documentation/intro/install/windows.rst |   2 +-
>  NEWS|   4 +-
>  debian/control.in   |   1 +
>  m4/openvswitch.m4   |   8 +-
>  python/TODO.rst |   7 +
>  python/automake.mk  |   2 +
>  python/ovs/dns_resolve.py   | 272 +++
>  python/ovs/socket_util.py   |  21 +-
>  python/ovs/stream.py|   2 +-
>  python/ovs/tests/test_dns_resolve.py| 280 
>  python/setup.py |   6 +-
>  rhel/openvswitch-fedora.spec.in |   2 +-
>  tests/vlog.at   |   2 +
>  16 files changed, 601 insertions(+), 18 deletions(-)
>  create mode 100644 python/ovs/dns_resolve.py
>  create mode 100644 python/ovs/tests/test_dns_resolve.py
>
> diff --git a/.github/workflows/build-and-test.yml 
> b/.github/workflows/build-and-test.yml
> index f66ab43b0..47d239f10 100644
> --- a/.github/workflows/build-and-test.yml
> +++ b/.github/workflows/build-and-test.yml
> @@ -183,10 +183,10 @@ jobs:
>run:  sudo apt update || true
>  - name: install common dependencies
>run:  sudo apt install -y ${{ env.dependencies }}
> -- name: install libunbound libunwind
> +- name: install libunbound libunwind python3-unbound
># GitHub Actions doesn't have 32-bit versions of these libraries.
>if:   matrix.m32 == ''
> -  run:  sudo apt install -y libunbound-dev libunwind-dev
> +  run:  sudo apt install -y libunbound-dev libunwind-dev python3-unbound
>  - name: install 32-bit libraries
>if:   matrix.m32 != ''
>run:  sudo apt install -y gcc-multilib
> diff --git a/Documentation/intro/install/general.rst 
> b/Documentation/intro/install/general.rst
> index 42b5682fd..19e360d47 100644
> --- a/Documentation/intro/install/general.rst
> +++ b/Documentation/intro/install/general.rst
> @@ -90,7 +90,7 @@ need the following software:
>If libcap-ng is installed, then Open vSwitch will automatically build with
>support for it.
>
> -- Python 3.4 or later.
> +- Python 3.6 or later.
>
>  - Unbound library, from http://www.unbound.net, is optional but recommended 
> if
>you want to enable ovs-vswitchd and other utilities to use DNS names when
> @@ -208,7 +208,7 @@ simply install and run Open vSwitch you require the 
> following software:
>from iproute2 (part of all major distributions and available at
>https://wiki.linuxfoundation.org/networking/iproute2).
>
> -- Python 3.4 or later.
> +- Python 3.6 or later.
>
>  On Linux you should ensure that ``/dev/urandom`` exists. To support TAP
>  devices, you must also ensure that ``/dev/net/tun`` exists.
> diff --git a/Documentation/intro/install/rhel.rst 
> b/Documentation/intro/install/rhel.rst
> index d1fc42021..f2151d890 1006

[ovs-dev] [PATCH v3] python: Add async DNS support

[Terry Wilson]

This adds a Python version of the async DNS support added in:

771680d96 DNS: Add basic support for asynchronous DNS resolving

The above version uses the unbound C library, and this
implimentation uses the SWIG-wrapped Python version of that.

In the event that the Python unbound library is not available,
a warning will be logged and the resolve() method will just
return None. For the case where inet_parse_active() is passed
an IP address, it will not try to resolve it, so existing
behavior should be preserved in the case that the unbound
library is unavailable.

Intentional differences from the C version are as follows:

  OVS_HOSTS_FILE environment variable can bet set to override
  the system 'hosts' file. This is primarily to allow testing to
  be done without requiring network connectivity.

  Since resolution can still be done via hosts file lookup, DNS
  lookups are not disabled when resolv.conf cannot be loaded.

  The Python socket_util module has fallen behind its C equivalent.
  The bare minimum change was done to inet_parse_active() to support
  sync/async dns, as there is no equivalent to
  parse_sockaddr_components(), inet_parse_passive(), etc. A TODO
  was added to bring socket_util.py up to equivalency to the C
  version.

Signed-off-by: Terry Wilson 
---
 .github/workflows/build-and-test.yml|   4 +-
 Documentation/intro/install/general.rst |   4 +-
 Documentation/intro/install/rhel.rst|   2 +-
 Documentation/intro/install/windows.rst |   2 +-
 NEWS|   4 +-
 debian/control.in   |   1 +
 m4/openvswitch.m4   |   8 +-
 python/TODO.rst |   7 +
 python/automake.mk  |   2 +
 python/ovs/dns_resolve.py   | 272 +++
 python/ovs/socket_util.py   |  21 +-
 python/ovs/stream.py|   2 +-
 python/ovs/tests/test_dns_resolve.py| 280 
 python/setup.py |   6 +-
 rhel/openvswitch-fedora.spec.in |   2 +-
 tests/vlog.at   |   2 +
 16 files changed, 601 insertions(+), 18 deletions(-)
 create mode 100644 python/ovs/dns_resolve.py
 create mode 100644 python/ovs/tests/test_dns_resolve.py

diff --git a/.github/workflows/build-and-test.yml 
b/.github/workflows/build-and-test.yml
index f66ab43b0..47d239f10 100644
--- a/.github/workflows/build-and-test.yml
+++ b/.github/workflows/build-and-test.yml
@@ -183,10 +183,10 @@ jobs:
   run:  sudo apt update || true
 - name: install common dependencies
   run:  sudo apt install -y ${{ env.dependencies }}
-- name: install libunbound libunwind
+- name: install libunbound libunwind python3-unbound
   # GitHub Actions doesn't have 32-bit versions of these libraries.
   if:   matrix.m32 == ''
-  run:  sudo apt install -y libunbound-dev libunwind-dev
+  run:  sudo apt install -y libunbound-dev libunwind-dev python3-unbound
 - name: install 32-bit libraries
   if:   matrix.m32 != ''
   run:  sudo apt install -y gcc-multilib
diff --git a/Documentation/intro/install/general.rst 
b/Documentation/intro/install/general.rst
index 42b5682fd..19e360d47 100644
--- a/Documentation/intro/install/general.rst
+++ b/Documentation/intro/install/general.rst
@@ -90,7 +90,7 @@ need the following software:
   If libcap-ng is installed, then Open vSwitch will automatically build with
   support for it.
 
-- Python 3.4 or later.
+- Python 3.6 or later.
 
 - Unbound library, from http://www.unbound.net, is optional but recommended if
   you want to enable ovs-vswitchd and other utilities to use DNS names when
@@ -208,7 +208,7 @@ simply install and run Open vSwitch you require the 
following software:
   from iproute2 (part of all major distributions and available at
   https://wiki.linuxfoundation.org/networking/iproute2).
 
-- Python 3.4 or later.
+- Python 3.6 or later.
 
 On Linux you should ensure that ``/dev/urandom`` exists. To support TAP
 devices, you must also ensure that ``/dev/net/tun`` exists.
diff --git a/Documentation/intro/install/rhel.rst 
b/Documentation/intro/install/rhel.rst
index d1fc42021..f2151d890 100644
--- a/Documentation/intro/install/rhel.rst
+++ b/Documentation/intro/install/rhel.rst
@@ -92,7 +92,7 @@ Once that is completed, remove the file ``/tmp/ovs.spec``.
 If python3-sphinx package is not available in your version of RHEL, you can
 install it via pip with 'pip install sphinx'.
 
-Open vSwitch requires python 3.4 or newer which is not available in older
+Open vSwitch requires python 3.6 or newer which is not available in older
 distributions. In the case of RHEL 6.x and its derivatives, one option is
 to install python34 from `EPEL`_.
 
diff --git a/Documentation/intro/install/windows.rst 
b/Documentation/intro/install/windows.rst
index 78f60f35a..fce099d5d 100644
--- a/Documentation/intro/install/windows.rst
+++ b/Documentation/intro/install/windows.rst

[grpc-io] Re: Please join us for gRPConf 2023!

['Terry Wilson' via grpc.io]

A quick follow-up on the pricing for the event:

*Early Bird*: $50 USD (through September 6)
*Standard*: $99 USD (September 7 - Event)

Hope to see you there!

On Monday, June 12, 2023 at 2:23:12 PM UTC-7 Terry Wilson wrote:

> gRPConf 2023 is happening!
>
> Join us on the Google Cloud Campus for a full day of talks, demos, case 
> studies, and code labs. Experts will discuss real-world implementations of 
> gRPC, best practices for developers, and deep dives into specific topics. 
> This is a must-attend event for anyone using gRPC in their applications 
> today, as well as those considering gRPC for their enterprise 
> microservices. 
>
> There will be ample time to meet project leads and key members of the gRPC 
> ecosystem, network with peers, and ask questions.
> Save the Date:When: September 20, 2023Where: Google Cloud Campus - 
> Sunnyvale, CAWhat: gRPConf 2023 *↗︎ * 
> <https://events.linuxfoundation.org/grpc-conf/>
> Call for Papers:CFP Open: June 8-July 2, 2023Interested in Speaking at 
> gRPConf 2023? Submit a Proposal *↗︎* 
> <https://events.linuxfoundation.org/grpc-conf/program/cfp/>
> CLICK HERE TO REGISTER NOW <https://events.linuxfoundation.org/grpc-conf/>
> We Want to Hear from You!Schedule a session at grpc.io/meetJoin the gRPC 
> mailing 
> list <http://groups.google.com/g/grpc-io> YouTube @grpcio 
> <https://www.youtube.com/@grpcio/featured> | Twitter @grpcio 
> <https://twitter.com/grpcio> 
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/3f664925-ac40-4611-a187-0ccc8707375dn%40googlegroups.com.

[grpc-io] Please join us for gRPConf 2023!

['Terry Wilson' via grpc.io]

gRPConf 2023 is happening!

Join us on the Google Cloud Campus for a full day of talks, demos, case
studies, and code labs. Experts will discuss real-world implementations of
gRPC, best practices for developers, and deep dives into specific topics.
This is a must-attend event for anyone using gRPC in their applications
today, as well as those considering gRPC for their enterprise
microservices.

There will be ample time to meet project leads and key members of the gRPC
ecosystem, network with peers, and ask questions.
Save the Date:When: September 20, 2023Where: Google Cloud Campus -
Sunnyvale, CAWhat: gRPConf 2023 *↗︎ *

Call for Papers:CFP Open: June 8-July 2, 2023Interested in Speaking at
gRPConf 2023? Submit a Proposal *↗︎*

CLICK HERE TO REGISTER NOW 
We Want to Hear from You!Schedule a session at grpc.io/meetJoin the
gRPC mailing
list  YouTube @grpcio
 | Twitter @grpcio


-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CAMnUFuCeTqhmbK_TxEOj5mCzpavmx6F%3D68ae8nXdsceA0hGfVw%40mail.gmail.com.

[ovs-dev] [PATCH v2] python: Add aync DNS support

[Terry Wilson]

This adds a Python version of the async DNS support added in:

771680d96 DNS: Add basic support for asynchronous DNS resolving

The above version uses the unbound C library, and this
implimentation uses the SWIG-wrapped Python version of that.

In the event that the Python unbound library is not available,
a warning will be logged and the resolve() method will just
return None. For the case where inet_parse_active() is passed
an IP address, it will not try to resolve it, so existing
behavior should be preserved in the case that the unbound
library is unavailable.

Intentional differences from the C version are as follows:

  OVS_HOSTS_FILE environment variable can bet set to override
  the system 'hosts' file. This is primarily to allow testing to
  be done without requiring network connectivity.

  Since resolution can still be done via hosts file lookup, DNS
  lookups are not disabled when resolv.conf cannot be loaded.

  The Python socket_util module has fallen behind its C equivalent.
  The bare minimum change was done to inet_parse_active() to support
  sync/async dns, as there is no equivalent to
  parse_sockaddr_components(), inet_parse_passive(), etc. A TODO
  was added to bring socket_util.py up to equivalency to the C
  version.

Signed-off-by: Terry Wilson 
---
 .github/workflows/build-and-test.yml |   4 +-
 debian/control.in|   1 +
 python/TODO.rst  |   7 +
 python/automake.mk   |   2 +
 python/ovs/dns_resolve.py| 257 
 python/ovs/socket_util.py|  21 +-
 python/ovs/stream.py |   2 +-
 python/ovs/tests/test_dns_resolve.py | 280 +++
 python/setup.py  |   6 +-
 rhel/openvswitch-fedora.spec.in  |   2 +-
 tests/vlog.at|   2 +
 11 files changed, 575 insertions(+), 9 deletions(-)
 create mode 100644 python/ovs/dns_resolve.py
 create mode 100644 python/ovs/tests/test_dns_resolve.py

diff --git a/.github/workflows/build-and-test.yml 
b/.github/workflows/build-and-test.yml
index f66ab43b0..47d239f10 100644
--- a/.github/workflows/build-and-test.yml
+++ b/.github/workflows/build-and-test.yml
@@ -183,10 +183,10 @@ jobs:
   run:  sudo apt update || true
 - name: install common dependencies
   run:  sudo apt install -y ${{ env.dependencies }}
-- name: install libunbound libunwind
+- name: install libunbound libunwind python3-unbound
   # GitHub Actions doesn't have 32-bit versions of these libraries.
   if:   matrix.m32 == ''
-  run:  sudo apt install -y libunbound-dev libunwind-dev
+  run:  sudo apt install -y libunbound-dev libunwind-dev python3-unbound
 - name: install 32-bit libraries
   if:   matrix.m32 != ''
   run:  sudo apt install -y gcc-multilib
diff --git a/debian/control.in b/debian/control.in
index 19f590d06..64b0a4ce0 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -287,6 +287,7 @@ Depends:
 Suggests:
  python3-netaddr,
  python3-pyparsing,
+ python3-unbound,
 Description: Python 3 bindings for Open vSwitch
  Open vSwitch is a production quality, multilayer, software-based,
  Ethernet virtual switch. It is designed to enable massive network
diff --git a/python/TODO.rst b/python/TODO.rst
index 3a53489f1..acc5461e2 100644
--- a/python/TODO.rst
+++ b/python/TODO.rst
@@ -32,3 +32,10 @@ Python Bindings To-do List
 
   * Support write-only-changed monitor mode (equivalent of
 OVSDB_IDL_WRITE_CHANGED_ONLY).
+
+* socket_util:
+
+  * Add equivalent fuctions to inet_parse_passive, parse_sockaddr_components,
+et al. to better support using async dns. The reconnect code will
+currently log a warning when inet_parse_active() returns w/o yet having
+resolved an address, but will continue to connect and eventually succeed.
diff --git a/python/automake.mk b/python/automake.mk
index d00911828..82a508787 100644
--- a/python/automake.mk
+++ b/python/automake.mk
@@ -16,6 +16,7 @@ ovs_pyfiles = \
python/ovs/compat/sortedcontainers/sorteddict.py \
python/ovs/compat/sortedcontainers/sortedset.py \
python/ovs/daemon.py \
+   python/ovs/dns_resolve.py \
python/ovs/db/__init__.py \
python/ovs/db/custom_index.py \
python/ovs/db/data.py \
@@ -55,6 +56,7 @@ ovs_pyfiles = \
 
 ovs_pytests = \
python/ovs/tests/test_decoders.py \
+   python/ovs/tests/test_dns_resolve.py \
python/ovs/tests/test_filter.py \
python/ovs/tests/test_kv.py \
python/ovs/tests/test_list.py \
diff --git a/python/ovs/dns_resolve.py b/python/ovs/dns_resolve.py
new file mode 100644
index 0..463a39277
--- /dev/null
+++ b/python/ovs/dns_resolve.py
@@ -0,0 +1,257 @@
+import collections
+import functools
+import ipaddress
+import os
+import threading
+import time
+import typing
+
+try:
+import unbound  # type: ignore
+except ImportError:
+pass
+
+import ovs.vlog
+
+vlog = ovs.vlog.Vlog

Re: [ovs-dev] [PATCH] python: Add aync DNS support

[Terry Wilson]

Signed-off-by: Terry Wilson 

I can re-send if needed for the sign-off. I've tried to list the
caveats in the commit message/TODO entry. Before I got too far into
digging around into the socket_util and jsonrpc/reconnect code, I
figured I'd put this out there to see if any major changes needed to
be made first. Hopefully major socket_util changes can hold off for a
follow-up patch. I tried to mostly follow the C lib (including by not
raising any Exceptions from public library methods), but there are
some differences listed. In addition, instead of returning a (err,
result) tuple with resolve() to mimic the err return value and string
reference, I just return result/None and log errors/warnings. None of
the code in the C lib actually used the error return value.

Terry
On Tue, May 16, 2023 at 10:52 PM Terry Wilson  wrote:
>
> This adds a Python version of the async DNS support added in:
>
> 771680d96 DNS: Add basic support for asynchronous DNS resolving
>
> The above version uses the unbound C library, and this
> implimentation uses the SWIG-wrapped Python version of that.
>
> In the event that the Python unbound library is not available,
> a warning will be logged and the resolve() method will just
> return None. For the case where inet_parse_active() is passed
> an IP address, it will not try to resolve it, so existing
> behavior should be preserved in the case that the unbound
> library is unavailable.
>
> Intentional differences from the C version are as follows:
>
>   OVS_HOSTS_FILE environment variable can bet set to override
>   the system 'hosts' file. This is primarily to allow testing to
>   be done without requiring network connectivity.
>
>   Since resolution can still be done via hosts file lookup, DNS
>   lookups are not disabled when resolv.conf cannot be loaded.
>
>   The Python socket_util module has fallen behind its C equivalent.
>   The bare minimum change was done to inet_parse_active() to support
>   sync/async dns, as there is no equivalent to
>   parse_sockaddr_components(), inet_parse_passive(), etc. A TODO
>   was added to bring socket_util.py up to equivalency to the C
>   version.
> ---
>  debian/control.in|   1 +
>  python/TODO.rst  |   7 +
>  python/automake.mk   |   2 +
>  python/ovs/dns_resolve.py| 257 +
>  python/ovs/socket_util.py|  21 ++-
>  python/ovs/stream.py |   2 +-
>  python/ovs/tests/test_dns_resolve.py | 270 +++
>  python/setup.py  |   6 +-
>  rhel/openvswitch-fedora.spec.in  |   2 +-
>  9 files changed, 561 insertions(+), 7 deletions(-)
>  create mode 100644 python/ovs/dns_resolve.py
>  create mode 100644 python/ovs/tests/test_dns_resolve.py
>
> diff --git a/debian/control.in b/debian/control.in
> index 19f590d06..64b0a4ce0 100644
> --- a/debian/control.in
> +++ b/debian/control.in
> @@ -287,6 +287,7 @@ Depends:
>  Suggests:
>   python3-netaddr,
>   python3-pyparsing,
> + python3-unbound,
>  Description: Python 3 bindings for Open vSwitch
>   Open vSwitch is a production quality, multilayer, software-based,
>   Ethernet virtual switch. It is designed to enable massive network
> diff --git a/python/TODO.rst b/python/TODO.rst
> index 3a53489f1..acc5461e2 100644
> --- a/python/TODO.rst
> +++ b/python/TODO.rst
> @@ -32,3 +32,10 @@ Python Bindings To-do List
>
>* Support write-only-changed monitor mode (equivalent of
>  OVSDB_IDL_WRITE_CHANGED_ONLY).
> +
> +* socket_util:
> +
> +  * Add equivalent fuctions to inet_parse_passive, parse_sockaddr_components,
> +et al. to better support using async dns. The reconnect code will
> +currently log a warning when inet_parse_active() returns w/o yet having
> +resolved an address, but will continue to connect and eventually succeed.
> diff --git a/python/automake.mk b/python/automake.mk
> index d00911828..82a508787 100644
> --- a/python/automake.mk
> +++ b/python/automake.mk
> @@ -16,6 +16,7 @@ ovs_pyfiles = \
> python/ovs/compat/sortedcontainers/sorteddict.py \
> python/ovs/compat/sortedcontainers/sortedset.py \
> python/ovs/daemon.py \
> +   python/ovs/dns_resolve.py \
> python/ovs/db/__init__.py \
> python/ovs/db/custom_index.py \
> python/ovs/db/data.py \
> @@ -55,6 +56,7 @@ ovs_pyfiles = \
>
>  ovs_pytests = \
> python/ovs/tests/test_decoders.py \
> +   python/ovs/tests/test_dns_resolve.py \
> python/ovs/tests/test_filter.py \
> python/ovs/tests/test_kv.py \
> python/ovs/tests/test_list.py \
> diff --git a/python/ovs/dns_resolve.py b/python/ovs/dns_resolve.py
> new file mode 100

[ovs-dev] [PATCH] python: Add aync DNS support

[Terry Wilson]

This adds a Python version of the async DNS support added in:

771680d96 DNS: Add basic support for asynchronous DNS resolving

The above version uses the unbound C library, and this
implimentation uses the SWIG-wrapped Python version of that.

In the event that the Python unbound library is not available,
a warning will be logged and the resolve() method will just
return None. For the case where inet_parse_active() is passed
an IP address, it will not try to resolve it, so existing
behavior should be preserved in the case that the unbound
library is unavailable.

Intentional differences from the C version are as follows:

  OVS_HOSTS_FILE environment variable can bet set to override
  the system 'hosts' file. This is primarily to allow testing to
  be done without requiring network connectivity.

  Since resolution can still be done via hosts file lookup, DNS
  lookups are not disabled when resolv.conf cannot be loaded.

  The Python socket_util module has fallen behind its C equivalent.
  The bare minimum change was done to inet_parse_active() to support
  sync/async dns, as there is no equivalent to
  parse_sockaddr_components(), inet_parse_passive(), etc. A TODO
  was added to bring socket_util.py up to equivalency to the C
  version.
---
 debian/control.in|   1 +
 python/TODO.rst  |   7 +
 python/automake.mk   |   2 +
 python/ovs/dns_resolve.py| 257 +
 python/ovs/socket_util.py|  21 ++-
 python/ovs/stream.py |   2 +-
 python/ovs/tests/test_dns_resolve.py | 270 +++
 python/setup.py  |   6 +-
 rhel/openvswitch-fedora.spec.in  |   2 +-
 9 files changed, 561 insertions(+), 7 deletions(-)
 create mode 100644 python/ovs/dns_resolve.py
 create mode 100644 python/ovs/tests/test_dns_resolve.py

diff --git a/debian/control.in b/debian/control.in
index 19f590d06..64b0a4ce0 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -287,6 +287,7 @@ Depends:
 Suggests:
  python3-netaddr,
  python3-pyparsing,
+ python3-unbound,
 Description: Python 3 bindings for Open vSwitch
  Open vSwitch is a production quality, multilayer, software-based,
  Ethernet virtual switch. It is designed to enable massive network
diff --git a/python/TODO.rst b/python/TODO.rst
index 3a53489f1..acc5461e2 100644
--- a/python/TODO.rst
+++ b/python/TODO.rst
@@ -32,3 +32,10 @@ Python Bindings To-do List
 
   * Support write-only-changed monitor mode (equivalent of
 OVSDB_IDL_WRITE_CHANGED_ONLY).
+
+* socket_util:
+
+  * Add equivalent fuctions to inet_parse_passive, parse_sockaddr_components,
+et al. to better support using async dns. The reconnect code will
+currently log a warning when inet_parse_active() returns w/o yet having
+resolved an address, but will continue to connect and eventually succeed.
diff --git a/python/automake.mk b/python/automake.mk
index d00911828..82a508787 100644
--- a/python/automake.mk
+++ b/python/automake.mk
@@ -16,6 +16,7 @@ ovs_pyfiles = \
python/ovs/compat/sortedcontainers/sorteddict.py \
python/ovs/compat/sortedcontainers/sortedset.py \
python/ovs/daemon.py \
+   python/ovs/dns_resolve.py \
python/ovs/db/__init__.py \
python/ovs/db/custom_index.py \
python/ovs/db/data.py \
@@ -55,6 +56,7 @@ ovs_pyfiles = \
 
 ovs_pytests = \
python/ovs/tests/test_decoders.py \
+   python/ovs/tests/test_dns_resolve.py \
python/ovs/tests/test_filter.py \
python/ovs/tests/test_kv.py \
python/ovs/tests/test_list.py \
diff --git a/python/ovs/dns_resolve.py b/python/ovs/dns_resolve.py
new file mode 100644
index 0..58638aae4
--- /dev/null
+++ b/python/ovs/dns_resolve.py
@@ -0,0 +1,257 @@
+import collections
+import functools
+import ipaddress
+import os
+import threading
+import time
+import typing
+
+try:
+import unbound  # type: ignore
+except ImportError:
+pass
+
+import ovs.vlog
+
+vlog = ovs.vlog.Vlog("dns_resolve")
+
+
+class DNSRequest:
+INVALID = 0
+PENDING = 1
+GOOD = 2
+ERROR = 3
+
+def __init__(self, name):
+self.name = name
+self.state = self.INVALID
+self.time = None
+self.result = None  # set by DNSResolver._callback
+self.ttl = None
+
+@property
+def expired(self):
+return time.time() > self.time + self.ttl
+
+@property
+def is_valid(self):
+return self.state == self.GOOD and not self.expired
+
+def __str__(self):
+return (f"DNSRequest(name={self.name}, state={self.state}, "
+f"time={self.time}, result={self.result})")
+
+
+class DefaultReqDict(collections.defaultdict):
+def __init__(self):
+super().__init__(DNSRequest)
+
+def __missing__(self, key):
+ret = self.default_factory(key)
+self[key] = ret
+return ret
+
+
+class UnboundException(Exception):
+
+def __init__(self, 

[ovs-discuss] python-ovs and OVSDB set types

[Terry Wilson via discuss]

A performance issue that has always bothered me:

OVSDB has a set data type that matches up with Python's set data type (an
unordered collection of unique items). The in-tree Python library
represents this set type as a list. Not only does it do that, but every
time you call Row.__getattr__() through accessing a Row with a set-type
column, it will loop through those values, add them to a new Python set
(presumably to remove duplicates)...and then return them as a sorted list.
Every single time the attribute is accessed [1].

Some of these sets can be quite huge. In OpenStack Neutron, for example, we
have a default Port Group that all ports are added to by default. This is
many thousands of ports.

Now, it would be very simple to just return a set here and users would get
the benefits of both less overhead on attribute access AND the ability to
do O(1) lookups on these sets. Things like "find port groups that have this
port" etc. would be *much* cheaper. The problem is that this breaks the
API. You can no longer do things like Port_Group.ports[0] as set objects
are unordered and do not have __getitem__(), operations like append() don't
exist, etc. This will also break tons of tests because they tend to rely on
order of objects since they do simple string matching. The latter issue is
probably pretty easy to fix in the tests themselves by just sorting the
results in the tests themselves.

It's probably possible to create a wrapper type object that makes a set
that kinda looks like a list enough to not break things, but that's also
pretty ugly. So I guess my question is, "what do we think about breaking
the API at some point to fix this?" It's pretty terrible behavior, but it's
also annoying when APIs change.

Terry

[1]
https://github.com/openvswitch/ovs/blob/d70688a7291edb432fd66b9230a92842fcfd3607/python/ovs/db/data.py#L498-L504
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[grpc-io] Re: Any suggestion on how to perform load testing of gRPC client & streaming service

['Terry Wilson' via grpc.io]

I'll also mention that there is a gRPC plugin for Gatling 
<https://github.com/phiSgr/gatling-grpc> and that K6 also supports gRPC 
<https://k6.io/blog/performance-testing-grpc-services/>.

On Wednesday, March 29, 2023 at 4:27:54 PM UTC-7 Terry Wilson wrote:

> I don't have any personal experience in this tool, but I've seen community 
> use of ghz.sh. Maybe start by looking at what it provides.
>
> On Sunday, March 19, 2023 at 12:15:24 PM UTC-7 Shailendra Omkar wrote:
>
>> Hi Team,
>>
>> I need to perform load testing of my application which uses gRPC client & 
>> streaming service.
>>
>> Can you please suggest on below
>>
>>1. Tools to use
>>2. Videos, Reference links
>>3. Sample example
>>
>> Appreciate your help on this.
>>
>> Thanks
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/abbfdd84-891a-44ac-ae0e-60bc20d9a333n%40googlegroups.com.

[grpc-io] Re: Any suggestion on how to perform load testing of gRPC client & streaming service

['Terry Wilson' via grpc.io]

I don't have any personal experience in this tool, but I've seen community 
use of ghz.sh. Maybe start by looking at what it provides.

On Sunday, March 19, 2023 at 12:15:24 PM UTC-7 Shailendra Omkar wrote:

> Hi Team,
>
> I need to perform load testing of my application which uses gRPC client & 
> streaming service.
>
> Can you please suggest on below
>
>1. Tools to use
>2. Videos, Reference links
>3. Sample example
>
> Appreciate your help on this.
>
> Thanks

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/2254151d-39cb-43d5-b4eb-f49166bba87cn%40googlegroups.com.

[grpc-io] gRPC-Java 1.54.0 Released

['Terry Wilson' via grpc.io]

The v1.54.0 release  
is now available.

*New Features*
- xds: Add weightedRoundRobin LB policy. The WRR policy allows picking the 
subchannel by weight based on the metrics feedback from the backend using 
ORCA API. See gRFC A58: Weighted Round Robin LB Policy. (#9873)
- census: Add per call latency metric which is latency across all attempts 
(#9906)

*Examples*
- Add examples for gcp observability (#9967)

*Bugfixes*
- rls:Fix throttling in route lookup where success and error metrics had 
been inverted ([b/262779100](https://b.corp.google.com/262779100)) (#9874)
- protobuf: update external javadoc link (#9890)
- core: fix outlier detection default ejection time (#9889)
- xds: deletion only to watchers of same control plane (#9896)
- compiler: add missing break in switch statement (#9901)
- api: Target scheme is now properly case insensitive (#9899). 
`NameResolverProvider`s, however, are expected to return the scheme used 
for registration in lower-case
- api: ForwardingServerCall now forwards getMethodDescriptor(). Previously 
only SimpleForwardingServerCall forwarded the method

*Behavior Changes*
- xds:Allow a cluster’s sum of weights to exceed the maximum signed integer 
up to a limit of max unsigned integer (#9864)
- grpclb: no SRV lookup for "metadata.google.internal."

*Improvements*
- xds, orca: Allow removing OobLoadReportListener from a subchannel in 
OrcaOobUil. (#9881)
- services: ORCA API change to allow recording QPS in MetricRecorder and 
CallMetricRecorder. (#9866)
- Move name resolution retry from managed channel to name resolver (take 
#2) (#9812)
- Rename AbstractXdsClient to ControlPlaneClient (#9934)
- all: fix build with errorprone 2.18 (#9886)
- build: allow Java 11+ to use modern error prone
- errorprone: enable UnnecessaryAnonymousClass (#9927)
- core: add logger to OutlierDetectionLoadBalancer (#9880)
- census: add trace annotation to report received message sizes (#9944)
- gcp-observability: emit latency and payload size metrics by default when 
monitoring is enabled (#9893)
- gcp-observability: add trace information like TraceId and SpanId in logs 
for log correlation when both logging and traces are enabled (#9963)
- gcp-observability: close() will take longer, to ensure metrics and traces 
are flushed (#9972)
- gcp-observability: update status code type in logs to Google RPC code 
instead of an integer (#9959)
- gcp-observability: retain default opencensus-task identifier even when 
custom labels are specified in the configuration (#9982)
- Build Improvements (#9855)
- Fixes MethodDescriptor java documentation (#9860)
- api: forward getSecurityLevel on PartialForwardingServerCall (#9912)
- Updating ServerInterceptors.java to support different marshallers for 
Request and Response messages. (#9877)

*API stabilizations*
- Stabilize method ServerBuilder.intercept which had previously been marked 
experimental. (#9894)
- api:stabilize offloadExecutor usage in ManagedChannelBuilder and 
NameResolver. (#9931)

*Dependencies*
- netty:Upgrade Netty from 4.1.79 to 4.1.87, tcnative from 2.0.54 to 2.0.56 
(#9784)
- gcp-observability: Transitive gRPC components now have the same gRPC 
version
- gcp-observability : Google cloud logging updated to 3.14.5

*Acknowledgements*
Benjamin Peterson
Sergey Matyukevich
Asaf Flescher
Benjamin Einaudi
Carl Mastrangelo
Ivan Bahdanau

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/bf88c58b-b132-40d4-8eff-40d9865414e8n%40googlegroups.com.

[Yahoo-eng-team] [Bug 2011590] [NEW] Startup times for large OVN dbs is greatly increased by frozen_row() calls

[Terry Wilson]

Public bug reported:

On a large OVN DB, frozen_row() calls for the event notification
processing can add 10ms up to 40ms or more depending on the size of the
row (as compared to 4usec for just passing the Row object). This can
easily make startup times w/ large DBs increase by a factor of 3 or
more.

We are currently calling frozen_row() for every event, but we really
only need it for the events that we have registered.

** Affects: neutron
 Importance: Undecided
 Status: In Progress

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2011590

Title:
  Startup times for large OVN dbs is greatly increased by frozen_row()
  calls

Status in neutron:
  In Progress

Bug description:
  On a large OVN DB, frozen_row() calls for the event notification
  processing can add 10ms up to 40ms or more depending on the size of
  the row (as compared to 4usec for just passing the Row object). This
  can easily make startup times w/ large DBs increase by a factor of 3
  or more.

  We are currently calling frozen_row() for every event, but we really
  only need it for the events that we have registered.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2011590/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

Re: [grpc-io] grpc vs rest benchmark

['Terry Wilson' via grpc.io]

In case you are not already aware of them, you might be interested in the 
benchmarks the gRPC team 
maintains: https://grpc.io/docs/guides/benchmarking/

You will find a link there to a dashboard 
 with performance history as 
well as to the repo  with the benchmark 
code.

On Thursday, February 16, 2023 at 6:02:10 AM UTC-8 shobhit agarwal wrote:

> Thanks for replying,
> I am using the code from below article: 
>
> https://www.techgeeknext.com/spring-boot/spring-boot-grpc-example#google_vignette
>
> It's spring boot application.
> Even for single request grpc is response time is 100 ms and REST is taking 
> 12 ms only.
>
>
>
>
>
> On Thursday, 16 February 2023 at 19:10:45 UTC+5:30 Gordan Krešić wrote:
>
>> On 16. 02. 2023. 14:38, Gordan Krešić wrote: 
>> > 
>> > I did similar test about a month ago, check the thread "gRPC 
>> performance (Java)": https://groups.google.com/g/grpc-io/c/4-bfxJDc7_s 
>> > 
>> > Over there you even have a link to a repo with sample projects I used 
>> to test. 
>>
>> Forgot to mention: check repo from the last post (
>> https://groups.google.com/g/grpc-io/c/4-bfxJDc7_s/m/y1qqIg5nCAAJ), not 
>> the first one. 
>>
>> -gkresic. 
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/b6a0fa3b-fc9b-4762-af68-4fb3f66a37e7n%40googlegroups.com.

[grpc-io] gRPC-Java 1.45.4 released

['Terry Wilson' via grpc.io]

The v1.45.4 release is now available.

*Bug Fixes*

   - core: Free unused MessageProducer in RetriableStream (#9853 
   )
   

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/96564ba3-0fc9-4ff8-a2ca-5cf8bb60b423n%40googlegroups.com.

Re: [ovs-dev] [PATCH v8] ovsdb-idl: Add the support to specify the uuid for row insert.

[Terry Wilson]

UUID already present within the table or
> deleted within the same transaction']])
> diff --git a/tests/test-ovsdb.c b/tests/test-ovsdb.c
> index 5f7110f41..84fe23276 100644
> --- a/tests/test-ovsdb.c
> +++ b/tests/test-ovsdb.c
> @@ -2400,7 +2400,7 @@ idltest_find_simple(struct ovsdb_idl *idl, int i)
>  return NULL;
>  }
>
> -static void
> +static bool
>  idl_set(struct ovsdb_idl *idl, char *commands, int step)
>  {
>  char *cmd, *save_ptr1 = NULL;
> @@ -2458,6 +2458,19 @@ idl_set(struct ovsdb_idl *idl, char *commands, int
> step)
>
>  s = idltest_simple_insert(txn);
>  idltest_simple_set_i(s, atoi(arg1));
> +} else if (!strcmp(name, "insert_uuid")) {
> +struct idltest_simple *s;
> +
> +if (!arg1 || !arg2) {
> +ovs_fatal(0, "\"insert\" command requires 2 arguments");
> +}
> +
> +struct uuid s_uuid;
> +if (!uuid_from_string(_uuid, arg1)) {
> + ovs_fatal(0, "\"insert_uuid\" command requires valid
> uuid");
> +}
> +s = idltest_simple_insert_persist_uuid(txn, _uuid);
> +idltest_simple_set_i(s, atoi(arg2));
>  } else if (!strcmp(name, "delete")) {
>  const struct idltest_simple *s;
>
> @@ -2522,7 +2535,7 @@ idl_set(struct ovsdb_idl *idl, char *commands, int
> step)
>  print_and_log("%03d: destroy", step);
>  ovsdb_idl_txn_destroy(txn);
>  ovsdb_idl_check_consistency(idl);
> -return;
> +return true;
>  } else {
>  ovs_fatal(0, "unknown command %s", name);
>  }
> @@ -2543,6 +2556,8 @@ idl_set(struct ovsdb_idl *idl, char *commands, int
> step)
>
>  ovsdb_idl_txn_destroy(txn);
>  ovsdb_idl_check_consistency(idl);
> +
> +return (status != TXN_ERROR);
>  }
>
>  static const struct ovsdb_idl_table_class *
> @@ -2777,7 +2792,14 @@ do_idl(struct ovs_cmdl_context *ctx)
>  update_conditions(idl, arg + strlen(cond_s));
>  print_and_log("%03d: change conditions", step++);
>  } else if (arg[0] != '[') {
> -idl_set(idl, arg, step++);
> +if (!idl_set(idl, arg, step++)) {
> +/* If idl_set() returns false, then no transaction
> + * was sent to the server and most likely 'seqno'
> + * would remain the same.  And the above 'Wait for update'
> + * for loop poll_block() would never return.
> + * So set seqno to 0. */
> +seqno = 0;
> +}
>  } else {
>  struct json *json = parse_json(arg);
>  substitute_uuids(json, symtab);
> diff --git a/tests/test-ovsdb.py b/tests/test-ovsdb.py
> index 402cacbe9..cca1818ea 100644
> --- a/tests/test-ovsdb.py
> +++ b/tests/test-ovsdb.py
> @@ -429,6 +429,14 @@ def idl_set(idl, commands, step):
>
>  s = txn.insert(idl.tables["simple"])
>  s.i = int(args[0])
> +elif name == "insert_uuid":
> +if len(args) != 2:
> +sys.stderr.write('"set" command requires 2 argument\n')
> +sys.exit(1)
> +
> +s = txn.insert(idl.tables["simple"], new_uuid=args[0],
> +   persist_uuid=True)
> +s.i = int(args[1])
>  elif name == "delete":
>  if len(args) != 1:
>  sys.stderr.write('"delete" command requires 1 argument\n')
> @@ -491,7 +499,7 @@ def idl_set(idl, commands, step):
>  print("%03d: destroy" % step)
>  sys.stdout.flush()
>  txn.abort()
> -return
> +return True
>  elif name == "linktest":
>  l1_0 = txn.insert(idl.tables["link1"])
>  l1_0.i = 1
> @@ -615,6 +623,8 @@ def idl_set(idl, commands, step):
>  sys.stdout.write("\n")
>  sys.stdout.flush()
>
> +return status != ovs.db.idl.Transaction.ERROR
> +
>
>  def update_condition(idl, commands):
>  commands = commands[len("condition "):].split(";")
> @@ -748,7 +758,13 @@ def do_idl(schema_file, remote, *commands):
>  sys.stdout.flush()
>  step += 1
>  elif not command.startswith("["):
> -idl_set(idl, command, step)
> +if not idl_set(idl, command, step):
> +# If idl_set() returns false, then no transaction
> +# was sent to the server and most likely seqno
> +# would remain the same.  And the above 'Wait for update'
> +# for loop poller.block() would never return.
> +# So set seqno to 0.
> +seqno = 0
>  step += 1
>  else:
>  json = ovs.json.from_string(command)
> --
> 2.38.1
>
>
Looks good to me, I'll work on adding some code to ovsdbapp that uses this
as well. Thanks!

Acked-by: Terry Wilson 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[grpc-io] Re: Question about proto message - breaking change behavior

['Terry Wilson' via grpc.io]

I can't comment on the C# specifics, but when dealing with protobuf 
changes, one should never reuse the ordinal numbers of deleted fields. If 
you don't need a field anymore, you should *reserve* the field number. You 
can find some documentation on this over here 
.

A better approach here for your version 2 would be:

message A {
  reserved 2;
  string field1 = 1;
  map field3 = 3*;*
}

This will avoid problems with coding/decoding the message, which I suspect 
you are experiencing here.

Hope that helps,
Terry


On Thursday, October 13, 2022 at 11:07:12 AM UTC-7 sre.ag...@gmail.com 
wrote:

> Hi All,
>
> I recently observed some behavior w.r.t proto message - 
> marshalling/unmarshalling. Wanted to know if there is a better way to 
> determine the contract break specifically for code written in C#?
>
> Client (Version 1) and server (Version 1) were using different versions of 
> a message with some **breaking change**. My understanding **was** in case 
> of a contract break we will see some sort of exception but turns out the 
> field (*field3*) was just an empty object [*Not null*]. In our scenario 
> it is possible to have an empty object for that field, so checking null or 
> empty object won't help either.
>
> Is there a guideline to determine a contract break at run time? Or do we 
> need to somehow ensure in our code change review process or build process 
> that ordinals are not changed?
>
> *Version 1*
> Message A {
> string field1 = 1;
> uint64 filed2 = 2;
> map field3 = 3;
> }
>
> *Version 2*
> Message A {
> string field1 = 1;
> map field3 =* 2;*
> }
>
> Regards,
> Vivek 
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/e5faf6bd-0cc9-43cd-ad5a-c450b7a9f06bn%40googlegroups.com.

[grpc-io] Last chance to sign up for gRPConf 2022

['Terry Wilson' via grpc.io]

Hi folks, this is your last chance to sign up for next week's KubeCon 2022 
in Detroit and more specifically gRPConf 2022 happening on Monday 10/24! 
Come learn about the latest developments from several talks we have 
prepared for you and bring your questions to the gRPC team. We are also 
very eager to hear what features you would like to see on the gRPC roadmap.

See you next week!

Register here: https://events.linuxfoundation.org/grpc-conf/register/
Schedule: https://events.linuxfoundation.org/grpc-conf/program/schedule/

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/4e9d0735-7b9d-487d-8dee-756db698fbb8n%40googlegroups.com.

[grpc-io] gRPC-Java 1.43.3 Released

['Terry Wilson' via grpc.io]

The v1.43.3 release is now available.

*Bugfixes*
   
   - android: fix for app coming to foreground #8850 
   
   - xds: fix the validation code to accept new-style 
   CertificateProviderPluginInstance wherever used

*Dependencies*
   
   - Bump protobuf to 3.19.6

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/d685b506-6853-45ff-bd67-fc449e40b57cn%40googlegroups.com.

[grpc-io] gRPC-Java v1.42.3 Released

['Terry Wilson' via grpc.io]

The v1.42.3 release is now available

*Dependencies*
   
   - Bump protobuf to 3.19.6

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/27a15b89-5b6f-48bf-81f9-a6b7776261cbn%40googlegroups.com.

[grpc-io] gRPC-Java 1.49.2 Released

['Terry Wilson' via grpc.io]

The v1.49.2 release  
is now available.

*Dependencies*
   
   - Bump protobuf to 3.21.7

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/a76a5f16-0bd1-4130-8374-6466cfad9c9en%40googlegroups.com.

[grpc-io] gRPC-Java 1.48.2 Released

['Terry Wilson' via grpc.io]

The v1.48.2 release  
is now available.

*Bug Fixes*
   
   - xds: Fix a bug in ring-hash load balancing policy that, during 
   TRANSIENT_FAILURE state, it might cause unnecessary internal connection 
   requests on subchannels. (#9537 
   )
   - auth: Fix AppEngine failing while retrieving access token when 
   instantiating a blocking stub using AppEngineCredentials (#9524 
   )
   - xds: channel_id hash policy now uses a random per-channel id instead 
   of an incrementing one. The incrementing id was the same for every process 
   of a binary, which was not the intention (#9453 
   )
   - bazel: Use valid target name for services and xds when overriding 
   Maven targets (#9422 ). 
   This fixes an error of the form no such target 
   '@io_grpc_grpc_java//services:services' for services and missing ORCA 
   classes for xds. The wrong target names were introduced in 1.47.0

*Dependencies*
   
   - Bump protobuf to 3.21.7

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/90c4717a-7ece-4cf9-a914-f0dbe1046cccn%40googlegroups.com.

[Yahoo-eng-team] [Bug 1989646] [NEW] neutron's override of ovsdbapp's idlutils.wait_for_change is busted

[Terry Wilson]

Public bug reported:

The method doesn't actually do anything unless seqno=None due to an
indentation issue.

** Affects: neutron
 Importance: Undecided
 Status: In Progress

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1989646

Title:
  neutron's override of ovsdbapp's idlutils.wait_for_change is busted

Status in neutron:
  In Progress

Bug description:
  The method doesn't actually do anything unless seqno=None due to an
  indentation issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1989646/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[grpc-io] gRPC Java v1.49.0 Release

['Terry Wilson' via grpc.io]

Release v1.49.0 is now available on Maven Central.

https://github.com/grpc/grpc-java/releases/tag/v1.49.0

*New Features*


   - okhttp: Add `OkHttpServerBuilder`. The server can be used directly, 
   but is not yet available via `ServerBuilder.forPort()` and 
   `Grpc.newServerBuilderForPort()`. It passes our tests, but has seen no 
   real-world use. It is also lacking connection management features
   - okhttp: Add support for byte-based private keys via 
   TlsChannelCredentials and TlsServerCredentials
   - core: New outlier detection load balancer
   - googleapis: google-c2p resolver is now stabilized

*Bug Fixes*


   - core: Fix retry causing memory leak for canceled RPCs. (#9360)
   - core: Use SyncContext for InProcess transport callbacks to avoid 
   deadlocks. This fixes the long-standing issue #3084 which prevented using 
   directExecutor() in some tests using streaming RPCs
   - core: Disable retries with in-process transport by default (#9361). 
   In-process does not compute message sizes so can retain excessive amounts 
   of memory
   - bazel: Use valid target name for services and xds when overriding 
   Maven targets (#9422). This fixes an error of the form `no such target 
   '@io_grpc_grpc_java//services:services'` for services and missing ORCA 
   classes for xds. The wrong target names were introduced in 1.47.0
   - xds: channel_id hash policy now uses a random per-channel id instead 
   of an incrementing one. The incrementing id was the same for every process 
   of a binary, which was not the intention (#9453)
   - core: Fix a bug that the server stream should not deliver halfClose() 
   when the call is immediately canceled. The bug causes a bad message 
   INTERNAL, desc: Half-closed without a request at server call. (#9362)
   - xds: Remove shaded orca proto dependency in ORCA api. The shading was 
   broken and couldn't really be used. (#9366)

*Behavior Changes*


   - gcp-observability: Interceptors are now injected in more situations, 
   including for non-Netty transports and when using transport-specific APIs 
   like NettyChannelBuilder. (#9309 #9312 #9424)
   - gcp-observability: custom tags now extended to metrics and traces 
   (#9402 #9407)
   - gcp-observability: excludes RPCs into Google Cloud Ops backend for 
   instrumentation (#9436)
   - xds: xdsNameResolver now matches channel overrideAuthority in 
   virtualHost matching (#9405)

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/983252f3-aaf6-4c73-ad9f-bf28aab990cdn%40googlegroups.com.

Re: [ovs-discuss] Unreasonably often OVS DB compaction

[Terry Wilson]

You'll need to use ovs 2.17 (at least python-ovs 2.17) to use raft
effectively. Leader transfer on compaction will cause disconnected
clients, and before python-ovs 2.17, monitor-cond-since/update3
support was not there to make the reconnect happen using a snapshot
instead of a full dump of the db from ovsdb-server.

Terry

On Wed, Aug 3, 2022 at 10:44 AM Oleksandr Mykhalskyi via discuss
 wrote:
>
> Dear openvswitch developers,
>
>
>
> After recent update of our openstack wallaby cloud, when OVS was updated from 
> 2.15.0 to 2.15.2, we observe new OVS DB behavior with often (every 10-20 min) 
> transferring leadership in raft cluster.
>
> Transferring leadership was implemented by 
> https://patchwork.ozlabs.org/project/openvswitch/patch/20210506124731.3599531-1-i.maxim...@ovn.org/#2682913
>
> It caused a lot of errors in our cloud, with neutron <-> OVN interaction.
>
>
>
> First of all, we have to schedule regular (every 10min) manual compaction to 
> avoid transferring leadership, which is unnecessary for us.
>
> Then, we tried to find out, why OVN database triggers compacting so often and 
> we can see next things:
>
>
>
> 1)  After restart of all OVN SB DB instances in raft cluster, there is no 
> compaction for about 20-24 hours;
>
>
>
> 2)  First time, compaction starts after 24 hours, or earlier after 
> doubling of DB size (after restart, DB size was 105MB, compaction was 
> triggered after DB size ~ 210MB);
>
>
>
> 3)  After this first compaction,  we have next compactions every 10-20 
> min. But it’s unclear why?
>
> In http://www.openvswitch.org/support/dist-docs/ovsdb-server.1.txt we have 
> next description - “A database is also compacted automatically when a 
> transaction is logged if it is over 2 times as  large as its previous 
> compacted size (and at least 10  MB)”.
>
> But according  our usual activity (below), SB DB should not trigger 
> compaction every 10-20 min, because during 10 min we have DB growth ~ 1Mb 
> only:
>
>
>
> Wed 03 Aug 2022 07:50:14 AM EDT
>
>
>
> # ls -l  /var/lib/docker/volumes/ovn_sb_db/_data/ovnsb.db
>
> -rw-r- 1 root root 105226017 Aug  3 07:50 
> /var/lib/docker/volumes/ovn_sb_db/_data/ovnsb.db
>
>
>
> # docker exec ovn_sb_db ovs-appctl -t /var/run/ovn/ovnsb_db.ctl memory/show
>
> cells:2422190 monitors:8 raft-connections:4 raft-log:2 sessions:88
>
>
>
> # docker exec ovn_sb_db ovsdb-tool show-log 
> /var/lib/openvswitch/ovn-sb/ovnsb.db   | grep -c record
>
> 6
>
>
>
> Wed 03 Aug 2022 07:59:39 AM EDT
>
>
>
> # ls -l  /var/lib/docker/volumes/ovn_sb_db/_data/ovnsb.db
>
> -rw-r- 1 root root 106027676 Aug  3 07:59 
> /var/lib/docker/volumes/ovn_sb_db/_data/ovnsb.db
>
>
>
> docker exec ovn_sb_db ovs-appctl -t /var/run/ovn/ovnsb_db.ctl memory/show
>
> cells:2422190 monitors:8 raft-connections:4 raft-log:1925 sessions:88
>
>
>
> # docker exec ovn_sb_db ovsdb-tool show-log 
> /var/lib/openvswitch/ovn-sb/ovnsb.db   | grep -c record
>
> 3852
>
>
>
> 4)  After investigation of old logs, we realized that we had often 
> compaction in OVS 2.15.0 also, for a long time, according regular messages 
> like “Unreasonably long 2939ms poll interval” (every 10-20 min). We just 
> didn`t see impact/errors from this compaction, like with patch “transferring 
> leadership”.
>
>
>
>
>
> Could you please help to find out – is it some bug with compaction trigger or 
> expected behaviour?
>
>
>
> P.S.  It would be good to have a choice in OVSDB – do we want to use 
> transferring leadership or no.
>
>
>
> Thank you.
>
>
>
>
>
> Oleksandr Mykhalskyi, System Engineer
> Netcracker Technology
>
>
>
>
>
>
> 
> The information transmitted herein is intended only for the person or entity 
> to which it is addressed and may contain confidential, proprietary and/or 
> privileged material. Any review, retransmission, dissemination or other use 
> of, or taking of any action in reliance upon, this information by persons or 
> entities other than the intended recipient is prohibited. If you received 
> this in error, please contact the sender and delete the material from any 
> computer.
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-dev] [PATCH ovsdb v1] Add CLI remote confiuration parity with DB

[Terry Wilson]

Several remote config options are configurable via the DB, e.g.
inactivity_probe and max_backoff. This patch adds the ability to
configure these options via the CLI as well, e.g.:

  --remote="pssl:6640;inactivity_probe=1,max_backoff=4000"

Signed-off-by: Terry Wilson 
---
 ovsdb/ovsdb-server.1.in |  4 
 ovsdb/ovsdb-server.c| 42 -
 2 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/ovsdb/ovsdb-server.1.in b/ovsdb/ovsdb-server.1.in
index da7a6fd5d..aaa3059a9 100644
--- a/ovsdb/ovsdb-server.1.in
+++ b/ovsdb/ovsdb-server.1.in
@@ -103,6 +103,10 @@ It is an error for \fIcolumn\fR to have another type.
 .RE
 .
 .IP
+When specifying a remote via the CLI, the options configurable via the
+above columns may be added as a comma-separated list following a
+semi-colon, e.g. \fB"pssl:6640;inactivity_probe=1,max_backoff=4000"\fR.
+
 To connect or listen on multiple connection methods, use multiple
 \fB\-\-remote\fR options.
 .
diff --git a/ovsdb/ovsdb-server.c b/ovsdb/ovsdb-server.c
index 5549b4e3a..0e0d45fa1 100644
--- a/ovsdb/ovsdb-server.c
+++ b/ovsdb/ovsdb-server.c
@@ -998,6 +998,46 @@ add_manager_options(struct shash *remotes, const struct 
ovsdb_row *row)
 }
 }
 
+static void
+add_cli_remote(struct shash *remotes, const char *target_str)
+{
+struct ovsdb_jsonrpc_options *options;
+char *save_ptr = NULL;
+char *target;
+char *opt;
+
+target = xstrdup(target_str);
+strtok_r(target, ";", _ptr);
+options = add_remote(remotes, target);
+for (opt = strtok_r(NULL, ",", _ptr); opt != NULL;
+ opt = strtok_r(NULL, ",", _ptr)) {
+char *save_ptr2 = NULL;
+char *key, *value;
+
+key = strtok_r(opt, "=", _ptr2);
+value = strtok_r(NULL, ",", _ptr2);
+if (value == NULL) {
+continue;
+}
+if (!strcmp(key, "max_backoff")) {
+options->max_backoff = atoi(value);
+} else if (!strcmp(key, "inactivity_probe")) {
+options->probe_interval = atoi(value);
+} else if (!strcmp(key, "read_only")) {
+options->read_only = !strcmp(value, "true");
+} else if (!strcmp(key, "role")) {
+free(options->role);
+options->role = xstrdup(value);
+} else if (!strcmp(key, "dscp")) {
+int dscp = atoi(value);
+if (dscp >= 0 && dscp <= 63) {
+options->dscp = dscp;
+}
+}
+}
+free(target);
+}
+
 static void
 query_db_remotes(const char *name, const struct shash *all_dbs,
  struct shash *remotes, struct ds *errors)
@@ -1308,7 +1348,7 @@ reconfigure_remotes(struct ovsdb_jsonrpc_server *jsonrpc,
 if (!strncmp(name, "db:", 3)) {
 query_db_remotes(name, all_dbs, _remotes, );
 } else {
-add_remote(_remotes, name);
+add_cli_remote(_remotes, name);
 }
 }
 ovsdb_jsonrpc_server_set_remotes(jsonrpc, _remotes);
-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v4 ovsdb 1/1] Add ovs-confctl utility for Local_Config db

[Terry Wilson]

This adds ovs-confctl to configure DBs running the Local_Config
schema added in 6f24c2bc7.

Signed-off-by: Terry Wilson 
---
 debian/openvswitch-common.install  |   1 +
 debian/openvswitch-common.manpages |   1 +
 lib/.gitignore |   3 +
 lib/automake.mk|   8 +
 lib/ovsconf-idl.ann|   9 +
 rhel/openvswitch.spec.in   |   2 +
 tests/automake.mk  |   1 +
 tests/ovs-confctl.at   |  58 +++
 tests/testsuite.at |   1 +
 utilities/.gitignore   |   2 +
 utilities/automake.mk  |   8 +
 utilities/ovs-confctl.8.xml| 213 +
 utilities/ovs-confctl.c| 726 +
 13 files changed, 1033 insertions(+)
 create mode 100644 lib/ovsconf-idl.ann
 create mode 100644 tests/ovs-confctl.at
 create mode 100644 utilities/ovs-confctl.8.xml
 create mode 100644 utilities/ovs-confctl.c

diff --git a/debian/openvswitch-common.install 
b/debian/openvswitch-common.install
index 3264ea53c..32acdb9b6 100644
--- a/debian/openvswitch-common.install
+++ b/debian/openvswitch-common.install
@@ -1,5 +1,6 @@
 etc/bash_completion.d/ovs-appctl-bashcomp.bash
 usr/bin/ovs-appctl
+usr/bin/ovs-confctl
 usr/bin/ovs-docker
 usr/bin/ovs-ofctl
 usr/bin/ovs-parse-backtrace
diff --git a/debian/openvswitch-common.manpages 
b/debian/openvswitch-common.manpages
index 95004122c..73c125af2 100644
--- a/debian/openvswitch-common.manpages
+++ b/debian/openvswitch-common.manpages
@@ -2,6 +2,7 @@ ovsdb/ovsdb-client.1
 ovsdb/ovsdb-tool.1
 utilities/bugtool/ovs-bugtool.8
 debian/tmp/usr/share/man/man8/ovs-appctl.8
+utilities/ovs-confctl.8
 utilities/ovs-ofctl.8
 debian/tmp/usr/share/man/man8/ovs-parse-backtrace.8
 debian/tmp/usr/share/man/man8/ovs-pki.8
diff --git a/lib/.gitignore b/lib/.gitignore
index ec9bdb092..c165deb72 100644
--- a/lib/.gitignore
+++ b/lib/.gitignore
@@ -8,6 +8,9 @@
 /ofp-actions.inc2
 /ofp-errors.inc
 /ofp-msgs.inc
+/ovsconf-idl.c
+/ovsconf-idl.h
+/ovsconf-idl.ovsidl
 /ovsdb-server-idl.c
 /ovsdb-server-idl.h
 /ovsdb-server-idl.ovsidl
diff --git a/lib/automake.mk b/lib/automake.mk
index 1d00cfa20..816fa1c99 100644
--- a/lib/automake.mk
+++ b/lib/automake.mk
@@ -426,6 +426,8 @@ nodist_lib_libopenvswitch_la_SOURCES = \
lib/dirs.c \
lib/ovsdb-server-idl.c \
lib/ovsdb-server-idl.h \
+   lib/ovsconf-idl.c \
+   lib/ovsconf-idl.h \
lib/vswitch-idl.c \
lib/vswitch-idl.h
 CLEANFILES += $(nodist_lib_libopenvswitch_la_SOURCES)
@@ -612,6 +614,12 @@ EXTRA_DIST += lib/vswitch-idl.ann
 lib/vswitch-idl.ovsidl: vswitchd/vswitch.ovsschema lib/vswitch-idl.ann
$(AM_V_GEN)$(OVSDB_IDLC) annotate $(srcdir)/vswitchd/vswitch.ovsschema 
$(srcdir)/lib/vswitch-idl.ann > $@.tmp && mv $@.tmp $@
 
+# local-config IDL
+OVSIDL_BUILT += lib/ovsconf-idl.c lib/ovsconf-idl.h lib/ovsconf-idl.ovsidl
+EXTRA_DIST += lib/ovsconf-idl.ann
+lib/ovsconf-idl.ovsidl: ovsdb/local-config.ovsschema lib/ovsconf-idl.ann
+   $(AM_V_GEN)$(OVSDB_IDLC) annotate 
$(srcdir)/ovsdb/local-config.ovsschema $(srcdir)/lib/ovsconf-idl.ann > $@.tmp 
&& mv $@.tmp $@
+
 lib/dirs.c: lib/dirs.c.in Makefile
$(AM_V_GEN)($(ro_c) && sed < $(srcdir)/lib/dirs.c.in \
-e 's,[@]srcdir[@],$(srcdir),g' \
diff --git a/lib/ovsconf-idl.ann b/lib/ovsconf-idl.ann
new file mode 100644
index 0..6c948d3b9
--- /dev/null
+++ b/lib/ovsconf-idl.ann
@@ -0,0 +1,9 @@
+# -*- python -*-
+
+# This code, when invoked by "ovsdb-idlc annotate" (by the build
+# process), annotates local-config.ovsschema with additional data that give
+# the ovsdb-idl engine information about the types involved, so that
+# it can generate more programmer-friendly data structures.
+
+s["idlPrefix"] = "ovsconf_"
+s["idlHeader"] = "\"lib/ovsconf-idl.h\""
diff --git a/rhel/openvswitch.spec.in b/rhel/openvswitch.spec.in
index 2d8ff18bb..34a64f5a0 100644
--- a/rhel/openvswitch.spec.in
+++ b/rhel/openvswitch.spec.in
@@ -206,6 +206,7 @@ exit 0
 /etc/sysconfig/network-scripts/ifup-ovs
 /etc/sysconfig/network-scripts/ifdown-ovs
 /usr/bin/ovs-appctl
+/usr/bin/ovs-confctl
 /usr/bin/ovs-dpctl
 /usr/bin/ovs-dpctl-top
 /usr/bin/ovs-docker
@@ -240,6 +241,7 @@ exit 0
 %{_mandir}/man7/ovsdb-server.7*
 /usr/share/man/man8/ovs-appctl.8.gz
 /usr/share/man/man8/ovs-bugtool.8.gz
+/usr/share/man/man8/ovs-confctl.8.gz
 /usr/share/man/man8/ovs-ctl.8.gz
 /usr/share/man/man8/ovs-dpctl.8.gz
 /usr/share/man/man8/ovs-dpctl-top.8.gz
diff --git a/tests/automake.mk b/tests/automake.mk
index b29cb783e..48130cd5b 100644
--- a/tests/automake.mk
+++ b/tests/automake.mk
@@ -98,6 +98,7 @@ TESTSUITE_AT = \
tests/ovsdb-idl.at \
tests/ovsdb-lock.at \
tests/ovsdb-rbac.at \
+   tests/ovs-confctl.at \
tests/ovs-vsctl.at \
tests/ovs-xapi-sync.at \
tests/stp.at \
diff --git a/tests/ovs-confctl.at b/tests

[ovs-dev] [PATCH v3 ovsdb 1/1] Add ovs-confctl utility for Local_Config db

[Terry Wilson]

This adds ovs-confctl to configure DBs running the Local_Config
schema added in 6f24c2bc7.

Signed-off-by: Terry Wilson 
---
 debian/openvswitch-common.install  |   1 +
 debian/openvswitch-common.manpages |   1 +
 lib/.gitignore |   3 +
 lib/automake.mk|   8 +
 lib/ovsconf-idl.ann|   9 +
 rhel/openvswitch.spec.in   |   2 +
 tests/automake.mk  |   1 +
 tests/ovs-confctl.at   |  58 +++
 tests/testsuite.at |   1 +
 utilities/.gitignore   |   2 +
 utilities/automake.mk  |   8 +
 utilities/ovs-confctl.8.xml| 213 +
 utilities/ovs-confctl.c| 726 +
 13 files changed, 1033 insertions(+)
 create mode 100644 lib/ovsconf-idl.ann
 create mode 100644 tests/ovs-confctl.at
 create mode 100644 utilities/ovs-confctl.8.xml
 create mode 100644 utilities/ovs-confctl.c

diff --git a/debian/openvswitch-common.install 
b/debian/openvswitch-common.install
index 3264ea53c..32acdb9b6 100644
--- a/debian/openvswitch-common.install
+++ b/debian/openvswitch-common.install
@@ -1,5 +1,6 @@
 etc/bash_completion.d/ovs-appctl-bashcomp.bash
 usr/bin/ovs-appctl
+usr/bin/ovs-confctl
 usr/bin/ovs-docker
 usr/bin/ovs-ofctl
 usr/bin/ovs-parse-backtrace
diff --git a/debian/openvswitch-common.manpages 
b/debian/openvswitch-common.manpages
index 95004122c..73c125af2 100644
--- a/debian/openvswitch-common.manpages
+++ b/debian/openvswitch-common.manpages
@@ -2,6 +2,7 @@ ovsdb/ovsdb-client.1
 ovsdb/ovsdb-tool.1
 utilities/bugtool/ovs-bugtool.8
 debian/tmp/usr/share/man/man8/ovs-appctl.8
+utilities/ovs-confctl.8
 utilities/ovs-ofctl.8
 debian/tmp/usr/share/man/man8/ovs-parse-backtrace.8
 debian/tmp/usr/share/man/man8/ovs-pki.8
diff --git a/lib/.gitignore b/lib/.gitignore
index ec9bdb092..c165deb72 100644
--- a/lib/.gitignore
+++ b/lib/.gitignore
@@ -8,6 +8,9 @@
 /ofp-actions.inc2
 /ofp-errors.inc
 /ofp-msgs.inc
+/ovsconf-idl.c
+/ovsconf-idl.h
+/ovsconf-idl.ovsidl
 /ovsdb-server-idl.c
 /ovsdb-server-idl.h
 /ovsdb-server-idl.ovsidl
diff --git a/lib/automake.mk b/lib/automake.mk
index 1d00cfa20..1f087c96e 100644
--- a/lib/automake.mk
+++ b/lib/automake.mk
@@ -426,6 +426,8 @@ nodist_lib_libopenvswitch_la_SOURCES = \
lib/dirs.c \
lib/ovsdb-server-idl.c \
lib/ovsdb-server-idl.h \
+   lib/ovsconf-idl.c \
+   lib/ovsconf-idl.h \
lib/vswitch-idl.c \
lib/vswitch-idl.h
 CLEANFILES += $(nodist_lib_libopenvswitch_la_SOURCES)
@@ -612,6 +614,12 @@ EXTRA_DIST += lib/vswitch-idl.ann
 lib/vswitch-idl.ovsidl: vswitchd/vswitch.ovsschema lib/vswitch-idl.ann
$(AM_V_GEN)$(OVSDB_IDLC) annotate $(srcdir)/vswitchd/vswitch.ovsschema 
$(srcdir)/lib/vswitch-idl.ann > $@.tmp && mv $@.tmp $@
 
+# local-config IDL
+OVSIDL_BUILT += lib/ovsconf-idl.c lib/ovsconf-idl.h lib/obsconf-idl.ovsidl
+EXTRA_DIST += lib/ovsconf-idl.ann
+lib/ovsconf-idl.ovsidl: ovsdb/local-config.ovsschema lib/ovsconf-idl.ann
+   $(AM_V_GEN)$(OVSDB_IDLC) annotate 
$(srcdir)/ovsdb/local-config.ovsschema $(srcdir)/lib/ovsconf-idl.ann > $@.tmp 
&& mv $@.tmp $@
+
 lib/dirs.c: lib/dirs.c.in Makefile
$(AM_V_GEN)($(ro_c) && sed < $(srcdir)/lib/dirs.c.in \
-e 's,[@]srcdir[@],$(srcdir),g' \
diff --git a/lib/ovsconf-idl.ann b/lib/ovsconf-idl.ann
new file mode 100644
index 0..6c948d3b9
--- /dev/null
+++ b/lib/ovsconf-idl.ann
@@ -0,0 +1,9 @@
+# -*- python -*-
+
+# This code, when invoked by "ovsdb-idlc annotate" (by the build
+# process), annotates local-config.ovsschema with additional data that give
+# the ovsdb-idl engine information about the types involved, so that
+# it can generate more programmer-friendly data structures.
+
+s["idlPrefix"] = "ovsconf_"
+s["idlHeader"] = "\"lib/ovsconf-idl.h\""
diff --git a/rhel/openvswitch.spec.in b/rhel/openvswitch.spec.in
index 2d8ff18bb..34a64f5a0 100644
--- a/rhel/openvswitch.spec.in
+++ b/rhel/openvswitch.spec.in
@@ -206,6 +206,7 @@ exit 0
 /etc/sysconfig/network-scripts/ifup-ovs
 /etc/sysconfig/network-scripts/ifdown-ovs
 /usr/bin/ovs-appctl
+/usr/bin/ovs-confctl
 /usr/bin/ovs-dpctl
 /usr/bin/ovs-dpctl-top
 /usr/bin/ovs-docker
@@ -240,6 +241,7 @@ exit 0
 %{_mandir}/man7/ovsdb-server.7*
 /usr/share/man/man8/ovs-appctl.8.gz
 /usr/share/man/man8/ovs-bugtool.8.gz
+/usr/share/man/man8/ovs-confctl.8.gz
 /usr/share/man/man8/ovs-ctl.8.gz
 /usr/share/man/man8/ovs-dpctl.8.gz
 /usr/share/man/man8/ovs-dpctl-top.8.gz
diff --git a/tests/automake.mk b/tests/automake.mk
index b29cb783e..48130cd5b 100644
--- a/tests/automake.mk
+++ b/tests/automake.mk
@@ -98,6 +98,7 @@ TESTSUITE_AT = \
tests/ovsdb-idl.at \
tests/ovsdb-lock.at \
tests/ovsdb-rbac.at \
+   tests/ovs-confctl.at \
tests/ovs-vsctl.at \
tests/ovs-xapi-sync.at \
tests/stp.at \
diff --git a/tests/ovs-confctl.at b/tests

[ovs-dev] [PATCH v2 ovsdb 1/1] Add ovs-confctl utility for Local_Config db

[Terry Wilson]

This adds ovs-confctl to configure DBs running the Local_Config
schema added in 6f24c2bc7.

Signed-off-by: Terry Wilson 
---
 debian/openvswitch-common.install  |   1 +
 debian/openvswitch-common.manpages |   1 +
 lib/.gitignore |   3 +
 lib/automake.mk|   8 +
 lib/ovsconf-idl.ann|   9 +
 rhel/openvswitch.spec.in   |   2 +
 tests/automake.mk  |   1 +
 tests/ovs-confctl.at   |  58 +++
 tests/testsuite.at |   1 +
 utilities/.gitignore   |   2 +
 utilities/automake.mk  |   8 +
 utilities/ovs-confctl.8.xml| 213 +
 utilities/ovs-confctl.c| 726 +
 13 files changed, 1033 insertions(+)
 create mode 100644 lib/ovsconf-idl.ann
 create mode 100644 tests/ovs-confctl.at
 create mode 100644 utilities/ovs-confctl.8.xml
 create mode 100644 utilities/ovs-confctl.c

diff --git a/debian/openvswitch-common.install 
b/debian/openvswitch-common.install
index 3264ea53c..32acdb9b6 100644
--- a/debian/openvswitch-common.install
+++ b/debian/openvswitch-common.install
@@ -1,5 +1,6 @@
 etc/bash_completion.d/ovs-appctl-bashcomp.bash
 usr/bin/ovs-appctl
+usr/bin/ovs-confctl
 usr/bin/ovs-docker
 usr/bin/ovs-ofctl
 usr/bin/ovs-parse-backtrace
diff --git a/debian/openvswitch-common.manpages 
b/debian/openvswitch-common.manpages
index 95004122c..73c125af2 100644
--- a/debian/openvswitch-common.manpages
+++ b/debian/openvswitch-common.manpages
@@ -2,6 +2,7 @@ ovsdb/ovsdb-client.1
 ovsdb/ovsdb-tool.1
 utilities/bugtool/ovs-bugtool.8
 debian/tmp/usr/share/man/man8/ovs-appctl.8
+utilities/ovs-confctl.8
 utilities/ovs-ofctl.8
 debian/tmp/usr/share/man/man8/ovs-parse-backtrace.8
 debian/tmp/usr/share/man/man8/ovs-pki.8
diff --git a/lib/.gitignore b/lib/.gitignore
index ec9bdb092..c165deb72 100644
--- a/lib/.gitignore
+++ b/lib/.gitignore
@@ -8,6 +8,9 @@
 /ofp-actions.inc2
 /ofp-errors.inc
 /ofp-msgs.inc
+/ovsconf-idl.c
+/ovsconf-idl.h
+/ovsconf-idl.ovsidl
 /ovsdb-server-idl.c
 /ovsdb-server-idl.h
 /ovsdb-server-idl.ovsidl
diff --git a/lib/automake.mk b/lib/automake.mk
index 1d00cfa20..67678b153 100644
--- a/lib/automake.mk
+++ b/lib/automake.mk
@@ -426,6 +426,8 @@ nodist_lib_libopenvswitch_la_SOURCES = \
lib/dirs.c \
lib/ovsdb-server-idl.c \
lib/ovsdb-server-idl.h \
+   lib/ovsconf-idl.c \
+   lib/ovsconf-idl.h \
lib/vswitch-idl.c \
lib/vswitch-idl.h
 CLEANFILES += $(nodist_lib_libopenvswitch_la_SOURCES)
@@ -612,6 +614,12 @@ EXTRA_DIST += lib/vswitch-idl.ann
 lib/vswitch-idl.ovsidl: vswitchd/vswitch.ovsschema lib/vswitch-idl.ann
$(AM_V_GEN)$(OVSDB_IDLC) annotate $(srcdir)/vswitchd/vswitch.ovsschema 
$(srcdir)/lib/vswitch-idl.ann > $@.tmp && mv $@.tmp $@
 
+# local-config IDL
+#CONFIDL_BUILT += lib/ovsconf-idl.c lib/ovsconf-idl.h lib/obsconf-idl.ovsidl
+EXTRA_DIST += lib/ovsconf-idl.ann
+lib/ovsconf-idl.ovsidl: ovsdb/local-config.ovsschema lib/ovsconf-idl.ann
+   $(AM_V_GEN)$(OVSDB_IDLC) annotate 
$(srcdir)/ovsdb/local-config.ovsschema $(srcdir)/lib/ovsconf-idl.ann > $@.tmp 
&& mv $@.tmp $@
+
 lib/dirs.c: lib/dirs.c.in Makefile
$(AM_V_GEN)($(ro_c) && sed < $(srcdir)/lib/dirs.c.in \
-e 's,[@]srcdir[@],$(srcdir),g' \
diff --git a/lib/ovsconf-idl.ann b/lib/ovsconf-idl.ann
new file mode 100644
index 0..6c948d3b9
--- /dev/null
+++ b/lib/ovsconf-idl.ann
@@ -0,0 +1,9 @@
+# -*- python -*-
+
+# This code, when invoked by "ovsdb-idlc annotate" (by the build
+# process), annotates local-config.ovsschema with additional data that give
+# the ovsdb-idl engine information about the types involved, so that
+# it can generate more programmer-friendly data structures.
+
+s["idlPrefix"] = "ovsconf_"
+s["idlHeader"] = "\"lib/ovsconf-idl.h\""
diff --git a/rhel/openvswitch.spec.in b/rhel/openvswitch.spec.in
index 2d8ff18bb..34a64f5a0 100644
--- a/rhel/openvswitch.spec.in
+++ b/rhel/openvswitch.spec.in
@@ -206,6 +206,7 @@ exit 0
 /etc/sysconfig/network-scripts/ifup-ovs
 /etc/sysconfig/network-scripts/ifdown-ovs
 /usr/bin/ovs-appctl
+/usr/bin/ovs-confctl
 /usr/bin/ovs-dpctl
 /usr/bin/ovs-dpctl-top
 /usr/bin/ovs-docker
@@ -240,6 +241,7 @@ exit 0
 %{_mandir}/man7/ovsdb-server.7*
 /usr/share/man/man8/ovs-appctl.8.gz
 /usr/share/man/man8/ovs-bugtool.8.gz
+/usr/share/man/man8/ovs-confctl.8.gz
 /usr/share/man/man8/ovs-ctl.8.gz
 /usr/share/man/man8/ovs-dpctl.8.gz
 /usr/share/man/man8/ovs-dpctl-top.8.gz
diff --git a/tests/automake.mk b/tests/automake.mk
index b29cb783e..48130cd5b 100644
--- a/tests/automake.mk
+++ b/tests/automake.mk
@@ -98,6 +98,7 @@ TESTSUITE_AT = \
tests/ovsdb-idl.at \
tests/ovsdb-lock.at \
tests/ovsdb-rbac.at \
+   tests/ovs-confctl.at \
tests/ovs-vsctl.at \
tests/ovs-xapi-sync.at \
tests/stp.at \
diff --git a/tests/ovs-confctl.at b/t

[ovs-dev] [PATCH ovsdb 1/1] Add ovs-confctl utility for Local_Config db

[Terry Wilson]

This adds ovs-confctl to configure DBs running the Local_Config
schema added in 6f24c2bc7.

Signed-off-by: Terry Wilson 
---
 debian/openvswitch-common.install  |   1 +
 debian/openvswitch-common.manpages |   1 +
 lib/.gitignore |   3 +
 lib/automake.mk|   8 +
 lib/ovsconf-idl.ann|   9 +
 rhel/openvswitch.spec.in   |   2 +
 tests/automake.mk  |   1 +
 tests/ovs-confctl.at   |  58 +++
 tests/testsuite.at |   1 +
 utilities/.gitignore   |   2 +
 utilities/automake.mk  |   8 +
 utilities/ovs-confctl.8.xml| 213 +
 utilities/ovs-confctl.c| 726 +
 13 files changed, 1033 insertions(+)
 create mode 100644 lib/ovsconf-idl.ann
 create mode 100644 tests/ovs-confctl.at
 create mode 100644 utilities/ovs-confctl.8.xml
 create mode 100644 utilities/ovs-confctl.c

diff --git a/debian/openvswitch-common.install 
b/debian/openvswitch-common.install
index 3264ea53c..32acdb9b6 100644
--- a/debian/openvswitch-common.install
+++ b/debian/openvswitch-common.install
@@ -1,5 +1,6 @@
 etc/bash_completion.d/ovs-appctl-bashcomp.bash
 usr/bin/ovs-appctl
+usr/bin/ovs-confctl
 usr/bin/ovs-docker
 usr/bin/ovs-ofctl
 usr/bin/ovs-parse-backtrace
diff --git a/debian/openvswitch-common.manpages 
b/debian/openvswitch-common.manpages
index 95004122c..73c125af2 100644
--- a/debian/openvswitch-common.manpages
+++ b/debian/openvswitch-common.manpages
@@ -2,6 +2,7 @@ ovsdb/ovsdb-client.1
 ovsdb/ovsdb-tool.1
 utilities/bugtool/ovs-bugtool.8
 debian/tmp/usr/share/man/man8/ovs-appctl.8
+utilities/ovs-confctl.8
 utilities/ovs-ofctl.8
 debian/tmp/usr/share/man/man8/ovs-parse-backtrace.8
 debian/tmp/usr/share/man/man8/ovs-pki.8
diff --git a/lib/.gitignore b/lib/.gitignore
index ec9bdb092..c165deb72 100644
--- a/lib/.gitignore
+++ b/lib/.gitignore
@@ -8,6 +8,9 @@
 /ofp-actions.inc2
 /ofp-errors.inc
 /ofp-msgs.inc
+/ovsconf-idl.c
+/ovsconf-idl.h
+/ovsconf-idl.ovsidl
 /ovsdb-server-idl.c
 /ovsdb-server-idl.h
 /ovsdb-server-idl.ovsidl
diff --git a/lib/automake.mk b/lib/automake.mk
index 1d00cfa20..67678b153 100644
--- a/lib/automake.mk
+++ b/lib/automake.mk
@@ -426,6 +426,8 @@ nodist_lib_libopenvswitch_la_SOURCES = \
lib/dirs.c \
lib/ovsdb-server-idl.c \
lib/ovsdb-server-idl.h \
+   lib/ovsconf-idl.c \
+   lib/ovsconf-idl.h \
lib/vswitch-idl.c \
lib/vswitch-idl.h
 CLEANFILES += $(nodist_lib_libopenvswitch_la_SOURCES)
@@ -612,6 +614,12 @@ EXTRA_DIST += lib/vswitch-idl.ann
 lib/vswitch-idl.ovsidl: vswitchd/vswitch.ovsschema lib/vswitch-idl.ann
$(AM_V_GEN)$(OVSDB_IDLC) annotate $(srcdir)/vswitchd/vswitch.ovsschema 
$(srcdir)/lib/vswitch-idl.ann > $@.tmp && mv $@.tmp $@
 
+# local-config IDL
+#CONFIDL_BUILT += lib/ovsconf-idl.c lib/ovsconf-idl.h lib/obsconf-idl.ovsidl
+EXTRA_DIST += lib/ovsconf-idl.ann
+lib/ovsconf-idl.ovsidl: ovsdb/local-config.ovsschema lib/ovsconf-idl.ann
+   $(AM_V_GEN)$(OVSDB_IDLC) annotate 
$(srcdir)/ovsdb/local-config.ovsschema $(srcdir)/lib/ovsconf-idl.ann > $@.tmp 
&& mv $@.tmp $@
+
 lib/dirs.c: lib/dirs.c.in Makefile
$(AM_V_GEN)($(ro_c) && sed < $(srcdir)/lib/dirs.c.in \
-e 's,[@]srcdir[@],$(srcdir),g' \
diff --git a/lib/ovsconf-idl.ann b/lib/ovsconf-idl.ann
new file mode 100644
index 0..6c948d3b9
--- /dev/null
+++ b/lib/ovsconf-idl.ann
@@ -0,0 +1,9 @@
+# -*- python -*-
+
+# This code, when invoked by "ovsdb-idlc annotate" (by the build
+# process), annotates local-config.ovsschema with additional data that give
+# the ovsdb-idl engine information about the types involved, so that
+# it can generate more programmer-friendly data structures.
+
+s["idlPrefix"] = "ovsconf_"
+s["idlHeader"] = "\"lib/ovsconf-idl.h\""
diff --git a/rhel/openvswitch.spec.in b/rhel/openvswitch.spec.in
index 2d8ff18bb..34a64f5a0 100644
--- a/rhel/openvswitch.spec.in
+++ b/rhel/openvswitch.spec.in
@@ -206,6 +206,7 @@ exit 0
 /etc/sysconfig/network-scripts/ifup-ovs
 /etc/sysconfig/network-scripts/ifdown-ovs
 /usr/bin/ovs-appctl
+/usr/bin/ovs-confctl
 /usr/bin/ovs-dpctl
 /usr/bin/ovs-dpctl-top
 /usr/bin/ovs-docker
@@ -240,6 +241,7 @@ exit 0
 %{_mandir}/man7/ovsdb-server.7*
 /usr/share/man/man8/ovs-appctl.8.gz
 /usr/share/man/man8/ovs-bugtool.8.gz
+/usr/share/man/man8/ovs-confctl.8.gz
 /usr/share/man/man8/ovs-ctl.8.gz
 /usr/share/man/man8/ovs-dpctl.8.gz
 /usr/share/man/man8/ovs-dpctl-top.8.gz
diff --git a/tests/automake.mk b/tests/automake.mk
index b29cb783e..48130cd5b 100644
--- a/tests/automake.mk
+++ b/tests/automake.mk
@@ -98,6 +98,7 @@ TESTSUITE_AT = \
tests/ovsdb-idl.at \
tests/ovsdb-lock.at \
tests/ovsdb-rbac.at \
+   tests/ovs-confctl.at \
tests/ovs-vsctl.at \
tests/ovs-xapi-sync.at \
tests/stp.at \
diff --git a/tests/ovs-confctl.at b/t

Re: [ovs-dev] [PATCH ovn v3 1/1] Allow arbitrary args to be passed to called binary

[Terry Wilson]

On Wed, Jun 29, 2022 at 2:40 AM Dumitru Ceara  wrote:
>
> On 6/28/22 17:22, Terry Wilson wrote:
> > On Tue, Jun 28, 2022 at 4:39 AM Dumitru Ceara  wrote:
> >>
> >> On 6/27/22 18:00, Terry Wilson wrote:
> >>> It is common to pass ovn-ctl options via an /etc/sysconfig file.
> >>> It would be useful to be able to pass custom --remote options or
> >>> additional DBs to listen to via this file. This would give end
> >>> users the ability to have more fine-grained control without
> >>> having to modify ovn-ctl.
> >>>
> >>> Signed-off-by: Terry Wilson 
> >>> ---
> >>
> >> Hi Terry,
> >>
> >> For the change itself:
> >>
> >> Acked-by: Dumitru Ceara 
> >
> > Thanks!
> >
> >> While we can make it work for now with this new arbitrary args feature,
> >> for the actual goal, of passing a custom --remote option and additional
> >> DBs to listen to I think we need a follow up.  Currently, when starting
> >> OVN databases, if the database doesn't exist ovn-ctl takes care of
> >> creating it:
> >>
> >> https://github.com/ovn-org/ovn/blob/86684ad759b4f517b8f34fbf7ba8bb8ed77bb575/utilities/ovn-ctl#L246
> >> (raft)
> >>
> >> https://github.com/ovn-org/ovn/blob/86684ad759b4f517b8f34fbf7ba8bb8ed77bb575/utilities/ovn-ctl#L249
> >> (standalone)
> >>
> >> In the future, after [0] is accepted, can we add a patch that changes
> >> ovn-ctl to check if the local_config.ovsschema file is installed?  If it
> >> is and if DB_*_USE_REMOTE_IN_DB=yes it could then create the
> >> corresponding local_config database if not already found in $ovn_dbdir
> >> and automatically add the --remote and new db file args.
> >>
> >> What do you think?
> >
> > Something like that sounds good to me. With this I was looking for
> > something that would not specifically require the ovs change, but
> > would still let me solve the problem if I needed to pass the
> > schema/create the db locally. And in general it's useful to be able to
> > pass through some options.
> >
>
> Agreed.
>
> > I hadn't originally planned to use Local_Config just because it
> > existed--I can imagine situations where you have a manually added
> > Connection or custom set things like inactivity_probe set up in the
> > main DB, and if ovn-ctl now notices you have a Local_Config schema, it
> > stops using the original table and you lose whatever was in the
> > original db. So I was thinking of an additional --use-local-config
> > kind of option to opt into using it.
> >
>
> Also fine, in my opinion.  Will you be working on adding this support to
> ovn-ctl?

Yeah, I can do that.

> Thanks!
>
> >> Thanks,
> >> Dumitru
> >>
> >>>  utilities/ovn-ctl   | 22 ++
> >>>  utilities/ovn-ctl.8.xml | 14 +-
> >>>  2 files changed, 35 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/utilities/ovn-ctl b/utilities/ovn-ctl
> >>> index 23d4d7f8c..93be9b84b 100755
> >>> --- a/utilities/ovn-ctl
> >>> +++ b/utilities/ovn-ctl
> >>> @@ -311,6 +311,10 @@ $cluster_remote_port
> >>>  set "$@" --sync-from=`cat $active_conf_file`
> >>>  fi
> >>>
> >>> +if test X"$extra_args" != X; then
> >>> +set "$@" $extra_args
> >>> +fi
> >>> +
> >>>  local run_ovsdb_in_bg="no"
> >>>  local process_id=
> >>>  if test X$detach = Xno && test $mode = cluster && test -z 
> >>> "$cluster_remote_addr" ; then
> >>> @@ -541,6 +545,10 @@ start_ic () {
> >>>
> >>>  set "$@" $OVN_IC_LOG $ovn_ic_params
> >>>
> >>> +if test X"$extra_args" != X; then
> >>> +set "$@" $extra_args
> >>> +fi
> >>> +
> >>>  OVS_RUNDIR=${OVS_RUNDIR} start_ovn_daemon "$OVN_IC_PRIORITY" 
> >>> "$OVN_IC_WRAPPER" "$@"
> >>>  fi
> >>>  }
> >>> @@ -563,6 +571,10 @@ start_controller () {
> >>>
> >>>  [ "$OVN_USER" != "" ] && set "$@" --user "$OVN_USER"
> >>>
> >>> +if test X"$extra_args" != X; then
> >>

Re: [ovs-dev] [PATCH ovn v3 1/1] Allow arbitrary args to be passed to called binary

[Terry Wilson]

On Tue, Jun 28, 2022 at 4:39 AM Dumitru Ceara  wrote:
>
> On 6/27/22 18:00, Terry Wilson wrote:
> > It is common to pass ovn-ctl options via an /etc/sysconfig file.
> > It would be useful to be able to pass custom --remote options or
> > additional DBs to listen to via this file. This would give end
> > users the ability to have more fine-grained control without
> > having to modify ovn-ctl.
> >
> > Signed-off-by: Terry Wilson 
> > ---
>
> Hi Terry,
>
> For the change itself:
>
> Acked-by: Dumitru Ceara 

Thanks!

> While we can make it work for now with this new arbitrary args feature,
> for the actual goal, of passing a custom --remote option and additional
> DBs to listen to I think we need a follow up.  Currently, when starting
> OVN databases, if the database doesn't exist ovn-ctl takes care of
> creating it:
>
> https://github.com/ovn-org/ovn/blob/86684ad759b4f517b8f34fbf7ba8bb8ed77bb575/utilities/ovn-ctl#L246
> (raft)
>
> https://github.com/ovn-org/ovn/blob/86684ad759b4f517b8f34fbf7ba8bb8ed77bb575/utilities/ovn-ctl#L249
> (standalone)
>
> In the future, after [0] is accepted, can we add a patch that changes
> ovn-ctl to check if the local_config.ovsschema file is installed?  If it
> is and if DB_*_USE_REMOTE_IN_DB=yes it could then create the
> corresponding local_config database if not already found in $ovn_dbdir
> and automatically add the --remote and new db file args.
>
> What do you think?

Something like that sounds good to me. With this I was looking for
something that would not specifically require the ovs change, but
would still let me solve the problem if I needed to pass the
schema/create the db locally. And in general it's useful to be able to
pass through some options.

I hadn't originally planned to use Local_Config just because it
existed--I can imagine situations where you have a manually added
Connection or custom set things like inactivity_probe set up in the
main DB, and if ovn-ctl now notices you have a Local_Config schema, it
stops using the original table and you lose whatever was in the
original db. So I was thinking of an additional --use-local-config
kind of option to opt into using it.

> Thanks,
> Dumitru
>
> >  utilities/ovn-ctl   | 22 ++
> >  utilities/ovn-ctl.8.xml | 14 +-
> >  2 files changed, 35 insertions(+), 1 deletion(-)
> >
> > diff --git a/utilities/ovn-ctl b/utilities/ovn-ctl
> > index 23d4d7f8c..93be9b84b 100755
> > --- a/utilities/ovn-ctl
> > +++ b/utilities/ovn-ctl
> > @@ -311,6 +311,10 @@ $cluster_remote_port
> >  set "$@" --sync-from=`cat $active_conf_file`
> >  fi
> >
> > +if test X"$extra_args" != X; then
> > +set "$@" $extra_args
> > +fi
> > +
> >  local run_ovsdb_in_bg="no"
> >  local process_id=
> >  if test X$detach = Xno && test $mode = cluster && test -z 
> > "$cluster_remote_addr" ; then
> > @@ -541,6 +545,10 @@ start_ic () {
> >
> >  set "$@" $OVN_IC_LOG $ovn_ic_params
> >
> > +if test X"$extra_args" != X; then
> > +set "$@" $extra_args
> > +fi
> > +
> >  OVS_RUNDIR=${OVS_RUNDIR} start_ovn_daemon "$OVN_IC_PRIORITY" 
> > "$OVN_IC_WRAPPER" "$@"
> >  fi
> >  }
> > @@ -563,6 +571,10 @@ start_controller () {
> >
> >  [ "$OVN_USER" != "" ] && set "$@" --user "$OVN_USER"
> >
> > +if test X"$extra_args" != X; then
> > +set "$@" $extra_args
> > +fi
> > +
> >  OVS_RUNDIR=${OVS_RUNDIR} start_ovn_daemon "$OVN_CONTROLLER_PRIORITY" 
> > "$OVN_CONTROLLER_WRAPPER" "$@"
> >  }
> >
> > @@ -590,6 +602,10 @@ start_controller_vtep () {
> >
> >  [ "$OVN_USER" != "" ] && set "$@" --user "$OVN_USER"
> >
> > +if test X"$extra_args" != X; then
> > +set "$@" $extra_args
> > +fi
> > +
> >  OVS_RUNDIR=${OVS_RUNDIR} start_ovn_daemon "$OVN_CONTROLLER_PRIORITY" 
> > "$OVN_CONTROLLER_WRAPPER" "$@"
> >  }
> >
> > @@ -1106,8 +1122,10 @@ EOF
> >
> >  set_defaults
> >  command=
> > +extra_args=
> >  for arg
> >  do
> > +shift
> >  case $arg in
> >  -h | --help)
> >  usage
> > @@ -1130,6 +1148,10 @@ do
> >  

[ovs-dev] [PATCH ovsdb v3 1/1] Add Local_Config schema

[Terry Wilson]

The only way to configure settings on a remote (e.g. inactivity_probe)
is via --remote=db:DB,table,row. There is no way to do this via the
existing CLI options.

For a clustered DB with multiple servers listening on unique addresses
there is no way to store these entries in the DB as the DB is shared.
For example, three servers listening on  1.1.1.1, 1.1.1.2, and 1.1.1.3
respectively would require a Manager/Connection row each, but then
all three servers would try to listen on all three addresses.

It is possible for ovsdb-server to serve multiple databases. This
means that we can have a local "config" database in addition to
the main database we are servering (Open_vSwitch, OVN_Southbound, etc.)
and this patch adds a Local_Config schema that currently just mirrors
the Connection table and a Config table with a 'connections' row that
stores each Connection.

Signed-off-by: Terry Wilson 
---
 NEWS   |   5 +
 debian/openvswitch-common.manpages |   1 +
 ovsdb/.gitignore   |   2 +
 ovsdb/automake.mk  |  21 ++
 ovsdb/local-config.ovsschema   |  43 +
 ovsdb/local-config.xml | 296 +
 rhel/openvswitch-fedora.spec.in|   1 +
 tests/ovsdb-cluster.at |  42 +++-
 8 files changed, 404 insertions(+), 7 deletions(-)
 create mode 100644 ovsdb/local-config.ovsschema
 create mode 100644 ovsdb/local-config.xml

diff --git a/NEWS b/NEWS
index 9fe3f44f4..b9e6f0216 100644
--- a/NEWS
+++ b/NEWS
@@ -32,6 +32,11 @@ Post-v2.17.0
- DPDK:
  * OVS validated with DPDK 21.11.1.  It is recommended to use this version
until further releases.
+   - Local_Config schema added:
+ * Clustered ovsdb-servers listening on unique addresses can pass a second
+   DB created with the new Local_Config schema in order to configure their
+   Connections independent from each other. See the ovsdb.local-config.5
+   manpage for schema details.
 
 
 v2.17.0 - 17 Feb 2022
diff --git a/debian/openvswitch-common.manpages 
b/debian/openvswitch-common.manpages
index 95004122c..7c46a2acf 100644
--- a/debian/openvswitch-common.manpages
+++ b/debian/openvswitch-common.manpages
@@ -5,3 +5,4 @@ debian/tmp/usr/share/man/man8/ovs-appctl.8
 utilities/ovs-ofctl.8
 debian/tmp/usr/share/man/man8/ovs-parse-backtrace.8
 debian/tmp/usr/share/man/man8/ovs-pki.8
+ovsdb/ovsdb.local-config.5
diff --git a/ovsdb/.gitignore b/ovsdb/.gitignore
index fbcefafc6..a4f9d38f1 100644
--- a/ovsdb/.gitignore
+++ b/ovsdb/.gitignore
@@ -1,5 +1,7 @@
 /_server.ovsschema.inc
 /_server.ovsschema.stamp
+/local-config.ovsschema.stamp
+/ovsdb.local-config.5
 /ovsdb-client
 /ovsdb-client.1
 /ovsdb-doc
diff --git a/ovsdb/automake.mk b/ovsdb/automake.mk
index 62cc02686..3b3140102 100644
--- a/ovsdb/automake.mk
+++ b/ovsdb/automake.mk
@@ -148,4 +148,25 @@ ovsdb/ovsdb-server.5: \
$(srcdir)/ovsdb/_server.xml > $@.tmp && \
mv $@.tmp $@
 
+EXTRA_DIST += ovsdb/local-config.ovsschema
+pkgdata_DATA += ovsdb/local-config.ovsschema
+
+# Version checking for local-config.ovsschema.
+ALL_LOCAL += ovsdb/local-config.ovsschema.stamp
+ovsdb/local-config.ovsschema.stamp: ovsdb/local-config.ovsschema
+   $(srcdir)/build-aux/cksum-schema-check $? $@
+CLEANFILES += ovsdb/local-config.ovsschema.stamp
+
+# Local_Config schema documentation
+EXTRA_DIST += ovsdb/local-config.xml
+CLEANFILES += ovsdb/ovsdb.local-config.5
+man_MANS += ovsdb/ovsdb.local-config.5
+ovsdb/ovsdb.local-config.5: \
+   ovsdb/ovsdb-doc ovsdb/ ovsdb/local-config.xml 
ovsdb/local-config.ovsschema
+   $(AM_V_GEN)$(OVSDB_DOC) \
+   --version=$(VERSION) \
+   $(srcdir)/ovsdb/local-config.ovsschema \
+   $(srcdir)/ovsdb/local-config.xml > $@.tmp && \
+   mv $@.tmp $@
+
 EXTRA_DIST += ovsdb/TODO.rst
diff --git a/ovsdb/local-config.ovsschema b/ovsdb/local-config.ovsschema
new file mode 100644
index 0..bd86d0f4f
--- /dev/null
+++ b/ovsdb/local-config.ovsschema
@@ -0,0 +1,43 @@
+{
+"name": "Local_Config",
+"version": "1.0.0",
+"cksum": "2048726482 1858",
+"tables": {
+"Config": {
+"columns": {
+"connections": {
+"type": {"key": {"type": "uuid",
+ "refTable": "Connection"},
+ "min": 0,
+ "max": "unlimited"}}},
+"maxRows": 1,
+"isRoot": true},
+"Connection": {
+"columns": {
+"target": {"type": "string"},
+"max_backoff": {"type": {&quo

[ovs-dev] [PATCH ovn v3 1/1] Allow arbitrary args to be passed to called binary

[Terry Wilson]

It is common to pass ovn-ctl options via an /etc/sysconfig file.
It would be useful to be able to pass custom --remote options or
additional DBs to listen to via this file. This would give end
users the ability to have more fine-grained control without
having to modify ovn-ctl.

Signed-off-by: Terry Wilson 
---
 utilities/ovn-ctl   | 22 ++
 utilities/ovn-ctl.8.xml | 14 +-
 2 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/utilities/ovn-ctl b/utilities/ovn-ctl
index 23d4d7f8c..93be9b84b 100755
--- a/utilities/ovn-ctl
+++ b/utilities/ovn-ctl
@@ -311,6 +311,10 @@ $cluster_remote_port
 set "$@" --sync-from=`cat $active_conf_file`
 fi
 
+if test X"$extra_args" != X; then
+set "$@" $extra_args
+fi
+
 local run_ovsdb_in_bg="no"
 local process_id=
 if test X$detach = Xno && test $mode = cluster && test -z 
"$cluster_remote_addr" ; then
@@ -541,6 +545,10 @@ start_ic () {
 
 set "$@" $OVN_IC_LOG $ovn_ic_params
 
+if test X"$extra_args" != X; then
+set "$@" $extra_args
+fi
+
 OVS_RUNDIR=${OVS_RUNDIR} start_ovn_daemon "$OVN_IC_PRIORITY" 
"$OVN_IC_WRAPPER" "$@"
 fi
 }
@@ -563,6 +571,10 @@ start_controller () {
 
 [ "$OVN_USER" != "" ] && set "$@" --user "$OVN_USER"
 
+if test X"$extra_args" != X; then
+set "$@" $extra_args
+fi
+
 OVS_RUNDIR=${OVS_RUNDIR} start_ovn_daemon "$OVN_CONTROLLER_PRIORITY" 
"$OVN_CONTROLLER_WRAPPER" "$@"
 }
 
@@ -590,6 +602,10 @@ start_controller_vtep () {
 
 [ "$OVN_USER" != "" ] && set "$@" --user "$OVN_USER"
 
+if test X"$extra_args" != X; then
+set "$@" $extra_args
+fi
+
 OVS_RUNDIR=${OVS_RUNDIR} start_ovn_daemon "$OVN_CONTROLLER_PRIORITY" 
"$OVN_CONTROLLER_WRAPPER" "$@"
 }
 
@@ -1106,8 +1122,10 @@ EOF
 
 set_defaults
 command=
+extra_args=
 for arg
 do
+shift
 case $arg in
 -h | --help)
 usage
@@ -1130,6 +1148,10 @@ do
 type=bool
 set_option
 ;;
+--)
+extra_args=$@
+break
+;;
 -*)
 echo >&2 "$0: unknown option \"$arg\" (use --help for help)"
 exit 1
diff --git a/utilities/ovn-ctl.8.xml b/utilities/ovn-ctl.8.xml
index a1d39b22b..42d16fabc 100644
--- a/utilities/ovn-ctl.8.xml
+++ b/utilities/ovn-ctl.8.xml
@@ -4,7 +4,10 @@
 ovn-ctl -- Open Virtual Network northbound daemon lifecycle utility
 
 Synopsis
-ovn-ctl [options] command
+
+  ovn-ctl [options] command
+  [--- extra_args]
+
 
 Description
 This program is intended to be invoked internally by Open Virtual 
Network
@@ -156,6 +159,15 @@
 --db-nb-probe-interval-to-active=Time in 
milliseconds
 --db-sb-probe-interval-to-active=Time in 
milliseconds
 
+ Extra Options 
+
+  Any options after '--' will be passed on to the binary run by
+  command with the exception of start_northd, which can have
+  options specified in ovn-northd-db-params.conf. Any extra_args
+  passed to start_northd will be passed to the ovsdb-servers if
+  --ovn-manage-ovsdb=yes
+
+
 Configuration files
 Following are the optional configuration files. If present, it should 
be located in the etc dir
 
-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] python: Add Python bindings TODO file.

[Terry Wilson]

On Mon, Jun 27, 2022 at 5:44 AM Dumitru Ceara  wrote:
>
> For now include the IDL related TODO items as discussed at:
> https://mail.openvswitch.org/pipermail/ovs-dev/2022-April/393516.html
>
> Signed-off-by: Dumitru Ceara 
> ---
>  python/TODO.rst| 34 ++
>  python/automake.mk |  2 ++
>  2 files changed, 36 insertions(+)
>  create mode 100644 python/TODO.rst
>
> diff --git a/python/TODO.rst b/python/TODO.rst
> new file mode 100644
> index ..3a53489f1280
> --- /dev/null
> +++ b/python/TODO.rst
> @@ -0,0 +1,34 @@
> +..
> +  Licensed under the Apache License, Version 2.0 (the "License"); you may
> +  not use this file except in compliance with the License. You may obtain
> +  a copy of the License at
> +
> +  http://www.apache.org/licenses/LICENSE-2.0
> +
> +  Unless required by applicable law or agreed to in writing, software
> +  distributed under the License is distributed on an "AS IS" BASIS, 
> WITHOUT
> +  WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See 
> the
> +  License for the specific language governing permissions and limitations
> +  under the License.
> +
> +  Convention for heading levels in Open vSwitch documentation:
> +
> +  ===  Heading 0 (reserved for the title in a document)
> +  ---  Heading 1
> +  ~~~  Heading 2
> +  +++  Heading 3
> +  '''  Heading 4
> +
> +  Avoid deeper levels because they do not render well.
> +
> +==
> +Python Bindings To-do List
> +==
> +
> +* IDL:
> +
> +  * Support incremental change tracking monitor mode (equivalent of
> +OVSDB_IDL_TRACK).
> +
> +  * Support write-only-changed monitor mode (equivalent of
> +OVSDB_IDL_WRITE_CHANGED_ONLY).
> diff --git a/python/automake.mk b/python/automake.mk
> index 767512f1757f..89c2ccbb06ae 100644
> --- a/python/automake.mk
> +++ b/python/automake.mk
> @@ -117,3 +117,5 @@ $(srcdir)/python/ovs/dirs.py: python/ovs/dirs.py.template
> mv $@.tmp $@
>  EXTRA_DIST += python/ovs/dirs.py.template
>  CLEANFILES += python/ovs/dirs.py
> +
> +EXTRA_DIST += python/TODO.rst
> --
> 2.31.1
>

Numan's patch for allowing one to specify the uuid via the IDL can go
in here when it's committed as well. :)

Acked-by: Terry Wilson 

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH ovsdb v2 1/1] Add Local_Config schema

[Terry Wilson]

The only way to configure settings on a remote (e.g. inactivity_probe)
is via --remote=db:DB,table,row. There is no way to do this via the
existing CLI options.

For a clustered DB with multiple servers listening on unique addresses
there is no way to store these entries in the DB as the DB is shared.
For example, three servers listening on  1.1.1.1, 1.1.1.2, and 1.1.1.3
respectively would require a Manager/Connection row each, but then
all three servers would try to listen on all three addresses.

It is possible for ovsdb-server to serve multiple databases. This
means that we can have a local "config" database in addition to
the main database we are servering (Open_vSwitch, OVN_Southbound, etc.)
and this patch adds a Local_Config schema that currently just mirrors
the Connection table and a Config table with a 'connections' row that
stores each Connection.

Signed-off-by: Terry Wilson 
---
 NEWS   |   5 +
 debian/openvswitch-common.manpages |   1 +
 ovsdb/.gitignore   |   2 +
 ovsdb/automake.mk  |  20 ++
 ovsdb/local_config.ovsschema   |  43 +
 ovsdb/local_config.xml | 281 +
 rhel/openvswitch-fedora.spec.in|   1 +
 tests/ovsdb-cluster.at |  42 -
 8 files changed, 388 insertions(+), 7 deletions(-)
 create mode 100644 ovsdb/local_config.ovsschema
 create mode 100644 ovsdb/local_config.xml

diff --git a/NEWS b/NEWS
index 9fe3f44f4..b9e6f0216 100644
--- a/NEWS
+++ b/NEWS
@@ -32,6 +32,11 @@ Post-v2.17.0
- DPDK:
  * OVS validated with DPDK 21.11.1.  It is recommended to use this version
until further releases.
+   - Local_Config schema added:
+ * Clustered ovsdb-servers listening on unique addresses can pass a second
+   DB created with the new Local_Config schema in order to configure their
+   Connections independent from each other. See the ovsdb.local-config.5
+   manpage for schema details.
 
 
 v2.17.0 - 17 Feb 2022
diff --git a/debian/openvswitch-common.manpages 
b/debian/openvswitch-common.manpages
index 95004122c..7c46a2acf 100644
--- a/debian/openvswitch-common.manpages
+++ b/debian/openvswitch-common.manpages
@@ -5,3 +5,4 @@ debian/tmp/usr/share/man/man8/ovs-appctl.8
 utilities/ovs-ofctl.8
 debian/tmp/usr/share/man/man8/ovs-parse-backtrace.8
 debian/tmp/usr/share/man/man8/ovs-pki.8
+ovsdb/ovsdb.local-config.5
diff --git a/ovsdb/.gitignore b/ovsdb/.gitignore
index fbcefafc6..747f119a9 100644
--- a/ovsdb/.gitignore
+++ b/ovsdb/.gitignore
@@ -1,5 +1,7 @@
 /_server.ovsschema.inc
 /_server.ovsschema.stamp
+/local_config.ovsschema.stamp
+/ovsdb.local-config.5
 /ovsdb-client
 /ovsdb-client.1
 /ovsdb-doc
diff --git a/ovsdb/automake.mk b/ovsdb/automake.mk
index 62cc02686..c53675a87 100644
--- a/ovsdb/automake.mk
+++ b/ovsdb/automake.mk
@@ -148,4 +148,24 @@ ovsdb/ovsdb-server.5: \
$(srcdir)/ovsdb/_server.xml > $@.tmp && \
mv $@.tmp $@
 
+EXTRA_DIST += ovsdb/local_config.ovsschema
+
+# Version checking for local_config.ovsschema.
+ALL_LOCAL += ovsdb/local_config.ovsschema.stamp
+ovsdb/local_config.ovsschema.stamp: ovsdb/local_config.ovsschema
+   $(srcdir)/build-aux/cksum-schema-check $? $@
+CLEANFILES += ovsdb/local_config.ovsschema.stamp
+
+# Local_Config schema documentation
+EXTRA_DIST += ovsdb/local_config.xml
+CLEANFILES += ovsdb/ovsdb.local-config.5
+man_MANS += ovsdb/ovsdb.local-config.5
+ovsdb/ovsdb.local-config.5: \
+   ovsdb/ovsdb-doc ovsdb/ ovsdb/local_config.xml 
ovsdb/local_config.ovsschema
+   $(AM_V_GEN)$(OVSDB_DOC) \
+   --version=$(VERSION) \
+   $(srcdir)/ovsdb/local_config.ovsschema \
+   $(srcdir)/ovsdb/local_config.xml > $@.tmp && \
+   mv $@.tmp $@
+
 EXTRA_DIST += ovsdb/TODO.rst
diff --git a/ovsdb/local_config.ovsschema b/ovsdb/local_config.ovsschema
new file mode 100644
index 0..bd86d0f4f
--- /dev/null
+++ b/ovsdb/local_config.ovsschema
@@ -0,0 +1,43 @@
+{
+"name": "Local_Config",
+"version": "1.0.0",
+"cksum": "2048726482 1858",
+"tables": {
+"Config": {
+"columns": {
+"connections": {
+"type": {"key": {"type": "uuid",
+ "refTable": "Connection"},
+ "min": 0,
+ "max": "unlimited"}}},
+"maxRows": 1,
+"isRoot": true},
+"Connection": {
+"columns": {
+"target": {"type": "string"},
+"max_backoff": {"type": {"key": {"type": "integer",
+   

[ovs-dev] [PATCH ovsdb 1/1] Add Local_Config schema

[Terry Wilson]

The only way to configure settings on a remote (e.g. inactivity_probe)
is via --remote=db:DB,table,row. There is no way to do this via the
existing CLI options.

For a clustered DB with multiple servers listening on unique addresses
there is no way to store these entries in the DB as the DB is shared.
For example, three servers listening on  1.1.1.1, 1.1.1.2, and 1.1.1.3
respectively would require a Manager/Connection row each, but then
all three servers would try to listen on all three addresses.

It is possible for ovsdb-server to serve multiple databases. This
means that we can have a local "config" database in addition to
the main database we are servering (Open_vSwitch, OVN_Southbound, etc.)
and this patch adds a Local_Config schema that currently just mirrors
the Connection table and a Config table with a 'connections' row that
stores each Connection.

Signed-off-by: Terry Wilson 
---
 ovsdb/.gitignore |   1 +
 ovsdb/automake.mk|  18 ++-
 ovsdb/local_config.ovsschema |  43 ++
 ovsdb/local_config.xml   | 270 +++
 tests/ovsdb-cluster.at   |  42 +-
 5 files changed, 365 insertions(+), 9 deletions(-)
 create mode 100644 ovsdb/local_config.ovsschema
 create mode 100644 ovsdb/local_config.xml

diff --git a/ovsdb/.gitignore b/ovsdb/.gitignore
index fbcefafc6..8361389b8 100644
--- a/ovsdb/.gitignore
+++ b/ovsdb/.gitignore
@@ -1,5 +1,6 @@
 /_server.ovsschema.inc
 /_server.ovsschema.stamp
+/local_config.ovsschema.stamp
 /ovsdb-client
 /ovsdb-client.1
 /ovsdb-doc
diff --git a/ovsdb/automake.mk b/ovsdb/automake.mk
index 62cc02686..6b87ad8ff 100644
--- a/ovsdb/automake.mk
+++ b/ovsdb/automake.mk
@@ -136,16 +136,30 @@ ovsdb/_server.ovsschema.stamp: ovsdb/_server.ovsschema
$(srcdir)/build-aux/cksum-schema-check $? $@
 CLEANFILES += ovsdb/_server.ovsschema.stamp
 
-# _Server schema documentation
+# _Server and Local_Config schema documentation
 EXTRA_DIST += ovsdb/_server.xml
+EXTRA_DIST += ovsdb/local_config.xml
 CLEANFILES += ovsdb/ovsdb-server.5
 man_MANS += ovsdb/ovsdb-server.5
 ovsdb/ovsdb-server.5: \
-   ovsdb/ovsdb-doc ovsdb/_server.xml ovsdb/_server.ovsschema
+   ovsdb/ovsdb-doc ovsdb/_server.xml ovsdb/_server.ovsschema \
+   ovsdb/local_config.ovsschema
$(AM_V_GEN)$(OVSDB_DOC) \
--version=$(VERSION) \
$(srcdir)/ovsdb/_server.ovsschema \
$(srcdir)/ovsdb/_server.xml > $@.tmp && \
+   $(AM_V_GEN)$(OVSDB_DOC) \
+   --version=$(VERSION) \
+   $(srcdir)/ovsdb/local_config.ovsschema \
+   $(srcdir)/ovsdb/local_config.xml >> $@.tmp && \
mv $@.tmp $@
 
+EXTRA_DIST += ovsdb/local_config.ovsschema
+
+# Version checking for local_config.ovsschema.
+ALL_LOCAL += ovsdb/local_config.ovsschema.stamp
+ovsdb/local_config.ovsschema.stamp: ovsdb/local_config.ovsschema
+   $(srcdir)/build-aux/cksum-schema-check $? $@
+CLEANFILES += ovsdb/local_config.ovsschema.stamp
+
 EXTRA_DIST += ovsdb/TODO.rst
diff --git a/ovsdb/local_config.ovsschema b/ovsdb/local_config.ovsschema
new file mode 100644
index 0..bd86d0f4f
--- /dev/null
+++ b/ovsdb/local_config.ovsschema
@@ -0,0 +1,43 @@
+{
+"name": "Local_Config",
+"version": "1.0.0",
+"cksum": "2048726482 1858",
+"tables": {
+"Config": {
+"columns": {
+"connections": {
+"type": {"key": {"type": "uuid",
+ "refTable": "Connection"},
+ "min": 0,
+ "max": "unlimited"}}},
+"maxRows": 1,
+"isRoot": true},
+"Connection": {
+"columns": {
+"target": {"type": "string"},
+"max_backoff": {"type": {"key": {"type": "integer",
+ "minInteger": 1000},
+ "min": 0,
+ "max": 1}},
+"inactivity_probe": {"type": {"key": "integer",
+  "min": 0,
+  "max": 1}},
+"read_only": {"type": "boolean"},
+"role": {"type": "string"},
+"other_config": {"type": {"key": "string",
+  "value": "string",
+   

[ovs-dev] [PATCH ovn v2 1/1] Allow arbitrary args to be passed to called binary

[Terry Wilson]

It is common to pass ovn-ctl options via an /etc/sysconfig file.
It would be useful to be able to pass custom --remote options or
additional DBs to listen to via this file. This would give end
users the ability to have more fine-grained control without
having to modify ovn-ctl.

Signed-off-by: Terry Wilson 
---
 utilities/ovn-ctl   | 22 ++
 utilities/ovn-ctl.8.xml | 10 +-
 2 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/utilities/ovn-ctl b/utilities/ovn-ctl
index 23d4d7f8c..93be9b84b 100755
--- a/utilities/ovn-ctl
+++ b/utilities/ovn-ctl
@@ -311,6 +311,10 @@ $cluster_remote_port
 set "$@" --sync-from=`cat $active_conf_file`
 fi
 
+if test X"$extra_args" != X; then
+set "$@" $extra_args
+fi
+
 local run_ovsdb_in_bg="no"
 local process_id=
 if test X$detach = Xno && test $mode = cluster && test -z 
"$cluster_remote_addr" ; then
@@ -541,6 +545,10 @@ start_ic () {
 
 set "$@" $OVN_IC_LOG $ovn_ic_params
 
+if test X"$extra_args" != X; then
+set "$@" $extra_args
+fi
+
 OVS_RUNDIR=${OVS_RUNDIR} start_ovn_daemon "$OVN_IC_PRIORITY" 
"$OVN_IC_WRAPPER" "$@"
 fi
 }
@@ -563,6 +571,10 @@ start_controller () {
 
 [ "$OVN_USER" != "" ] && set "$@" --user "$OVN_USER"
 
+if test X"$extra_args" != X; then
+set "$@" $extra_args
+fi
+
 OVS_RUNDIR=${OVS_RUNDIR} start_ovn_daemon "$OVN_CONTROLLER_PRIORITY" 
"$OVN_CONTROLLER_WRAPPER" "$@"
 }
 
@@ -590,6 +602,10 @@ start_controller_vtep () {
 
 [ "$OVN_USER" != "" ] && set "$@" --user "$OVN_USER"
 
+if test X"$extra_args" != X; then
+set "$@" $extra_args
+fi
+
 OVS_RUNDIR=${OVS_RUNDIR} start_ovn_daemon "$OVN_CONTROLLER_PRIORITY" 
"$OVN_CONTROLLER_WRAPPER" "$@"
 }
 
@@ -1106,8 +1122,10 @@ EOF
 
 set_defaults
 command=
+extra_args=
 for arg
 do
+shift
 case $arg in
 -h | --help)
 usage
@@ -1130,6 +1148,10 @@ do
 type=bool
 set_option
 ;;
+--)
+extra_args=$@
+break
+;;
 -*)
 echo >&2 "$0: unknown option \"$arg\" (use --help for help)"
 exit 1
diff --git a/utilities/ovn-ctl.8.xml b/utilities/ovn-ctl.8.xml
index a1d39b22b..b287a2f86 100644
--- a/utilities/ovn-ctl.8.xml
+++ b/utilities/ovn-ctl.8.xml
@@ -4,7 +4,7 @@
 ovn-ctl -- Open Virtual Network northbound daemon lifecycle utility
 
 Synopsis
-ovn-ctl [options] command
+ovn-ctl [options] command [-- 
extra_args]
 
 Description
 This program is intended to be invoked internally by Open Virtual 
Network
@@ -156,6 +156,14 @@
 --db-nb-probe-interval-to-active=Time in 
milliseconds
 --db-sb-probe-interval-to-active=Time in 
milliseconds
 
+ Extra Options 
+
+Any options after '--' will be passed on to the binary run by 
command
+with the exception of start_northd, which can have options specified in 
ovn-northd-db-params.conf.
+Any extra_args passed to start_northd will be passed to the 
ovsdb-servers if
+--ovn-manage-ovsdb=yes
+
+
 Configuration files
 Following are the optional configuration files. If present, it should 
be located in the etc dir
 
-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH ovn 1/1] Allow arbitrary args to be passed to called binary

[Terry Wilson]

It is common to pass ovn-ctl options via an /etc/sysconfig file.
It would be useful to be able to pass custom --remote options or
additional DBs to listen to via this file. This would give end
users the ability to have more fine-grained control without
having to modify ovn-ctl.

Signed-off-by: Terry Wilson 
---
 utilities/ovn-ctl   | 22 ++
 utilities/ovn-ctl.8.xml | 10 +-
 2 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/utilities/ovn-ctl b/utilities/ovn-ctl
index 23d4d7f8c..955ddd9a3 100755
--- a/utilities/ovn-ctl
+++ b/utilities/ovn-ctl
@@ -311,6 +311,10 @@ $cluster_remote_port
 set "$@" --sync-from=`cat $active_conf_file`
 fi
 
+if test X"$extra_args" != X; then
+   set "$@" $extra_args
+fi
+
 local run_ovsdb_in_bg="no"
 local process_id=
 if test X$detach = Xno && test $mode = cluster && test -z 
"$cluster_remote_addr" ; then
@@ -541,6 +545,10 @@ start_ic () {
 
 set "$@" $OVN_IC_LOG $ovn_ic_params
 
+if test X"$extra_args" != X; then
+set "$@" $extra_args
+fi
+
 OVS_RUNDIR=${OVS_RUNDIR} start_ovn_daemon "$OVN_IC_PRIORITY" 
"$OVN_IC_WRAPPER" "$@"
 fi
 }
@@ -563,6 +571,10 @@ start_controller () {
 
 [ "$OVN_USER" != "" ] && set "$@" --user "$OVN_USER"
 
+if test X"$extra_args" != X; then
+   set "$@" $extra_args
+fi
+
 OVS_RUNDIR=${OVS_RUNDIR} start_ovn_daemon "$OVN_CONTROLLER_PRIORITY" 
"$OVN_CONTROLLER_WRAPPER" "$@"
 }
 
@@ -590,6 +602,10 @@ start_controller_vtep () {
 
 [ "$OVN_USER" != "" ] && set "$@" --user "$OVN_USER"
 
+if test X"$extra_args" != X; then
+   set "$@" $extra_args
+fi
+
 OVS_RUNDIR=${OVS_RUNDIR} start_ovn_daemon "$OVN_CONTROLLER_PRIORITY" 
"$OVN_CONTROLLER_WRAPPER" "$@"
 }
 
@@ -1106,8 +1122,10 @@ EOF
 
 set_defaults
 command=
+extra_args=
 for arg
 do
+shift
 case $arg in
 -h | --help)
 usage
@@ -1130,6 +1148,10 @@ do
 type=bool
 set_option
 ;;
+--)
+extra_args=$@
+break
+;;
 -*)
 echo >&2 "$0: unknown option \"$arg\" (use --help for help)"
 exit 1
diff --git a/utilities/ovn-ctl.8.xml b/utilities/ovn-ctl.8.xml
index a1d39b22b..b287a2f86 100644
--- a/utilities/ovn-ctl.8.xml
+++ b/utilities/ovn-ctl.8.xml
@@ -4,7 +4,7 @@
 ovn-ctl -- Open Virtual Network northbound daemon lifecycle utility
 
 Synopsis
-ovn-ctl [options] command
+ovn-ctl [options] command [-- 
extra_args]
 
 Description
 This program is intended to be invoked internally by Open Virtual 
Network
@@ -156,6 +156,14 @@
 --db-nb-probe-interval-to-active=Time in 
milliseconds
 --db-sb-probe-interval-to-active=Time in 
milliseconds
 
+ Extra Options 
+
+Any options after '--' will be passed on to the binary run by 
command
+with the exception of start_northd, which can have options specified in 
ovn-northd-db-params.conf.
+Any extra_args passed to start_northd will be passed to the 
ovsdb-servers if
+--ovn-manage-ovsdb=yes
+
+
 Configuration files
 Following are the optional configuration files. If present, it should 
be located in the etc dir
 
-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v5 ovn 2/2] Ensure pid belongs to ovsdb-server in ovn-ctl

[Terry Wilson]

When checking if ovsdb-server is running, ensure that the binary
we are going to run matches the one actually running with the the
pid that was in our pidfile.

Signed-off-by: Terry Wilson 
---
 utilities/ovn-ctl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/utilities/ovn-ctl b/utilities/ovn-ctl
index 14d37a3d6..e2f05915b 100755
--- a/utilities/ovn-ctl
+++ b/utilities/ovn-ctl
@@ -200,7 +200,7 @@ start_ovsdb__() {
 ovn_install_dir "$ovn_etcdir"
 
 # Check and eventually start ovsdb-server for DB
-if pidfile_is_running $db_pid_file; then
+if pidfile_is_running $db_pid_file ovsdb-server; then
 return
 fi
 
-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v5 ovn 1/2] Handle re-used pids in pidfile_is_running

[Terry Wilson]

Since pids can be re-used, it is necessary to check that the
process that is running with a pid matches the one that we expect.

This adds the ability to optionally pass a 'binary' argument to
pidfile_is_running, and if it is passed to match the binary against
/proc/$pid/exe.

Signed-off-by: Terry Wilson 
---
 utilities/ovn-ctl | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/utilities/ovn-ctl b/utilities/ovn-ctl
index d733aa42d..14d37a3d6 100755
--- a/utilities/ovn-ctl
+++ b/utilities/ovn-ctl
@@ -42,7 +42,8 @@ ovn_ic_db_conf_file="$ovn_etcdir/ovn-ic-db-params.conf"
 
 pidfile_is_running () {
 pidfile=$1
-test -e "$pidfile" && [ -s "$pidfile" ] && pid=`cat "$pidfile"` && 
pid_exists "$pid"
+cmd=$2
+test -e "$pidfile" && [ -s "$pidfile" ] && pid=`cat "$pidfile"` && 
pid_exists "$pid" && [ -z $cmd -o pid_comm_check "$cmd" "$pid" ]
 } >/dev/null 2>&1
 
 stop_nb_ovsdb() {
-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v4 2/2] Ensure pid belongs to ovsdb-server in ovn-ctl

[Terry Wilson]

When checking if ovsdb-server is running, ensure that the binary
we are going to run matches the one actually running with the the
pid that was in our pidfile.

Signed-off-by: Terry Wilson 
---
 utilities/ovn-ctl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/utilities/ovn-ctl b/utilities/ovn-ctl
index 14d37a3d6..e2f05915b 100755
--- a/utilities/ovn-ctl
+++ b/utilities/ovn-ctl
@@ -200,7 +200,7 @@ start_ovsdb__() {
 ovn_install_dir "$ovn_etcdir"
 
 # Check and eventually start ovsdb-server for DB
-if pidfile_is_running $db_pid_file; then
+if pidfile_is_running $db_pid_file ovsdb-server; then
 return
 fi
 
-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v4 1/2] Handle re-used pids in pidfile_is_running

[Terry Wilson]

Since pids can be re-used, it is necessary to check that the
process that is running with a pid matches the one that we expect.

This adds the ability to optionally pass a 'binary' argument to
pidfile_is_running, and if it is passed to match the binary against
/proc/$pid/exe.

Signed-off-by: Terry Wilson 
---
 utilities/ovn-ctl | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/utilities/ovn-ctl b/utilities/ovn-ctl
index d733aa42d..14d37a3d6 100755
--- a/utilities/ovn-ctl
+++ b/utilities/ovn-ctl
@@ -42,7 +42,8 @@ ovn_ic_db_conf_file="$ovn_etcdir/ovn-ic-db-params.conf"
 
 pidfile_is_running () {
 pidfile=$1
-test -e "$pidfile" && [ -s "$pidfile" ] && pid=`cat "$pidfile"` && 
pid_exists "$pid"
+cmd=$2
+test -e "$pidfile" && [ -s "$pidfile" ] && pid=`cat "$pidfile"` && 
pid_exists "$pid" && [ -z $cmd -o pid_comm_check "$cmd" "$pid" ]
 } >/dev/null 2>&1
 
 stop_nb_ovsdb() {
-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v3 1/2] Handle re-used pids in pidfile_is_running

[Terry Wilson]

Since pids can be re-used, it is necessary to check that the
process that is running with a pid matches the one that we expect.

This adds the ability to optionally pass a 'binary' argument to
pidfile_is_running, and if it is passed to match the binary against
/proc/$pid/exe.

Signed-off-by: Terry Wilson 
---
 utilities/ovn-ctl | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/utilities/ovn-ctl b/utilities/ovn-ctl
index d733aa42d..14d37a3d6 100755
--- a/utilities/ovn-ctl
+++ b/utilities/ovn-ctl
@@ -42,7 +42,8 @@ ovn_ic_db_conf_file="$ovn_etcdir/ovn-ic-db-params.conf"
 
 pidfile_is_running () {
 pidfile=$1
-test -e "$pidfile" && [ -s "$pidfile" ] && pid=`cat "$pidfile"` && 
pid_exists "$pid"
+cmd=$2
+test -e "$pidfile" && [ -s "$pidfile" ] && pid=`cat "$pidfile"` && 
pid_exists "$pid" && [ -z $cmd -o pid_comm_check "$cmd" "$pid" ]
 } >/dev/null 2>&1
 
 stop_nb_ovsdb() {
-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v3 2/2] Ensure pid belongs to ovsdb-server in ovn-ctl

[Terry Wilson]

When checking if ovsdb-server is running, ensure that the binary
we are going to run matches the one actually running with the the
pid that was in our pidfile.

Signed-off-by: Terry Wilson 
---
 utilities/ovn-ctl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/utilities/ovn-ctl b/utilities/ovn-ctl
index 14d37a3d6..e2f05915b 100755
--- a/utilities/ovn-ctl
+++ b/utilities/ovn-ctl
@@ -200,7 +200,7 @@ start_ovsdb__() {
 ovn_install_dir "$ovn_etcdir"
 
 # Check and eventually start ovsdb-server for DB
-if pidfile_is_running $db_pid_file; then
+if pidfile_is_running $db_pid_file ovsdb-server; then
 return
 fi
 
-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v2 ovn 1/2] Handle re-used pids in pidfile_is_running

[Terry Wilson]

Since pids can be re-used, it is necessary to check that the
process that is running with a pid matches the one that we expect.

This adds the ability to optionally pass a 'binary' argument to
pidfile_is_running, and if it is passed to match the binary against
/proc/$pid/exe.

Signed-off-by: Terry Wilson 
---
 utilities/ovn-ctl | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/utilities/ovn-ctl b/utilities/ovn-ctl
index d733aa42d..41fa89770 100755
--- a/utilities/ovn-ctl
+++ b/utilities/ovn-ctl
@@ -40,9 +40,16 @@ ovn_ic_db_conf_file="$ovn_etcdir/ovn-ic-db-params.conf"
 ## start ##
 ## - ##
 
+pid_exe_matches () {
+pid=$1
+binary=$2
+[ -z "$binary" -o `readlink /proc/$pid/exe` = "$binary" ]
+}
+
 pidfile_is_running () {
 pidfile=$1
-test -e "$pidfile" && [ -s "$pidfile" ] && pid=`cat "$pidfile"` && 
pid_exists "$pid"
+binary=$2
+test -e "$pidfile" && [ -s "$pidfile" ] && pid=`cat "$pidfile"` && 
pid_exists "$pid" && pid_exe_matches "$pid" "$binary"
 } >/dev/null 2>&1
 
 stop_nb_ovsdb() {
-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v2 ovn 2/2] Ensure pid belongs to ovsdb-server in ovn-ctl

[Terry Wilson]

When checking if ovsdb-server is running, ensure that the binary
we are going to run matches the one actually running with the the
pid that was in our pidfile.

Signed-off-by: Terry Wilson 
---
 utilities/ovn-ctl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/utilities/ovn-ctl b/utilities/ovn-ctl
index 41fa89770..48ad42780 100755
--- a/utilities/ovn-ctl
+++ b/utilities/ovn-ctl
@@ -206,7 +206,7 @@ start_ovsdb__() {
 ovn_install_dir "$ovn_etcdir"
 
 # Check and eventually start ovsdb-server for DB
-if pidfile_is_running $db_pid_file; then
+if pidfile_is_running $db_pid_file `which ovsdb-server`; then
 return
 fi
 
-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn 1/2] Handle re-used pids in pidfile_is_running

[Terry Wilson]

On Wed, Jun 1, 2022 at 10:18 PM Ihar Hrachyshka  wrote:
>
> On Wed, Jun 1, 2022 at 1:26 PM Terry Wilson  wrote:
> >
> > Since pids can be re-used, it is necessary to check that the
> > process that is running with a pid matches the one that we expect.
> >
> > This adds the ability to optionally pass a 'binary' argument to
> > pidfile_is_running, and if it is passed to match the binary against
> > /proc/$pid/exe.
> >
> > Signed-off-by: Terry Wilson 
> > ---
> >  ovs   | 2 +-
>
> Why do you bump the submodule in this patch?

Very good question. Not sure how that snuck in. :/

> >  utilities/ovn-ctl | 9 -
> >  2 files changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/ovs b/ovs
> > index d7c0b90fa..91e1ff5dd 16
> > --- a/ovs
> > +++ b/ovs
> > @@ -1 +1 @@
> > -Subproject commit d7c0b90fa360a694f0f3b4f4ce1c514fec4e4359
> > +Subproject commit 91e1ff5dde396fbcc8623ac0726066e970e6de15
> > diff --git a/utilities/ovn-ctl b/utilities/ovn-ctl
> > index d733aa42d..41fa89770 100755
> > --- a/utilities/ovn-ctl
> > +++ b/utilities/ovn-ctl
> > @@ -40,9 +40,16 @@ ovn_ic_db_conf_file="$ovn_etcdir/ovn-ic-db-params.conf"
> >  ## start ##
> >  ## - ##
> >
> > +pid_exe_matches () {
> > +pid=$1
> > +binary=$2
> > +[ -z "$binary" -o `readlink /proc/$pid/exe` = "$binary" ]
> > +}
> > +
> >  pidfile_is_running () {
> >  pidfile=$1
> > -test -e "$pidfile" && [ -s "$pidfile" ] && pid=`cat "$pidfile"` && 
> > pid_exists "$pid"
> > +binary=$2
> > +test -e "$pidfile" && [ -s "$pidfile" ] && pid=`cat "$pidfile"` && 
> > pid_exists "$pid" && pid_exe_matches "$pid" "$binary"
> >  } >/dev/null 2>&1
> >
> >  stop_nb_ovsdb() {
> > --
> > 2.34.3
> >
> > ___
> > 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

Re: [ovs-dev] [PATCH ovn 1/2] Handle re-used pids in pidfile_is_running

[Terry Wilson]

On Wed, Jun 1, 2022 at 1:30 PM 0-day Robot  wrote:
> checkpatch:
> WARNING: Line is 124 characters long (recommended limit is 79)
> #44 FILE: utilities/ovn-ctl:52:
> test -e "$pidfile" && [ -s "$pidfile" ] && pid=`cat "$pidfile"` && 
> pid_exists "$pid" && pid_exe_matches "$pid" "$binary"
>
> Lines checked: 50, Warnings: 1, Errors: 0

Since the line was > 79 chars before I got here and there are much
longer lines in this file, I'm going to treat this as a non-issue
unless I hear otherwise.

Terry

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH ovn 1/2] Handle re-used pids in pidfile_is_running

[Terry Wilson]

Since pids can be re-used, it is necessary to check that the
process that is running with a pid matches the one that we expect.

This adds the ability to optionally pass a 'binary' argument to
pidfile_is_running, and if it is passed to match the binary against
/proc/$pid/exe.

Signed-off-by: Terry Wilson 
---
 ovs   | 2 +-
 utilities/ovn-ctl | 9 -
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/ovs b/ovs
index d7c0b90fa..91e1ff5dd 16
--- a/ovs
+++ b/ovs
@@ -1 +1 @@
-Subproject commit d7c0b90fa360a694f0f3b4f4ce1c514fec4e4359
+Subproject commit 91e1ff5dde396fbcc8623ac0726066e970e6de15
diff --git a/utilities/ovn-ctl b/utilities/ovn-ctl
index d733aa42d..41fa89770 100755
--- a/utilities/ovn-ctl
+++ b/utilities/ovn-ctl
@@ -40,9 +40,16 @@ ovn_ic_db_conf_file="$ovn_etcdir/ovn-ic-db-params.conf"
 ## start ##
 ## - ##
 
+pid_exe_matches () {
+pid=$1
+binary=$2
+[ -z "$binary" -o `readlink /proc/$pid/exe` = "$binary" ]
+}
+
 pidfile_is_running () {
 pidfile=$1
-test -e "$pidfile" && [ -s "$pidfile" ] && pid=`cat "$pidfile"` && 
pid_exists "$pid"
+binary=$2
+test -e "$pidfile" && [ -s "$pidfile" ] && pid=`cat "$pidfile"` && 
pid_exists "$pid" && pid_exe_matches "$pid" "$binary"
 } >/dev/null 2>&1
 
 stop_nb_ovsdb() {
-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH ovn 2/2] Ensure pid belongs to ovsdb-server in ovn-ctl

[Terry Wilson]

When checking if ovsdb-server is running, ensure that the binary
we are going to run matches the one actually running with the the
pid that was in our pidfile.

Signed-off-by: Terry Wilson 
---
 utilities/ovn-ctl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/utilities/ovn-ctl b/utilities/ovn-ctl
index 41fa89770..48ad42780 100755
--- a/utilities/ovn-ctl
+++ b/utilities/ovn-ctl
@@ -206,7 +206,7 @@ start_ovsdb__() {
 ovn_install_dir "$ovn_etcdir"
 
 # Check and eventually start ovsdb-server for DB
-if pidfile_is_running $db_pid_file; then
+if pidfile_is_running $db_pid_file `which ovsdb-server`; then
 return
 fi
 
-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH ovn 0/2] Add check for for process in pidfile_is_running

[Terry Wilson]

We ran into an issue in a container environment where the pid files
are on a mount in the host system and not cleaned up. In this case,
due to reuse of pids and ovn-ctl using exec(), the pid of ovn-ctl
itself was in the ovnnb_db.pid file. So ovn-ctl would fail to start
ovsdb-server.

This adds the ability to add an optional process name check to avoid
this situation.

Terry Wilson (2):
  Handle re-used pids in pidfile_is_running
  Ensure pid belongs to ovsdb-server in ovn-ctl

 ovs   |  2 +-
 utilities/ovn-ctl | 11 +--
 2 files changed, 10 insertions(+), 3 deletions(-)

-- 
2.34.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v3 01/18] python: add generic Key-Value parser

[Terry Wilson]

LGTM

Acked-by: Terry Wilson 

On Fri, Mar 11, 2022 at 9:22 AM Adrian Moreno  wrote:
>
> Most of ofproto and dpif flows are based on key-value pairs. These
> key-value pairs can be represented in several ways, eg: key:value,
> key=value, key(value).
>
> Add the following classes that allow parsing of key-value strings:
> * KeyValue: holds a key-value pair
> * KeyMetadata: holds some metadata associated with a KeyValue such as
>   the original key and value strings and their position in the global
>   string
> * KVParser: is able to parse a string and extract it's key-value pairs
>   as KeyValue instances. Before creating the KeyValue instance it tries
>   to decode the value via the KVDecoders
> * KVDecoders holds a number of decoders that KVParser can use to decode
>   key-value pairs. It accepts a dictionary of keys and callables to
>   allow users to specify what decoder (i.e: callable) to use for each
>   key
>
> Also, flake8 seems to be incorrectly reporting an error (E203) in:
> "slice[index + offset : index + offset]" which is PEP8 compliant. So,
> ignore this error.
>
> Signed-off-by: Adrian Moreno 
> ---
>  Makefile.am  |   3 +-
>  python/automake.mk   |   6 +-
>  python/ovs/flows/__init__.py |   0
>  python/ovs/flows/decoders.py |  18 ++
>  python/ovs/flows/kv.py   | 314 +++
>  python/setup.py  |   2 +-
>  6 files changed, 340 insertions(+), 3 deletions(-)
>  create mode 100644 python/ovs/flows/__init__.py
>  create mode 100644 python/ovs/flows/decoders.py
>  create mode 100644 python/ovs/flows/kv.py
>
> diff --git a/Makefile.am b/Makefile.am
> index cb8076433..4f51d225e 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -391,6 +391,7 @@ ALL_LOCAL += flake8-check
>  #   E128 continuation line under-indented for visual indent
>  #   E129 visually indented line with same indent as next logical line
>  #   E131 continuation line unaligned for hanging indent
> +#   E203 whitespace before ':'
>  #   E722 do not use bare except, specify exception instead
>  #   W503 line break before binary operator
>  #   W504 line break after binary operator
> @@ -403,7 +404,7 @@ ALL_LOCAL += flake8-check
>  #   H233 Python 3.x incompatible use of print operator
>  #   H238 old style class declaration, use new style (inherit from `object`)
>  FLAKE8_SELECT = H231,H232,H233,H238
> -FLAKE8_IGNORE = 
> E121,E123,E125,E126,E127,E128,E129,E131,E722,W503,W504,F811,D,H,I
> +FLAKE8_IGNORE = 
> E121,E123,E125,E126,E127,E128,E129,E131,E203,E722,W503,W504,F811,D,H,I
>  flake8-check: $(FLAKE8_PYFILES)
> $(FLAKE8_WERROR)$(AM_V_GEN) \
>   src='$^' && \
> diff --git a/python/automake.mk b/python/automake.mk
> index 767512f17..7ce842d66 100644
> --- a/python/automake.mk
> +++ b/python/automake.mk
> @@ -16,7 +16,6 @@ ovs_pyfiles = \
> python/ovs/compat/sortedcontainers/sorteddict.py \
> python/ovs/compat/sortedcontainers/sortedset.py \
> python/ovs/daemon.py \
> -   python/ovs/fcntl_win.py \
> python/ovs/db/__init__.py \
> python/ovs/db/custom_index.py \
> python/ovs/db/data.py \
> @@ -26,6 +25,10 @@ ovs_pyfiles = \
> python/ovs/db/schema.py \
> python/ovs/db/types.py \
> python/ovs/fatal_signal.py \
> +   python/ovs/fcntl_win.py \
> +   python/ovs/flows/__init__.py \
> +   python/ovs/flows/decoders.py \
> +   python/ovs/flows/kv.py \
> python/ovs/json.py \
> python/ovs/jsonrpc.py \
> python/ovs/ovsuuid.py \
> @@ -42,6 +45,7 @@ ovs_pyfiles = \
> python/ovs/version.py \
> python/ovs/vlog.py \
> python/ovs/winutils.py
> +
>  # These python files are used at build time but not runtime,
>  # so they are not installed.
>  EXTRA_DIST += \
> diff --git a/python/ovs/flows/__init__.py b/python/ovs/flows/__init__.py
> new file mode 100644
> index 0..e69de29bb
> diff --git a/python/ovs/flows/decoders.py b/python/ovs/flows/decoders.py
> new file mode 100644
> index 0..0c2259c76
> --- /dev/null
> +++ b/python/ovs/flows/decoders.py
> @@ -0,0 +1,18 @@
> +"""Defines helpful decoders that can be used to decode information from the
> +flows.
> +
> +A decoder is generally a callable that accepts a string and returns the value
> +object.
> +"""
> +
> +
> +def decode_default(value):
> +"""Default decoder.
> +
> +It tries to convert into an integer value and, if it fails, just
> +returns the string.
> +"""
> +try:
> +return int(value, 0)
> +except ValueError:
> +

[ovs-dev] [PATCH] python: Raise AttributeError from uuid_to_row

[Terry Wilson]

Prior to 4e3966e64, when calling _uuid_to_row, it would raise an
AttributeError when trying to access base.ref_table.rows if the
referenced table was not registered. When called from
Row.__getattr__(), this would appropriately raise an AttributeError.

After 4e3966e64, a KeyError would be raised, which is not expected
from a getattr() or hasattr() call, which could break existing
code.

Fixes: 4e3966e64 (python: Politely handle misuse of table.condition.)
Signed-off-by: Terry Wilson 
---
 python/ovs/db/idl.py | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/python/ovs/db/idl.py b/python/ovs/db/idl.py
index c98985773..b87099ff5 100644
--- a/python/ovs/db/idl.py
+++ b/python/ovs/db/idl.py
@@ -1299,7 +1299,12 @@ class Row(object):
 
 def _uuid_to_row(self, atom, base):
 if base.ref_table:
-return self._idl.tables[base.ref_table.name].rows.get(atom)
+try:
+table = self._idl.tables[base.ref_table.name]
+except KeyError as e:
+msg = "Table {} is not registered".format(base.ref_table.name)
+raise AttributeError(msg) from e
+return table.rows.get(atom)
 else:
 return atom
 
-- 
2.35.1

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] python: Raise AttributeError from uuid_to_row

[Terry Wilson]

On Sat, Apr 30, 2022 at 3:10 PM Terry Wilson  wrote:
>
> Prior to 4e3966e64, when calling _uuid_to_row, it would raise an
> AttributeError when trying to access base.ref_table.rows if the
> referenced table was not registered. When called from
> Row.__getattr__(), this would appropriately raise an AttributeError.
>
> After 4e3966e64, a KeyError would be raised, which is not expected
> from a getattr() or hasattr() call, which could break existing
> code.
>
> Fixes: 4e3966e64 (python: Politely handle misuse of table.condition.)
> Signed-off-by: Terry Wilson 
> ---
>  python/ovs/db/idl.py | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/python/ovs/db/idl.py b/python/ovs/db/idl.py
> index c98985773..ca61c5f73 100644
> --- a/python/ovs/db/idl.py
> +++ b/python/ovs/db/idl.py
> @@ -1299,7 +1299,12 @@ class Row(object):
>
>  def _uuid_to_row(self, atom, base):
>  if base.ref_table:
> -return self._idl.tables[base.ref_table.name].rows.get(atom)
> +try:
> +table = self._idl.tables[base.ref_table.name]
> +except KeyError as e:

Part of me thinks that we could just return atom here to return the
UUID if the table wasn't registered, but I went with trying to restore
the previous behavior.

> +raise AttributeError(
> +f"Table {base.ref_table.name} is not registered") from e
> +return table.rows.get(atom)
>  else:
>  return atom
>
> --
> 2.35.1
>

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] python: Raise AttributeError from uuid_to_row

[Terry Wilson]

Prior to 4e3966e64, when calling _uuid_to_row, it would raise an
AttributeError when trying to access base.ref_table.rows if the
referenced table was not registered. When called from
Row.__getattr__(), this would appropriately raise an AttributeError.

After 4e3966e64, a KeyError would be raised, which is not expected
from a getattr() or hasattr() call, which could break existing
code.

Fixes: 4e3966e64 (python: Politely handle misuse of table.condition.)
Signed-off-by: Terry Wilson 
---
 python/ovs/db/idl.py | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/python/ovs/db/idl.py b/python/ovs/db/idl.py
index c98985773..ca61c5f73 100644
--- a/python/ovs/db/idl.py
+++ b/python/ovs/db/idl.py
@@ -1299,7 +1299,12 @@ class Row(object):
 
 def _uuid_to_row(self, atom, base):
 if base.ref_table:
-return self._idl.tables[base.ref_table.name].rows.get(atom)
+try:
+table = self._idl.tables[base.ref_table.name]
+except KeyError as e:
+raise AttributeError(
+f"Table {base.ref_table.name} is not registered") from e
+return table.rows.get(atom)
 else:
 return atom
 
-- 
2.35.1

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[grpc-io] gRFC A52: gRPC xDS Custom Load Balancer Configuration

['Terry Wilson' via grpc.io]

Hi folks, I have a PR out for a new gRFC 
at: https://github.com/grpc/proposal/pull/298

This one covers custom load balancer policy configurations in the control 
plane and their delivery to gRPC via xDS.

Feel free to leave any comments!
Terry

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/8287a977-2d13-42db-b706-d31729f6c6d0n%40googlegroups.com.