Add helmify subcommand

[ThorstenHans]

This PR adds the helmify subcommand. Which allows users to generate Helm charts for a Spin App.

The command is added as subcommand to scaffold and re-uses the flags defined on scaffold.

Usage

spin kube scaffold helmify -f ttl.sh/hello-spinkube:24h \
  --memory-request 64Mi \
  --memory-limit 128Mi \
  --cpu-request 100m \
  --cpu-limit 200m \
  --replicas 4

[bacongobbler]

Thank you for the contribution. Would you mind taking some time to write down some documentation in the README?

A PR like this was a concern of mine when the scaffold command was introduced to the plugin. Every company has their own tools and their own mechanisms for deploying assets to Kubernetes. By adding scaffold, I was concerned that we've now opened the floodgates and we will now need to maintain commands for other third-party projects like Helm, Kustomize, cdk8s, <insert obscure template language here>... How do you envision us handling that maintenance burden over time? Do you think it'd make sense to split out helmify as a separate CLI plugin?

I've marked this as "request changes" because there are a few things that should be addressed before merging this PR, but I think it'd be worth addressing the larger question of whether it makes sense to maintain this as a separate plugin before proceeding.

[bacongobbler]

I think it'd be better if we make this spin kube helmify rather than spin kube scaffold helmify. While both scaffold and helmify perform the same rough amount of work (prepare a Spin application to be deployed to Kubernetes), the use cases for both are quite distinct (prepare an app for package management and distribution vs scaffold out a manifest), and I believe they should be treated as such.

By tying this command as a subcommand of scaffold, every feature flag that gets introduced to scaffold must now be added to helmify. There may be cases in the future where there will be a feature flag that will only work with scaffold but not helmify, and it'd be confusing for users to see that feature flag available in helmify's help output because of the way this command has been architected.

[bacongobbler]

Why is this included if it isn't a direct dependency of the plugin?

[ThorstenHans]

If you're talking about the helm.sh/helm/v3 dependency, it's added because I decided to use chart and chartutil from helm itself instead of rolling everything manually

[bacongobbler]

Why is this included if it isn't a direct dependency of the plugin?

[ThorstenHans]

what do you mean by "this" k8s.io/apimachinery? As part of the PR I added helm as a dependency maybe I've to go mod tidy it again?

[bacongobbler]

Alternatively, what makes this command different from a starter chart written specifically for Spin apps?

[rajatjindal]

you think it'd make sense to split out helmify as a separate CLI plugin

there is also https://github.com/arttor/helmify (which we use in spin-operator I believe).

[ThorstenHans]

@bacongobbler I was also uncertain if this should be added to kube scaffold or if it should become a custom plugin. Obviously, there are many ways on how to treat k8s deployment manifests.

IMO we could address the majority of scenarios with being able to scaffold plain k8s manifests and helm charts. I went for a subcommand of scaffold because it allowed me to re-use most parts of the CLI interface.

I'm happy to move the command around.

[ThorstenHans]

I don't see a helm starter chart as an equivalent solution for this.

• How could we distribute the starter chart to a broad audience
• Users have to alter the values.yaml and provide all the details of their app

As addition to the 2nd point, spin kube scaffold provides a way more guided experience

[bacongobbler]

While I appreciate your perspective on this matter, I've found @rajatjindal's solution quite compelling. helmify is not only well-regarded within the Helm community, boasting over 1.1k stars on GitHub, but it's also under active development. This signals a robust tool that's gaining traction and is supported by the community.

Through helmify, I was able to generate a Helm chart from the output of spin kube scaffold:

$ spin kube scaffold -f bacongobbler/myapp:1.0.0 | ./helmify mychart
$ cat mychart/templates/myapp.yaml
apiVersion: core.spinoperator.dev/v1alpha1
kind: SpinApp
metadata:
  name: {{ include "mychart.fullname" . }}-myapp
  labels:
  {{- include "mychart.labels" . | nindent 4 }}
spec:
  executor: containerd-shim-spin
  image: bacongobbler/myapp:1.0.0
  replicas: 2

It accepts all of spin kube scaffold's arguments:

><> spin kube scaffold \
    --from bacongobbler/myapp:1.0.0 \
    --autoscaler hpa \
    --cpu-limit 100m \
    --memory-limit 128Mi | ./helmify

This example not only demonstrates the practical utility of helmify, but also its compatibility with spin kube scaffold’s arguments, effectively addressing the specific use case you outlined regarding Helm chart generation for Spin Apps.

I understand the inclination to develop a bespoke solution. However, I would prefer that we harness tools that already exist from the community. It not only fosters collaboration, but also builds upon a foundation of tooling that many developers are already familiar with. Unless there's an overwhelmingly compelling reason to develop something independently, we should strive to engage and collaborate with the community.

Additionally, this project's core objective is to provide a great developer tool to interact with Spin Apps running on Kubernetes. That objective involves the relationship between the Kubernetes API and the client (spin kube). In this context, the necessity of packaging and distribution as Helm charts seems somewhat detached from the project's core objective.

What are your thoughts on documenting the integration of helmify with spin kube scaffold for now, and revisit the need for an alternative solution as we assess community feedback?

[bacongobbler]

This line needs to be indented one more space. I just discovered this bug and filed an issue: #68

[bacongobbler]

Closing; helmify can take spin kube scaffold as input and output a Helm chart.