4 ms·

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 forma

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.

eru 4y ago
> 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.
- valenterry 4y ago
  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.
  - ghostwriter 4y ago
    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.
    - valenterry 4y ago
      Potentially yes. But if we compare it to Dhall, then the sandbox would just allow to generate a config, potentially based on some inputs, but without disk access, network access, etc. If you allow that for Dhall, then you also have the problem of a config potentially taking extremely long to load / to be ready. So you will want to set a timeout anyways and I don't see a big difference here from a practical point of view.
  - eru 4y ago
    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.
    - valenterry 4y ago
      I mean, theoretically yes - but I doubt that this would be an issue in any but the rarest cases.
      - eru 4y ago
        Depends on how aggressive your timeouts are, I guess?

eru 4y ago

> 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.

valenterry 4y ago
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.
- ghostwriter 4y ago
  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.
  - valenterry 4y ago
    Potentially yes. But if we compare it to Dhall, then the sandbox would just allow to generate a config, potentially based on some inputs, but without disk access, network access, etc. If you allow that for Dhall, then you also have the problem of a config potentially taking extremely long to load / to be ready. So you will want to set a timeout anyways and I don't see a big difference here from a practical point of view.
- eru 4y ago
  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.
  - valenterry 4y ago
    I mean, theoretically yes - but I doubt that this would be an issue in any but the rarest cases.
    - eru 4y ago
      Depends on how aggressive your timeouts are, I guess?