napalm-qnap-qts

5 Commits

Author	SHA1	Message	Date
Christian Manivong	8ad1c66ace	ci: run the tests and build the package on every push and pull request CI / test (3.10) (push) Successful in 27s Details CI / test (3.11) (push) Successful in 26s Details CI / test (3.12) (push) Successful in 28s Details CI / test (3.10) (pull_request) Successful in 29s Details CI / test (3.11) (pull_request) Successful in 27s Details CI / test (3.12) (pull_request) Successful in 30s Details 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.	2026-10-07 07:52:44 +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	b4fe7c7a91	docs: point repository URLs at the NAPALM organisation	2026-09-24 09:05:24 +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