Brian Grant on Twitter: "This thread is already the longest yet, so I'll start another later with configuration terminology: declarative vs intent, macros vs config languages, packages vs stacks, prototypes vs templates, whitebox vs blackbox, overlays, lifecycle directives, etc."

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

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

Whereas Apply facilitates collaborative config authoring between humans and machines (thanks to @originalavalamp for that description), kustomize enables collaboration among humans, by facilitating modification of unchanged base prototype/seed configurations.

1 reply 1 retweet 6 likes

Show this thread

Brian Grant‏ @bgrant0607 1 May 2019

Report Tweet
Report NetzDG Violation

The declarative API, Apply, and kustomize facilitate maintaining configuration as YAML or JSON or proto, amenable to manipulation by tools, rather than as YAML marked up with macros, complex configuration languages, or scripts written in general-purpose programming language.

2 replies 1 retweet 3 likes

Show this thread

Brian Grant‏ @bgrant0607 1 May 2019

Report Tweet
Report NetzDG Violation

On one hand, the ~100 tools that have been developed show that the decoupling of config format and the API has worked. OTOH, it shows there are still gaps. With work like diff and dry run (https://github.com/kubernetes/enhancements/pull/893 …) and prune (https://github.com/kubernetes/enhancements/pull/810 …), we're working to close them

1 reply 1 retweet 8 likes

Show this thread

Brian Grant‏ @bgrant0607 1 May 2019

Report Tweet
Report NetzDG Violation

A list of tools can be found here: https://docs.google.com/spreadsheets/d/1FCgqz1Ci7_VCz_wdh8vBitZ3giBtac_H8SBw4uxnrsE/edit#gid=0 …. I just added another 20 or so that I've seen.

1 reply 0 retweets 17 likes

Show this thread

Brian Grant‏ @bgrant0607 1 May 2019

Report Tweet
Report NetzDG Violation

This thread is already the longest yet, so I'll start another later with configuration terminology: declarative vs intent, macros vs config languages, packages vs stacks, prototypes vs templates, whitebox vs blackbox, overlays, lifecycle directives, etc.

9:19 AM - 1 May 2019