Implement Helm library

[mateoflorido]

Summary

This pull request adds a library for managing Helm charts and includes a proof of concept for CLI entries (enable, disable) for components.

Changes

• Integration of CoreDNS chart (version 1.11.1).
• Addition of charts using the dump plugin to bundle them within the snap.
• Implementation of a minimal CLI for enabling and disabling components.
• Creation of a Helm library designed to manage the chart/release lifecycle.
• PoC facade to enhance the integration between the CLI|REST API endpoints, and the Helm library.

FAQ

• Why use the Helm SDK instead of a custom wrapper around the binary?: Using the Helm SDK offers streamlined integration with Helm's robust code, reducing the need for extensive boilerplate. Also, it ensures enhanced error handling capabilities, facilitating the debugging and maintenance.

[mateoflorido]

Manual testing:

➜  k8s git:(KU-104/helm-wrapper) sudo ./bin/static/k8s enable dns -f ~/values.yaml
INFO[0000] Component dns enabled
➜  k8s git:(KU-104/helm-wrapper) k get cm -A
NAMESPACE         NAME                                                   DATA   AGE
kube-system       extension-apiserver-authentication                     6      11h
kube-system       kube-apiserver-legacy-service-account-token-tracking   1      11h
default           kube-root-ca.crt                                       1      11h
kube-node-lease   kube-root-ca.crt                                       1      11h
kube-public       kube-root-ca.crt                                       1      11h
kube-system       kube-root-ca.crt                                       1      11h
kube-system       ck-dns-coredns                                         1      45s
➜  k8s git:(KU-104/helm-wrapper) sudo ./bin/static/k8s disable dns
INFO[0000] Component dns disabled

[jnsgruk]

➜  k8s git:(KU-104/helm-wrapper) sudo ./bin/static/k8s enable dns -f ~/values.yaml

Why does your binary expose -f values.yaml? That should definitely be hidden from our users?

[neoaggelos]

Really nice work overall! Leaving some comments

I assumed that we wanted to have k8s only talk with k8sd. Is this simply a PoC that shows that this works, and a separate PR will move things to a components endpoint?

As for the charts, I would prefer keeping the tar.gz around unless we have to edit it somehow, things would be a lot more tidy (and has no functional differences)

I am also missing some tooling/README/doc that describes the process of upgrading the bundled charts (how do we fetch them? how do we tell k8s to use the new version? this could look like helm pull ... and update src/k8s/component/component.componentMap accordingly.

As a final comment, I would love to be able to quickly tell the component version, e.g. have things like:

charts/coredns-1.11.1.tgz
charts/cilium-1.15.0.tgz
...

[bschimke95]

Great work @mateoflorido!

One thing:
We want the CLI to only interact with the REST API that is exposed by k8sd. I assume the current CLI implementation is for testing and will eventually moved to an /component endpoint in a future PR?

[mateoflorido]

I have addressed (hopefully) all the comments in the code review. I have performed a refactor on the Helm package (now Component Manager) to make it more generic. Also, I removed the flags for setting values and additional configuration for the components.

[bschimke95]

Added some comments on how the component manager interface is used. Sorry that I haven't seen this in the first review iteration.

[mateoflorido]

I have switched to using a configuration file for defining the components, using Viper. Additionally, I have refactored the component package to make it more generic and decoupled from its implementation.

[bschimke95]

Cool stuff, @mateoflorido!
I really like the interface now.

One final question: The Refresh method is not yet used, is it?