IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Replacement for ctdb tool will not support multiple debug levels.
This test could be modified to use the default debug level but that
would make it identical to reloadnodes test #19.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
New function simple_test_other() allows other tool commands to be
tested along with the main command.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
If CTDB_TESTS_VAR isn't cleaned up between runs then this can result
in a lot of accumulated temporary files, so clean up the temporary
files.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
This makes the ctdbd setup explicit and allows multiple calls to
simple_test() in the same test without ugly re-initialisation.
While here drop any unneeded ctdbd initialisation, such as VNNMAP and
IFACES. These have often been needlessly present, cluttering the
tests.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
These tests do not use ctdb tool stub anymore.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
Autobuild-User(master): Amitay Isaacs <amitay@samba.org>
Autobuild-Date(master): Wed May 11 02:19:20 CEST 2016 on sn-devel-144
Since there are no public IPs setup, these tests do not really test the
functionality.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
This tested parse_nodestring function from tools/ctdb.c. However,
ctdb.c is soon going to be replaced with the code using new client API.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
For "master", if there is a master then print the PNN, otherwise print
nothing.
For "list", print the PNN and IP addresses without a colon in between.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
This simply calls out to the wrapper, so that commands are changed as
follows:
ctdb lvsmaster -> ctdb lvs master
ctdb lvs -> ctdb lvs list
This provides a simple, extensible interface and means that "ctdb lvs
status" is also available.
Unit tests are streamlined so that there is a single test for each
CTDB state. Each test does "master", "list" and "status" sub-tests.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
The "natgwlist" command is no longer marked "auto all" and is also
marked "without daemon". That latter is not strictly true because
ctdb_natgw needs the daemon so a subsequent invocation of "ctdb
nodestatus" will work. However, "without daemon" is used here because
the top-level "ctdb natgwlist" does not need to open a connection to
the daemon. It just needs to invoke ctdb_natgw.
Update tests to suit.
It would make sense to make "ctdb natgw" generally call out to
ctdb_natgw, passing all argument. However, that can be done later.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
These tests deal only with timeouts that can occur retrieving
capabilities. The NAT gateway capability is going away so drop the
tests now to simplify future commits.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
Some features, such NAT gateway and LVS support, can be implemented
without daemon and (internal) ctdb CLI tool support. These are
non-core features that don't need incredible performance and they
don't need to be in the core code. They can easily be reimplemented
in scripts, along with some configuration changes.
For continuity, the ctdb CLI tool code will call out to helper scripts
so that the current status information can still be provided. Those
helper scripts may then reinvoke the ctdb CLI tool to gather
information.
So, redo the tool testing using a "ctdb" stub command. This will
swallow standard input and feed it to the test program each time the
"ctdb" stub is called.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
There is no reason to serialise these or even handle remote nodes
first. Using a broadcast is more efficient and is less code.
Update expected test results to reflect changed order of messages.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
Autobuild-User(master): Amitay Isaacs <amitay@samba.org>
Autobuild-Date(master): Mon Mar 23 15:04:00 CET 2015 on sn-devel-104
"ctdb reloadnodes" currently does no sanity checking of the nodes
file. This can cause chaos if a line is deleted from the nodes file
rather than commented out. It also repeatedly produces a spurious
warning for each deleted node, even if the node was deleted a long
time ago.
Instead compare the nodemap with the contents of the local nodes file
to sanity check before attempting any reloads. Note that this is
still imperfect if the nodes files are inconsistent across nodes but
it is better. Also ensure that any nodes that are to be deleted are
already disconnected. Avoid trying to talk to deleted nodes.
The current implementation is a bit unfortunate when it comes to
deleting nodes. The most obvious alternative to the above complexity
would be to reloadnodes on the specified node first, then fetch the
node map (in which newly deleted nodes would be marked as such) and
then handle the remote nodes. However, the implementation of
reloadnodes is asynchronous and it only actions the reload after 1
second. This is presumably to avoid the recovery master noticing the
inconsistency between nodemaps and triggering a recovery before all
nodes have had their nodemaps updated.
Note that this recovery can still occur if the check is done at an
inconvenient time. A better long term approach might be to quiesce
the recovery master checks while reloadnodes is in progress.
Update a unit test to reflect the change.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
