3 ms·
Yes, I'm not criticising Dhall so much as the behaviours it permits. IMO it should be difficult to 'program' the generation of a config file, because the applic
by desc 7y ago
Yes, I'm not criticising Dhall so much as the behaviours it permits. IMO it should be difficult to 'program' the generation of a config file, because the application should be designed such that that degree of flexibility is not required at the level of configuration.
We've done things with generated config before. Looked necessary. We took a few steps back and realised that it was never necessary, only permitted, so it got fudged in deployment instead of being fixed in application design.
- nine_k 7y agoIf you operated services that should run at scale, or 24/7, or both, you must have noticed that the ability to fix an urgent issue (which may be totally not a fault of the deployed code) by changing just configs is valuable.
- desc 7y agoOf the failure modes I've had to deal with, even when we did use a lot of interpreted scripts which could be live-patched, very few of the important issues were fixable that way. Because the stuff which broke was rare and deep. One could argue that everything would be config-related if all the code were interpreted and considered to be configuration. So absolutely everything could be fixed in Production. I'd argue that absolutely everything could be broken in Production too, in that case. The point is that you test the invariant stuff, and have a small surface area of variables which define the permutations of Live behaviours. Configuration is not code. Code gets tested and doesn't vary between Canary, Nightly, Stable Test, Customer Test and Customer Live for a given build. Because some of us build stuff for customers who won't justify the 'risk' of updating every day, and have upgrade cycles measured in months.