Not specifically developed for Borg use, https://jsonnet.org/articles/design.html … and https://github.com/cuelang/cue/ were inspired by BCL. http://aurora.apache.org/documentation/latest/reference/configuration-templating/ … and https://github.com/stripe/skycfg were inspired by the Python language.
-
Show this thread
-
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
3 replies 1 retweet 1 likeShow this thread -
Replying to @bgrant0607
What do you think about stack sets like https://github.com/zalando-incubator/stackset-controller … ?
1 reply 0 retweets 0 likes -
Replying to @sszuecs
I was aware of it, but haven't had time to look at it closely
1 reply 0 retweets 0 likes -
Replying to @bgrant0607
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.
1 reply 0 retweets 0 likes -
Replying to @sszuecs @bgrant0607
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
1 reply 0 retweets 0 likes -
Replying to @sszuecs
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.
2 replies 0 retweets 1 like -
Replying to @bgrant0607 @sszuecs
Configuration should be represented as data, and we need to build reusable, testable programs that manipulate the data. We have http://github.com/kubernetes-client …, but more work is needed on SDKs to make that easier. If an encapsulated abstraction is needed, build it using CRDs
2 replies 0 retweets 1 like -
-
Replying to @sszuecs @bgrant0607
.. but humans don't want to write data. Otherwise every k8s config would be mountains of literal near-duplicated YAML, and we wouldn't have these 100 tools. Humans want to describe *patterns*, use late-binding, composition, encapsulate expertise, etc.
2 replies 0 retweets 0 likes
I agree on the goal. There are other approaches to achieve that goal that haven't yet been used widely. A big reason for 100 tools is the lack of clean separation of concerns, though. People can't mix and match generation languages, packaging mechanisms, stack management, etc
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.