← Back to context

Comment by eru

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

6 comments

eru

Reply
valenterry  3 years 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  3 years 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  3 years 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  3 years 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.