mirror of
https://github.com/xcat2/xcat-core.git
synced 2026-10-07 10:06:39 +00:00
9f03656318
Both spec.md files are design documents for this organisation: they argue about what xCAT ought to put on the wire, cite the plugin lines that decide it, and record where the original proposal was wrong. Shipped under xCAT-test/ they would land in an RPM on every management node and be offered upstream as part of a test directory, which is not what they are for. They now live in the internal repository as specs/dhcp-wire.md and specs/provision-chain.md. The suites keep their clause tags, so a failing case still names the clause it belongs to.
50 lines
1.6 KiB
Plaintext
50 lines
1.6 KiB
Plaintext
# Stage 6: flow control on UDP 3001. Spec P-40, P-41.
|
|
#
|
|
# A large discovery has hundreds of machines asking for the same few xcatd
|
|
# slots at once, so genesis asks before it connects: `xcatflowrequest` sends
|
|
# `resourcerequest: xcatd` and loops until a grant comes back. Two datagrams,
|
|
# and they are not the same datagram -- the first says the request was heard,
|
|
# the second says there is room. A server that sends the first and never the
|
|
# second leaves every node in the cluster waiting silently.
|
|
#
|
|
# provtest run --set server=10.99.1.1 --set client=10.99.1.11 \
|
|
# conf/flowcontrol.conf
|
|
|
|
[defaults]
|
|
server = %(server)s
|
|
bind = %(client)s
|
|
timeout = 10
|
|
retries = 2
|
|
|
|
# --- P-40 -------------------------------------------------------------------
|
|
|
|
[scenario acknowledged]
|
|
description = A resource request is acknowledged immediately
|
|
|
|
[step request]
|
|
type = flowrequest
|
|
message = resourcerequest: xcatd
|
|
replies = 1
|
|
assert =
|
|
count >= 1
|
|
replies == ackresourcerequest
|
|
|
|
# --- P-41 -------------------------------------------------------------------
|
|
|
|
[scenario granted]
|
|
description = A resource request is granted, not merely acknowledged
|
|
|
|
[step grant]
|
|
type = flowrequest
|
|
message = resourcerequest: xcatd
|
|
replies = 2
|
|
# The grant is sent on the next pass of the requestor table rather than in
|
|
# reply to the datagram, so it arrives seconds later on an idle server and
|
|
# much later on a busy one. A single retry, a long window: a retransmit here
|
|
# would put a second entry in the table and be answered twice.
|
|
timeout = 30
|
|
retries = 1
|
|
assert =
|
|
count >= 2
|
|
replies == resourcerequest: ok
|