Known limitations

Read these before you deploy qfence to protect anything. Each is also in the Known gaps of What the tests prove, with more detail; that list is longer, and is kept with the tests.

What has been tested against what

• Most infrastructure controllers are tested against doubles, not equipment. Redfish, IPMI, FortiGate and Proxmox are real clients of their vendors’ documented APIs, each tested against a double of that API, or a fake ipmitool for IPMI. None has yet run against a real BMC, firewall or hypervisor. The Docker controller runs against real Docker Engines and Swarms.
• How long real equipment takes is unknown. The Redfish and IPMI power fences and Proxmox VE’s vm.stop read their target’s state once, right after the device accepts the command, and a VM’s start after its host is powered on does not wait for the host to boot. The doubles and the lab’s simulator switch at once, so this has not been seen to matter; on equipment that is slower, a failover blocks rather than goes ahead (infrastructure controllers).
• The Vault provider runs against a real Vault; the AWS Secrets Manager reader only against a double of AWS, which AWS’s own Python SDK accepts.
• Sign-in through OIDC is tested against Keycloak only. Other identity providers have not been tried, and signing keys must be RSA (RS256).
• The Terraform modules have never been applied to a real Proxmox cluster or AWS account. They validate, and their first-boot scripts have been run on Ubuntu 22.04 in a container.
• Delayed packets are covered by simulation only. The chaos tests partition real raft clusters, but do not delay individual packets; the simulation tier reorders messages instead.

What qfence does and does not decide for you

• Automatic failover is off until you turn it on, with -automatic-failover on the orchestrators and automatic_failover: true on a plan. Its signal is a site with no reachable raft voter. It acts on an application only where the plan has health bindings and failover.application_health: a restart at the owner site, then a failover when restarts do not hold. A plan without them stays ACTIVE at a site whose application has died.
• An application-level fence never proves a site stopped. A demotion or a stopped unit is a secondary fence: every plan still needs a compute or network fence at each site.
• Your own application controllers are your own services. qfence calls them with mutual TLS and a pinned certificate, counts any reply outside the protocol as UNKNOWN, and qfence-orchestrator conformance checks one before you bind it. It cannot prove a controller that passes the kit tells the truth afterwards.
• An attested failover is only as true as the statement behind it. When a fence cannot be reached, an administrator can attest that the site is down. qfence cannot check the statement; if it is wrong, two sites may run. Two approvals compare identities, not people.
• Recovering from BLOCKED is manual, by design: someone checks the old site, then releases the plan and fails it over.

Operating it

• Configuration made through the API on a node with no configuration source chosen stays on that node. That is the single-node and demo default. A cluster uses file mode, where every orchestrator loads the same file, or replicated mode, where configuration goes through raft encrypted (Configure).
• Tokens from SSO sign-ins never expire, and are kept, as hashes, with the node’s state.
• The IPMI password is an argument of ipmitool, which other users of the orchestrator’s host can read while it runs. Keep the host to qfence alone.
• The consoles have not had a pass by a person using a screen reader. They are scanned with axe-core on every route in both themes, and checked with the keyboard alone and for colour-vision deficiency.