Brian Grant on Twitter: "BTW, eventually a "production database" called ProdSpec, did succeed and rolled out. Borg has converged towards a model similar to the Kubernetes Resource Model and "GitOps" (though our internal VCS isn't git), described here: https://t.co/NruSd3YpAh"

Country	Code	For customers of
United States	40404	(any)
Canada	21212	(any)
United Kingdom	86444	Vodafone, Orange, 3, O2
Brazil	40404	Nextel, TIM
Haiti	40404	Digicel, Voila
Ireland	51210	Vodafone, O2
India	53000	Bharti Airtel, Videocon, Reliance
Indonesia	89887	AXIS, 3, Telkomsel, Indosat, XL Axiata
Italy	4880804	Wind
3424486444	Vodafone
» See SMS short codes for other countries

Brian Grant‏ @bgrant0607 1 May 2019

Report Tweet
Report NetzDG Violation

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

1 reply 1 retweet 2 likes

Show this thread

Brian Grant‏ @bgrant0607 1 May 2019

Report Tweet
Report NetzDG Violation

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 likes

Show this thread

Brian Grant‏ @bgrant0607 1 May 2019

Report Tweet
Report NetzDG Violation

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 likes

Show this thread

Brian Grant‏ @bgrant0607 1 May 2019

Report Tweet
Report NetzDG Violation

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 like

Show this thread

Brian Grant‏ @bgrant0607 1 May 2019

Report Tweet
Report NetzDG Violation

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 likes

Show this thread

Brian Grant‏ @bgrant0607 1 May 2019

Report Tweet
Report NetzDG Violation

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 likes

Show this thread

Brian Grant‏ @bgrant0607 1 May 2019

Report Tweet
Report NetzDG Violation

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 likes

Show this thread

Brian Grant‏ @bgrant0607 1 May 2019

Report Tweet
Report NetzDG Violation

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 likes

Show this thread

Brian Grant‏ @bgrant0607 1 May 2019

Report Tweet
Report NetzDG Violation

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 likes

Show this thread

Brian Grant‏ @bgrant0607 1 May 2019

Report Tweet
Report NetzDG Violation

I wrote an overview of the motivation and principles for the configuration design in https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/declarative-application-management.md …. The original draft of that also contained sketches of what became https://github.com/kubernetes-sigs/application … andhttps://github.com/kubernetes-sigs/kustomize …

2 replies 2 retweets 10 likes

Show this thread

Brian Grant‏ @bgrant0607 1 May 2019

Report Tweet
Report NetzDG Violation

BTW, eventually a "production database" called ProdSpec, did succeed and rolled out. Borg has converged towards a model similar to the Kubernetes Resource Model and "GitOps" (though our internal VCS isn't git), described here:https://www.youtube.com/watch?v=b4PFHj9s5F8&t=1084s …

8:46 PM - 1 May 2019