helmify rfc

docs/designs/helmify.md

@@ -0,0 +1,44 @@
+# Helm-ify
+
+## The problem
+
+Currently the project relies on helm install-ing several helm Charts,
+required for the various components. 
+However, other parts of the project such as the project components themselves 
+and migrations are a combination of `kustomize.yaml` manifests (components), k8s
+ yamls applied through `draconctl` (migrations). This is significantly confusing
+and tech debt since it is not clear what installs what, how and why.
+
+It is suggested that the project uses Helm as its sole way of deploying things.
+
+## Changes suggested
+
+The following changes are suggested
+
+* Make a `dracon-dev` chart which installs all the sub-charts referenced by 
+the `make-dev` target
+* Make `draconctl migrations apply` only apply migrations against a database url
+and not try to manage a k8s job
+* Make a `dracon` chart which installs dracon components and migrations only
+assuming there are prerequisite systems present (Elasticsearch, Postgres etc),
+values for those systems are provided through `values.yaml`
+* Transform all components into Charts, one chart for each.
+* Make `pipelines` be their own Charts
+* Add the ability for draconctl to interface with an OCI registry and discover 
+  components.
+* Add the ability for draconctl to create Charts via CLI arguments and manage
+  them
+
+## Benefits
+
+This approach allows for maximum extensibility and configurability.
+e.g. Adding private components is an extra line in the Chart, adding migrations
+is just running another chart with another post-job that depends on the original
+dracon.
+
+Moreover this makes components universally findeable and allows anyone to host 
+components wherever they want.
+
+This approach is also testable as there are lots of Helm test utils and allows 
+for flexibility in both deployment and piecing together our many 
+(often optional) moving parts.