Warn on unknown config options

[anderseknert]

It would be a nice touch if the server printed an informative message on startup when unknown config options was encountered. These could come from either typos or mistaking some startup parameter like --log-level for a config option.

Expected Behavior

# Mistakenly missing the "s" ending "decision_log"
$ opa run --server --set decision_log.console=true
{"addrs":[":8181"],"diagnostic-addrs":[],"insecure_addr":"","level":"info","msg":"Initializing server.","time":"2020-10-02T13:32:28+02:00"}
{"level":"info","msg":"Unknown config option 'decision_log.console' encountered","time":"2020-10-02T13:32:34+02:00"}

Actual Behavior

$ opa run --server --set decision_log.console=true
{"addrs":[":8181"],"diagnostic-addrs":[],"insecure_addr":"","level":"info","msg":"Initializing server.","time":"2020-10-02T13:32:28+02:00"}

[tsandall]

This would be nice however without a schema for the OPA configuration the implementation will be quite brittle. If we introduce a configuration schema, we'll have to provide some way for people to extend it with their custom sections (for use cases like the opa-envoy-plugin).

[anderseknert]

Yeah a schema would be sweet - not only for printing out warnings, but a complete JSON schema could also be published to https://www.schemastore.org/json/ for inclusion in most IDE's to offer validation, suggestions and auto-completion when editing OPA config files.

As for extending it I guess plugins or extensions could provide their patches on top that would get merged on top of the base schema when building the server.

[stale[bot]]

This issue has been automatically marked as inactive because it has not had any activity in the last 30 days.

[stale[bot]]

This issue has been automatically marked as inactive because it has not had any activity in the last 30 days.

[srenatus]

I still want this.

[stale[bot]]

This issue has been automatically marked as inactive because it has not had any activity in the last 30 days.

[anderseknert]

💭 Rather than using schemas for configuration, I'd love to see us using Rego for config validation. Looking at most of the validateAndInjectDefaults functions currently written in Go for this purpose, most of them would lend themselves perfectly for Rego!

Any plugin could provide their own validation policy, and we'd simply source all of the active ones from some well-known location for evaluation. Ideally, teams could extend this validation with their own policies, adding requirements which might not make sense for OPA, but would make perfect sense to their organization. Nothing beats OPA at this game, after all 🙂