Name and Version
0.19.0
What is the problem this feature will solve?
-
P1 — Two configuration planes, no shared mental model. Some entities live only in the config file (models, interceptors, roles, keys, routes, app-type schemas), some only in the Resource API (files, conversations, prompts), some in both (applications, toolsets). There's no single answer to "where does this entity belong?"
-
P2 — Eventual consistency between DIAL Admin and DIAL Core. Admin Backend writes a config file (or KeyVault / ConfigMap / etc.) and DIAL Core polls every 60 s. End-to-end propagation: 60–180+ s. Multi-replica deployments compound this — each pod polls independently with no cross-replica notification.
-
P3 — No audit trail. Neither plane records who changed what when. Config-file changes are only tracked if the underlying storage is versioned (e.g. Git for Helm values). The audit subsystem is designed but not part of this API surface; structured DIAL Core logs cover all Configuration API writes.
-
P4 — No single source of truth API for runtime state. No endpoint returns the effective config DIAL Core is actually serving. "What's the current state of all models/roles/keys in this instance?" requires inspecting multiple sources.
What is the feature you are proposing to solve the problem?
use configuration API (new and old) on DIAL Core directly from adminFE. archive adminBE.
some functionality will be unavailable in new admin (all write related features for file-based config). new admin panel FE should allow to manage all entities as resources (over DIAL API).
and provide read-only access to all entities from config-file mounted in core (except keys).
scope of work for BE team:
What alternatives have you considered?
No response
Name and Version
0.19.0
What is the problem this feature will solve?
P1 — Two configuration planes, no shared mental model. Some entities live only in the config file (models, interceptors, roles, keys, routes, app-type schemas), some only in the Resource API (files, conversations, prompts), some in both (applications, toolsets). There's no single answer to "where does this entity belong?"
P2 — Eventual consistency between DIAL Admin and DIAL Core. Admin Backend writes a config file (or KeyVault / ConfigMap / etc.) and DIAL Core polls every 60 s. End-to-end propagation: 60–180+ s. Multi-replica deployments compound this — each pod polls independently with no cross-replica notification.
P3 — No audit trail. Neither plane records who changed what when. Config-file changes are only tracked if the underlying storage is versioned (e.g. Git for Helm values). The audit subsystem is designed but not part of this API surface; structured DIAL Core logs cover all Configuration API writes.
P4 — No single source of truth API for runtime state. No endpoint returns the effective config DIAL Core is actually serving. "What's the current state of all models/roles/keys in this instance?" requires inspecting multiple sources.
What is the feature you are proposing to solve the problem?
use configuration API (new and old) on DIAL Core directly from adminFE. archive adminBE.
some functionality will be unavailable in new admin (all write related features for file-based config). new admin panel FE should allow to manage all entities as resources (over DIAL API).
and provide read-only access to all entities from config-file mounted in core (except keys).
scope of work for BE team:
What alternatives have you considered?
No response