spike: investigate dhall for deploy-sourcegraph

[ggilmore]

Related:

• https://github.com/sourcegraph/sourcegraph/issues/10100
• https://github.com/sourcegraph/sourcegraph/issues/10063

In RFC 141, we're exploring new configuration mechanisms for deploy-sourcegraph. As stated in the RFC, the main requirements for a solution are:

• [ Should not require customers to resolve git conflicts in the base Kubernetes manifests ]
• Should not add friction to the initial installation process
• Should not require customers to learn a substantial new domain of knowledge (e.g., a DSL)
• Should not conflict with other tools customers use to deploy and manage Kubernetes clusters
• Should be simple and easy to reason about
• Should be extensible by customers if they want customizations we have not yet thought of

RFC 141's proposed solution involves using bash scripts (plus yj and jq) to manipulate the base manifests. This solution has a few pitfalls:

• Using bash isn't type-safe. As mentioned by @uwedeportivo, this approach is similar to just using something like sed - the tool has no knowledge of yaml or kubernetes schemas so it's possible for it to make syntactic and semantic errors

• Running multiple customization bash scripts isn't guaranteed to be commutative . Off the shelf ways I can think of to solve this would be very complex and hard to maintain (total ordering of bash scripts, making all bash scripts aware of each other's existence).

---

dhall is a tool that I think can address some subset of these issues and a few more:

• Main benefit relevant to this issue: can be run as a validation layer on top of deploy-sourcegraph and our provided customization bash scripts.

• Extra benefits:

  • relevant to our development: Can use dhall to import / generate our existing Kubernetes manifests and can reduce boilerplate
  • relevant to our development: Can share configuration between different environments and deployment targets (example: publish core definitions in sourcegraph/sourcegraph, import / tweak them in deploy-sourcegraph, deploy-sourcegraph-dot-com, deploy-sourcegraph-docker, etc.)
  • relevant to our customers: Dhall includes language bindings that allow their languages to read in our dhall configuration and marshal it into their native structs

What I plan to do in the spike:

• Run through https://docs.dhall-lang.org/tutorials/Getting-started_Generate-JSON-or-YAML.html
• Use dhall to render our existing deploy-sourcegraph yaml manifests
• Implement a basic customization to our manifests (e.g. tuning gitserver's replica count)
• Try using dhall as a validation layer on top of bash script transformations

Questions I want to answer:

• Ease of picking up dhall's language, syntax, and semantics
• What our development workflow of using dhall would look like
• Is dhall a viable option for generating deploy-sourcegraph manifests
• Is dhall a viable option for applying a validation layer for manifests that both @sourcegraph and our users can run

[ggilmore]

see https://github.com/sourcegraph/sourcegraph/issues/10936