Hacker News new | past | comments | ask | show | jobs | submit login

Finally a public version of GCL/Borgcfg :-)

For people who doesn't know, GCL (Generic/Google Config Language) is a language that uses dynamic scope. You can define a `template` object with a variable defined as `external`. This way you can create similar objects by providing a concrete value for those `external`s at the time of instantiating.

The following paper was referenced in Google's borg paper and gives a good overview of the syntax.

https://research.tue.nl/en/studentTheses/gcl-viewer




(shameless plug) The missing piece to turn it into borgcfg: https://github.com/bitnami/kubecfg


Maybe it’s because I’m not a top 1% intelligence that I don’t get this but under what circumstances would configurations become complex enough to where this becomes necessary?


I don't think it's an intelligence thing just what problems one's come across. Generating configs for various deployments where resources change? Generating configs for developer set up? If you start having a lot of environmental variables or private keys it might be more manageable to get them from another secure source.


Let's say you manage a public GCP product. You need to run your job in multiple data center. Naturally the data center name is different between each Job object. You should only define one template and then substitute the data center name in the object.

But wait the product have multiple regions. For each region we will depend on regionalized database etc to improve reliability. We need to have some sort of "mixin" so that certain command line arguments can be consistently applied to all jobs in that region.

And then SWE want to rollout a new feature, as the first step they want to roll it out in one data center first then move to full prod later. Now you need to have a data center level overrides.

Can all of these be done in a generic programming language? Yes sure, but why not use a language that intentionally limit what you can do, is almost side effect free?


IMO this would mostly be useful if you had an architecture that evolved over time where you started with flat files for configuration and later moved to a centralized configuration system, many of which have concepts of references. Duplicating configuration or tapping into some of the advanced functions in here isn’t super helpful when you’re purely dealing with flat files, but this becomes helpful if you’re combining it with some synced external state because you can use this to “smooth over” differences in data shape.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: