Apart frem the gc_thresh indirect check, perform other checks.
For now, just highlight that tcp_sack being disabled can really
mess with BMC connections. Since the management node may have high speed and the BMC may be behind a 100MBit link, SACK
is needed to overcome the massive loss and
induce TCP to rate limit appropriately.
A common issue in larger layer 2 configurations is
for the neighbor table to be undersized for the number of
nodes.
Detect this manifesting and present a message.
Reap ssh-agent to avoid stale agents lying around.
Remove nuisance warnings about virbr0 when present.
Do a full runthrough as the confluent user to ssh to a node when user
requests with '-a', marking known_hosts and automation key issues.
Whether due to the management node or node IP addresses,
check if deployment can reasonably proceed using IPv4 or IPv6,
and give a warning with some suggestions to check.
Also, add nodeinventory <node> -s as an example resolution for missing
uuid.
When a node installs, it may not have it's node mapped address up,
or may not have one at all. Try to use the ip if it would be in the
same set that produced it's ssh certificate.
There remains a gap if a system has no static addressing *and* doesn't
map nodename to IP, but we have an impasse as the situation is too fuzzy
to grant a prinicpal in an SSH cert, and without that we can't securely
attempt rsync. For now, this scenario would still fail and I will
just hope that doesn't come up.
