Helm chart collator chart version update handling #164
Assignees
Labels
2-Manifests
Relates to manifest/document set related issues
enhancement
New feature or request
priority/low
Items that are considered non-critical for functionality, such as quality of life improvements
size m
2-5 days [moderate complexity, generic code, or enhancement to existing feature]]
Milestone
Comments
jezogwza
added
2-Manifests
seaneagan
added
the
size m
airshipbot
pushed a commit
to airshipit/images
that referenced
this issue
Jun 11, 2021
This moves to relying on the hcc's default behavior of generating unique chart versions based on the git source so that the versions exposed by the hcc produced chart will change along with the chart's content, so that the flux source controller can be triggered to consume the new version, which is the first step of hcc chart update handling [0]. [0]: airshipit/treasuremap#164 The reason for the patchset dependency below is to ensure this patchset doesn't break treasuremap, so we can account for these (and any other) changes when we are ready to. Depends-On: https://review.opendev.org/c/airship/treasuremap/+/795165 Signed-off-by: Sean Eagan <seaneagan1@gmail.com> Change-Id: I04d6c4c445b44bc62594e26463d66594bddd0b3e
|
Now that https://review.opendev.org/c/airship/images/+/794657 is merged, we just need to update treasuremap to use the unique versions it produced, and document this process, and then we can close this. |
airshipbot
pushed a commit
that referenced
this issue
Jul 13, 2021
- Update the helm-chart-collator image to one which: - uses versions unique to the git source [0] - includes all helm charts used by treasuremap [1] - Rewire all the HelmReleases to point at the hcc HelmRepository - Removes all the other HelmRepositories and associated config [0]: https://review.opendev.org/c/airship/images/+/794657 [1]: https://review.opendev.org/c/airship/images/+/794838 Relates-To: #162 Relates-To: #164 Signed-off-by: Sean Eagan <seaneagan1@gmail.com> Change-Id: Ia96820b627d76feee7909471dd98a27de8594bf1
|
Closed per patchset merge |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Problem description (if applicable)
We are currently exposing hard coded chart versions in the helm collator output image:
https://github.com/airshipit/images/blob/b7d03d4def5c58302c322f94fe5827145f351776/helm-chart-collator/config/charts.yaml#L7
If we update the content without updating the exposed version, then the flux source-controller will have no way to know that it needs to re-download the chart from the helm repository. So we need to at least update the chart versions in the helm collator when they become available. This can be done by using the default unique chart versions generated by the helm chart collator:
https://github.com/airshipit/images/blob/58b69cea414bf799082e0e280041f3f127b8fe72/helm-chart-collator/playbooks/roles/install_git_repo_charts/tasks/main.yaml#L30-L37
For the helm chart version used in the HelmReleases, we could leave them unset, in which case the source-controller will use the latest version, which it should discover the new version each time it re-indexes the HelmRepository, which it does on a configurable time interval. This would mean though that the HelmRelease may get reconciled at an arbitrary time, separate to the update that will happen if/when the HelmRelease itself gets updated with e.g. new values overrides.
So in order to ensure a single coordinated update to the HelmRelease with the new chart version, we would want to set the version explicitly to the unique one generated by the helm chart collator referenced above in each HelmRelease (still via the ReplacementTransformer). The helm-chart-collator image build does output the generated versions in its logs, but we should output them to an more easily consumable file, likely can just store the helm repo index file in the zuul build output. Then in order to consume this new helm chart collator version in e.g. treasuremap, these values would need to be manually copied to the versions catalogue (at least for the charts that changed). Or we could perhaps try to automate the updating of the versions catalogue by downloading the configured helm collator image, extracting the helm repo index, translating it into versions catalogue format, and writing that to the appropriate location in the manifests, which may be easier if we moved the chart versions to their own catalogue.
The text was updated successfully, but these errors were encountered: