#1993 : Pass big bang values through to package charts

General MR

Summary

This MR duplicates the logic currently present in the wrapper chart for presenting bigbang variables in the wrapped package's value space, and provides the same functionality to user defined or community supported packages that do not use the wrapper.

Before this patch, this (intentionally simple and contrived) test case would technically succeed when not using the wrapper:

networkPolicies:
  enabled: true
  controlPlaneCidr: 192.168.254.0/24
packages:
  jira:
    wrapper: false
    enabled: true
    values:
      networkPolicies:
        controlPlaneCidr: "{{ .Values.networkPolicies.controlPlaneCidr }}"      

... The chart will successfully render, but deployment will fail because the value is empty:

NetworkPolicy.networking.k8s.io "egress-kube-api" is invalid: spec.egress[0].to[0].ipBlock.cidr: Required value

This is because (as pointed out in #1993 (closed)) the wrapper chart has logic to merge bigbang values into the package values under a toplevel bigbang: key, while the bare package chart does not. By updating the package {{ $pkg }}-values and {{ $pkg }}-wrapper-values secret generators, and abstracting the wrapper value generation logic into a helm template that we can re-use in the package generator, we can get the same behavior in both locations, so that now we can:

networkPolicies:
  enabled: true
  controlPlaneCidr: 192.168.254.0/24
packages:
  jira:
    wrapper: false
    enabled: true
    values:
      networkPolicies:
        controlPlaneCidr: "{{ .Values.bigbang.networkPolicies.controlPlaneCidr }}"  

The discussion of "why use a toplevel bigbang key, why not just merge the roots together?" has already been discussed when this functionality was built into the wrapper chart and so isn't debated here. TLDR - because there are things in the toplevel of the package value space and the bigbang value space (like openshift) that are incompatible in type and usage pattern. Separation is necessary.

Relevant logs/screenshots

This is proven effective with a chart generation using my jira override from my dotfiles and comparing the results. Here is a summary of the test results:

branch	wrapper?	result file	result md5sum
master	no	master-nowrapper-values.yaml	e9bf50493dd13d50ac7b2f37ac048e54
1993_package_bbvars_passthrough_opt2	no	1993-nowrapper-values.yaml	72f5fc5de7f4e5d4a4b69bb1e82d827e
master	yes	master-wrapper-values.yaml	5da70c0350bd5686dfde934c54b978da
1993_package_bbvars_passthrough_opt2	yes	1993-wrapper-values.yaml	5da70c0350bd5686dfde934c54b978da

This tells us that the new code produces identical values for the wrapper as the master branch. This proves that the new values-bigbang helper method produces identical output to the previous version.

However we need to prove that the output of the new toplevel bigbang: map entry is identical in the wrapper and non-wrapper versions. We can use yq to extract the bigbang data, sort it, and md5sum it from both versions:

$ cat 1993-nowrapper-values.yaml | yq '.stringData.*' | yq -P '.bigbang | sort_keys(..)' | md5sum
02bde2050f9a6933f4b2b980de9fb777  -
$ cat 1993-wrapper-values.yaml | yq '.stringData.*' | yq -P '.bigbang | sort_keys(..)' | md5sum
02bde2050f9a6933f4b2b980de9fb777  -

Linked Issue

Closes #1993 (closed)

Upgrade Notices

N/A