Skip to content
Configure

Configure

An orchestrator takes its configuration from three places.

Its settings are the binary’s flags. Installed with systemd, they come from /etc/qfence-orchestrator/orchestrator.env. orchestrator.env.example explains each one: the raft peers and keys, the API’s certificate, sign-in through OIDC, the secrets stores, automatic failover. The command-line reference lists every flag, as qfence-orchestrator -h does.

Its controllers and availability plans are YAML: controllers: and availability_plans: (ADR 0010). A cluster has one source for them, which an administrator chooses (ADR 0001):

  • File mode, recommended: a configuration file, -config (QFENCE_CONFIG_FILE), the same on every orchestrator. The API and the console only read it: a change made in the console gives you the entry to add to the file instead. Change the file on every orchestrator, then reload each, with systemctl reload qfence-orchestrator or the console’s reload button. A file that cannot be applied in full changes nothing.
  • Replicated mode: the configuration is edited in the console or through the API, and reaches every orchestrator through raft, encrypted under a key only the orchestrators hold (QFENCE_CONFIG_KEY_FILE). The witness stores ciphertext.
  • Local, until a mode is chosen: each orchestrator starts from its own file, if it has one, and keeps the changes made through its own API and console. A change made through one orchestrator reaches no other, so a cluster should choose file or replicated mode. The demo lab runs this way.

Settings → Configuration in the console switches between them, through a dry run. GET /api/v1/config/export prints the running configuration as a file, a good start for file mode. Each orchestrator reports a fingerprint of its configuration, and the console shows when they differ.

Complete examples: the demo lab’s, with Redfish, Proxmox, FortiGate and systemd controllers, and the swarm lab’s, with Docker, PostgreSQL and Keycloak. The controller guides show the parts for each controller type. The configuration file’s reference lists every field, and each controller type’s its connection, auth and capabilities.

Its credentials are never in the configuration. A controller names a secret by reference, credentials_ref: local:bmc-dc1, and each orchestrator resolves it from a store of its own, a store shared through raft, or its site’s Vault: see secrets.