3.6 KiB
Managing serving configuration
Open Configuration after unlocking the Console. The catalog lists typed values, deployment source where provable, sensitivity, validation bounds and whether the value is editable.
Five numeric controls have a live serving consumer: embedding batch size, input character limit, gateway request timeout, gateway queue timeout, and telemetry staleness threshold. Other entries remain deployment-managed. The separate Scheduler policy workflow remains authoritative for its policy values; this editor cannot create a competing scheduler policy.
- Enter one or more safe overrides. Queue timeout must remain below request timeout. Use Use deployment value to remove an existing override.
- Choose Preview changes. Review before/after values, source changes and impact.
- Acknowledge the impact and choose Apply reviewed changes. Administrator authority is required; operators may preview and viewers may inspect.
- The result names the accepted revision and consumer. The API's serving policy reader uses that snapshot for new requests. Requests that already consumed their configuration retain their snapshot; no worker restart or model promotion is implied.
If another operator applies a change or deployment-resolved values change after preview, apply fails with a conflict. Refresh and preview again; the Console does not retry mutations silently.
Revision history and rollback retains actor, time, request correlation and complete override sets. Restoring an earlier revision or deployment defaults creates another preview followed by explicit apply. It does not erase history. Revision zero means the current deployment defaults; it does not restore an old environment file.
Export and import safe overrides exports JSON with format/product compatibility metadata, safe overrides and names of secret slots. It excludes connection strings, credentials and unrelated deployment topology. Import replaces the complete override set after a compatibility check and review. Slot names are references only; imports never set, rotate or revoke secrets.
Bootstrap and deployment-managed credentials still require the deployment's documented procedure. The fixed Hugging Face control-plane slot has a separate administrator-only write-only workflow for candidate creation, testing, activation, rotation and revocation; it never reveals or exports a token. It does not manage node download credentials. See the secret lifecycle procedure. Do not paste credentials into the numeric editor or a configuration export.
Persistence, upgrade and recovery
Schema 20260907_0025 adds configuration_state and configuration_revisions. Both are
authoritative PostgreSQL backup state. A validated override, active pointer and attributable audit
event commit together. Failed audit writes roll back the configuration change. Runtime credentials
can append revision history but cannot update, delete or truncate it.
The migration leaves existing model, project, credential and audit evidence unchanged and initially introduces two empty tables. It supports a mechanical downgrade only while there is no operator revision history. After configuration changes, recovery uses the verified pre-migration backup; the downgrade guard refuses to destroy the history. Restore compatibility accepts older-schema backups only when the added configuration tables are exactly empty, and requires exact retained configuration fingerprints for schema-0025 restores.
This source milestone does not create a release or change the deployed 1.2.2 schema. A release requires exact-head validation and the separate install/upgrade/rollback qualification.