Hello helm

[didierofrivia]

This PR introduces a way to manage a Limitador Operator Helm Chart. This is not meant to replace the way we are building and delivering our manifests (Kustomize, OLM) but to provide an alternative (complementary) way of delivering the operator.

This early implementation uses Kustomize to create the chart template, instead of creating and maintaining new ones with Helm, to later customize the Helm only settings with its values.yaml

NOTES

• This chart (and every other operator chart we package in the future: Authorino, DNS, etc) bundles only the operator in the same fashion OLM does.
• The operator version matches the chart version
• This first release doesn't use helm templating, it provides only the manifests previously built by Kustomize.
• The sole repository for all our operator charts will be hosted in Kuadrant/helm-charts.
• The "source of truth" (source code and releasing logic) will be provided in each operator repo, not in the helm charts repository above.
• The release workflow is not fully automated yet, just exposing workflow_dispatch it will change in the near future.
• The PR related for the repository is WIP
• Documentation will be provided once the repository and other operator charts are tested.
• The steps to try out the repository will be provided in the kuadrant helm charts repo.

TODO

• Build manifests with Kustomize
• Install/Uninstall and Upgrade targets
• Adjust Charts mandatory settings
• Decide on chart versioning (if matching operators or keep its own) ---> Same as OLM, same as Operator image
• Github workflow for release package

Verification Steps

1. Create a local kind cluster

make kind-create-cluster

2. Deploy (install) the default (latest) Limitador Operator chart

make helm-install

3. Verify the installed operator image:

kubectl get deployments/limitador-operator-controller-manager -n limitador-operator-system -o yaml | grep image:

it should return:

image: quay.io/kuadrant/limitador-operator:latest

4. Build new manifests with specific version of the operator

make helm-build \
            VERSION=0.9.0 \
            LIMITADOR_VERSION=1.4.0

5. Upgrade the current installed operator to the freshly built one

make helm-upgrade

6. Check the installed operator image:

kubectl get deployments/limitador-operator-controller-manager -n limitador-operator-system -o yaml | grep image:

it should return:

image: quay.io/kuadrant/limitador-operator:v0.9.0

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.70%. Comparing base (9187002) to head (25f5aed).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #137      +/-   ##
==========================================
- Coverage   85.51%   84.70%   -0.81%     
==========================================
  Files          19       19              
  Lines         994      994              
==========================================
- Hits          850      842       -8     
- Misses         94       98       +4     
- Partials       50       54       +4     

Flag	Coverage Δ
integration	78.67% <ø> (-1.21%)	⬇️
unit	66.51% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
api/v1alpha1 (u)	100.00% <ø> (ø)
pkg/helpers (u)	83.87% <ø> (ø)
pkg/log (u)	94.73% <ø> (ø)
pkg/reconcilers (u)	74.67% <ø> (ø)
pkg/limitador (u)	98.11% <ø> (ø)
controllers (i)	74.33% <ø> (-2.67%)	⬇️
pkg/upgrades	88.88% <ø> (ø)

see 1 file with indirect coverage changes

[eguzki]

looking good so far!

[eguzki]

@ficap join forces here Kuadrant/installation#1

[eguzki]

overall looks good to me.

few comments dropped, though, for further discussion.

[eguzki]

I feel like we should not be doing this. The git commit (or tag) we are releasing should have done previously make helm-build. Any thought?

[didierofrivia]

Yes, I was thinking it should be part of the building manifests steps just before tagging... However, just a reminder that currently we do that manually before tagging and then let the CI to build the manifests again and publish them to Quay... meaning it's kind of the same in this case, we could run this target and commit it with the rest of the manifests when releasing... but having a separated workflow is convenient when you want to attach charts to other already released operators. What do you reckon?

[eguzki]

currently we do that manually before tagging and then let the CI to build the manifests again and publish them to Quay.

Isn't that redundant? What I would do, maybe, it is a test to run (on release event) make helm-build and check that no files changed. Same we do with go generate or make bundle.

having a separated workflow is convenient when you want to attach charts to other already released operators

Not sure I follow.

Anyway, I was not asking for changes actually. Whatever you decide is ok for me on this regard.

[didierofrivia]

I agree with you, we'll need to address the redundancy in our workflows, part should be reflected in Kuadrant/architecture#41