Brian Grant

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 …

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 …).

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 …

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

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.