2
0
mirror of https://github.com/openvswitch/ovs synced 2025-08-31 14:25:26 +00:00
Files
ovs/tests/ovsdb-monitor.at

1081 lines
39 KiB
Plaintext
Raw Normal View History

2009-11-16 10:38:14 -08:00
AT_BANNER([OVSDB -- ovsdb-server monitors])
OVS_START_SHELL_HELPERS
# ovsdb_check_monitor SCHEMA_FUNC DB TABLE OUTPUT COLUMNS
# PRE-MONITOR-TXN... -- TRANSACTION...
ovsdb_check_monitor () {
local schema_func=$1 db=$2 table=$3 output=$4 columns=$5
shift; shift; shift; shift; shift
$schema_func > schema
AT_CHECK([ovsdb-tool create db schema], [0], [stdout], [ignore])
while test "$1" != "--"; do
AT_CHECK([ovsdb-tool transact db "$1"], [0], [ignore], [ignore])
shift
done
shift
AT_CHECK([ovsdb-server --detach --no-chdir --pidfile --remote=punix:socket --log-file db > ovsdb-server.stdout 2> ovsdb-server.stderr],
[0], [], [])
on_exit 'kill `cat ovsdb-server.pid`'
if test "$IS_WIN32" = "yes"; then
AT_CHECK([ovsdb-client -vjsonrpc --pidfile --log-file -d json monitor --format=csv unix:socket $db $table $columns > output 2> ovsdb-client.stderr &],
[0], [ignore], [ignore])
sleep 1
else
AT_CHECK([ovsdb-client -vjsonrpc --detach --no-chdir --pidfile --log-file -d json monitor --format=csv unix:socket $db $table $columns > output 2> ovsdb-client.stderr],
[0], [ignore], [ignore])
fi
on_exit 'kill `cat ovsdb-client.pid`'
for txn in ${1+"$@"} '[["'$db'"]]'; do
AT_CHECK([ovsdb-client transact unix:socket "$txn"], [0], [ignore], [ignore])
done
OVSDB_SERVER_SHUTDOWN
OVS_WAIT_UNTIL([test ! -e ovsdb-client.pid])
AT_CHECK_UNQUOTED([$PYTHON3 $srcdir/ovsdb-monitor-sort.py < output | uuidfilt], [0], [$output], [ignore])
}
OVS_END_SHELL_HELPERS
# OVSDB_CHECK_MONITOR(TITLE, SCHEMA, [PRE-MONITOR-TXN], DB, TABLE,
# TRANSACTIONS, OUTPUT, [COLUMNS], [KEYWORDS])
2009-11-16 10:38:14 -08:00
#
# Creates a database with the given SCHEMA, starts an ovsdb-server on
# that database, and runs each of the TRANSACTIONS (which should be a
# quoted list of quoted strings) against it with ovsdb-client one at a
# time. COLUMNS, if specified, is passed to ovsdb-client as the set
# of columns and operations to select.
2009-11-16 10:38:14 -08:00
#
# Checks that the overall output is OUTPUT, but UUIDs in the output
# are replaced by markers of the form <N> where N is a number. The
# first unique UUID is replaced by <0>, the next by <1>, and so on.
# If a given UUID appears more than once it is always replaced by the
# same marker.
#
# TITLE is provided to AT_SETUP and KEYWORDS to AT_KEYWORDS.
m4_define([OVSDB_CHECK_MONITOR],
2009-11-16 10:38:14 -08:00
[AT_SETUP([$1])
AT_KEYWORDS([ovsdb server monitor positive $9])
AT_CAPTURE_FILE([ovsdb-server.log])
AT_CAPTURE_FILE([ovsdb-server.stdout])
AT_CAPTURE_FILE([ovsdb-server.stderr])
AT_CAPTURE_FILE([ovsdb-client.log])
AT_CAPTURE_FILE([ovsdb-client.stderr])
ovsdb_check_monitor '$2' '$4' '$5' '$7' '$8' \
m4_foreach([txn], [$3], ['txn' ]) -- \
m4_foreach([txn], [$6], ['txn' ])
2009-11-16 10:38:14 -08:00
AT_CLEANUP])
# OVSDB_CHECK_MONITOR_COND(TITLE, SCHEMA, [PRE-MONITOR-TXN], DB, TABLE,
# TRANSACTIONS, OUTPUT, CONDITIONS, [COLUMNS], [KEYWORDS],
# [CONDITIONS_CHANGE])
#
# Creates a database with the given SCHEMA, starts an ovsdb-server on
# that database, and runs each of the TRANSACTIONS (which should be a
# quoted list of quoted strings) against it with ovsdb-client one at a
# time. COLUMNS, if specified, is passed to ovsdb-client as the set
# of columns and operations to select.
#
# Checks that the overall output is OUTPUT, but UUIDs in the output
# are replaced by markers of the form <N> where N is a number. The
# first unique UUID is replaced by <0>, the next by <1>, and so on.
# If a given UUID appears more than once it is always replaced by the
# same marker.
#
# TITLE is provided to AT_SETUP and KEYWORDS to AT_KEYWORDS.
m4_define([OVSDB_CHECK_MONITOR_COND],
[AT_SETUP([$1])
AT_KEYWORDS([ovsdb server monitor monitor-cond positive $10])
$2 > schema
AT_CHECK([ovsdb-tool create db schema], [0], [stdout], [ignore])
for txn in m4_foreach([txn], [$3], ['txn' ]); do
AT_CHECK([ovsdb-tool transact db "$txn"], [0], [ignore], [ignore])
done
AT_CAPTURE_FILE([ovsdb-server.log])
AT_CHECK([ovsdb-server --detach --no-chdir --pidfile --remote=punix:socket --log-file db], [0], [ignore], [ignore])
tests: Get rid of overly specific --pidfile and --unixctl options. At an early point in OVS development, OVS was built with fixed default directories for pidfiles and sockets. This meant that it was necessary to use lots of --pidfile and --unixctl options in the testsuite, to point the daemons to where they should put these files (since the testsuite cannot and generally should not touch the real system /var/run). Later on, the environment variables OVS_RUNDIR, OVS_LOGDIR, etc. were introduced to override these defaults, and even later the testsuite was changed to always set these variables correctly in every test. Thus, these days it isn't usually necessary to specify a filename on --pidfile or to specify --unixctl at all. However, many of the tests are built by cut-and-paste, so they tended to keep appearing anyhow. This commit drops most of them, making the testsuite easier to read and understand. This commit also sweeps away some other historical detritus. In particular, in early days of the testsuite there was no way to automatically kill daemons when a test failed (or otherwise ended). This meant that some tests were littered with calls to "kill `cat pidfile`" on almost every line (or m4 macros that expanded to the same thing) so that if a test failed partway through the testsuite would not hang waiting for a daemon to die that was never going to die without manual intervention. However, a long time ago we introduced the "on_exit" mechanism that obsoletes this. This commit eliminates a lot of the old litter of kill invocations, which also makes those tests easier to read. Signed-off-by: Ben Pfaff <blp@ovn.org> Acked-by: Andy Zhou <azhou@ovn.org>
2016-10-05 20:07:56 -07:00
on_exit 'kill `cat ovsdb-server.pid`'
AT_CHECK([ovsdb-client -vjsonrpc --pidfile --detach --no-chdir -d json monitor-cond --format=csv unix:socket $4 '[$8]' $5 $9 > output 2> ovsdb-client.stderr],
[0], [ignore], [ignore])
tests: Get rid of overly specific --pidfile and --unixctl options. At an early point in OVS development, OVS was built with fixed default directories for pidfiles and sockets. This meant that it was necessary to use lots of --pidfile and --unixctl options in the testsuite, to point the daemons to where they should put these files (since the testsuite cannot and generally should not touch the real system /var/run). Later on, the environment variables OVS_RUNDIR, OVS_LOGDIR, etc. were introduced to override these defaults, and even later the testsuite was changed to always set these variables correctly in every test. Thus, these days it isn't usually necessary to specify a filename on --pidfile or to specify --unixctl at all. However, many of the tests are built by cut-and-paste, so they tended to keep appearing anyhow. This commit drops most of them, making the testsuite easier to read and understand. This commit also sweeps away some other historical detritus. In particular, in early days of the testsuite there was no way to automatically kill daemons when a test failed (or otherwise ended). This meant that some tests were littered with calls to "kill `cat pidfile`" on almost every line (or m4 macros that expanded to the same thing) so that if a test failed partway through the testsuite would not hang waiting for a daemon to die that was never going to die without manual intervention. However, a long time ago we introduced the "on_exit" mechanism that obsoletes this. This commit eliminates a lot of the old litter of kill invocations, which also makes those tests easier to read. Signed-off-by: Ben Pfaff <blp@ovn.org> Acked-by: Andy Zhou <azhou@ovn.org>
2016-10-05 20:07:56 -07:00
on_exit 'kill `cat ovsdb-client.pid`'
for txn in m4_foreach([txn], [$6], ['txn' ]); do
AT_CHECK([ovsdb-client transact unix:socket "$txn"], [0],
[ignore], [ignore], [kill `cat server-pid client-pid`])
done
for cond in m4_foreach([cond], [$10], ['cond' ]); do
AT_CHECK([ovs-appctl -t ovsdb-client ovsdb-client/cond_change $5 "$cond"], [0], [ignore], [ignore])
done
AT_CHECK([ovsdb-client transact unix:socket '[["$4"]]'], [0],
tests: Get rid of overly specific --pidfile and --unixctl options. At an early point in OVS development, OVS was built with fixed default directories for pidfiles and sockets. This meant that it was necessary to use lots of --pidfile and --unixctl options in the testsuite, to point the daemons to where they should put these files (since the testsuite cannot and generally should not touch the real system /var/run). Later on, the environment variables OVS_RUNDIR, OVS_LOGDIR, etc. were introduced to override these defaults, and even later the testsuite was changed to always set these variables correctly in every test. Thus, these days it isn't usually necessary to specify a filename on --pidfile or to specify --unixctl at all. However, many of the tests are built by cut-and-paste, so they tended to keep appearing anyhow. This commit drops most of them, making the testsuite easier to read and understand. This commit also sweeps away some other historical detritus. In particular, in early days of the testsuite there was no way to automatically kill daemons when a test failed (or otherwise ended). This meant that some tests were littered with calls to "kill `cat pidfile`" on almost every line (or m4 macros that expanded to the same thing) so that if a test failed partway through the testsuite would not hang waiting for a daemon to die that was never going to die without manual intervention. However, a long time ago we introduced the "on_exit" mechanism that obsoletes this. This commit eliminates a lot of the old litter of kill invocations, which also makes those tests easier to read. Signed-off-by: Ben Pfaff <blp@ovn.org> Acked-by: Andy Zhou <azhou@ovn.org>
2016-10-05 20:07:56 -07:00
[ignore], [ignore])
OVSDB_SERVER_SHUTDOWN
tests: Get rid of overly specific --pidfile and --unixctl options. At an early point in OVS development, OVS was built with fixed default directories for pidfiles and sockets. This meant that it was necessary to use lots of --pidfile and --unixctl options in the testsuite, to point the daemons to where they should put these files (since the testsuite cannot and generally should not touch the real system /var/run). Later on, the environment variables OVS_RUNDIR, OVS_LOGDIR, etc. were introduced to override these defaults, and even later the testsuite was changed to always set these variables correctly in every test. Thus, these days it isn't usually necessary to specify a filename on --pidfile or to specify --unixctl at all. However, many of the tests are built by cut-and-paste, so they tended to keep appearing anyhow. This commit drops most of them, making the testsuite easier to read and understand. This commit also sweeps away some other historical detritus. In particular, in early days of the testsuite there was no way to automatically kill daemons when a test failed (or otherwise ended). This meant that some tests were littered with calls to "kill `cat pidfile`" on almost every line (or m4 macros that expanded to the same thing) so that if a test failed partway through the testsuite would not hang waiting for a daemon to die that was never going to die without manual intervention. However, a long time ago we introduced the "on_exit" mechanism that obsoletes this. This commit eliminates a lot of the old litter of kill invocations, which also makes those tests easier to read. Signed-off-by: Ben Pfaff <blp@ovn.org> Acked-by: Andy Zhou <azhou@ovn.org>
2016-10-05 20:07:56 -07:00
OVS_WAIT_UNTIL([test ! -e ovsdb-server.pid && test ! -e ovsdb-client.pid])
AT_CHECK([$PYTHON3 $srcdir/ovsdb-monitor-sort.py < output | uuidfilt], [0], [$7], [ignore])
AT_CLEANUP])
OVSDB_CHECK_MONITOR([monitor insert into empty table],
[ordinal_schema],
2009-11-16 10:38:14 -08:00
[],
[ordinals], [ordinals],
[[[["ordinals",
{"op": "insert",
2009-11-16 10:38:14 -08:00
"table": "ordinals",
"row": {"number": 0, "name": "zero"}}]]]],
[[row,action,name,number,_version
<0>,insert,"""zero""",0,"[""uuid"",""<1>""]"
]])
OVSDB_CHECK_MONITOR([monitor insert into populated table],
[ordinal_schema],
[[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 10, "name": "ten"}}]]]],
[ordinals], [ordinals],
[[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 0, "name": "zero"}}]]]],
[[row,action,name,number,_version
<0>,initial,"""ten""",10,"[""uuid"",""<1>""]"
row,action,name,number,_version
<2>,insert,"""zero""",0,"[""uuid"",""<3>""]"
]])
OVSDB_CHECK_MONITOR([monitor delete],
[ordinal_schema],
[[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 10, "name": "ten"}}]]]],
[ordinals], [ordinals],
[[[["ordinals",
{"op": "delete",
"table": "ordinals",
"where": [["number", "==", 10]]}]]]],
[[row,action,name,number,_version
<0>,initial,"""ten""",10,"[""uuid"",""<1>""]"
row,action,name,number,_version
<0>,delete,"""ten""",10,"[""uuid"",""<1>""]"
]])
OVSDB_CHECK_MONITOR([monitor row update],
[ordinal_schema],
[[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 10, "name": "ten"}}]]]],
[ordinals], [ordinals],
[[[["ordinals",
{"op": "update",
"table": "ordinals",
"where": [["number", "==", 10]],
"row": {"name": "five plus five"}}]]]],
[[row,action,name,number,_version
<0>,initial,"""ten""",10,"[""uuid"",""<1>""]"
row,action,name,number,_version
<0>,old,"""ten""",,"[""uuid"",""<1>""]"
,new,"""five plus five""",10,"[""uuid"",""<2>""]"
]])
OVSDB_CHECK_MONITOR([monitor no-op row updates],
[ordinal_schema],
[[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 10, "name": "ten"}}]]]],
[ordinals], [ordinals],
[[[["ordinals",
{"op": "update",
"table": "ordinals",
"where": [["number", "==", 10]],
"row": {"number": 10, "name": "ten"}}]]],
[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 9, "name": "nine"}}]]]],
[[row,action,name,number,_version
<0>,initial,"""ten""",10,"[""uuid"",""<1>""]"
row,action,name,number,_version
<2>,insert,"""nine""",9,"[""uuid"",""<3>""]"
]])
OVSDB_CHECK_MONITOR([monitor insert-and-update transaction],
[ordinal_schema],
[[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 10, "name": "ten"}}]]]],
[ordinals], [ordinals],
[[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 9, "name": "nine"},
"uuid-name": "nine"},
{"op": "update",
"table": "ordinals",
"where": [["_uuid", "==", ["named-uuid", "nine"]]],
"row": {"name": "three squared"}}]]]],
[[row,action,name,number,_version
<0>,initial,"""ten""",10,"[""uuid"",""<1>""]"
row,action,name,number,_version
<2>,insert,"""three squared""",9,"[""uuid"",""<3>""]"
]])
OVSDB_CHECK_MONITOR([monitor insert-update-and-delete transaction],
[ordinal_schema],
[[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 10, "name": "ten"}}]]]],
[ordinals], [ordinals],
[[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 9, "name": "nine"},
"uuid-name": "nine"},
{"op": "update",
"table": "ordinals",
"where": [["_uuid", "==", ["named-uuid", "nine"]]],
"row": {"name": "three squared"}},
{"op": "delete",
"table": "ordinals",
"where": [["_uuid", "==", ["named-uuid", "nine"]]]},
{"op": "insert",
"table": "ordinals",
"row": {"number": 7, "name": "seven"}}]]]],
[[row,action,name,number,_version
<0>,initial,"""ten""",10,"[""uuid"",""<1>""]"
row,action,name,number,_version
<2>,insert,"""seven""",7,"[""uuid"",""<3>""]"
]])
OVSDB_CHECK_MONITOR([monitor weak reference change],
[weak_schema],
[[[["weak",
{"op": "insert",
"table": "a",
"row": {"a": 0,
"a2a1": ["named-uuid", "a0"],
"a2b": ["named-uuid", "b2"]},
"uuid-name": "a0"},
{"op": "insert",
"table": "a",
"row": {"a": 1,
"a2a": ["named-uuid", "a0"],
"a2a1": ["named-uuid", "a1"],
"a2b": ["named-uuid", "b2"]},
"uuid-name": "a1"},
{"op": "insert",
"table": "b",
"row": {"b": 2},
"uuid-name": "b2"}]]]],
[weak], [a],
[[[["weak",
{"op": "delete",
"table": "a",
"where": [["a", "==", 0]]}]]]],
[[row,action,a,a2a,a2a1,a2b,_version
<0>,initial,0,"[""set"",[]]","[""uuid"",""<0>""]","[""uuid"",""<1>""]","[""uuid"",""<2>""]"
<3>,initial,1,"[""uuid"",""<0>""]","[""uuid"",""<3>""]","[""uuid"",""<1>""]","[""uuid"",""<4>""]"
row,action,a,a2a,a2a1,a2b,_version
<0>,delete,0,"[""set"",[]]","[""uuid"",""<0>""]","[""uuid"",""<1>""]","[""uuid"",""<2>""]"
<3>,old,,"[""uuid"",""<0>""]",,,"[""uuid"",""<4>""]"
,new,1,"[""set"",[]]","[""uuid"",""<3>""]","[""uuid"",""<1>""]","[""uuid"",""<5>""]"
]])
OVSDB_CHECK_MONITOR([monitor insert-update-and-delete transaction],
[ordinal_schema],
[[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 10, "name": "ten"}}]]]],
[ordinals], [ordinals],
[[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 9, "name": "nine"},
"uuid-name": "nine"},
{"op": "update",
"table": "ordinals",
"where": [["_uuid", "==", ["named-uuid", "nine"]]],
"row": {"name": "three squared"}},
{"op": "delete",
"table": "ordinals",
"where": [["_uuid", "==", ["named-uuid", "nine"]]]},
{"op": "insert",
"table": "ordinals",
"row": {"number": 7, "name": "seven"}}]]]],
[[row,action,name,number,_version
<0>,initial,"""ten""",10,"[""uuid"",""<1>""]"
row,action,name,number,_version
<2>,insert,"""seven""",7,"[""uuid"",""<3>""]"
]])
AT_BANNER([ovsdb -- ovsdb-monitor monitor only some operations])
m4_define([OVSDB_MONITOR_INITIAL],
[[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 10, "name": "ten"}}]]]])
m4_define([OVSDB_MONITOR_TXNS],
[[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 5, "name": "five"}}]]],
[[["ordinals",
{"op": "update",
"table": "ordinals",
"where": [["name", "==", "five"]],
"row": {"name": "FIVE"}}]]],
[[["ordinals",
{"op": "delete",
"table": "ordinals",
"where": []}]]]])
OVSDB_CHECK_MONITOR([monitor all operations],
[ordinal_schema], [OVSDB_MONITOR_INITIAL],
[ordinals], [ordinals], [OVSDB_MONITOR_TXNS],
[[row,action,name,number,_version
<0>,initial,"""ten""",10,"[""uuid"",""<1>""]"
row,action,name,number,_version
<2>,insert,"""five""",5,"[""uuid"",""<3>""]"
row,action,name,number,_version
<2>,old,"""five""",,"[""uuid"",""<3>""]"
,new,"""FIVE""",5,"[""uuid"",""<4>""]"
row,action,name,number,_version
<2>,delete,"""FIVE""",5,"[""uuid"",""<4>""]"
<0>,delete,"""ten""",10,"[""uuid"",""<1>""]"
]])
dnl A monitor with "initial" only doesn't really make sense,
dnl but it's still allowed and should work.
OVSDB_CHECK_MONITOR([monitor initial only],
[ordinal_schema], [OVSDB_MONITOR_INITIAL],
[ordinals], [ordinals], [OVSDB_MONITOR_TXNS],
[[row,action,name,number,_version
<0>,initial,"""ten""",10,"[""uuid"",""<1>""]"
]], [!insert,!delete,!modify])
OVSDB_CHECK_MONITOR([monitor insert only],
[ordinal_schema], [OVSDB_MONITOR_INITIAL],
[ordinals], [ordinals], [OVSDB_MONITOR_TXNS],
[[row,action,name,number,_version
<0>,insert,"""five""",5,"[""uuid"",""<1>""]"
]], [!initial,!delete,!modify])
OVSDB_CHECK_MONITOR([monitor delete only],
[ordinal_schema], [OVSDB_MONITOR_INITIAL],
[ordinals], [ordinals], [OVSDB_MONITOR_TXNS],
[[row,action,name,number,_version
<0>,delete,"""FIVE""",5,"[""uuid"",""<1>""]"
<2>,delete,"""ten""",10,"[""uuid"",""<3>""]"
]], [!initial,!insert,!modify])
OVSDB_CHECK_MONITOR([monitor modify only],
[ordinal_schema], [OVSDB_MONITOR_INITIAL],
[ordinals], [ordinals], [OVSDB_MONITOR_TXNS],
[[row,action,name,number,_version
<0>,old,"""five""",,"[""uuid"",""<1>""]"
,new,"""FIVE""",5,"[""uuid"",""<2>""]"
]], [!initial,!insert,!delete])
AT_BANNER([ovsdb -- ovsdb-monitor-cond conditional monitor only some operations])
OVSDB_CHECK_MONITOR_COND([monitor-cond empty condition],
[ordinal_schema],
[[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 0, "name": "zero"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 1, "name": "one"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 2, "name": "two"}}]]]],
[ordinals], [ordinals],
[[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 10, "name": "ten"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 11, "name": "eleven"}}]]]],
[[row,action,name,number,_version
<0>,initial,"""one""",1,"[""uuid"",""<1>""]"
<2>,initial,"""two""",2,"[""uuid"",""<3>""]"
<4>,initial,"""zero""",,"[""uuid"",""<5>""]"
row,action,name,number,_version
<6>,insert,"""eleven""",11,"[""uuid"",""<7>""]"
<8>,insert,"""ten""",10,"[""uuid"",""<9>""]"
]],
[[]])
OVSDB_CHECK_MONITOR_COND([monitor-cond multiple conditions],
[ordinal_schema],
[[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 0, "name": "zero"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 1, "name": "one"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 2, "name": "two"}}]]]],
[ordinals], [ordinals],
[[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 10, "name": "ten"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 11, "name": "eleven"}}]]]],
[[row,action,name,number,_version
<0>,initial,"""one""",1,"[""uuid"",""<1>""]"
row,action,name,number,_version
<2>,insert,"""ten""",10,"[""uuid"",""<3>""]"
]],
[[["name","==","one"],["name","==","ten"]]])
OVSDB_CHECK_MONITOR_COND([monitor-cond delete from populated table],
[ordinal_schema],
[[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 0, "name": "zero"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 1, "name": "one"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 2, "name": "two"}}]]]],
[ordinals], [ordinals],
[[[["ordinals",
{"op": "delete",
"table": "ordinals",
"where": []}]]]],
[[row,action,name,number,_version
<0>,initial,"""one""",1,"[""uuid"",""<1>""]"
row,action,name,number,_version
<0>,delete,,,
]],
[[["name","==","one"],["name","==","ten"]]])
OVSDB_CHECK_MONITOR_COND([monitor-cond insert due to modify],
[ordinal_schema],
[[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 0, "name": "zero"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 1, "name": "one"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 2, "name": "two"}}]]]],
[ordinals], [ordinals],
[[[["ordinals",
{"op": "update",
"table": "ordinals",
"where": [["name", "==", "one"]],
"row": {"name": "ONE"}}]]]],
[[row,action,name,number,_version
<0>,insert,"""ONE""",1,"[""uuid"",""<1>""]"
]],
[[["name","==","ONE"]]],
[!initial,!delete,!modify])
OVSDB_CHECK_MONITOR_COND([monitor-cond delete due to modify],
[ordinal_schema],
[[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 0, "name": "zero"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 1, "name": "one"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 2, "name": "two"}}]]]],
[ordinals], [ordinals],
[[[["ordinals",
{"op": "update",
"table": "ordinals",
"where": [["name", "==", "one"]],
"row": {"name": "ONE"}}]]]],
[[row,action,name,number,_version
<0>,delete,,,
]],
[[["name","==","one"]]],
[!initial,!insert,!modify])
OVSDB_CHECK_MONITOR_COND([monitor-cond condition non-monitored columns],
[ordinal_schema],
[[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 0, "name": "zero"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 1, "name": "one"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 2, "name": "two"}}]]]],
[ordinals], [ordinals],
[[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 10, "name": "ten"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 11, "name": "eleven"}}]]]],
[[row,action,number
<0>,initial,1
row,action,number
<1>,insert,10
]],
[[["name","==","one"],["name","==","ten"]]],
["number"])
OVSDB_CHECK_MONITOR_COND([monitor-cond-change],
[ordinal_schema],
[[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 0, "name": "zero"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 1, "name": "one"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 2, "name": "two"}}]]]],
[ordinals], [ordinals],
[],
[[row,action,name,number,_version
<0>,initial,"""one""",1,"[""uuid"",""<1>""]"
<2>,initial,"""two""",2,"[""uuid"",""<3>""]"
<4>,initial,"""zero""",,"[""uuid"",""<5>""]"
row,action,name,number,_version
<4>,delete,,,
row,action,name,number,_version
<2>,delete,,,
row,action,name,number,_version
<0>,delete,,,
row,action,name,number,_version
<0>,insert,"""one""",1,"[""uuid"",""<1>""]"
<2>,insert,"""two""",2,"[""uuid"",""<3>""]"
<4>,insert,"""zero""",,"[""uuid"",""<5>""]"
]],
[[]],
[],
[[[[["name","==","one"],["name","==","two"]]]],
[[[["name","==","two"],["name","==","one"]]]],
[[[["name","==","one"]]]],
[[[false]]],
[[[true]]]])
monitor: Fix crash when monitor condition adds new columns. The OVSDB conditional monitor implementation allows many clients to share same copy of monitored data if the clients are sharing same tables and columns being monitored, while they can have different monitor conditions. In monitor conditions they can have different columns which can be different from the columns being monitored. So the struct ovsdb_monitor_table maintains the union of the all the columns being used in any conditions. The problem of the current implementation is that for each change set generated, it doesn't maintain any metadata for the number of columns for the data that has already populated in it. Instead, it always rely on the n_columns field of the struct ovsdb_monitor_table to manipulate the data. However, the n_columns in struct ovsdb_monitor_table can increase (e.g. when a client changes its condition which involves more columns). So it can result in that the existing rows in a change set with N columns being later processed as if it had more than N columns, typically, when the row is freed. This causes the ovsdb-server crashing (see an example of the backtrace). The patch fixes the problem by maintaining n_columns for each change set, and added a test case which fails without the fix. (gdb) bt at lib/ovsdb-data.c:1031 out>, mt=<optimized out>) at ovsdb/monitor.c:320 mt=0x1e7b940) at ovsdb/monitor.c:333 out>, transaction=<optimized out>) at ovsdb/monitor.c:527 initial=<optimized out>, cond_updated=cond_updated@entry=false, unflushed_=unflushed_@entry=0x20dae70, condition=<optimized out>, version=<optimized out>) at ovsdb/monitor.c:1156 (m=m@entry=0x20dae40, initial=initial@entry=false) at ovsdb/jsonrpc-server.c:1655 at ovsdb/jsonrpc-server.c:1729 ovsdb/jsonrpc-server.c:551 ovsdb/jsonrpc-server.c:586 ovsdb/jsonrpc-server.c:401 exiting=0x7ffdb947f76f, run_process=0x0, remotes=0x7ffdb947f7c0, unixctl=0x1e7a560, all_dbs=0x7ffdb947f800, jsonrpc=<optimized out>, config=0x7ffdb947f820) at ovsdb/ovsdb-server.c:209 Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-11 18:19:21 -08:00
AT_SETUP(monitor-cond-change with many sessions pending)
AT_KEYWORDS([ovsdb server monitor monitor-cond negative])
ordinal_schema > schema
AT_CHECK([ovsdb-tool create db schema], [0], [stdout], [ignore])
AT_CAPTURE_FILE([ovsdb-server.log])
ovsdb-monitor: Support monitor_cond_since. Support the new monitor method monitor_cond_since so that a client can request monitoring start from a specific point instead of always from beginning. This will reduce the cost at scenarios when server is restarted/failed-over but client still has all existing data. In these scenarios only new changes (and in most cases no change) needed to be transfered to client. When ovsdb-server restarted, history transactions are read from disk file; when ovsdb-server failed over, history transactions exists already in the memory of the new server. There are situations that the requested transaction may not be found. For example, a transaction that is too old and has been discarded from the maintained history list in memory, or the transactions on disk has been compacted during ovsdb compaction. In those situations the server fall backs to transfer all data start from begining. For more details of the protocol change, see Documentation/ref/ovsdb-server.7.rst. This change includes both server side and ovsdb-client side changes with the new protocol. IDLs using this capability will be added in future patches. Now the feature takes effect only for cluster mode of ovsdb-server, because cluster mode is the only mode that supports unique transcation uuid today. For other modes, the monitor_cond_since always fall back to transfer all data with found = false. Support for those modes can be added in the future. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-28 09:15:18 -08:00
AT_CHECK([ovsdb-server --detach --no-chdir --pidfile --remote=punix:socket --log-file db], [0], [ignore], [ignore])
monitor: Fix crash when monitor condition adds new columns. The OVSDB conditional monitor implementation allows many clients to share same copy of monitored data if the clients are sharing same tables and columns being monitored, while they can have different monitor conditions. In monitor conditions they can have different columns which can be different from the columns being monitored. So the struct ovsdb_monitor_table maintains the union of the all the columns being used in any conditions. The problem of the current implementation is that for each change set generated, it doesn't maintain any metadata for the number of columns for the data that has already populated in it. Instead, it always rely on the n_columns field of the struct ovsdb_monitor_table to manipulate the data. However, the n_columns in struct ovsdb_monitor_table can increase (e.g. when a client changes its condition which involves more columns). So it can result in that the existing rows in a change set with N columns being later processed as if it had more than N columns, typically, when the row is freed. This causes the ovsdb-server crashing (see an example of the backtrace). The patch fixes the problem by maintaining n_columns for each change set, and added a test case which fails without the fix. (gdb) bt at lib/ovsdb-data.c:1031 out>, mt=<optimized out>) at ovsdb/monitor.c:320 mt=0x1e7b940) at ovsdb/monitor.c:333 out>, transaction=<optimized out>) at ovsdb/monitor.c:527 initial=<optimized out>, cond_updated=cond_updated@entry=false, unflushed_=unflushed_@entry=0x20dae70, condition=<optimized out>, version=<optimized out>) at ovsdb/monitor.c:1156 (m=m@entry=0x20dae40, initial=initial@entry=false) at ovsdb/jsonrpc-server.c:1655 at ovsdb/jsonrpc-server.c:1729 ovsdb/jsonrpc-server.c:551 ovsdb/jsonrpc-server.c:586 ovsdb/jsonrpc-server.c:401 exiting=0x7ffdb947f76f, run_process=0x0, remotes=0x7ffdb947f7c0, unixctl=0x1e7a560, all_dbs=0x7ffdb947f800, jsonrpc=<optimized out>, config=0x7ffdb947f820) at ovsdb/ovsdb-server.c:209 Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-11 18:19:21 -08:00
on_exit 'kill `cat ovsdb-server.pid`'
for txn in m4_foreach([txn], [[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 0, "name": "zero"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 1, "name": "one"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 2, "name": "two"}}]]]], ['txn' ]); do
AT_CHECK([ovsdb-client transact unix:socket "$txn"], [0], [ignore], [ignore])
done
# 1001 clients monitoring column "name" and with condition for "name" only.
# The clients are created in a way that the 991th client will request condition
# change, so that the chance is high that the condition change will be handled
# before some pending changes are freed.
cond='[[["name","==","ten"]]]'
for i in `seq 1 990`; do
AT_CHECK([ovsdb-client -vjsonrpc --pidfile=ovsdb-client$i.pid --detach --no-chdir -d json monitor-cond --format=csv unix:socket ordinals $cond ordinals ["name"] >ovsdb-client$i.out 2>&1], [0], [ignore], [ignore])
monitor: Fix crash when monitor condition adds new columns. The OVSDB conditional monitor implementation allows many clients to share same copy of monitored data if the clients are sharing same tables and columns being monitored, while they can have different monitor conditions. In monitor conditions they can have different columns which can be different from the columns being monitored. So the struct ovsdb_monitor_table maintains the union of the all the columns being used in any conditions. The problem of the current implementation is that for each change set generated, it doesn't maintain any metadata for the number of columns for the data that has already populated in it. Instead, it always rely on the n_columns field of the struct ovsdb_monitor_table to manipulate the data. However, the n_columns in struct ovsdb_monitor_table can increase (e.g. when a client changes its condition which involves more columns). So it can result in that the existing rows in a change set with N columns being later processed as if it had more than N columns, typically, when the row is freed. This causes the ovsdb-server crashing (see an example of the backtrace). The patch fixes the problem by maintaining n_columns for each change set, and added a test case which fails without the fix. (gdb) bt at lib/ovsdb-data.c:1031 out>, mt=<optimized out>) at ovsdb/monitor.c:320 mt=0x1e7b940) at ovsdb/monitor.c:333 out>, transaction=<optimized out>) at ovsdb/monitor.c:527 initial=<optimized out>, cond_updated=cond_updated@entry=false, unflushed_=unflushed_@entry=0x20dae70, condition=<optimized out>, version=<optimized out>) at ovsdb/monitor.c:1156 (m=m@entry=0x20dae40, initial=initial@entry=false) at ovsdb/jsonrpc-server.c:1655 at ovsdb/jsonrpc-server.c:1729 ovsdb/jsonrpc-server.c:551 ovsdb/jsonrpc-server.c:586 ovsdb/jsonrpc-server.c:401 exiting=0x7ffdb947f76f, run_process=0x0, remotes=0x7ffdb947f7c0, unixctl=0x1e7a560, all_dbs=0x7ffdb947f800, jsonrpc=<optimized out>, config=0x7ffdb947f820) at ovsdb/ovsdb-server.c:209 Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-11 18:19:21 -08:00
done
AT_CHECK([ovsdb-client -vjsonrpc --pidfile --detach --no-chdir -d json monitor-cond --format=csv unix:socket ordinals $cond ordinals ["name"] > output 2> ovsdb-client.stderr],
monitor: Fix crash when monitor condition adds new columns. The OVSDB conditional monitor implementation allows many clients to share same copy of monitored data if the clients are sharing same tables and columns being monitored, while they can have different monitor conditions. In monitor conditions they can have different columns which can be different from the columns being monitored. So the struct ovsdb_monitor_table maintains the union of the all the columns being used in any conditions. The problem of the current implementation is that for each change set generated, it doesn't maintain any metadata for the number of columns for the data that has already populated in it. Instead, it always rely on the n_columns field of the struct ovsdb_monitor_table to manipulate the data. However, the n_columns in struct ovsdb_monitor_table can increase (e.g. when a client changes its condition which involves more columns). So it can result in that the existing rows in a change set with N columns being later processed as if it had more than N columns, typically, when the row is freed. This causes the ovsdb-server crashing (see an example of the backtrace). The patch fixes the problem by maintaining n_columns for each change set, and added a test case which fails without the fix. (gdb) bt at lib/ovsdb-data.c:1031 out>, mt=<optimized out>) at ovsdb/monitor.c:320 mt=0x1e7b940) at ovsdb/monitor.c:333 out>, transaction=<optimized out>) at ovsdb/monitor.c:527 initial=<optimized out>, cond_updated=cond_updated@entry=false, unflushed_=unflushed_@entry=0x20dae70, condition=<optimized out>, version=<optimized out>) at ovsdb/monitor.c:1156 (m=m@entry=0x20dae40, initial=initial@entry=false) at ovsdb/jsonrpc-server.c:1655 at ovsdb/jsonrpc-server.c:1729 ovsdb/jsonrpc-server.c:551 ovsdb/jsonrpc-server.c:586 ovsdb/jsonrpc-server.c:401 exiting=0x7ffdb947f76f, run_process=0x0, remotes=0x7ffdb947f7c0, unixctl=0x1e7a560, all_dbs=0x7ffdb947f800, jsonrpc=<optimized out>, config=0x7ffdb947f820) at ovsdb/ovsdb-server.c:209 Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-11 18:19:21 -08:00
[0], [ignore], [ignore])
for i in `seq 991 1000`; do
AT_CHECK([ovsdb-client -vjsonrpc --pidfile=ovsdb-client$i.pid --detach --no-chdir -d json monitor-cond --format=csv unix:socket ordinals $cond ordinals ["name"] >ovsdb-client$i.out 2>&1 ], [0], [ignore], [ignore])
monitor: Fix crash when monitor condition adds new columns. The OVSDB conditional monitor implementation allows many clients to share same copy of monitored data if the clients are sharing same tables and columns being monitored, while they can have different monitor conditions. In monitor conditions they can have different columns which can be different from the columns being monitored. So the struct ovsdb_monitor_table maintains the union of the all the columns being used in any conditions. The problem of the current implementation is that for each change set generated, it doesn't maintain any metadata for the number of columns for the data that has already populated in it. Instead, it always rely on the n_columns field of the struct ovsdb_monitor_table to manipulate the data. However, the n_columns in struct ovsdb_monitor_table can increase (e.g. when a client changes its condition which involves more columns). So it can result in that the existing rows in a change set with N columns being later processed as if it had more than N columns, typically, when the row is freed. This causes the ovsdb-server crashing (see an example of the backtrace). The patch fixes the problem by maintaining n_columns for each change set, and added a test case which fails without the fix. (gdb) bt at lib/ovsdb-data.c:1031 out>, mt=<optimized out>) at ovsdb/monitor.c:320 mt=0x1e7b940) at ovsdb/monitor.c:333 out>, transaction=<optimized out>) at ovsdb/monitor.c:527 initial=<optimized out>, cond_updated=cond_updated@entry=false, unflushed_=unflushed_@entry=0x20dae70, condition=<optimized out>, version=<optimized out>) at ovsdb/monitor.c:1156 (m=m@entry=0x20dae40, initial=initial@entry=false) at ovsdb/jsonrpc-server.c:1655 at ovsdb/jsonrpc-server.c:1729 ovsdb/jsonrpc-server.c:551 ovsdb/jsonrpc-server.c:586 ovsdb/jsonrpc-server.c:401 exiting=0x7ffdb947f76f, run_process=0x0, remotes=0x7ffdb947f7c0, unixctl=0x1e7a560, all_dbs=0x7ffdb947f800, jsonrpc=<optimized out>, config=0x7ffdb947f820) at ovsdb/ovsdb-server.c:209 Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-11 18:19:21 -08:00
done
for txn in m4_foreach([txn], [[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 10, "name": "ten"}}]]]], ['txn' ]); do
AT_CHECK([ovsdb-client transact unix:socket "$txn"], [0],
[ignore], [ignore], [kill `cat server-pid client-pid`])
done
# Change the condition so that a new column "number" is added to monitor table.
cond='[[["number","==",1]]]'
AT_CHECK([ovs-appctl -t ovsdb-client ovsdb-client/cond_change ordinals $cond], [0], [ignore], [ignore])
# Give some time for the server to flush and free pending changes
# (to crash, when n_columns is not handled properly)
sleep 1
AT_CHECK([ovsdb-client transact unix:socket '[["ordinals"]]'], [0],
[ignore], [ignore])
OVSDB_SERVER_SHUTDOWN("/Too many open files/d")
monitor: Fix crash when monitor condition adds new columns. The OVSDB conditional monitor implementation allows many clients to share same copy of monitored data if the clients are sharing same tables and columns being monitored, while they can have different monitor conditions. In monitor conditions they can have different columns which can be different from the columns being monitored. So the struct ovsdb_monitor_table maintains the union of the all the columns being used in any conditions. The problem of the current implementation is that for each change set generated, it doesn't maintain any metadata for the number of columns for the data that has already populated in it. Instead, it always rely on the n_columns field of the struct ovsdb_monitor_table to manipulate the data. However, the n_columns in struct ovsdb_monitor_table can increase (e.g. when a client changes its condition which involves more columns). So it can result in that the existing rows in a change set with N columns being later processed as if it had more than N columns, typically, when the row is freed. This causes the ovsdb-server crashing (see an example of the backtrace). The patch fixes the problem by maintaining n_columns for each change set, and added a test case which fails without the fix. (gdb) bt at lib/ovsdb-data.c:1031 out>, mt=<optimized out>) at ovsdb/monitor.c:320 mt=0x1e7b940) at ovsdb/monitor.c:333 out>, transaction=<optimized out>) at ovsdb/monitor.c:527 initial=<optimized out>, cond_updated=cond_updated@entry=false, unflushed_=unflushed_@entry=0x20dae70, condition=<optimized out>, version=<optimized out>) at ovsdb/monitor.c:1156 (m=m@entry=0x20dae40, initial=initial@entry=false) at ovsdb/jsonrpc-server.c:1655 at ovsdb/jsonrpc-server.c:1729 ovsdb/jsonrpc-server.c:551 ovsdb/jsonrpc-server.c:586 ovsdb/jsonrpc-server.c:401 exiting=0x7ffdb947f76f, run_process=0x0, remotes=0x7ffdb947f7c0, unixctl=0x1e7a560, all_dbs=0x7ffdb947f800, jsonrpc=<optimized out>, config=0x7ffdb947f820) at ovsdb/ovsdb-server.c:209 Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-11 18:19:21 -08:00
OVS_WAIT_UNTIL([test ! -e ovsdb-server.pid && test ! -e ovsdb-client.pid])
AT_CHECK([$PYTHON3 $srcdir/ovsdb-monitor-sort.py < output | uuidfilt], [0], [[row,action,name
monitor: Fix crash when monitor condition adds new columns. The OVSDB conditional monitor implementation allows many clients to share same copy of monitored data if the clients are sharing same tables and columns being monitored, while they can have different monitor conditions. In monitor conditions they can have different columns which can be different from the columns being monitored. So the struct ovsdb_monitor_table maintains the union of the all the columns being used in any conditions. The problem of the current implementation is that for each change set generated, it doesn't maintain any metadata for the number of columns for the data that has already populated in it. Instead, it always rely on the n_columns field of the struct ovsdb_monitor_table to manipulate the data. However, the n_columns in struct ovsdb_monitor_table can increase (e.g. when a client changes its condition which involves more columns). So it can result in that the existing rows in a change set with N columns being later processed as if it had more than N columns, typically, when the row is freed. This causes the ovsdb-server crashing (see an example of the backtrace). The patch fixes the problem by maintaining n_columns for each change set, and added a test case which fails without the fix. (gdb) bt at lib/ovsdb-data.c:1031 out>, mt=<optimized out>) at ovsdb/monitor.c:320 mt=0x1e7b940) at ovsdb/monitor.c:333 out>, transaction=<optimized out>) at ovsdb/monitor.c:527 initial=<optimized out>, cond_updated=cond_updated@entry=false, unflushed_=unflushed_@entry=0x20dae70, condition=<optimized out>, version=<optimized out>) at ovsdb/monitor.c:1156 (m=m@entry=0x20dae40, initial=initial@entry=false) at ovsdb/jsonrpc-server.c:1655 at ovsdb/jsonrpc-server.c:1729 ovsdb/jsonrpc-server.c:551 ovsdb/jsonrpc-server.c:586 ovsdb/jsonrpc-server.c:401 exiting=0x7ffdb947f76f, run_process=0x0, remotes=0x7ffdb947f7c0, unixctl=0x1e7a560, all_dbs=0x7ffdb947f800, jsonrpc=<optimized out>, config=0x7ffdb947f820) at ovsdb/ovsdb-server.c:209 Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-11 18:19:21 -08:00
<0>,insert,"""ten"""
row,action,name
<0>,delete,
<1>,insert,"""one"""
]], [ignore])
AT_CLEANUP
ovsdb-monitor: Support monitor_cond_since. Support the new monitor method monitor_cond_since so that a client can request monitoring start from a specific point instead of always from beginning. This will reduce the cost at scenarios when server is restarted/failed-over but client still has all existing data. In these scenarios only new changes (and in most cases no change) needed to be transfered to client. When ovsdb-server restarted, history transactions are read from disk file; when ovsdb-server failed over, history transactions exists already in the memory of the new server. There are situations that the requested transaction may not be found. For example, a transaction that is too old and has been discarded from the maintained history list in memory, or the transactions on disk has been compacted during ovsdb compaction. In those situations the server fall backs to transfer all data start from begining. For more details of the protocol change, see Documentation/ref/ovsdb-server.7.rst. This change includes both server side and ovsdb-client side changes with the new protocol. IDLs using this capability will be added in future patches. Now the feature takes effect only for cluster mode of ovsdb-server, because cluster mode is the only mode that supports unique transcation uuid today. For other modes, the monitor_cond_since always fall back to transfer all data with found = false. Support for those modes can be added in the future. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-28 09:15:18 -08:00
# Test monitor-cond-since with zero uuid, which shouldn't
# be found in server and server should send all rows
# as initial.
AT_SETUP([monitor-cond-since not found])
AT_KEYWORDS([ovsdb server monitor monitor-cond-since positive])
ordinal_schema > schema
AT_CHECK([ovsdb-tool create-cluster db schema unix:db.raft], [0], [stdout], [ignore])
AT_CAPTURE_FILE([ovsdb-server.log])
AT_CHECK([ovsdb-server --detach --no-chdir --pidfile --remote=punix:socket --log-file db], [0], [ignore], [ignore])
ovsdb-monitor: Support monitor_cond_since. Support the new monitor method monitor_cond_since so that a client can request monitoring start from a specific point instead of always from beginning. This will reduce the cost at scenarios when server is restarted/failed-over but client still has all existing data. In these scenarios only new changes (and in most cases no change) needed to be transfered to client. When ovsdb-server restarted, history transactions are read from disk file; when ovsdb-server failed over, history transactions exists already in the memory of the new server. There are situations that the requested transaction may not be found. For example, a transaction that is too old and has been discarded from the maintained history list in memory, or the transactions on disk has been compacted during ovsdb compaction. In those situations the server fall backs to transfer all data start from begining. For more details of the protocol change, see Documentation/ref/ovsdb-server.7.rst. This change includes both server side and ovsdb-client side changes with the new protocol. IDLs using this capability will be added in future patches. Now the feature takes effect only for cluster mode of ovsdb-server, because cluster mode is the only mode that supports unique transcation uuid today. For other modes, the monitor_cond_since always fall back to transfer all data with found = false. Support for those modes can be added in the future. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-28 09:15:18 -08:00
on_exit 'kill `cat ovsdb-server.pid`'
for txn in m4_foreach([txn], [[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 0, "name": "zero"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 1, "name": "one"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 2, "name": "two"}}]]]], ['txn' ]); do
AT_CHECK([ovsdb-client transact unix:socket "$txn"], [0], [ignore], [ignore])
done
# Omitting the last_id parameter in ovsdb-client monitor-cond-since command
# will by default using all zero uuid, which doesn't exist in any history txn.
AT_CHECK([ovsdb-client -vjsonrpc --pidfile --detach --no-chdir -d json monitor-cond-since --format=csv unix:socket ordinals '[[["name","==","one"],["name","==","ten"]]]' ordinals > output 2> ovsdb-client.stderr],
ovsdb-monitor: Support monitor_cond_since. Support the new monitor method monitor_cond_since so that a client can request monitoring start from a specific point instead of always from beginning. This will reduce the cost at scenarios when server is restarted/failed-over but client still has all existing data. In these scenarios only new changes (and in most cases no change) needed to be transfered to client. When ovsdb-server restarted, history transactions are read from disk file; when ovsdb-server failed over, history transactions exists already in the memory of the new server. There are situations that the requested transaction may not be found. For example, a transaction that is too old and has been discarded from the maintained history list in memory, or the transactions on disk has been compacted during ovsdb compaction. In those situations the server fall backs to transfer all data start from begining. For more details of the protocol change, see Documentation/ref/ovsdb-server.7.rst. This change includes both server side and ovsdb-client side changes with the new protocol. IDLs using this capability will be added in future patches. Now the feature takes effect only for cluster mode of ovsdb-server, because cluster mode is the only mode that supports unique transcation uuid today. For other modes, the monitor_cond_since always fall back to transfer all data with found = false. Support for those modes can be added in the future. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-28 09:15:18 -08:00
[0], [ignore], [ignore])
on_exit 'kill `cat ovsdb-client.pid`'
for txn in m4_foreach([txn], [[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 10, "name": "ten"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 11, "name": "eleven"}}]]]], ['txn' ]); do
AT_CHECK([ovsdb-client transact unix:socket "$txn"], [0],
[ignore], [ignore], [kill `cat server-pid client-pid`])
done
AT_CHECK([ovsdb-client transact unix:socket '[["ordinals"]]'], [0],
[ignore], [ignore])
OVSDB_SERVER_SHUTDOWN
ovsdb-monitor: Support monitor_cond_since. Support the new monitor method monitor_cond_since so that a client can request monitoring start from a specific point instead of always from beginning. This will reduce the cost at scenarios when server is restarted/failed-over but client still has all existing data. In these scenarios only new changes (and in most cases no change) needed to be transfered to client. When ovsdb-server restarted, history transactions are read from disk file; when ovsdb-server failed over, history transactions exists already in the memory of the new server. There are situations that the requested transaction may not be found. For example, a transaction that is too old and has been discarded from the maintained history list in memory, or the transactions on disk has been compacted during ovsdb compaction. In those situations the server fall backs to transfer all data start from begining. For more details of the protocol change, see Documentation/ref/ovsdb-server.7.rst. This change includes both server side and ovsdb-client side changes with the new protocol. IDLs using this capability will be added in future patches. Now the feature takes effect only for cluster mode of ovsdb-server, because cluster mode is the only mode that supports unique transcation uuid today. For other modes, the monitor_cond_since always fall back to transfer all data with found = false. Support for those modes can be added in the future. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-28 09:15:18 -08:00
OVS_WAIT_UNTIL([test ! -e ovsdb-server.pid && test ! -e ovsdb-client.pid])
AT_CHECK([$PYTHON3 $srcdir/ovsdb-monitor-sort.py < output | uuidfilt], [0],
ovsdb-monitor: Support monitor_cond_since. Support the new monitor method monitor_cond_since so that a client can request monitoring start from a specific point instead of always from beginning. This will reduce the cost at scenarios when server is restarted/failed-over but client still has all existing data. In these scenarios only new changes (and in most cases no change) needed to be transfered to client. When ovsdb-server restarted, history transactions are read from disk file; when ovsdb-server failed over, history transactions exists already in the memory of the new server. There are situations that the requested transaction may not be found. For example, a transaction that is too old and has been discarded from the maintained history list in memory, or the transactions on disk has been compacted during ovsdb compaction. In those situations the server fall backs to transfer all data start from begining. For more details of the protocol change, see Documentation/ref/ovsdb-server.7.rst. This change includes both server side and ovsdb-client side changes with the new protocol. IDLs using this capability will be added in future patches. Now the feature takes effect only for cluster mode of ovsdb-server, because cluster mode is the only mode that supports unique transcation uuid today. For other modes, the monitor_cond_since always fall back to transfer all data with found = false. Support for those modes can be added in the future. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-28 09:15:18 -08:00
[[found: false, last_id: <0>
row,action,name,number,_version
<1>,initial,"""one""",1,"[""uuid"",""<2>""]"
last_id: <3>
row,action,name,number,_version
<4>,insert,"""ten""",10,"[""uuid"",""<5>""]"
]], [ignore])
AT_CLEANUP
# Test monitor-cond-since in ovsdb server restart scenario.
# ovsdb-client should receive only new changes after the
# specific transaction id.
AT_SETUP([monitor-cond-since db restart])
AT_KEYWORDS([ovsdb server monitor monitor-cond-since positive])
ordinal_schema > schema
AT_CHECK([ovsdb-tool create-cluster db schema unix:db.raft], [0], [stdout], [ignore])
AT_CAPTURE_FILE([ovsdb-server.log])
AT_CHECK([ovsdb-server --detach --no-chdir --pidfile --remote=punix:socket --log-file db], [0], [ignore], [ignore])
ovsdb-monitor: Support monitor_cond_since. Support the new monitor method monitor_cond_since so that a client can request monitoring start from a specific point instead of always from beginning. This will reduce the cost at scenarios when server is restarted/failed-over but client still has all existing data. In these scenarios only new changes (and in most cases no change) needed to be transfered to client. When ovsdb-server restarted, history transactions are read from disk file; when ovsdb-server failed over, history transactions exists already in the memory of the new server. There are situations that the requested transaction may not be found. For example, a transaction that is too old and has been discarded from the maintained history list in memory, or the transactions on disk has been compacted during ovsdb compaction. In those situations the server fall backs to transfer all data start from begining. For more details of the protocol change, see Documentation/ref/ovsdb-server.7.rst. This change includes both server side and ovsdb-client side changes with the new protocol. IDLs using this capability will be added in future patches. Now the feature takes effect only for cluster mode of ovsdb-server, because cluster mode is the only mode that supports unique transcation uuid today. For other modes, the monitor_cond_since always fall back to transfer all data with found = false. Support for those modes can be added in the future. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-28 09:15:18 -08:00
on_exit 'kill `cat ovsdb-server.pid`'
for txn in m4_foreach([txn], [[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 0, "name": "zero"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 1, "name": "one"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 2, "name": "two"}}]]]], ['txn' ]); do
AT_CHECK([ovsdb-client transact unix:socket "$txn"], [0], [ignore], [ignore])
done
AT_CHECK([ovsdb-client -vjsonrpc --pidfile --detach --no-chdir -d json monitor-cond-since --format=csv unix:socket ordinals '[[["name","==","one"],["name","==","ten"]]]' ordinals > output 2> ovsdb-client.stderr],
ovsdb-monitor: Support monitor_cond_since. Support the new monitor method monitor_cond_since so that a client can request monitoring start from a specific point instead of always from beginning. This will reduce the cost at scenarios when server is restarted/failed-over but client still has all existing data. In these scenarios only new changes (and in most cases no change) needed to be transfered to client. When ovsdb-server restarted, history transactions are read from disk file; when ovsdb-server failed over, history transactions exists already in the memory of the new server. There are situations that the requested transaction may not be found. For example, a transaction that is too old and has been discarded from the maintained history list in memory, or the transactions on disk has been compacted during ovsdb compaction. In those situations the server fall backs to transfer all data start from begining. For more details of the protocol change, see Documentation/ref/ovsdb-server.7.rst. This change includes both server side and ovsdb-client side changes with the new protocol. IDLs using this capability will be added in future patches. Now the feature takes effect only for cluster mode of ovsdb-server, because cluster mode is the only mode that supports unique transcation uuid today. For other modes, the monitor_cond_since always fall back to transfer all data with found = false. Support for those modes can be added in the future. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-28 09:15:18 -08:00
[0], [ignore], [ignore])
on_exit 'kill `cat ovsdb-client.pid`'
OVS_WAIT_UNTIL([grep last_id output])
OVSDB_SERVER_SHUTDOWN
ovsdb-monitor: Support monitor_cond_since. Support the new monitor method monitor_cond_since so that a client can request monitoring start from a specific point instead of always from beginning. This will reduce the cost at scenarios when server is restarted/failed-over but client still has all existing data. In these scenarios only new changes (and in most cases no change) needed to be transfered to client. When ovsdb-server restarted, history transactions are read from disk file; when ovsdb-server failed over, history transactions exists already in the memory of the new server. There are situations that the requested transaction may not be found. For example, a transaction that is too old and has been discarded from the maintained history list in memory, or the transactions on disk has been compacted during ovsdb compaction. In those situations the server fall backs to transfer all data start from begining. For more details of the protocol change, see Documentation/ref/ovsdb-server.7.rst. This change includes both server side and ovsdb-client side changes with the new protocol. IDLs using this capability will be added in future patches. Now the feature takes effect only for cluster mode of ovsdb-server, because cluster mode is the only mode that supports unique transcation uuid today. For other modes, the monitor_cond_since always fall back to transfer all data with found = false. Support for those modes can be added in the future. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-28 09:15:18 -08:00
OVS_WAIT_UNTIL([test ! -e ovsdb-server.pid && test ! -e ovsdb-client.pid])
# Remember the last_id, which will be used for monitor-cond-since later.
last_id=`grep last_id output | awk '{print $4}'`
AT_CHECK([ovsdb-server --detach --no-chdir --pidfile --remote=punix:socket --log-file db], [0], [ignore], [ignore])
ovsdb-monitor: Support monitor_cond_since. Support the new monitor method monitor_cond_since so that a client can request monitoring start from a specific point instead of always from beginning. This will reduce the cost at scenarios when server is restarted/failed-over but client still has all existing data. In these scenarios only new changes (and in most cases no change) needed to be transfered to client. When ovsdb-server restarted, history transactions are read from disk file; when ovsdb-server failed over, history transactions exists already in the memory of the new server. There are situations that the requested transaction may not be found. For example, a transaction that is too old and has been discarded from the maintained history list in memory, or the transactions on disk has been compacted during ovsdb compaction. In those situations the server fall backs to transfer all data start from begining. For more details of the protocol change, see Documentation/ref/ovsdb-server.7.rst. This change includes both server side and ovsdb-client side changes with the new protocol. IDLs using this capability will be added in future patches. Now the feature takes effect only for cluster mode of ovsdb-server, because cluster mode is the only mode that supports unique transcation uuid today. For other modes, the monitor_cond_since always fall back to transfer all data with found = false. Support for those modes can be added in the future. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-28 09:15:18 -08:00
# Some new changes made to db after restarting the server.
for txn in m4_foreach([txn], [[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 10, "name": "ten"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 11, "name": "eleven"}}]]]], ['txn' ]); do
AT_CHECK([ovsdb-client transact unix:socket "$txn"], [0],
[ignore], [ignore], [kill `cat server-pid client-pid`])
done
# Use last_id to monitor and get only the new changes.
AT_CHECK([ovsdb-client -vjsonrpc --pidfile --detach --no-chdir -d json monitor-cond-since --format=csv unix:socket ordinals $last_id '[[["name","==","one"],["name","==","ten"]]]' ordinals > output 2> ovsdb-client.stderr],
ovsdb-monitor: Support monitor_cond_since. Support the new monitor method monitor_cond_since so that a client can request monitoring start from a specific point instead of always from beginning. This will reduce the cost at scenarios when server is restarted/failed-over but client still has all existing data. In these scenarios only new changes (and in most cases no change) needed to be transfered to client. When ovsdb-server restarted, history transactions are read from disk file; when ovsdb-server failed over, history transactions exists already in the memory of the new server. There are situations that the requested transaction may not be found. For example, a transaction that is too old and has been discarded from the maintained history list in memory, or the transactions on disk has been compacted during ovsdb compaction. In those situations the server fall backs to transfer all data start from begining. For more details of the protocol change, see Documentation/ref/ovsdb-server.7.rst. This change includes both server side and ovsdb-client side changes with the new protocol. IDLs using this capability will be added in future patches. Now the feature takes effect only for cluster mode of ovsdb-server, because cluster mode is the only mode that supports unique transcation uuid today. For other modes, the monitor_cond_since always fall back to transfer all data with found = false. Support for those modes can be added in the future. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-28 09:15:18 -08:00
[0], [ignore], [ignore])
AT_CHECK([ovsdb-client transact unix:socket '[["ordinals"]]'], [0],
[ignore], [ignore])
OVSDB_SERVER_SHUTDOWN
ovsdb-monitor: Support monitor_cond_since. Support the new monitor method monitor_cond_since so that a client can request monitoring start from a specific point instead of always from beginning. This will reduce the cost at scenarios when server is restarted/failed-over but client still has all existing data. In these scenarios only new changes (and in most cases no change) needed to be transfered to client. When ovsdb-server restarted, history transactions are read from disk file; when ovsdb-server failed over, history transactions exists already in the memory of the new server. There are situations that the requested transaction may not be found. For example, a transaction that is too old and has been discarded from the maintained history list in memory, or the transactions on disk has been compacted during ovsdb compaction. In those situations the server fall backs to transfer all data start from begining. For more details of the protocol change, see Documentation/ref/ovsdb-server.7.rst. This change includes both server side and ovsdb-client side changes with the new protocol. IDLs using this capability will be added in future patches. Now the feature takes effect only for cluster mode of ovsdb-server, because cluster mode is the only mode that supports unique transcation uuid today. For other modes, the monitor_cond_since always fall back to transfer all data with found = false. Support for those modes can be added in the future. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-28 09:15:18 -08:00
OVS_WAIT_UNTIL([test ! -e ovsdb-server.pid && test ! -e ovsdb-client.pid])
AT_CHECK([$PYTHON3 $srcdir/ovsdb-monitor-sort.py < output | uuidfilt], [0],
ovsdb-monitor: Support monitor_cond_since. Support the new monitor method monitor_cond_since so that a client can request monitoring start from a specific point instead of always from beginning. This will reduce the cost at scenarios when server is restarted/failed-over but client still has all existing data. In these scenarios only new changes (and in most cases no change) needed to be transfered to client. When ovsdb-server restarted, history transactions are read from disk file; when ovsdb-server failed over, history transactions exists already in the memory of the new server. There are situations that the requested transaction may not be found. For example, a transaction that is too old and has been discarded from the maintained history list in memory, or the transactions on disk has been compacted during ovsdb compaction. In those situations the server fall backs to transfer all data start from begining. For more details of the protocol change, see Documentation/ref/ovsdb-server.7.rst. This change includes both server side and ovsdb-client side changes with the new protocol. IDLs using this capability will be added in future patches. Now the feature takes effect only for cluster mode of ovsdb-server, because cluster mode is the only mode that supports unique transcation uuid today. For other modes, the monitor_cond_since always fall back to transfer all data with found = false. Support for those modes can be added in the future. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-28 09:15:18 -08:00
[[found: true, last_id: <0>
row,action,name,number,_version
<1>,insert,"""ten""",10,"[""uuid"",""<2>""]"
]], [ignore])
AT_CLEANUP
# Test monitor-cond-since with last_id found in server
# but there is no new change after that transaction.
AT_SETUP([monitor-cond-since found but no new rows])
AT_KEYWORDS([ovsdb server monitor monitor-cond-since positive])
ordinal_schema > schema
AT_CHECK([ovsdb-tool create-cluster db schema unix:db.raft], [0], [stdout], [ignore])
AT_CAPTURE_FILE([ovsdb-server.log])
AT_CHECK([ovsdb-server --detach --no-chdir --pidfile --remote=punix:socket --log-file db], [0], [ignore], [ignore])
ovsdb-monitor: Support monitor_cond_since. Support the new monitor method monitor_cond_since so that a client can request monitoring start from a specific point instead of always from beginning. This will reduce the cost at scenarios when server is restarted/failed-over but client still has all existing data. In these scenarios only new changes (and in most cases no change) needed to be transfered to client. When ovsdb-server restarted, history transactions are read from disk file; when ovsdb-server failed over, history transactions exists already in the memory of the new server. There are situations that the requested transaction may not be found. For example, a transaction that is too old and has been discarded from the maintained history list in memory, or the transactions on disk has been compacted during ovsdb compaction. In those situations the server fall backs to transfer all data start from begining. For more details of the protocol change, see Documentation/ref/ovsdb-server.7.rst. This change includes both server side and ovsdb-client side changes with the new protocol. IDLs using this capability will be added in future patches. Now the feature takes effect only for cluster mode of ovsdb-server, because cluster mode is the only mode that supports unique transcation uuid today. For other modes, the monitor_cond_since always fall back to transfer all data with found = false. Support for those modes can be added in the future. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-28 09:15:18 -08:00
on_exit 'kill `cat ovsdb-server.pid`'
for txn in m4_foreach([txn], [[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 0, "name": "zero"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 1, "name": "one"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 2, "name": "two"}}]]]], ['txn' ]); do
AT_CHECK([ovsdb-client transact unix:socket "$txn"], [0], [ignore], [ignore])
done
AT_CHECK([ovsdb-client -vjsonrpc --pidfile --detach --no-chdir -d json monitor-cond-since --format=csv unix:socket ordinals '[[["name","==","one"],["name","==","ten"]]]' ordinals > output 2> ovsdb-client.stderr],
ovsdb-monitor: Support monitor_cond_since. Support the new monitor method monitor_cond_since so that a client can request monitoring start from a specific point instead of always from beginning. This will reduce the cost at scenarios when server is restarted/failed-over but client still has all existing data. In these scenarios only new changes (and in most cases no change) needed to be transfered to client. When ovsdb-server restarted, history transactions are read from disk file; when ovsdb-server failed over, history transactions exists already in the memory of the new server. There are situations that the requested transaction may not be found. For example, a transaction that is too old and has been discarded from the maintained history list in memory, or the transactions on disk has been compacted during ovsdb compaction. In those situations the server fall backs to transfer all data start from begining. For more details of the protocol change, see Documentation/ref/ovsdb-server.7.rst. This change includes both server side and ovsdb-client side changes with the new protocol. IDLs using this capability will be added in future patches. Now the feature takes effect only for cluster mode of ovsdb-server, because cluster mode is the only mode that supports unique transcation uuid today. For other modes, the monitor_cond_since always fall back to transfer all data with found = false. Support for those modes can be added in the future. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-28 09:15:18 -08:00
[0], [ignore], [ignore])
on_exit 'kill `cat ovsdb-client.pid`'
OVS_WAIT_UNTIL([grep last_id output])
kill `cat ovsdb-client.pid`
OVS_WAIT_UNTIL([test ! -e ovsdb-client.pid])
last_id=`grep last_id output | awk '{print $4}'`
AT_CHECK([ovsdb-client -vjsonrpc --pidfile --detach --no-chdir -d json monitor-cond-since --format=csv unix:socket ordinals $last_id '[[["name","==","one"],["name","==","ten"]]]' ordinals > output 2> ovsdb-client.stderr],
ovsdb-monitor: Support monitor_cond_since. Support the new monitor method monitor_cond_since so that a client can request monitoring start from a specific point instead of always from beginning. This will reduce the cost at scenarios when server is restarted/failed-over but client still has all existing data. In these scenarios only new changes (and in most cases no change) needed to be transfered to client. When ovsdb-server restarted, history transactions are read from disk file; when ovsdb-server failed over, history transactions exists already in the memory of the new server. There are situations that the requested transaction may not be found. For example, a transaction that is too old and has been discarded from the maintained history list in memory, or the transactions on disk has been compacted during ovsdb compaction. In those situations the server fall backs to transfer all data start from begining. For more details of the protocol change, see Documentation/ref/ovsdb-server.7.rst. This change includes both server side and ovsdb-client side changes with the new protocol. IDLs using this capability will be added in future patches. Now the feature takes effect only for cluster mode of ovsdb-server, because cluster mode is the only mode that supports unique transcation uuid today. For other modes, the monitor_cond_since always fall back to transfer all data with found = false. Support for those modes can be added in the future. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-28 09:15:18 -08:00
[0], [ignore], [ignore])
AT_CHECK([ovsdb-client transact unix:socket '[["ordinals"]]'], [0],
[ignore], [ignore])
OVSDB_SERVER_SHUTDOWN
ovsdb-monitor: Support monitor_cond_since. Support the new monitor method monitor_cond_since so that a client can request monitoring start from a specific point instead of always from beginning. This will reduce the cost at scenarios when server is restarted/failed-over but client still has all existing data. In these scenarios only new changes (and in most cases no change) needed to be transfered to client. When ovsdb-server restarted, history transactions are read from disk file; when ovsdb-server failed over, history transactions exists already in the memory of the new server. There are situations that the requested transaction may not be found. For example, a transaction that is too old and has been discarded from the maintained history list in memory, or the transactions on disk has been compacted during ovsdb compaction. In those situations the server fall backs to transfer all data start from begining. For more details of the protocol change, see Documentation/ref/ovsdb-server.7.rst. This change includes both server side and ovsdb-client side changes with the new protocol. IDLs using this capability will be added in future patches. Now the feature takes effect only for cluster mode of ovsdb-server, because cluster mode is the only mode that supports unique transcation uuid today. For other modes, the monitor_cond_since always fall back to transfer all data with found = false. Support for those modes can be added in the future. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-28 09:15:18 -08:00
OVS_WAIT_UNTIL([test ! -e ovsdb-server.pid && test ! -e ovsdb-client.pid])
AT_CHECK([$PYTHON3 $srcdir/ovsdb-monitor-sort.py < output | uuidfilt], [0],
ovsdb-monitor: Support monitor_cond_since. Support the new monitor method monitor_cond_since so that a client can request monitoring start from a specific point instead of always from beginning. This will reduce the cost at scenarios when server is restarted/failed-over but client still has all existing data. In these scenarios only new changes (and in most cases no change) needed to be transfered to client. When ovsdb-server restarted, history transactions are read from disk file; when ovsdb-server failed over, history transactions exists already in the memory of the new server. There are situations that the requested transaction may not be found. For example, a transaction that is too old and has been discarded from the maintained history list in memory, or the transactions on disk has been compacted during ovsdb compaction. In those situations the server fall backs to transfer all data start from begining. For more details of the protocol change, see Documentation/ref/ovsdb-server.7.rst. This change includes both server side and ovsdb-client side changes with the new protocol. IDLs using this capability will be added in future patches. Now the feature takes effect only for cluster mode of ovsdb-server, because cluster mode is the only mode that supports unique transcation uuid today. For other modes, the monitor_cond_since always fall back to transfer all data with found = false. Support for those modes can be added in the future. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-28 09:15:18 -08:00
[[found: true, last_id: <0>
]], [ignore])
AT_CLEANUP
# Test monitor-cond-since against empty DB
AT_SETUP([monitor-cond-since empty db])
AT_KEYWORDS([ovsdb server monitor monitor-cond-since positive])
ordinal_schema > schema
AT_CHECK([ovsdb-tool create-cluster db schema unix:db.raft], [0], [stdout], [ignore])
AT_CAPTURE_FILE([ovsdb-server.log])
AT_CHECK([ovsdb-server --detach --no-chdir --pidfile --remote=punix:socket --log-file db], [0], [ignore], [ignore])
ovsdb-monitor: Support monitor_cond_since. Support the new monitor method monitor_cond_since so that a client can request monitoring start from a specific point instead of always from beginning. This will reduce the cost at scenarios when server is restarted/failed-over but client still has all existing data. In these scenarios only new changes (and in most cases no change) needed to be transfered to client. When ovsdb-server restarted, history transactions are read from disk file; when ovsdb-server failed over, history transactions exists already in the memory of the new server. There are situations that the requested transaction may not be found. For example, a transaction that is too old and has been discarded from the maintained history list in memory, or the transactions on disk has been compacted during ovsdb compaction. In those situations the server fall backs to transfer all data start from begining. For more details of the protocol change, see Documentation/ref/ovsdb-server.7.rst. This change includes both server side and ovsdb-client side changes with the new protocol. IDLs using this capability will be added in future patches. Now the feature takes effect only for cluster mode of ovsdb-server, because cluster mode is the only mode that supports unique transcation uuid today. For other modes, the monitor_cond_since always fall back to transfer all data with found = false. Support for those modes can be added in the future. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-28 09:15:18 -08:00
on_exit 'kill `cat ovsdb-server.pid`'
AT_CHECK([ovsdb-client -vjsonrpc --pidfile --detach --no-chdir -d json monitor-cond-since --format=csv unix:socket ordinals '[[["name","==","one"],["name","==","ten"]]]' ordinals > output 2> ovsdb-client.stderr],
ovsdb-monitor: Support monitor_cond_since. Support the new monitor method monitor_cond_since so that a client can request monitoring start from a specific point instead of always from beginning. This will reduce the cost at scenarios when server is restarted/failed-over but client still has all existing data. In these scenarios only new changes (and in most cases no change) needed to be transfered to client. When ovsdb-server restarted, history transactions are read from disk file; when ovsdb-server failed over, history transactions exists already in the memory of the new server. There are situations that the requested transaction may not be found. For example, a transaction that is too old and has been discarded from the maintained history list in memory, or the transactions on disk has been compacted during ovsdb compaction. In those situations the server fall backs to transfer all data start from begining. For more details of the protocol change, see Documentation/ref/ovsdb-server.7.rst. This change includes both server side and ovsdb-client side changes with the new protocol. IDLs using this capability will be added in future patches. Now the feature takes effect only for cluster mode of ovsdb-server, because cluster mode is the only mode that supports unique transcation uuid today. For other modes, the monitor_cond_since always fall back to transfer all data with found = false. Support for those modes can be added in the future. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-28 09:15:18 -08:00
[0], [ignore], [ignore])
on_exit 'kill `cat ovsdb-client.pid`'
OVS_WAIT_UNTIL([grep last_id output])
AT_CHECK([ovsdb-client transact unix:socket '[["ordinals"]]'], [0],
[ignore], [ignore])
OVSDB_SERVER_SHUTDOWN
ovsdb-monitor: Support monitor_cond_since. Support the new monitor method monitor_cond_since so that a client can request monitoring start from a specific point instead of always from beginning. This will reduce the cost at scenarios when server is restarted/failed-over but client still has all existing data. In these scenarios only new changes (and in most cases no change) needed to be transfered to client. When ovsdb-server restarted, history transactions are read from disk file; when ovsdb-server failed over, history transactions exists already in the memory of the new server. There are situations that the requested transaction may not be found. For example, a transaction that is too old and has been discarded from the maintained history list in memory, or the transactions on disk has been compacted during ovsdb compaction. In those situations the server fall backs to transfer all data start from begining. For more details of the protocol change, see Documentation/ref/ovsdb-server.7.rst. This change includes both server side and ovsdb-client side changes with the new protocol. IDLs using this capability will be added in future patches. Now the feature takes effect only for cluster mode of ovsdb-server, because cluster mode is the only mode that supports unique transcation uuid today. For other modes, the monitor_cond_since always fall back to transfer all data with found = false. Support for those modes can be added in the future. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-28 09:15:18 -08:00
OVS_WAIT_UNTIL([test ! -e ovsdb-server.pid && test ! -e ovsdb-client.pid])
AT_CHECK([$PYTHON3 $srcdir/ovsdb-monitor-sort.py < output | uuidfilt], [0],
ovsdb-monitor: Support monitor_cond_since. Support the new monitor method monitor_cond_since so that a client can request monitoring start from a specific point instead of always from beginning. This will reduce the cost at scenarios when server is restarted/failed-over but client still has all existing data. In these scenarios only new changes (and in most cases no change) needed to be transfered to client. When ovsdb-server restarted, history transactions are read from disk file; when ovsdb-server failed over, history transactions exists already in the memory of the new server. There are situations that the requested transaction may not be found. For example, a transaction that is too old and has been discarded from the maintained history list in memory, or the transactions on disk has been compacted during ovsdb compaction. In those situations the server fall backs to transfer all data start from begining. For more details of the protocol change, see Documentation/ref/ovsdb-server.7.rst. This change includes both server side and ovsdb-client side changes with the new protocol. IDLs using this capability will be added in future patches. Now the feature takes effect only for cluster mode of ovsdb-server, because cluster mode is the only mode that supports unique transcation uuid today. For other modes, the monitor_cond_since always fall back to transfer all data with found = false. Support for those modes can be added in the future. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-28 09:15:18 -08:00
[[found: false, last_id: <0>
]], [ignore])
AT_CLEANUP
# Test monitor-cond-since with cond-change followed.
AT_SETUP([monitor-cond-since condition change])
AT_KEYWORDS([ovsdb server monitor monitor-cond-since positive])
ordinal_schema > schema
AT_CHECK([ovsdb-tool create-cluster db schema unix:db.raft], [0], [stdout], [ignore])
AT_CAPTURE_FILE([ovsdb-server.log])
AT_CHECK([ovsdb-server --detach --no-chdir --pidfile --remote=punix:socket --log-file -vjsonrpc:file:dbg db], [0], [ignore], [ignore])
ovsdb-monitor: Support monitor_cond_since. Support the new monitor method monitor_cond_since so that a client can request monitoring start from a specific point instead of always from beginning. This will reduce the cost at scenarios when server is restarted/failed-over but client still has all existing data. In these scenarios only new changes (and in most cases no change) needed to be transfered to client. When ovsdb-server restarted, history transactions are read from disk file; when ovsdb-server failed over, history transactions exists already in the memory of the new server. There are situations that the requested transaction may not be found. For example, a transaction that is too old and has been discarded from the maintained history list in memory, or the transactions on disk has been compacted during ovsdb compaction. In those situations the server fall backs to transfer all data start from begining. For more details of the protocol change, see Documentation/ref/ovsdb-server.7.rst. This change includes both server side and ovsdb-client side changes with the new protocol. IDLs using this capability will be added in future patches. Now the feature takes effect only for cluster mode of ovsdb-server, because cluster mode is the only mode that supports unique transcation uuid today. For other modes, the monitor_cond_since always fall back to transfer all data with found = false. Support for those modes can be added in the future. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-28 09:15:18 -08:00
on_exit 'kill `cat ovsdb-server.pid`'
for txn in m4_foreach([txn], [[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 0, "name": "zero"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 1, "name": "one"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 2, "name": "two"}}]]]], ['txn' ]); do
AT_CHECK([ovsdb-client transact unix:socket "$txn"], [0], [ignore], [ignore])
done
AT_CAPTURE_FILE([ovsdb-client.log])
AT_CHECK([ovsdb-client -vjsonrpc --log-file --pidfile --detach --no-chdir -d json monitor-cond-since --format=csv unix:socket ordinals '[[]]' ordinals > output 2> ovsdb-client.stderr])
ovsdb-monitor: Support monitor_cond_since. Support the new monitor method monitor_cond_since so that a client can request monitoring start from a specific point instead of always from beginning. This will reduce the cost at scenarios when server is restarted/failed-over but client still has all existing data. In these scenarios only new changes (and in most cases no change) needed to be transfered to client. When ovsdb-server restarted, history transactions are read from disk file; when ovsdb-server failed over, history transactions exists already in the memory of the new server. There are situations that the requested transaction may not be found. For example, a transaction that is too old and has been discarded from the maintained history list in memory, or the transactions on disk has been compacted during ovsdb compaction. In those situations the server fall backs to transfer all data start from begining. For more details of the protocol change, see Documentation/ref/ovsdb-server.7.rst. This change includes both server side and ovsdb-client side changes with the new protocol. IDLs using this capability will be added in future patches. Now the feature takes effect only for cluster mode of ovsdb-server, because cluster mode is the only mode that supports unique transcation uuid today. For other modes, the monitor_cond_since always fall back to transfer all data with found = false. Support for those modes can be added in the future. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-28 09:15:18 -08:00
on_exit 'kill `cat ovsdb-client.pid`'
for cond in m4_foreach([cond],
[[[[["name","==","one"],["name","==","two"]]]],
[[[["name","==","one"]]]],
[[[false]]],
[[[true]]]], ['cond' ]); do
AT_CHECK([ovs-appctl -t ovsdb-client ovsdb-client/cond_change ordinals "$cond"], [0], [ignore], [ignore])
done
AT_CHECK([ovsdb-client transact unix:socket '[["ordinals"]]'], [0],
[ignore], [ignore])
OVSDB_SERVER_SHUTDOWN
ovsdb-monitor: Support monitor_cond_since. Support the new monitor method monitor_cond_since so that a client can request monitoring start from a specific point instead of always from beginning. This will reduce the cost at scenarios when server is restarted/failed-over but client still has all existing data. In these scenarios only new changes (and in most cases no change) needed to be transfered to client. When ovsdb-server restarted, history transactions are read from disk file; when ovsdb-server failed over, history transactions exists already in the memory of the new server. There are situations that the requested transaction may not be found. For example, a transaction that is too old and has been discarded from the maintained history list in memory, or the transactions on disk has been compacted during ovsdb compaction. In those situations the server fall backs to transfer all data start from begining. For more details of the protocol change, see Documentation/ref/ovsdb-server.7.rst. This change includes both server side and ovsdb-client side changes with the new protocol. IDLs using this capability will be added in future patches. Now the feature takes effect only for cluster mode of ovsdb-server, because cluster mode is the only mode that supports unique transcation uuid today. For other modes, the monitor_cond_since always fall back to transfer all data with found = false. Support for those modes can be added in the future. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-28 09:15:18 -08:00
OVS_WAIT_UNTIL([test ! -e ovsdb-server.pid && test ! -e ovsdb-client.pid])
AT_CHECK([$PYTHON3 $srcdir/ovsdb-monitor-sort.py < output | uuidfilt], [0],
ovsdb-monitor: Support monitor_cond_since. Support the new monitor method monitor_cond_since so that a client can request monitoring start from a specific point instead of always from beginning. This will reduce the cost at scenarios when server is restarted/failed-over but client still has all existing data. In these scenarios only new changes (and in most cases no change) needed to be transfered to client. When ovsdb-server restarted, history transactions are read from disk file; when ovsdb-server failed over, history transactions exists already in the memory of the new server. There are situations that the requested transaction may not be found. For example, a transaction that is too old and has been discarded from the maintained history list in memory, or the transactions on disk has been compacted during ovsdb compaction. In those situations the server fall backs to transfer all data start from begining. For more details of the protocol change, see Documentation/ref/ovsdb-server.7.rst. This change includes both server side and ovsdb-client side changes with the new protocol. IDLs using this capability will be added in future patches. Now the feature takes effect only for cluster mode of ovsdb-server, because cluster mode is the only mode that supports unique transcation uuid today. For other modes, the monitor_cond_since always fall back to transfer all data with found = false. Support for those modes can be added in the future. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-28 09:15:18 -08:00
[[found: false, last_id: <0>
row,action,name,number,_version
<1>,initial,"""one""",1,"[""uuid"",""<2>""]"
<3>,initial,"""two""",2,"[""uuid"",""<4>""]"
<5>,initial,"""zero""",,"[""uuid"",""<6>""]"
last_id: <0>
row,action,name,number,_version
<5>,delete,,,
last_id: <0>
row,action,name,number,_version
<3>,delete,,,
last_id: <0>
row,action,name,number,_version
<1>,delete,,,
last_id: <0>
row,action,name,number,_version
<1>,insert,"""one""",1,"[""uuid"",""<2>""]"
<3>,insert,"""two""",2,"[""uuid"",""<4>""]"
<5>,insert,"""zero""",,"[""uuid"",""<6>""]"
]], [ignore])
AT_CLEANUP
# Test monitor-cond-since with non-cluster mode server
AT_SETUP([monitor-cond-since non-cluster])
AT_KEYWORDS([ovsdb server monitor monitor-cond-since positive])
ordinal_schema > schema
AT_CHECK([ovsdb-tool create db schema], [0], [stdout], [ignore])
AT_CAPTURE_FILE([ovsdb-server.log])
AT_CHECK([ovsdb-server --detach --no-chdir --pidfile --remote=punix:socket --log-file db], [0], [ignore], [ignore])
ovsdb-monitor: Support monitor_cond_since. Support the new monitor method monitor_cond_since so that a client can request monitoring start from a specific point instead of always from beginning. This will reduce the cost at scenarios when server is restarted/failed-over but client still has all existing data. In these scenarios only new changes (and in most cases no change) needed to be transfered to client. When ovsdb-server restarted, history transactions are read from disk file; when ovsdb-server failed over, history transactions exists already in the memory of the new server. There are situations that the requested transaction may not be found. For example, a transaction that is too old and has been discarded from the maintained history list in memory, or the transactions on disk has been compacted during ovsdb compaction. In those situations the server fall backs to transfer all data start from begining. For more details of the protocol change, see Documentation/ref/ovsdb-server.7.rst. This change includes both server side and ovsdb-client side changes with the new protocol. IDLs using this capability will be added in future patches. Now the feature takes effect only for cluster mode of ovsdb-server, because cluster mode is the only mode that supports unique transcation uuid today. For other modes, the monitor_cond_since always fall back to transfer all data with found = false. Support for those modes can be added in the future. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-28 09:15:18 -08:00
on_exit 'kill `cat ovsdb-server.pid`'
for txn in m4_foreach([txn], [[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 0, "name": "zero"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 1, "name": "one"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 2, "name": "two"}}]]]], ['txn' ]); do
AT_CHECK([ovsdb-client transact unix:socket "$txn"], [0], [ignore], [ignore])
done
AT_CHECK([ovsdb-client -vjsonrpc --pidfile --detach --no-chdir -d json monitor-cond-since --format=csv unix:socket ordinals '[[["name","==","one"],["name","==","ten"]]]' ordinals > output 2> ovsdb-client.stderr],
ovsdb-monitor: Support monitor_cond_since. Support the new monitor method monitor_cond_since so that a client can request monitoring start from a specific point instead of always from beginning. This will reduce the cost at scenarios when server is restarted/failed-over but client still has all existing data. In these scenarios only new changes (and in most cases no change) needed to be transfered to client. When ovsdb-server restarted, history transactions are read from disk file; when ovsdb-server failed over, history transactions exists already in the memory of the new server. There are situations that the requested transaction may not be found. For example, a transaction that is too old and has been discarded from the maintained history list in memory, or the transactions on disk has been compacted during ovsdb compaction. In those situations the server fall backs to transfer all data start from begining. For more details of the protocol change, see Documentation/ref/ovsdb-server.7.rst. This change includes both server side and ovsdb-client side changes with the new protocol. IDLs using this capability will be added in future patches. Now the feature takes effect only for cluster mode of ovsdb-server, because cluster mode is the only mode that supports unique transcation uuid today. For other modes, the monitor_cond_since always fall back to transfer all data with found = false. Support for those modes can be added in the future. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-28 09:15:18 -08:00
[0], [ignore], [ignore])
on_exit 'kill `cat ovsdb-client.pid`'
2019-08-19 16:30:35 -07:00
for txn in m4_foreach([txn], [[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 10, "name": "ten"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 11, "name": "eleven"}}]]]], ['txn' ]); do
AT_CHECK([ovsdb-client transact unix:socket "$txn"], [0],
[ignore], [ignore], [kill `cat server-pid client-pid`])
done
AT_CHECK([ovsdb-client transact unix:socket '[["ordinals"]]'], [0],
[ignore], [ignore])
OVSDB_SERVER_SHUTDOWN
2019-08-19 16:30:35 -07:00
OVS_WAIT_UNTIL([test ! -e ovsdb-server.pid && test ! -e ovsdb-client.pid])
# Transaction shouldn't be found, and last_id returned should always
# be the same (all zero uuid)
AT_CHECK([$PYTHON3 $srcdir/ovsdb-monitor-sort.py < output | uuidfilt], [0],
2019-08-19 16:30:35 -07:00
[[found: false, last_id: <0>
row,action,name,number,_version
<1>,initial,"""one""",1,"[""uuid"",""<2>""]"
last_id: <0>
row,action,name,number,_version
<3>,insert,"""ten""",10,"[""uuid"",""<4>""]"
]], [ignore])
AT_CLEANUP
# Test monitor-cond-since with non-cluster mode server with non-zero last_id
AT_SETUP([monitor-cond-since non-cluster non-zero last_id])
AT_KEYWORDS([ovsdb server monitor monitor-cond-since negative])
ordinal_schema > schema
AT_CHECK([ovsdb-tool create db schema], [0], [stdout], [ignore])
AT_CAPTURE_FILE([ovsdb-server.log])
AT_CHECK([ovsdb-server --detach --no-chdir --pidfile --remote=punix:socket --log-file db], [0], [ignore], [ignore])
2019-08-19 16:30:35 -07:00
on_exit 'kill `cat ovsdb-server.pid`'
for txn in m4_foreach([txn], [[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 0, "name": "zero"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 1, "name": "one"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 2, "name": "two"}}]]]], ['txn' ]); do
AT_CHECK([ovsdb-client transact unix:socket "$txn"], [0], [ignore], [ignore])
done
# A non-zero uuid
last_id=11111111-1111-1111-1111-111111111111
AT_CHECK([ovsdb-client -vjsonrpc --pidfile --detach --no-chdir -d json monitor-cond-since --format=csv unix:socket ordinals $last_id '[[["name","==","one"],["name","==","ten"]]]' ordinals > output 2> ovsdb-client.stderr],
2019-08-19 16:30:35 -07:00
[0], [ignore], [ignore])
on_exit 'kill `cat ovsdb-client.pid`'
ovsdb-monitor: Support monitor_cond_since. Support the new monitor method monitor_cond_since so that a client can request monitoring start from a specific point instead of always from beginning. This will reduce the cost at scenarios when server is restarted/failed-over but client still has all existing data. In these scenarios only new changes (and in most cases no change) needed to be transfered to client. When ovsdb-server restarted, history transactions are read from disk file; when ovsdb-server failed over, history transactions exists already in the memory of the new server. There are situations that the requested transaction may not be found. For example, a transaction that is too old and has been discarded from the maintained history list in memory, or the transactions on disk has been compacted during ovsdb compaction. In those situations the server fall backs to transfer all data start from begining. For more details of the protocol change, see Documentation/ref/ovsdb-server.7.rst. This change includes both server side and ovsdb-client side changes with the new protocol. IDLs using this capability will be added in future patches. Now the feature takes effect only for cluster mode of ovsdb-server, because cluster mode is the only mode that supports unique transcation uuid today. For other modes, the monitor_cond_since always fall back to transfer all data with found = false. Support for those modes can be added in the future. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-28 09:15:18 -08:00
for txn in m4_foreach([txn], [[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 10, "name": "ten"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 11, "name": "eleven"}}]]]], ['txn' ]); do
AT_CHECK([ovsdb-client transact unix:socket "$txn"], [0],
[ignore], [ignore], [kill `cat server-pid client-pid`])
done
AT_CHECK([ovsdb-client transact unix:socket '[["ordinals"]]'], [0],
[ignore], [ignore])
OVSDB_SERVER_SHUTDOWN
ovsdb-monitor: Support monitor_cond_since. Support the new monitor method monitor_cond_since so that a client can request monitoring start from a specific point instead of always from beginning. This will reduce the cost at scenarios when server is restarted/failed-over but client still has all existing data. In these scenarios only new changes (and in most cases no change) needed to be transfered to client. When ovsdb-server restarted, history transactions are read from disk file; when ovsdb-server failed over, history transactions exists already in the memory of the new server. There are situations that the requested transaction may not be found. For example, a transaction that is too old and has been discarded from the maintained history list in memory, or the transactions on disk has been compacted during ovsdb compaction. In those situations the server fall backs to transfer all data start from begining. For more details of the protocol change, see Documentation/ref/ovsdb-server.7.rst. This change includes both server side and ovsdb-client side changes with the new protocol. IDLs using this capability will be added in future patches. Now the feature takes effect only for cluster mode of ovsdb-server, because cluster mode is the only mode that supports unique transcation uuid today. For other modes, the monitor_cond_since always fall back to transfer all data with found = false. Support for those modes can be added in the future. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-28 09:15:18 -08:00
OVS_WAIT_UNTIL([test ! -e ovsdb-server.pid && test ! -e ovsdb-client.pid])
# Transaction shouldn't be found, and last_id returned should always
# be the same (all zero uuid)
AT_CHECK([$PYTHON3 $srcdir/ovsdb-monitor-sort.py < output | uuidfilt], [0],
ovsdb-monitor: Support monitor_cond_since. Support the new monitor method monitor_cond_since so that a client can request monitoring start from a specific point instead of always from beginning. This will reduce the cost at scenarios when server is restarted/failed-over but client still has all existing data. In these scenarios only new changes (and in most cases no change) needed to be transfered to client. When ovsdb-server restarted, history transactions are read from disk file; when ovsdb-server failed over, history transactions exists already in the memory of the new server. There are situations that the requested transaction may not be found. For example, a transaction that is too old and has been discarded from the maintained history list in memory, or the transactions on disk has been compacted during ovsdb compaction. In those situations the server fall backs to transfer all data start from begining. For more details of the protocol change, see Documentation/ref/ovsdb-server.7.rst. This change includes both server side and ovsdb-client side changes with the new protocol. IDLs using this capability will be added in future patches. Now the feature takes effect only for cluster mode of ovsdb-server, because cluster mode is the only mode that supports unique transcation uuid today. For other modes, the monitor_cond_since always fall back to transfer all data with found = false. Support for those modes can be added in the future. Signed-off-by: Han Zhou <hzhou8@ebay.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-02-28 09:15:18 -08:00
[[found: false, last_id: <0>
row,action,name,number,_version
<1>,initial,"""one""",1,"[""uuid"",""<2>""]"
last_id: <0>
row,action,name,number,_version
<3>,insert,"""ten""",10,"[""uuid"",""<4>""]"
]], [ignore])
AT_CLEANUP
ovsdb: monitor: Destroy initial change set when new columns added. Initial change set is preserved for as long as the monitor itself. However, if a new client has a condition on a column that is not one of the monitored columns, this column will be added to the monitor via ovsdb_monitor_condition_bind(). This new column, however, doesn't exist in the initial change set. That will cause ovsdb-server to malfunction or crash trying to access non-existent column during condition evaluation: ERROR: AddressSanitizer: heap-buffer-overflow READ of size 4 at 0x606000006780 thread T0 0 ovsdb_clause_evaluate ovsdb/condition.c:328:26 1 ovsdb_condition_match_any_clause ovsdb/condition.c:441:13 2 ovsdb_condition_empty_or_match_any ovsdb/condition.h:84:13 3 ovsdb_monitor_row_update_type_condition ovsdb/monitor.c:892:28 4 ovsdb_monitor_compose_row_update2 ovsdb/monitor.c:1058:12 5 ovsdb_monitor_compose_update ovsdb/monitor.c:1172:24 6 ovsdb_monitor_get_update ovsdb/monitor.c:1276:24 7 ovsdb_jsonrpc_monitor_create ovsdb/jsonrpc-server.c:1505:12 8 ovsdb_jsonrpc_session_got_request ovsdb/jsonrpc-server.c:1030:21 9 ovsdb_jsonrpc_session_run ovsdb/jsonrpc-server.c:572:17 10 ovsdb_jsonrpc_session_run_all ovsdb/jsonrpc-server.c:602:21 11 ovsdb_jsonrpc_server_run ovsdb/jsonrpc-server.c:417:9 12 main_loop ovsdb/ovsdb-server.c:222:9 13 main ovsdb/ovsdb-server.c:500:5 14 __libc_start_call_main 15 __libc_start_main@GLIBC_2.2.5 16 _start (ovsdb/ovsdb-server+0x473034) Located 0 bytes after 64-byte region [0x606000006740,0x606000006780) allocated by thread T0 here: 0 malloc (ovsdb/ovsdb-server+0x50dc82) 1 xmalloc__ lib/util.c:140:15 2 xmalloc lib/util.c:175:12 3 clone_monitor_row_data ovsdb/monitor.c:336:12 4 ovsdb_monitor_changes_update ovsdb/monitor.c:1384:23 5 ovsdb_monitor_get_initial ovsdb/monitor.c:1535:21 6 ovsdb_jsonrpc_monitor_create ovsdb/jsonrpc-server.c:1502:9 7 ovsdb_jsonrpc_session_got_request ovsdb/jsonrpc-server.c:1030:21 8 ovsdb_jsonrpc_session_run ovsdb/jsonrpc-server.c:572:17 9 ovsdb_jsonrpc_session_run_all ovsdb/jsonrpc-server.c:602:21 10 ovsdb_jsonrpc_server_run ovsdb/jsonrpc-server.c:417:9 11 main_loop ovsdb/ovsdb-server.c:222:9 12 main ovsdb/ovsdb-server.c:500:5 13 __libc_start_call_main 14 __libc_start_main@GLIBC_2.2.5 15 _start (ovsdb/ovsdb-server+0x473034) Fix that by destroying the initial change set every time new columns are added to the monitor. This will trigger re-generation of the change set and it will contain all the necessary columns afterwards. Fixes: 07c27226ee96 ("ovsdb: Monitor: Keep and maintain the initial change set.") Reported-by: Han Zhou <hzhou@ovn.org> Acked-by: Han Zhou <hzhou@ovn.org> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2023-06-07 15:08:32 +02:00
AT_SETUP([monitor-cond initial reply with condition on non-monitored column])
AT_KEYWORDS([ovsdb server monitor monitor-cond positive initial non-monitored])
ordinal_schema > schema
AT_CHECK([ovsdb-tool create db schema], [0], [stdout], [ignore])
on_exit 'kill `cat ovsdb-server.pid`'
AT_CAPTURE_FILE([ovsdb-server.log])
AT_CHECK([ovsdb-server --detach --no-chdir --pidfile \
--remote=punix:socket --log-file db], [0], [ignore], [ignore])
dnl Initialize the database content.
for txn in m4_foreach([txn], [[[["ordinals",
{"op": "insert",
"table": "ordinals",
"row": {"number": 0, "name": "zero"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 1, "name": "one"}},
{"op": "insert",
"table": "ordinals",
"row": {"number": 2, "name": "two"}}]]]], ['txn' ]); do
AT_CHECK([ovsdb-client transact unix:socket "$txn"], [0], [ignore], [ignore])
done
dnl Start a first client that monitors only the column 'name'.
on_exit 'kill `cat client-1.pid`'
AT_CAPTURE_FILE([client-1.out])
AT_CHECK([ovsdb-client -vjsonrpc --pidfile=client-1.pid --detach --no-chdir \
-d json monitor-cond --format=csv unix:socket \
ordinals '[[true]]' ordinals ["name"] \
> client-1.out 2> client-1.err], [0], [ignore], [ignore])
dnl Wait for the initial monitor reply.
OVS_WAIT_UNTIL([grep -q 'initial' client-1.out])
dnl Start a second client that monitors the column 'name', but has a condition
dnl on column 'number'.
on_exit 'kill `cat client-2.pid`'
AT_CAPTURE_FILE([client-2.out])
AT_CHECK([ovsdb-client -vjsonrpc --pidfile=client-2.pid --detach --no-chdir \
-d json monitor-cond --format=csv unix:socket \
ordinals '[[["number", "!=", 1]]]' ordinals ["name"] \
> client-2.out 2> client-2.err], [0], [ignore], [ignore])
dnl Wait for the initial monitor reply.
OVS_WAIT_UNTIL([grep -q 'initial' client-2.out])
OVSDB_SERVER_SHUTDOWN
OVS_WAIT_UNTIL([test ! -e ovsdb-server.pid && \
test ! -e client-1.pid && test ! -e client-2.pid])
dnl The first client should have all the names.
AT_CHECK([$PYTHON3 $srcdir/ovsdb-monitor-sort.py < client-1.out | uuidfilt],
[0], [dnl
row,action,name
<0>,initial,"""one"""
<1>,initial,"""two"""
<2>,initial,"""zero"""
])
dnl The second client should not have the name 'one'.
AT_CHECK([$PYTHON3 $srcdir/ovsdb-monitor-sort.py < client-2.out | uuidfilt],
[0], [dnl
row,action,name
<0>,initial,"""two"""
<1>,initial,"""zero"""
])
AT_CLEANUP