_Server database is not managed by the user and needed mostly for IDL
itself to see changes in the schema or cluster leadership. However,
we're currently delivering notifications about changes in that database
confusing the application (the application didn't subscribe to this
database) and also we're increasing the change_seqno potentially
returning true for has_ever_connected() call even if we didn't really
get any real data yet or even connected to the right database.
In the tests these notifications can be seen as two events at the
beginning of every test with the notification enabled:
000: event:create, row={}, uuid=<0>, updates=None
000: event:create, row={}, uuid=<1>, updates=None
Tests only print the 'simple' table, so the content is omitted, but
the data is still there and the empty events are printed out.
We should not notify the application nor touch the change_seqno.
Tests updated accordingly. Unfortunately, removing first two lines
from a test changes the numbers generated by the UUID filter, so the
rest of the test needs adjustments as well.
Fixes: c39751e44539 ("python: Monitor Database table to manage lifecycle of IDL client.")
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Row stringification happens a lot in client logs and it is far
more useful to have the logged Row's uuid printed. This also
adds converting referenced Row objects, and references within
set and map columns to UUIDs.
Signed-off-by: Terry Wilson <twilson@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Previously the complete table.rows object was recreated,
which caused the loss of custom indexes.
This behavior is now consistent with the C implementation.
See discussion [0] for more details.
[0] https://patchwork.ozlabs.org/project/openvswitch/patch/Z64R_bZhCDcYsHom@SIT-SDELAP1634.int.lidl.net/
Fixes: 13973bc41524 ("Add multi-column index support for the Python IDL")
Signed-off-by: Max Lamprecht <max.lamprecht@stackit.cloud>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
This is very basic, but it should give enough pointers to get started.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
While creating passive TCP connections the library stores part of the
connection method as a bind path regardless of it being a path. And
then it may attempt to unlink it on close:
fatal-signal | WARN | could not unlink "27.0.0.1:58866"
(No such file or directory)
Unlinking only makes sense for unix sockets, not TCP, so the variable
should only be initialized for "punix" case. It's not a big problem
since those files are unlikely to exist, but it generates strange
warnings in the logs.
Fixes: af3582371193 ("python: Add TCP passive-mode to IDL.")
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
When inserting a Row with persist_uuid=True, the Row will have
a 'uuid' element and not a 'named-uuid' element, so ensure that
other operations in the transaction refer to the row by 'uuid'.
Fixes: 55b9507e6824 ("ovsdb-idl: Add the support to specify the uuid for row insert.")
Signed-off-by: Terry Wilson <twilson@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
If a table's schema allows no columns to be set when inserting,
python-ovs should handle that case.
Signed-off-by: Terry Wilson <twilson@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
The graphviz library has a large set of dependencies, and as such
it may be desireable to not install it by default.
Before this patch execution of ovs-flowviz would end in
ImportError when graphviz is unavailable.
Exit with a friendly message instead, allowing the user to consume
the parts of the program that do not depend on graphviz.
Signed-off-by: Frode Nordahl <fnordahl@ubuntu.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
All the ssl.OP_NO_* options are deprecated since OpenSSL 1.1.0.
Use minimum/maximum_version configuration instead.
Unfortunately, those only available in Python 3.7, so increasing
the minimal supported Python version. Python 3.7+ should be
available in most modern distributions. It is also EoL at this
point, but there is no need to require higher versions.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
SSLv23_method() is deprecated since OpenSSL 1.1.0. In practice, it is
just renamed into TLS_method(). Use the new name instead.
For the python version of the code, we can use PROTOCOL_TLS_CLIENT,
since we only support client side of the connection. It turns on
the hostname check by default, though. So, we need to turn it off,
otherwise we would have to provide the server_hostname for every
wrap_socket. We would just use generic PROTOCOL_TLS as we do in C,
but unfortunately PROTOCOL_TLS is deprecated since Python 3.10.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
SSL protocol family is not actually being used or supported in OVS.
What we use is actually TLS.
Terms "SSL" and "TLS" are often used interchangeably in modern
software and refer to the same thing, which is normally just TLS.
Let's replace "SSL" with "SSL/TLS" in documentation and user-visible
messages, where it makes sense. This may make it more clear what
is meant for a less experienced user that may look for TLS support
in OVS and not find much.
We're not changing any actual code, because, for example, most of
OpenSSL APIs are using just SSL, for historical reasons. And our
database is using "SSL" table. We may consider migrating to "TLS"
naming for user-visible configuration like command line arguments
and database names, but that will require extra work on making sure
upgrades can still work. In general, a slightly more clear
documentation should be enough for now, especially since term SSL
is still widely used in the industry.
"SSL/TLS" is chosen over "TLS/SSL" simply because our user-visible
configuration knobs are using "SSL" naming, e.g. '--ssl-cyphers'
or 'ovs-vsctl set-ssl'. So, it might be less confusing this way.
We may switch that, if we decide on re-working the user-visible
commands towards "TLS" naming, or providing both alternatives.
Some other projects did similar changes. For example, the python ssl
library is now using "TLS/SSL" in the documentation whenever possible.
Same goes for OpenSSL itself.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
TLSv1 and TLSv1.1 are officially deprecated by RFC 8996 since March
of 2021: https://datatracker.ietf.org/doc/rfc8996/
Both protocols should not generally be used (RFC says MUST NOT) and
are being actively removed from support by major distributions and
libraries.
Deprecate these protocols in OVS and turn them off by default.
Ability to use them preserved for now with a warning. We'll fully
remove support in OVS 3.6.
Before this change, OVS would use TLSv1 or later, if the protocols
are not specified in the database or command line (this includes
TLSv1.3 that is not supported explicitly). After the change, this
becomes TLSv1.2 or later.
Python library only supports client side of SSL/TLS and doesn't
support configuring protocols. So, just turning off TLSv1 and
TLSv1.1. Meaning, new python clients will not be able to connect
to servers that only have TLSv1.1 or lower. This is a strange
configuration for a modern server and can be fixed by allowing the
server to use newer protocols. So, there might not be a real need
in making client side configurable. If the server is so old that
it doesn't support TLSv1.2, it may be a time to update it.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
For flake8 rule E713, "Test for membership should be 'not in'" so
replace any "if not x in the_list" with "if x not in the_list"
Acked-by: Mike Pattrick <mkp@redhat.com>
Signed-off-by: Timothy Redaelli <tredaelli@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Specifying data_files makes setuptools install this file to a global
sys.prefix. So, it ends up in both the main directory of the python
package and in the /usr/ovs-flowviz.conf, which is not good:
warning: install_data: setup script did not provide a directory for
'ovs/flowviz/ovs-flowviz.conf' -- installing right in
'build/bdist.linux-x86_64/wheel/ovs-3.4.90.data/data'
adding 'ovs-3.4.90.data/data/ovs-flowviz.conf'
There is no real point installing this file globally, just use the
package_data to ensure it is included in the python package.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Reviewed-by: Adrian Moreno <amorenoz@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Graph view leverages the TreeFlow hierarchy and uses graphviz library to
build a visual graph of the datapath tree.
Conntrack zones are shown in random colors to help visualize connection
tracking interdependencies.
An html flag builds an HTML page with both the html flows and the graph
(in svg) that enables navigation.
Examples:
$ ovs-appctl dpctl/dump-flows -m | ovs-flowviz datapath graph | dot
-Tpng -o graph.png
$ ovs-appctl dpctl/dump-flows -m | ovs-flowviz datapath graph --html >
flows.html
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Adrian Moreno <amorenoz@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Using the existing FlowTree and HTMLFormatter, create an HTML tree
visualization that also supports collapsing and expanding the entire
flow subtrees.
Examples:
$ ovs-appcl dpctl/dump-flows | ovs-flowviz --highlight drop datapath
html > /tmp/flows.html
$ ovs-appcl dpctl/dump-flows | ovs-flowviz -f "output.port=3"
datapath html > /tmp/flows.html
Both light and dark styles are supported.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Adrian Moreno <amorenoz@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
When analyzing OVN issues, it might be useful to see what OpenFlow
flows were generated from each logical flow. In order to make it simpler
to visualize this, add a cookie format that simply sorts the flows first
by cookie, then by table.
Example:
$ export OVN_NB_DB=...
$ export OVN_SB_DB=...
$ ovs-vsctl dump-flows br-int | ovs-flowviz openflow cookie
--ovn-filter="acl.*icmp4"
$ ovs-vsctl dump-flows br-int | ovs-flowviz openflow cookie
--ovn-detrace
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Adrian Moreno <amorenoz@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
This view is interesting for debugging the logical pipeline. It arranges
the flows in "logical" groups (not to be confused with OVN's
Logical_Flows). A logical group of flows is a set of flows that:
- Have the same table number and priority
- Match on the same fields (regardless of the value they match against)
- Have the same actions, regardless of the arguments for those actions,
except for output and recirc, for which arguments do care.
Optionally, the cookie can also be forced to be unique for the logical
group. By doing so, we can extend the information we show by querying an
external OVN database and running "ovn-detrace" on each cookie. The
result is a compact list of flow groups with interleaved OVN
information.
Furthermore, if connected to an OVN database, we can apply an OVN
regexp filter.
Examples:
$ ovs-ofctl dump-flows br-int | ovs-flowviz openflow logic
$ ovs-ofctl dump-flows br-int | ovs-flowviz openflow logic -s -h
$ export OVN_NB_DB=...
$ export OVN_SB_DB=...
$ ovs-ofctl dump-flows br-int | ovs-flowviz openflow logic -d
$ ovs-ofctl dump-flows br-int | ovs-flowviz openflow logic -d
--ovn-filter="acl.*icmp4"
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Adrian Moreno <amorenoz@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Datapath flows can be arranged into a "tree"-like structure based on
recirculation ids and input ports.
A recirculation group is composed of flows sharing the same "recirc_id"
and "in_port" match. Within that group, flows are arranged in blocks of
flows that have the same action list. Finally, if an action associated
with one of this "blocks" contains a "recirc" action, the recirculation
group is shown underneath.
When filtering, instead of blindly dropping non-matching flows, drop all
the "subtrees" that don't have any matching flow.
Examples:
$ ovs-flowviz -i dpflows.txt --style dark datapath tree | less -R
$ ovs-flowviz -i dpflows.txt --filter "output.port=eth0" datapath tree
This patch adds the logic to build this structure in a format-agnostic
object called FlowTree and adds support for formatting it in the
console.
Console format supports:
- head-maps formatting of statistics
- hash-based pallete of recirculation ids: each recirculation id is
assigned a unique color to easily follow the sequence of related
actions.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Adrian Moreno <amorenoz@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Add a HTML Formatter and use it to print OpenFlow flows in an HTML list
with table links.
Examples
$ ovs-flowviz -i offlows.txt --highlight "drop" openflow html >
/tmp/flows.html
$ ovs-flowviz -i offlows.txt --filter "n_packets > 0" openflow html >
/tmp/flows.html
Both light and dark styles are supported.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Adrian Moreno <amorenoz@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Add a flow formatting framework and one implementation for console
printing using rich.
The flow formatting framework is a simple set of classes that can be
used to write different flow formatting implementations. It supports
styles to be described by any class, highlighting and config-file based
style definition.
The first flow formatting implementation is also introduced: the
ConsoleFormatter. It uses the an advanced rich-text printing library
[1].
The console printing supports:
- Heatmap: printing the packet/byte statistics of each flow in a color
that represents its relative size: blue (low) -> red (high).
- Printing a banner with the file name and alias.
- Extensive style definition via config file.
This console format is added to both OpenFlow and Datapath flows.
Examples:
- Highlight drops in datapath flows:
$ ovs-flowviz -i flows.txt --highlight "drop" datapath console
- Quickly detect where most packets are going using heatmap and
paginated output:
$ ovs-ofctl dump-flows br-int | ovs-flowviz openflow console -h
[1] https://rich.readthedocs.io/en/stable/introduction.html
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Adrian Moreno <amorenoz@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Add a new python package (just the scheleton for now) to hold a flow
visualization tool based on the flow parsing library.
flowviz dependencies are installed via "extras_require", so a user must
run:
$ pip install .[flowviz]
or
$ pip install ovs[flowviz]
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Adrian Moreno <amorenoz@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Add "offloaded" key in the info section of datapath flow.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Adrian Moreno <amorenoz@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
DPDK flows can have this extra section that, for now, only has one
possible key (miniflow_bits). Add it to the ODPFlow flow.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Adrian Moreno <amorenoz@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Since on CentOS/RHEL the builds are based on stable branches and not on
tags for debugging purpose it's better to have the downstream version as
version so it's easier to know which commits are included in a build.
This commit adds --with-version-suffix as ./configure option in
order to set an OVS version suffix that should be shown to the user via
ovs-vsctl -V and, so, also on database, on ovs-vsctl show and the other
utilities.
--with-version-suffix is used in Fedora/CentOS/RHEL spec file in order to have
the version be aligned with the downstream one.
Signed-off-by: Timothy Redaelli <tredaelli@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
When sample action gets used as a way of sampling traffic with
controller-generated metadata (i.e: obs_domain_id and obs_point_id),
the controller will have to increase the number of flows to ensure each
part of the pipeline contains the right metadata.
As an example, if the controller decides to sample stateful traffic, it
could store the computed metadata for each connection in the conntrack
label. However, for established connections, a flow must be created for
each different ct_label value with a sample action that contains a
different hardcoded obs_domain and obs_point id.
This patch adds a new version of the NXAST_RAW_SAMPLE* action (number 4)
that supports specifying the observation point and domain using an
OpenFlow field reference, so now the controller can express:
sample(...
obs_domain_id=NXM_NX_CT_LABEL[0..31],
obs_point_id=NXM_NX_CT_LABEL[32..63]
...
)
Signed-off-by: Adrian Moreno <amorenoz@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Add support for parsing and formatting the new action.
Also, flag OVS_ACTION_ATTR_SAMPLE as requiring datapath assistance if it
contains a nested OVS_ACTION_ATTR_PSAMPLE. The reason is that the
sampling rate from the parent "sample" is made available to the nested
"psample" by the kernel.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Adrian Moreno <amorenoz@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
This patch introduces support for different output formats to Python
Unixctl* classes and appctl.py, similar to what the previous commit did
for ovs-appctl.
In particular, tests/appctl.py gains a global option '-f,--format'
which allows users to request JSON instead of plain-text for humans.
Reported-at: https://bugzilla.redhat.com/1824861
Signed-off-by: Jakob Meng <code@jakobmeng.de>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
For monitoring systems such as Prometheus it would be beneficial if
OVS would expose statistics in a machine-readable format.
This patch introduces support for different output formats to
ovs-appctl. It gains a global option '-f,--format' which changes it to
print a JSON document instead of plain-text for humans. For example, a
later patch implements support for
'ovs-appctl --format json dpif/show'. By default, the output format
is plain-text as before.
A new 'set-options' command has been added to lib/unixctl.c which
allows to change the output format of the commands executed afterwards
on the same socket connection. It is supposed to be run by ovs-appctl
transparently for the user when a specific output format has been
requested.
For example, when a user calls 'ovs-appctl --format json dpif/show',
then ovs-appctl will call 'set-options' to set the output format as
requested by the user and afterwards it will call the actual command
'dpif/show'.
This ovs-appctl behaviour has been implemented in a backward compatible
way. One can use an updated client (ovs-appctl) with an old server
(ovs-vswitchd) and vice versa. Of course, JSON output only works when
both sides have been updated.
Two access functions unixctl_command_{get,set}_output_format() and a
unixctl_command_reply_json function have been added to lib/unixctl.h:
unixctl_command_get_output_format() is supposed to be used in commands
like 'dpif/show' to query the requested output format. When JSON output
has been selected, the unixctl_command_reply_json() function can be
used to return JSON objects to the client (ovs-appctl) instead of
plain-text with the unixctl_command_reply{,_error}() functions.
When JSON has been requested but a command has not implemented JSON
output the plain-text output will be wrapped in a provisional JSON
document with the following structure:
{"reply":"$PLAIN_TEXT_HERE","reply-format":"plain"}
Thus commands which have been executed successfully will not fail when
they try to render the output at a later stage.
A test for the 'version' command has been implemented which shows how
the provisional JSON document looks like in practice. For a cleaner
JSON document, the trailing newline has been moved from the program
version string to function ovs_print_version(). This way, the
plain-text output of the 'version' command has not changed.
Output formatting has been moved from unixctl_client_transact() in
lib/unixctl.c to utilities/ovs-appctl.c. The former merely returns the
JSON objects returned from the server and the latter is now responsible
for printing it properly.
In popular tools like kubectl the option for output control is usually
called '-o|--output' instead of '-f,--format'. But ovs-appctl already
has an short option '-o' which prints the available ovs-appctl options
('--option'). The now chosen name also better aligns with ovsdb-client
where '-f,--format' controls output formatting.
Reported-at: https://bugzilla.redhat.com/1824861
Signed-off-by: Jakob Meng <code@jakobmeng.de>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
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 <twilson@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
When a row is modified, python IDL doesn't perform any operations on
existing client-side indexes. This means that if the column on which
index is created changes, the old value will remain in the index and
the new one will not be added to the index. Beside lookup failures
this is also causing inability to remove modified rows, because the
new column value doesn't exist in the index causing an exception on
attempt to remove it:
Traceback (most recent call last):
File "ovsdbapp/backend/ovs_idl/connection.py", line 110, in run
self.idl.run()
File "ovs/db/idl.py", line 465, in run
self.__parse_update(msg.params[2], OVSDB_UPDATE3)
File "ovs/db/idl.py", line 924, in __parse_update
self.__do_parse_update(update, version, self.tables)
File "ovs/db/idl.py", line 964, in __do_parse_update
changes = self.__process_update2(table, uuid, row_update)
File "ovs/db/idl.py", line 991, in __process_update2
del table.rows[uuid]
File "ovs/db/custom_index.py", line 102, in __delitem__
index.remove(val)
File "ovs/db/custom_index.py", line 66, in remove
self.values.remove(self.index_entry_from_row(row))
File "sortedcontainers/sortedlist.py", line 2015, in remove
raise ValueError('{0!r} not in list'.format(value))
ValueError: Datapath_Binding(
uuid=UUID('498e66a2-70bc-4587-a66f-0433baf82f60'),
tunnel_key=16711683, load_balancers=[], external_ids={}) not in list
Fix that by always removing an existing row from indexes before
modification and adding back afterwards. This ensures that old
values are removed from the index and new ones are added.
This behavior is consistent with the C implementation.
The new test that reproduces the removal issue is added. Some extra
testing infrastructure added to be able to handle and print out the
'indexed' table from the idltest schema.
Fixes: 13973bc41524 ("Add multi-column index support for the Python IDL")
Reported-at: https://mail.openvswitch.org/pipermail/ovs-discuss/2024-May/053159.html
Reported-by: Roberto Bartzen Acosta <roberto.acosta@luizalabs.com>
Acked-by: Mike Pattrick <mkp@redhat.com>
Acked-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Terry Wilson <twilson@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
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 <twilson@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
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 <twilson@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
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 instantiate 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 <twilson@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
'pkg_resources' module is deprecated and no longer available in newer
versions of python, so pytest tests are skipped:
DeprecationWarning: pkg_resources is deprecated as an API.
See https://setuptools.pypa.io/en/latest/pkg_resources.html
Unfortunately, there is no direct replacement for it and functionality
is scattered between different packages.
Using a new standard library importlib.metadata to find installed
packages and their versions. Using packaging.requirements to parse
lines from the requirements file and compare versions. This covers
all we need.
The 'packaging' is a project used by pip and a dependency for many
other libraries, so should be available for any supported verison of
python. 'importlib' was introduced in python 3.8. Since we support
older versions of python and 'packaging' is not part of the standard
library, checking that import is possible and falling back to
'pkg_resources' if needed. We may remove the fallback when we stop
supporting python below 3.8.
Even though 'packaging' is a common dependency, added to the test
requirements so it will not be missed in CI.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Before the patch, the size of the backlog depended on the type of socket
(UNIX vs INET) as well as on the language (C vs Python), specifically:
- python used backlog size = 10 for all sockets;
- C used 64 for UNIX sockets but 10 for INET sockets.
This consolidates the values across the board. It effectively bumps the
number of simultaneous connections to python unixctl servers to 64. Also
for INET C servers too.
The rationale to do it, on top of consistency, is as follows:
- fmt_pkt in ovn testsuite is limited by python server listen backlog,
and as was found out when adopting the tool, it is sometimes useful to
run lots of parallel calls to fmt_pkt unixctl server in some tests.
(See [1] for example.)
- there is a recent report [2] on discuss@ ML where the reporter noticed
significant listen queue overflows in some scenarios (large openstack
deployments; happens during leader transition when hundreds of neutron
nodes - with dozens of neutron api workers each - simultaneously
reconnect to the same northbound leader.) Note: While there is no
clear indication that this backlog size bump would resolve the
reported issues, it would probably help somewhat.
[1] 0baca3e519
[2] https://mail.openvswitch.org/pipermail/ovs-discuss/2024-April/053049.html
Signed-off-by: Ihar Hrachyshka <ihrachys@redhat.com>
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Simon Horman <horms@ovn.org>
After running ovs-tcpdump and inputs multiple CTRL+C, the program will
raise the following exception.
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
File "/usr/bin/ovs-tcpdump", line 421, in cleanup_mirror
ovsdb = OVSDB(db_sock)
File "/usr/bin/ovs-tcpdump", line 168, in __init__
OVSDB.wait_for_db_change(self._idl_conn) # Initial Sync with DB
File "/usr/bin/ovs-tcpdump", line 155, in wait_for_db_change
while idl.change_seqno == seq and not idl.run():
The default handler of SIGINT is default_int_handler, so it was not
registered to the signal handler. When received CTRL+C again, the program
was broken, and calling hook could not be executed completely.
Signed-off-by: Daniel Ding <danieldin186@gmail.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
In general, most actions must be lists since the keys can be repeated.
Signed-off-by: Adrian Moreno <amorenoz@redhat.com>
Signed-off-by: Simon Horman <horms@ovn.org>
Avoid code duplication by moving the section testing code to its own
function.
Also, verify the length of the kv_list meets the expectations.
Signed-off-by: Adrian Moreno <amorenoz@redhat.com>
Signed-off-by: Simon Horman <horms@ovn.org>
Add the sample action to those that can be called in nested actions
(such as clone).
Signed-off-by: Adrian Moreno <amorenoz@redhat.com>
Signed-off-by: Simon Horman <horms@ovn.org>
Parsing of info and matches was being tested as generic k-v parsing.
Also verify we don't find any unexpected field.
Also, verify the length of the kv_list meets the expectations.
Signed-off-by: Adrian Moreno <amorenoz@redhat.com>
Signed-off-by: Simon Horman <horms@ovn.org>
