Comment by valenterry
3 years ago
As much as I love Dhall, I think it's actually better to allow any turing complete programming language and require it to generate the config in a certain format (whatever it is, maybe even dhall).
The only thing is needed to run the config-generation process in a sandbox and restrict how long it can run. If it takes too long then we stop it - the same we should do with a Dhall config as well, even if Dhall theoretically will finish in a finite amount of time.
That way everyone can use their preferred language to describe and maintain the configuration. We just have to agree on the format that is being spit out at the end, such as json, yaml, dhall or even a proprietary format.
> The only thing is needed to run the config-generation process in a sandbox and restrict how long it can run.
That's a very brittle restriction at best, and if implemented strictly on time, it's a very flaky on as well.
How so? Normally, generating a config, even a big one, is a matter of milliseconds even for slow languages.
We are not talking about applying the config - we are just talking about using some inputs (variables) and generating a string / text-file that we return to the entitiy that then validates and uses the config.
Not sure why that would be flaky.
Generating a config may include downloading a number of remote definitions, their evaluation & caching for future reuse (Dhall does that, Nix too), which doesn't fit into milliseconds threshold on the first run.
1 reply →
Flaky in the sense that you can have stuff that's fitting right into your cut-off time limit on some runs, and going over on some others.
2 replies →