napalm-linux 0.9.0 names no warnings (netOrk #1111), so the override that
kept the inherited get_device_warnings from asking for updates goes. The
package proxy it now reports is switched off with the template that sets
it: QTS has no apt. Requires napalm-linux 0.9.0.
napalm-linux 0.8 implements napalm-device-types' fix templates. QTS has
no apt, dnf or opkg and sets its SNMP agent in its own UI, so
configure_snmp_agent, configure_package_proxy and ensure_package are
None here: a capability check answers no instead of offering a fix
that fails, as the inherited fix_snmp and fix_apt_proxy did.
get_device_warnings returns nothing: the inherited one asked for
updates, which is None here, and logged a TypeError on every poll.
The role test follows napalm-linux's get_os_users.
Closes#6. Part of #7.
napalm-linux 0.3.0 drops the Docker CLI methods the override served.
_container_engine_binary("docker") returns Container Station's path
itself, which is all netOrk needs: it reaches the engine through
open_container_engine (NetOrk/netork#765, phase 9).
Requires napalm-linux >= 0.3.0. Version 0.3.0.
napalm-device-types 2.6.0 opens a host's container engine through
`open_container_engine()`, and asks the driver for the binary through
`_container_engine_binary()`. Under QTS docker is not on PATH; the hook
now returns the path `open()` already discovers, so the Engine API stream
(`<path> system dial-stdio`) and the CLI reach Container Station while
callers only pass arguments (NetOrk/netork#765).
Version 0.2.0, requires napalm-device-types >= 2.6.0 and
napalm-linux >= 0.2.0.
Refs NAPALM/napalm-device-types#17
The same job as napalm-fritzbox and napalm-opnsense: Python 3.10, 3.11 and
3.12, pytest, then wheel and sdist. napalm-device-types comes from
git.netork.io first, because PyPI has an unrelated package of that name.
napalm-linux, which this driver builds on, is installed from git as well:
it is not on PyPI either.
QTS has no apt, dnf or opkg, so the update readers inherited from
LinuxDriver find no package manager, and QPKG updates are not implemented.
get_available_updates, refresh_available_updates and apply_updates are None,
the same opt-out as manage_service: netOrk's patch groups and compliance
report include a driver only when these are callable.
QnapQtsDriver inherits LinuxDriver, which now has manage_service() through
napalm-device-types' SystemdServicesMixin. QTS has no systemd, so every
action would fail. manage_service = None makes every capability check --
is manage_service callable -- answer no, so netOrk offers no controls that
cannot work.
A QNAP is a NAS, a hypervisor and a Linux host. It can now say so, because role
bases in napalm-device-types v1.0 declare their methods without implementing
them:
class QnapQtsDriver(StorageDriver, HypervisorDriver, LinuxDriver):
device_class comes from the first base, so DEVICE_CLASS is gone. The get_services
forwarder is gone with it — nothing shadows LinuxDriver's version any more — and
so is the TestMroForwarding class that guarded the collisions.
Removing the shadowing exposed something the shadowing had been hiding by
accident. This driver never implemented package management; StorageDriver's stub
for install_package covered LinuxDriver's working one, so calling it raised and
looked correct. It was a coincidence, not a decision: without the stub the call
falls through to LinuxDriver, which would run apt or dnf against a NAS that has
neither. QTS uses QPKG.
get_packages, install_package and uninstall_package are therefore overridden
here to refuse with a reason, until the device harvest supplies real QPKG
parsing. See netork#114.
Christian Manivong