Closed jhunt closed 6 years ago
I'll work on a POC PR for this :+1: thanks @jhunt
@jhunt Is it necessary to validate the HCL as HCL, or is checking that it's valid JSON enough? In some tests Vault validates its own configs pretty well and gives messages like:
* listeners.tcp: invalid key 'buddy' on line 24
Error loading configuration from /var/vcap/jobs/vault/config/server.hcl: error parsing 'listener': 1 error occurred:
Mostly I just want to avoid having to bundle random Ruby deps to do the HCL validation.
I wouldn't even bother validating it. This is expert mode; users can probably figure out the error messages.
:+1: One less thing. I've got a viable proof of concept on my local just doing some random testing today and I'll put up the PR. As you can imagine it's a pretty basic change, delay is me brushing up on bosh2 stuff.
Landed!
Thanks a TON to @MattSurabian !
Introduce a new property,
config
that contains a big long string of HCL to inject into the config.This will allow us to retire 80% of the properties in this BOSH release, while allowing tinkerers to tinker to their tinkering hearts' content. People who want a stable, curated Vault should look at the safe BOSH release (https://github.com/cloudfoundry-community/safe-boshrelease).
Once we have a release with the config support, that people can migrate via, we'll deprecate the old custom backend properties, bump major version and cut a new release.