`default.toml` as a Structured Configuration Interface

[reset]

We currently expose the file default.toml which allows Plan authors to specify sensible defaults for configuration values. We however perform no validation at runtime when applying a configuration to a service group or allow Plan authors to mark a configuration field as required. Not being able to mark a configuration as required will lead to a service starting and failing, or worse, automatically updating and causing an outage (related https://github.com/habitat-sh/habitat/issues/5197).

We can improve this by allowing a Plan author to describe configuration information like the following:

[http.port]
default = 80
type = "integer"

[database.password]
type = "string"

[backend.aws]
optional = true
[backend.aws.username]
type = "string"

Using a structured format to represent the configuration will allow us to implement things like:

• Validate configuration on application to service group
• Validate handlebars templates on Studio build
• Allowing a service to be set in the intervene state (described in #5197) if a configuration value is missing on upgrade

This could be accomplished by reworking default.toml or adding a new file to sit alongside it as a replacement, keeping default.toml as is for backwards compatibility reasons.

[rsertelon]

Is toml still the best format for such structured information?

[raskchanky]

The other thing that comes immediately to mind is http://json-schema.org/ and there's likely already a bunch of libraries and tooling around that that could be leveraged. The main downside there is everyone's already using toml files. 😁

[reset]

It's reasonable to question the implementation for sure. I think it's a good choice to go forward with TOML since that's the format we've chosen for almost nearly everything else. I think it would be valuable to include @ryankeairns in the conversation if we want to dig into UX details!

[raskchanky]

Interestingly enough, it sounds like it's possible to validate a TOML document against a JSON Schema. Relevant links:

https://json-schema-everywhere.github.io/toml https://github.com/json-schema-everywhere/pajv https://github.com/any-json/any-json

From what I can tell, this works by converting the TOML document into JSON first, then validating against the JSON Schema.

[reset]

@raskchanky that's an interesting approach for sure. We also won't need to write any docs no our non-standard validation language ;)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you.