The gap
opencmdb has no administration page, and none is planned. Checked against the planning artifacts: the UX specification describes no settings screen, and none of the 23 epics owns an administration surface. Source configuration appears throughout (FR3, FR21; epics 11, 12, 14) but always as a capability, never as a screen.
Meanwhile the list of things that can only be set through the environment keeps growing:
| Setting |
Today |
| Scan subnets |
OPENCMDB_SCAN_CIDR (see #3, #4) |
| Probes in flight |
OPENCMDB_SCAN_CONCURRENCY |
| Probe timeout |
OPENCMDB_SCAN_TIMEOUT_MS |
| UI locale |
OPENCMDB_LOCALE |
| Log retention |
OPENCMDB_LOG_RETENTION |
| Metrics scrape token |
OPENCMDB_METRICS_TOKEN |
| Connector credentials |
not yet — epic 10 will need somewhere to put them |
Every one of them requires editing a file on the host and restarting the container.
Why this matters beyond convenience
The target user runs this on a NAS, quite possibly through Synology Container Manager rather than a shell. Asking that person to edit .env over SMB and recreate a container in order to try a different scan timeout is a poor fit for the product's own audience — and these are settings that want iterative tuning against a live network, not one-shot declaration.
There is also a coherence argument. opencmdb's thesis is that the declared state should be documented and visible; a product built on that idea keeping its own configuration in undocumented environment variables, invisible from its interface, is at odds with itself.
Scope to decide
This is a planning question before it is an implementation one — it probably needs an epic, and a UX pass, rather than being bolted onto an existing story. Open questions worth settling first:
- Which settings move to the database, which must stay bootstrap-only in the environment (the database connection obviously cannot configure itself)?
- Per-subnet scan parameters rather than global ones? A wired /24 and a wireless one do not deserve the same timeout.
- Where do connector credentials fit, given epic 10's encrypted storage?
- Does an administration surface imply authentication and roles arriving earlier than currently sequenced?
Related: #3, #4, #11.
The gap
opencmdb has no administration page, and none is planned. Checked against the planning artifacts: the UX specification describes no settings screen, and none of the 23 epics owns an administration surface. Source configuration appears throughout (FR3, FR21; epics 11, 12, 14) but always as a capability, never as a screen.
Meanwhile the list of things that can only be set through the environment keeps growing:
OPENCMDB_SCAN_CIDR(see #3, #4)OPENCMDB_SCAN_CONCURRENCYOPENCMDB_SCAN_TIMEOUT_MSOPENCMDB_LOCALEOPENCMDB_LOG_RETENTIONOPENCMDB_METRICS_TOKENEvery one of them requires editing a file on the host and restarting the container.
Why this matters beyond convenience
The target user runs this on a NAS, quite possibly through Synology Container Manager rather than a shell. Asking that person to edit
.envover SMB and recreate a container in order to try a different scan timeout is a poor fit for the product's own audience — and these are settings that want iterative tuning against a live network, not one-shot declaration.There is also a coherence argument. opencmdb's thesis is that the declared state should be documented and visible; a product built on that idea keeping its own configuration in undocumented environment variables, invisible from its interface, is at odds with itself.
Scope to decide
This is a planning question before it is an implementation one — it probably needs an epic, and a UX pass, rather than being bolted onto an existing story. Open questions worth settling first:
Related: #3, #4, #11.