mirror of
https://github.com/xcat2/xcat-core.git
synced 2026-10-15 08:12:02 +00:00
Daniel Hilst
2efcbcde08
Running the scenarios against a live management node found nine places where they asserted something xCAT does not do. Corrected here, each with the reason in the file: - install configs carry no xcatd= or destiny=; those are written for the genesis states only. - #END OF SCRIPT is plain-transport framing; over TLS a reply ends with <serverdone>. - getcredentials is named in <arg> and answered as <data><content/> <desc/></data>, so both fields are addressable now. - currstate for an install is "install <osimage>", so the operator is starts-with. - bootparams is empty for an ordinary install, so kernel and initrd cannot be asserted from getdestiny. - a server never reached sends no <error>; assert the handshake instead. - an NXDOMAIN answer is the expected result of a removal scenario. - P-75 has to precede P-74: a withdrawn name cannot be nodeset again. Also adds netutil.hex_net: a per-network config is named by as many hex digits as the netmask covers, not by all eight.
111 lines
4.1 KiB
Plaintext
111 lines
4.1 KiB
Plaintext
# Failing at exactly one place. Spec P-72, P-74, P-75.
|
|
#
|
|
# Every scenario in this file arranges for each stage before the interesting
|
|
# one to be correct, so the run goes red at one identifiable point. That is the
|
|
# whole argument for a wire suite: today all of these failures look the same
|
|
# from the outside -- the node times out -- and telling them apart means
|
|
# watching a console during a reboot.
|
|
#
|
|
# P-75 needs a second nodeset and P-74 needs the node's name withdrawn from
|
|
# resolution, and that order cannot be reversed: nodeset names the config it
|
|
# writes after the node's address, which it gets by resolving the node, so once
|
|
# the name is gone there is no second nodeset to be had. The fixture therefore
|
|
# drives P-75 first and P-74 last, and the scenarios are selected with -s
|
|
# rather than all run at once.
|
|
#
|
|
# provtest run \
|
|
# --set server=10.99.1.1 --set client=10.99.1.11 \
|
|
# --set node=provtestcn --set hexip=0A63010B \
|
|
# --set xcatport=3001 --set unreachable=10.99.1.250 \
|
|
# --set destiny=install --set second=boot \
|
|
# conf/ordering.conf
|
|
|
|
[defaults]
|
|
server = %(server)s
|
|
bind = %(client)s
|
|
timeout = 15
|
|
retries = 1
|
|
|
|
# --- P-72 -------------------------------------------------------------------
|
|
|
|
[scenario unreachable-master]
|
|
description = A master that does not answer is distinguishable from one that refuses
|
|
|
|
[step reachable]
|
|
type = xcatreq
|
|
port = %(xcatport)s
|
|
command = lsxcatd
|
|
element =
|
|
arg = -v
|
|
assert =
|
|
handshake == yes
|
|
|
|
[step unreachable]
|
|
type = xcatreq
|
|
server = %(unreachable)s
|
|
port = %(xcatport)s
|
|
command = lsxcatd
|
|
expect = fail
|
|
# The two steps differ in one thing: the address. A node whose kernel command
|
|
# line names an address nothing answers on boots perfectly and then stops, and
|
|
# from the console that looks identical to a protocol fault at a server that
|
|
# is up. Here the two are told apart without booting anything.
|
|
assert =
|
|
# No handshake and no answer, against a step that got both from the real
|
|
# address a moment earlier. `error` is deliberately not asserted: that
|
|
# field carries an <error> element the server sent, and a server that was
|
|
# never reached sends nothing at all -- which is the distinction being
|
|
# drawn, not an omission in the assertion.
|
|
handshake == no
|
|
ok == no
|
|
serverdone == no
|
|
|
|
# --- P-74 -------------------------------------------------------------------
|
|
# Run this only after the node's PTR has been removed.
|
|
|
|
[scenario missing-ptr]
|
|
description = A node whose reverse record is gone is treated as an unknown client
|
|
|
|
[step getdestiny]
|
|
type = xcatreq
|
|
port = %(xcatport)s
|
|
command = getdestiny
|
|
# Nothing about the node changed: it is still defined, still set to install,
|
|
# still on the same address. One DNS record decides whether xcatd recognises
|
|
# it, and its absence is reported nowhere -- the node is simply told to
|
|
# discover itself, forever.
|
|
assert =
|
|
destiny == discover
|
|
destiny != %(destiny)s
|
|
|
|
# --- P-75 -------------------------------------------------------------------
|
|
# Run this only after a second nodeset has set the node to another state.
|
|
|
|
[scenario state-replaced]
|
|
description = A second nodeset leaves no trace of the first state
|
|
|
|
[step config]
|
|
type = tftp
|
|
path = boot/grub2/grub.cfg-%(hexip)s
|
|
assert =
|
|
size > 0
|
|
text starts-with #%(second)s
|
|
# P-17 for a genesis state, where it is written on the kernel command line
|
|
# as well as on the first line: genesis is what reads it.
|
|
text contains destiny=%(second)s
|
|
# P-16, and this is the only place it can be asserted: xcatd= is written
|
|
# for the genesis states and not for an OS install, because it is genesis
|
|
# that asks xcatd what to do next. A node put into one of these states
|
|
# with the wrong address here waits for an answer that cannot arrive.
|
|
text contains xcatd=%(master)s:%(xcatport)s
|
|
|
|
[step stale]
|
|
type = extract
|
|
from = $config.text
|
|
pattern = destiny=%(destiny)s
|
|
# The previous state's artefacts are the ones nobody looks for. A config
|
|
# rewritten in place is fine; a config left behind under another of its names
|
|
# is a node that boots last week's decision.
|
|
assert =
|
|
matched == no
|