Mixes in napalm-device-types 4.9's SystemIdentityMixin: the host's
SMBIOS system UUID, product serial and board serial, read as root on an
exec channel, vendor placeholders empty. netOrk links a server's BMC to
the host on these.
napalm-device-types 4.7 changed three things this driver depends on:
- parse_dnf_security needs the "__DNF_RC=<status>" line that
DNF_SECURITY_COMMAND prints and raises ValueError without it or when dnf
failed. The yum security query had no such line, so listing updates on
any yum host raised. _YUM_SECURITY_COMMAND now prints the marker the same
way ("{ ...; echo __DNF_RC=$?; } | cat"). _rpm_security_names checks
__DNF_RC itself and turns a failed query, or output cut short before the
marker, into None (security unknown) rather than "no advisories" or an
exception.
- OSDriver.get_users was renamed to get_os_users, since NAPALM's own
get_users has another shape. LinuxDriver.get_users is now get_os_users
with the same return value.
- run_on_transport reads an exec channel to EOF after its exit status
arrives; the tests' fake channels gain recv/recv_stderr for that.
Require napalm-device-types>=4.7.1 and bump the version to 0.6.0.
Where docker lives is device-specific; what to do with it is not. QNAP's
Container Station installs docker under /share/<pool>/.qpkg/ and never
puts it on PATH, so a QTS driver inheriting this class found no docker at
all.
Rather than reimplementing the Docker surface in the vendor driver, the
path becomes a single overridable method and every call site goes through
it. Per docs/ARCHITECTURE.md 4.4, generic logic belongs to the shared
driver and only the device-specific mechanics belong to the vendor one.
A test asserts that *every* docker call site uses the hook — a half
converted set would let detection find the binary while the actual
queries still missed it, which only shows up against real hardware.
christianmanivong