Brian Grant

A Python-based language was later developed, also. It interfaced with the update logic via a protobuf that wasn't quite the same as Borgmaster's. Other languages, such as Ruby, weren't used in Google. Several new Borg config languages were developed, but none were approved

Borgcfg didn't provide configuration packages. Shared templates were unversioned and directly imported from their homes in the monorepo, which inflicted churn on their consumers. There were also no "stacks" or lifecycle directives, so a number of imperative updates were needed

What do you think about stack sets like https://github.com/zalando-incubator/stackset-controller … ?

I was aware of it, but haven't had time to look at it closely

I think it would be valuable input for us to get feedback from people, like you, having used very different systems/deployment styles. Your posts about borg and the deployment styles (borgcfg and bcl) are very interesting for me. We use mustache templates in our cd pipelines.

I am not sure if Turing complete languages should be used to deploy, because it adds too much complexity. Our templates get input from our CI/CD system and an application owned delivery.yaml, that is used to have variables like application or version,which exists in all manifests

I believe the downsides of bespoke languages outweigh the benefits. More generally, I don't advise macro languages, configuration languages, or scripting using general-purpose languages. Keep it as simple as possible, ideally understandable by humans and tools.