napalm-qnap-qts

6 Commits

Author	SHA1	Message	Date
christianmanivong	39532471b7	Merge pull request 'feat: hand the container engine connection Container Station's docker' (#4 ) from feat/container-engine-binary into main 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 29s Details	2026-10-07 16:10:44 +00:00
christianmanivong	b868f53990	Merge pull request 'ci: run the tests and build the package on every push and pull request' (#3 ) from ci/workflow into main CI / test (3.10) (push) Successful in 29s Details CI / test (3.11) (push) Successful in 27s Details CI / test (3.12) (push) Successful in 29s Details	2026-10-07 06:37:00 +00:00
christianmanivong	0f4b4f56c4	Merge pull request 'fix: do not claim update reading or applying QTS cannot do' (#2 ) from fix/no-update-reader into main	2026-10-05 22:20:13 +00:00
christianmanivong	872e5718a3	Merge pull request 'fix: do not claim service control QTS cannot do' (#1 ) from fix/no-service-control into main	2026-10-05 11:12:16 +00:00
christianmanivong	35c47bdb24	docs: do not claim hardware testing that has not happened yet	2026-08-21 09:55:20 +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