| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Python 2 reaches end-of-life on January 1, 2020, which is only
a few months away. This means that OVS needs to stop depending
on in the next release that should occur roughly that same time.
Therefore, this commit removes all support for Python 2. It
also makes Python 3 a mandatory build dependency.
Some of the interesting consequences:
- HAVE_PYTHON, HAVE_PYTHON2, and HAVE_PYTHON3 conditionals have
been removed, since we now know that Python3 is available.
- $PYTHON and $PYTHON2 are removed, and $PYTHON3 is always
available.
- Many tests for Python 2 support have been removed, and the ones
that depended on Python 3 now run unconditionally. This allowed
several macros in the testsuite to be removed, making the code
clearer. This does make some of the changes to the testsuite
files large due to indentation level changes.
- #! lines for Python now use /usr/bin/python3 instead of
/usr/bin/python.
- Packaging depends on Python 3 packages.
Acked-by: Numan Siddique <nusiddiq@redhat.com>
Tested-by: Numan Siddique <nusiddiq@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adding / removing a range of integers to a column accepting a set of
integers requires enumarating all of the integers. This patch simplifies
it by introducing 'range' concept to the database commands. Two integers
separated by a hyphen represent an inclusive range.
The patch adds positive and negative tests for the new syntax.
The patch was tested by 'make check'. Covarage was tested by
'make check-lcov'.
Signed-off-by: Lukasz Rzasik <lukasz.rzasik@gmail.com>
Suggested-by: <my_ovs_discuss@yahoo.com>
Suggested-by: Ben Pfaff <blp@ovn.org>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
| |
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Ryan Moats <rmoats@us.ibm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When an OVSDB column change its value, it is more efficient to only
send what has changed, rather than sending the entire new copy.
This is analogous to software programmer send patches rather than
the entire source file.
For columns store a single element, the "diff" datum is the same
as the "new" datum.
For columns that store set or map, it is only necessary to send the
information about the elements changed (including addition or removal).
The "diff" for those types are all elements that are changed.
Those APIs are mainly used for implementing a new OVSDB server
"update2" JSON-RPC notification, which encodes modifications
of a column with the contents of those "diff"s. Later patch implements
the "update2" notification.
Signed-off-by: Andy Zhou <azhou@nicira.com>
Acked-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
| |
No content change.
Signed-off-by: Andy Zhou <azhou@nicira.com>
Acked-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
| |
The error message should not include bytes already copied from the input
string.
Found by inspection.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Alex Wang <alexw@nicira.com>
|
| |
|
|
|
|
|
|
|
| |
Narrow Python can't handle Unicode characters outside the BMP, so skip the
test.
Reported-by: Michael Shigorin <mike@osdn.org.ua>
Tested-by: Michael Shigorin <mike@osdn.org.ua>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OVS has two Python tests that have always failed, for reasons not
understood, since they were added to the tree. This commit fixes them.
One problem was that Python was assuming that stdout was encoded in ASCII.
Apparently the only way to "fix" this at runtime is to set PYTHONIOENCODING
to utf_8 in the environment, so this change does that.
Second, it appears that Python really doesn't like to print invalid UTF-8,
so this avoids doing that in python/ovs/json.py, instead just printing
the hexadecimal values of the invalid bytes. For consistency, it makes
the same change to the C version.
Third, the C version of test-ovsdb doesn't check UTF-8 for consistency, it
just sends it blindly to the OVSDB server, but Python does check it and so
it bails out earlier. This commit changes the Python version of the
"no invalid UTF-8 sequences in strings" to allow for the slight difference
in output that occurs for that reason.
Finally, test-ovsdb.py needs to convert error messages to Unicode
explicitly before printing them in the "parse-atoms" function. I don't
really understand why, but now it works.
|
| |
|
|
|
|
| |
UUID.from_json(['named-uuid', 'x'], None) should raise an error about
invalid syntax, but instead it was raising a TypeError because it would
try to evaluate "'x' not in None". This fixes the problem and adds a test.
|
| |
|
|
|
|
| |
Python can be built with either UCS2 or UCS4 support. When built
with UCS2 the python related surrogate pairs tests cannot pass.
This commit handles this situation more gracefully.
|
| |
|
|
|
|
|
|
|
|
| |
These initial bindings pass a few hundred of the corresponding tests
for C implementations of various bits of the Open vSwitch library API.
The poorest part of them is actually the Python IDL interface in
ovs.db.idl, which has not received enough attention yet. It appears
to work, but it doesn't yet support writes (transactions) and it is
difficult to use. I hope to improve it as it becomes clear what
semantics Python applications actually want from an IDL.
|
| |
|
|
|
| |
Having access to const copies of default atoms and data will allow OVSDB
code to avoid memory allocations and reduce copying in upcoming commits.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The \x escape is not part of POSIX, but it is a common extension. The
dash shell's built-in "printf" implementation does not include this
extension, which caused the testsuite to be generated incorrectly if it
is used as the default shell (as it is on newer versions of Debian and
Ubuntu).
This commit fixes the problem by using standard octal escapes instead.
Reported-by: Joan Cirer <joan@ev0.net>
|
| |
|
|
|
|
| |
Some of the uses for the formerly supported regular expression constraints
were simply to limit values to those in a set of allowed values.
This commit adds support for that kind of simple enumeration constraint.
|
| |
|
|
|
|
|
|
| |
Regular expression constraints have caused nothing but trouble due to the
lack of a ubiquitous regular expression library. PCRE is *almost*
everywhere, but it has different versions, and different features, and
different bugs, in different places. It is more trouble than it is worth.
So this commit drops support.
|
| |
|
|
|
|
| |
It is natural to write "abc" in place of ["set",["abc"]] and vice versa.
I cannot think of a reason not to support this, and it can make reading
and writing OVSDB files and transactions easier, so support it.
|
| |
|
|
|
| |
This is one of the loose ends that I intended to fix up and test before
pushing off my commits to add use of PCRE, but obviously I forgot.
|
| | |
|
| |
|
|
| |
Bug #2396.
|
| |
|
|
|
|
|
|
|
|
| |
A "min" value greater than 1 is problematic for the database. There is no
reasonable way to synthesize a default value for such a column: keys in a
set or map must unique, so the database cannot, say, simply set a set of
3 or more integers to [0, 0, 0].
This should have no effect on the vswitch in practice because it does not
have any columns that require more than one element.
|
| |
|
