chore: add helm chart support (PoC)

[philipp-hinteregger]

This PR

• is a PoC for Research: Automation of Helm Chart releases and maintenance #426

Questions from the Issue

can we fully generate a helm chart through kustomize?

• Yes, it is possible to generate a Helm Chart with Kustomize, as shown in this PR

should we combine kustomize with helm or can we maybe replace kustomize with helm?

• If we take something like Google Trends into consideration, it might make sense to adopt Helm for a second release strategy at some point, since it's more popular than Kustomize, according to the Google Trends search. Also the current release strategy is using Kustomize to create the manifest files, that are being uploaded to the GitHub release. This PoC uses Kustomize to generate the Helm chart, so it would take additional overhead to replace every configuration that relates to Kustomize, with the respective Helm configurations. Compared to the expected outcome, this might not be a viable solution. Since a working solution for Kustomize already exists, it would make sense to keep it, and rather consider the idea of adopting Helm as an additional release strategy.
• The prioritization might be an important factor for this decision, since a significant criteria for using Helm would be the ability to customize the chart for the user needs. But the KLT doesn't provide/need much of customization just yet. What's also worth mentioning at this point is, that this approach also carries some risk of unintentionally breaking the Helm installation. E.g. by changing the default manifests in a way that Kustomize patches aren't able to match their required target, thus failing the generation of the Helm chart.

if we combine kustomize with helm, how would that affect the future maintainability of the project?

• The complexity of releasing the project will grow, since changes can affect both, the release with Kustomize as well as Helm. Fortunately it's possible to use the same base, so most of the time additional changes for Helm won't be necessary.
  It's possible that in the future some Kustomize patches would be required, adding more complexity than this example. This adds a lot of complexity and will have an impact on the maintainability.

how would the process look like when a user requests a feature for the helm chart, e.g. a new helm value?

• adapt the overlays/helm/kustomization.yaml, e.g. namespace like in this example
• add a respective templating function in the _helpers.tpl file
• provide default values in the values.yaml file

This will use the rendered mainfest file and replace the values defined in the kustomization.yaml with the respective templating functions of the _helpers.tpl. While rendering the chart, Helm will replace the templating values with the values provided in the values.yaml file. However, this is a rather simple example. A rather complex approach is using Kustomize patches. In that case, a respective patch file needs to be created (like in this PoC) to match the required resource and the target property.

should we maintain 2 types of how to install the KLT? (manifests/helm)

• Depends on the overall goal of the project. It's possible to maintain either of those or both. Although maintaining both options, adds a layer of complexity.

if we decide to use helm, should we keep the charts in the same project, or create a separate project for the helm charts and maintain them there?

• The main problem lies within the versioning strategy. There's the option to hold the chart version in sync with the application version, or using a separate version for Helm charts. If the chart version is kept in sync, there won't be a need to extract the chart into it's own repository. However, if the Helm charts are tracked with their own version number, the risk occurs that changes might happen within the chart, without bumping the chart version. In that case it might be easier to track changes for the chart within a separate repository. It might be worth mentioning, that the second approach might also add a little bit of complexity, since the release process between the application and the Helm chart might be asynchronous. (further reading)

Signed-off-by: Philipp Hinteregger philipp.hinteregger@dynatrace.com

[codecov]

Codecov Report

Merging #489 (69fab0e) into main (145a6ab) will decrease coverage by 10.75%.
The diff coverage is n/a.

Additional details and impacted files

@@             Coverage Diff             @@
##             main     #489       +/-   ##
===========================================
- Coverage   59.54%   48.78%   -10.76%     
===========================================
  Files          28       55       +27     
  Lines        2101     5143     +3042     
===========================================
+ Hits         1251     2509     +1258     
- Misses        745     2527     +1782     
- Partials      105      107        +2     

Impacted Files	Coverage Δ
operator/controllers/common/evaluationhandler.go	78.07% <0.00%> (-0.57%)	⬇️
operator/api/v1alpha2/common/common.go	100.00% <0.00%> (ø)
operator/api/v1alpha2/keptnapp_types.go	91.66% <0.00%> (ø)
operator/api/v1alpha2/keptnapp_conversion.go	0.00% <0.00%> (ø)
...ator/api/v1alpha2/keptnevaluationprovider_types.go	100.00% <0.00%> (ø)
operator/api/v1alpha1/common/phases.go	100.00% <0.00%> (ø)
...or/api/v1alpha2/keptnevaluationdefinition_types.go	100.00% <0.00%> (ø)
operator/api/v1alpha1/keptnworkload_types.go	92.00% <0.00%> (ø)
operator/api/v1alpha2/keptnevaluation_types.go	96.92% <0.00%> (ø)
operator/api/v1alpha1/keptnevaluation_types.go	96.92% <0.00%> (ø)
... and 18 more

Flag	Coverage Δ
component-tests	50.88% <ø> (+0.12%)	⬆️
keptn-lifecycle-operator	47.27% <ø> (-9.38%)	⬇️
scheduler	4.52% <ø> (ø)

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

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication