This commit introduces a slight change to the CRD chart templates in order to only run the check for whether CRDs exist in the cluster when a user uses `helm install`. On a `helm template`, no error will ever be thrown and on a `helm install --dry-run`, an error will only be thrown if the CRD is required as part of the chart installation (which is the default behavior of --dry-run either way).
The way it accomplishes this is by using the Helm lookup function; based on the [Helm 3 docs](https://helm.sh/docs/chart_template_guide/functions_and_pipelines/), the lookup function never gets called on a `helm install --dry-run` or a `helm template`, so the output of the lookup function will always be nil for those requests (i.e. the number of ClusterRoles returned will always be 0).
However, Kubernetes clusters have default ClusterRoles, so this ensures that CRDs are installed if at least one ClusterRole is returned (i.e. the most common setup).
This commit adds a new flag to the experimental feature of generating a CRD chart for charts that need to be able to assume the ownership of any existing CRDs within a cluster. It also modifies the existing `prepare-crd` script to use template files stored in the `./scripts/chart-templates/` directory instead of utilizing numerous `cat` commands in order to achieve the same result.
Feature charts with this flag enabled will differ from the normal CRD chart in the following ways:
- Instead of having CRDs from `crd/` in `templates/`, they will be relocated to `crd-manifest/`.
- On render, the CRDs in `crd-manifest` are placed into a ConfigMap that will be deployed on the cluster.
- On install / upgrade / rollback, a pre-install / pre-upgrade / pre-rollback hook Job that does a `kubectl apply -f` on the manifest within the crd-manifest ConfigMap (with appropriate RBAC credentials via a ServiceAccount, CRB, and ClusterRole) will install the CRDs onto the cluster.
- On uninstall, a delete hook Job does a `kubectl delete -f` on the manifest within the crd-manifest ConfigMap (with the same RBAC credentials) to remove the CRDs from the cluster.
At the moment, this will only be used by the `rancher-monitoring` chart.
Related Issue: https://github.com/rancher/rancher/issues/28326
By utilizing the `clean-crds` script, both `validate` and `clean` can cleanly deal with issues related to annotations added and files overlaid as part of the CRD chart process.
This commit deprecates the providesGVR flag used by charts in favor of charts adding this annotation directly to the patch of their chart (or their Chart.yaml).
Before, the logic for reverting a CRD chart was located in `generate-patch` since it was the only script that required these changes. Now that the same logic is required on a `make clean` in order to support reverting just the generateCRDChart changes from local charts, this commit moves that logic out to its own script `clean-crds`.
Based on discussion in https://github.com/rancher/charts/pull/607#discussion_r483288658.
This commit adds the ability to add patches on subcharts in `rancher/charts` that meet the following constraints:
- Must be a remote chart (i.e. the repo url cannot point to a `file://<path>`)
- Must have a fixed version number (since we need a consistent base to apply the patch on)
The following changes have been made to the scripts to faciliate this feature:
**prepare**
Only run the patch after preparing the subchart
**prepare-subcharts:**
Inital checks:
1. We only prepare the subcharts if the chart has a `requirements.yaml`.
2. Extract the patches that would be applied to the requirements.yaml and only apply that
Note: in the future, we need to add support for dependencies outlined in the Chart.yaml directory, which is currently the recommended approach for Helm 3 charts that use `apiVersion: v2`, but since none of our charts currently use that it is assumed that they will encode their dependencies in a `requirements.yaml` at the moment.
Generate special dependencies (overlay, package.yaml):
1. For dependencies that are mirrored (i.e. rancher-kiali-server, where the dependency itself is stored as a `package.yaml`) that have not generated a `charts/` directory yet, we recursively run the `prepare` script for them in order to generate the directories so that `helm dependency update` can pull them in. The assumption here is that there will be no circular dependencies, although there is no explicit check for this.
2. For dependencies that are overlaid, we perform the overlay so that `helm dependency update` operates as expected.
Pull in latest subcharts and update files:
1. Perform `helm dependency update` to update the `requirements.yaml` and `requirements.lock` with the latest subchart versions
Cleanup (overlay, package.yaml, patched requirements)
1. Remove overlaid dependencies since they won't be tracked in the patch
2. Run the `clean` script on the mirrored dependencies
3. Revert the patch on the requirements.yaml
Apply logic to enable / disable patching:
1. If a subchart is a local chart, leave it as a tgz so it will be ignored on patch
2. If a subchart does not have a fixed version number, leave it as a tgz so it will be ignored on patch
3. If neither of these are true, unarchive the tgz for the subchart and delete the tgz so it will be tracked by the patch
NOTE: since the dependency still exists as either a tgz or a directory, `generate-charts` will not break from this change.
**generate-patch:**
Loop through the local `charts/requirements.yaml` to update the `charts-original/charts` directory:
1. If a subchart is not a local chart, remove it as we don't need to check for patches against it
2. If a subchart does not have a fixed version number, remove it as we don't need to check for patches against it
3. If neither of these are true, pull in the version number specified from the remote helm repo to track patches against it.
**Why does the version number need to be fixed?**:
In general, Helm chart owners can use wildcards within a `requirements.yaml` to specify the version of a subchart when a specific patch version does not necessarily need to be fixed. This is usually a great feature since that means that parent charts do not need to be updated in order for a `helm dependency update` to automatically pull in the latest versions of a dependency that do not break the parent chart; however, this causes an issue with patching subcharts since the base that the patch is applied on is not fixed.
Therefore, this commit only allows users to apply patches on subcharts that have a fixed subchart version specified in their `requirements.yaml`.
**Why can't we track local charts?**
If the chart is local to this repo, the assumption is that you should directly be making the changes to the chart.
This commit splits the subchart logic from the `prepare` script into a separate `prepare-subcharts` script and slightly modifies the prepare logic to generate CRD charts only after preparing subcharts and applying the patch file.
Venkata Krishna Rohit Sakala
Lucas Lopes
Lucas Machado
Steven Crespo
Mauren Berti
Arvind Iyengar
Caleb Bron
Caleb Bron
Daishan Peng
Daishan
aiyengar2
Brenda Rearden