55 lines
3.6 KiB
Markdown
55 lines
3.6 KiB
Markdown
# 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.
|
|
|
|
1. Enter one or more safe overrides. Queue timeout must remain below request timeout. Use
|
|
**Use deployment value** to remove an existing override.
|
|
2. Choose **Preview changes**. Review before/after values, source changes and impact.
|
|
3. Acknowledge the impact and choose **Apply reviewed changes**. Administrator authority is
|
|
required; operators may preview and viewers may inspect.
|
|
4. 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](SECRET_LIFECYCLE.md).
|
|
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.
|