Also fixes a typo that caused one version of the error message to have a
hyphen and the other to have a space.
Suggested-by: Reid Price <reid@nicira.com>
According to Reid, there may be some disadvantages to having this class be
anonymous, for example, cannot do instance/typechecking, might be
allocating a new class for every row as well, which isn't the most memory
efficient.
Suggested-by: Reid Price <reid@nicira.com>
Idl.__parse_row_update() assumed that every change that the database server
sent down actually modified the database. This is generally true, but
since Idl.__modify_row() already returns whether there was a change, we
might as well use it.
Reported-by: Reid Price <reid@nicira.com>
Strangely malformed <row-update>s could hypothetically get confusing error
message. Using the Parser class should avoid that.
Reported-by: Reid Price <reid@nicira.com>
This leaves one use of __dict__ used for iterating through attributes.
I could use dir() instead, but I was put off by this note in its
documentation in the Python Library Reference:
Because dir() is supplied primarily as a convenience for use at an
interactive prompt, it tries to supply an interesting set of names more
than it tries to supply a rigorously or consistently defined set of names,
and its detailed behavior may change across releases. For example,
metaclass attributes are not in the result list when the argument is a
class.
Suggested-by: Reid Price <reid@nicira.com>
The loop here is supposed to run at least once, and to continue looping as
long as the loop body changes the current state, but this bug caused it to
continue looping until the connection completed in success or failure. It
probably didn't cause many problems in practice because only Unix domain
socket connections are currently supported, and those connections normally
complete immediately.
Reported-by: Reid Price <reid@nicira.com>
Given the invalid input <C0 22>, some versions of Python report <C0> as the
invalid sequence and other versions report <C0 22> as the invalid sequence.
Similarly, given input <ED 80 7F>, some report <ED 80> and others report
<ED 80 7F> as the invalid sequence. This caused spurious test failures for
the test "no invalid UTF-8 sequences in strings - Python", so this commit
makes the messages consistent by dropping the extra trailing byte from the
message.
I first noticed the longer sequences <C0 22> and <ED 80 7F> on Ubuntu
10.04 with python version 2.6.5-0ubuntu1, but undoubtedly it exists
elsewhere also.
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.
Until now, if two copies of one OVS daemon started up at the same time,
then due to races in pidfile creation it was possible for both of them to
start successfully, instead of just one. This was made worse when a
previous copy of the daemon had died abruptly, leaving a stale pidfile.
This commit implements a new pidfile creation and removal protocol that I
believe closes these races. Now, a pidfile is asserted with "link" instead
of "rename", which prevents the race on creation, and a stale pidfile may
only be deleted by a process after it has taken a lock on it.
This may solve mysterious problems seen occasionally on vswitch restart.
I'm still puzzled by these problems, however, because I don't see anything
in our tests cases that would actually cause two copies of a daemon to
start at the same time, which as far as I can see is a necessary
precondition for the problem.
Until now, it has been the responsibility of an individual daemon to call
die_if_already_running() at an appropriate time. A long time ago, this
had to happen *before* daemonizing, because once the process daemonized
itself there was no way to report failure to the process that originally
started the daemon. With the introduction of daemonize_start(), this is
now possible, but we haven't been taking advantage of it.
Therefore, this commit integrates the die_if_already_running() call into
daemonize_start() and deletes the calls to it from individual daemons.
When a strong reference to a non-root table is ephemeral, the database log
can contain inconsistencies. In particular, if the column in question is
the only reference to a row, then the row will be created in one logged
transaction but the reference to it will not be logged (because it is
ephemeral). Thus, any later occurrence of the row later in the log (to
modify it, to delete it, or just to reference it) will yield a transaction
error and reading the database will abort at that point.
This commit fixes the problem by forcing any column with a strong reference
to a non-root table to be persistent.
The change to ovsdb_schema_from_json() looks bigger than it really is: it
just swaps the order of two operations on the schema and updates their
comments. Similarly for the update to ovs.db.DbSchema.__init__().
Bug #5144.
Reported-by: Sujatha Sumanth <ssumanth@nicira.com>
Bug #5149.
Reported-by: Ram Jothikumar <rjothikumar@nicira.com>
Commit 5eda645e36 (ovsdb-server: Report time since last connect and disconnect
for each manager.) used a conditional expression in reconnect.py. That syntax
is only supported in Python 2.5 and later. XenServer 5.6 is based on RHEL 5,
which uses Python 2.4.3, so various OVS scripts on XenServer fail with Python
tracebacks.
Reported-by: Cedric Hobbs <cedric@nicira.com>
Only the time connected (if connected) or disconnected (if disconnected) is
currently reported for each manager. Change to reporting both in seconds since
the last connect and disconnect events respectively. An empty value indicates
no previous connection or disconnection.
This can help diagnose certain connectivity problems, e.g. flapping.
Requested-by: Peter Balland <peter@nicira.com>
Bug #4833.
Otherwise the refType always appears to be 0 (OVSDB_REF_STRONG).
Nothing in the code that uses these structures actually uses the refType
yet, so this does not fix any existing bug, but upcoming commits will add
users.
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.
reconnect uses the same connection state names as rconn with the exception of
the above. This commit makes their states identical, which should reduce
confusion for people debugging connection problems.
Commit a4613b01ab (ovsdb: Change the way connection duration time is reported
in Manager table.), pushed earlier today, requires this commit, so OVSDB has
been unbuildable from then to now.
This makes it possible to run tests that need access to installation
directories, such as the rundir, without having access to the actual
installation directories (/var/run is generally not world-writable), by
setting environment variables. This is not a good way to do things in
general--usually it would be better to choose the correct directories
at configure time--so for now this is undocumented.
