5 Commits

Include renames

Author	SHA1	Message	Date
Christian Manivong	5838685690	feat: hand the container engine connection Container Station's docker ... 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	2026-10-07 17:59:55 +02:00
Christian Manivong	5e371db3af	fix: do not claim update reading or applying QTS cannot do ... 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.	2026-10-06 00:20:12 +02:00
Christian Manivong	77313ca436	fix: do not claim service control QTS cannot do ... 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.	2026-10-05 13:12:16 +02:00
Christian Manivong	927e39bf36	feat: declare all three roles, and refuse QPKG writes deliberately ... 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.	2026-08-21 12:50:27 +07:00
christianmanivong	26d723f417	feat: initial QNAP QTS driver scaffold ... QTS is a Linux distribution, so the driver inherits the OS surface from LinuxDriver and adds QNAP's storage, QPKG and virtualisation layers. What is here: the class with its discovery fingerprints, per-session detection of the QTS major version and of the QPKG-local docker and virsh binaries, and explicit resolution of the MRO collisions that StorageDriver creates over LinuxDriver. What is not: the storage, QPKG and VM parsers. Those need real command output from QTS 4 and QTS 5 hardware to be written against, which is what tools/harvest.sh collects and tools/sanitize.py anonymises. Two tests are marked xfail(strict) as the specification for that work.	2026-08-21 09:53:13 +07:00