This created a monolithic configuration and tool ecosystem. Even frameworks like mapreduce and services on top of Borg like BorgCron had to use BCL and borgcfg to interact with Borg. Getting-started tools generated BCL
-
Show this thread
-
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
1 reply 1 retweet 2 likesShow this thread -
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.
3 replies 2 retweets 7 likesShow 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 -
In Kubernetes, we wanted to decouple configuration authoring and generation from updates to the desired state via the API, so that users could express configuration using languages and tools familiar to them: Jinja, Python, Ruby, Javascript, Terraform, Ansible, whatever
1 reply 6 retweets 18 likesShow this thread -
I wrote about this in http://prs.k8s.io/1007 . I also felt it needed to be possible for automation to write directly to the API and not need to update some arbitrary configuration language. To do that, we needed to be able to merge user intent and automated changes
1 reply 2 retweets 6 likesShow this thread -
My initial proposal, in http://issues.k8s.io/1178 , was to maintain and merge 2 separate layers of desired state in the server. Resistance to that idea led to my client-side Apply proposal in http://issues.k8s.io/1702 . We're finally getting server-side apply:https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/0006-apply.md …
1 reply 2 retweets 8 likesShow this thread -
A gotcha we ran into early in the Apply implementation was complex schema topology. Merging 2 flat maps is easy, but we unfortunately had associative lists: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#lists-of-named-subobjects-preferred-over-maps …. And also sets and undiscriminated unions (being addressed: https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190325-unions.md …).
1 reply 0 retweets 5 likesShow this thread -
Strategic merge patch was developed so that we could diff and merge two objects containing associative lists (non-ordinal lists with index keys in values of fields within list elements): https://github.com/kubernetes/community/blob/master/contributors/devel/sig-api-machinery/strategic-merge-patch.md …
2 replies 0 retweets 3 likesShow this thread -
Replying to @bgrant0607
I think the biggest issue with strategic merge patch is, that it is not testable. AFAIK client-go doesn’t provide the test implementation. This lead us to build control loops with: list, compute, full-update
1 reply 0 retweets 0 likes
There are many issues with strategic merge patch. It grew organically, extended by several different people, worked around pre-existing API inconsistencies, is driven by Go field type tags, and mixed in some lifecycle directives. @originalavalamp has looked at overhauling it
-
-
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
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.