chore: overhaul chart

[tamcore]

This should greatly improve readability of the chart itself, and make it easier to extend in the future

• moved the Pod spec for both the Deployment and StatefulSet into a common template in _pod.yaml
• replace a bunch of if $value; print $value-type blocks with with $value; print .
• replaced command.set in values.yaml with command directly
  • this was broken anyways, as the chart wrongly referenced command.cmd for both Deployment and StatefulSet
• added relatively complete .values-test.yaml for development/CI purposes

---

To make use of .values-test.yaml, just pass it to --values. For example:

For stateless provisioning (aka Deployment)

helm upgrade \ 
  --install \
  --create-namespace \
  --namespace dragonfly \
  dragonfly . \
  --values values.yaml \
  --values .values-test.yaml

For stateful deployment (aka StatefulSet)

helm upgrade \ 
  --install \
  --create-namespace \
  --namespace dragonfly \
  dragonfly . \
  --values values.yaml \
  --values .values-test.yaml \
  --set storage.enabled=false

[romange]

Curious, what are the use-cases that may require stateless deployment of Dragonfly? Caching?
What type do you usually use?

[tamcore]

Yep. Lets say you have a cache-heavy Grafana Loki stack. It heavily benefits from having a fast cache backend, but it will still work without it and is pretty fast about refilling it's cache as well. So it'd be a waste of resources (and money - when using a managed kubernetes provider, as you're paying per GB), to deploy Dragonfly in a stateful mode, if it's not really needed.

Additionally, as PersistentVolume reattachments are not instant, as they have to be removed from the previous worker node first, you might lose precious time while waiting for the PersistentVolume become available, before the Dragonfly Pod can be started.

Actually, I think, all of our memcache and redis instances are stateless.

[romange]

what's the reason you separated stuff into lots of tiny files? :)

[tamcore]

For CI. I'm trying to prepare another PR right now, which will make use of helm/chart-testing-action. Helm's ct iterates over the ci subfolder of a chart and tries to provision the chart with each file. That's useful for testing different combinations :)

[romange]

I do not have any comments so if you finished with this PR I can merge 😃

[tamcore]

This PR is finished :) Also opened #622 for the CI testing of the chart. If you're feeling fancy today, then merge 622 first and re-trigger the checks on this one :D

[romange]

@tamcore https://github.com/dragonflydb/dragonfly/actions/runs/3801785982/jobs/6466627069#step:9:75

Also, is it the right place to have the CI as part of our C++ CI? it uses docker images, so what's the point of the CI? Maybe make it part of the release pipeline? or introduce a separate pipeline that is triggered only on helm changes and also runs on docker release?

[tamcore]

On mobile, so only briefly.

The check fails, because Kubernetes doesn't recognize the Pod (v0.12.0 tag) as ready, as it's not able to execute the health/readyness check we've defined in the chart, as that script wasn't included in the container build. This will be fixed with the next Dragonfly release.

We could temporarily update the install step, to null the probes to make the linter happy. But then this change should be reverted after the next Dragonfly release.

As for the inclusion in the main ci workflow, that seemed to be the right place at this point. The C++ checks also run every time an unrelated file gets changed. This one at least skips everything, if no change is detected.

[tamcore]

I've nulled the probes. For now that's fine, as we're only validating that the chart outputs valid Kubernetes resources. At a later point, when potentially trying to include clustering in the chart, the probes might need to be included again.