Just a note regarding using Bitnami as the repo source for helm charts, as happened in the past with Minio, they have a 6m retention policy for their repo index, which means that old versions will be dropped from the main index after that period. This is, in the future, our deployments are bound to break if the version is not found by Helm.
User benefit
Right now, we are bound to have broken deployments of the old Nebari versions in the future; as an example, v0.4.0 and v0.4.1 are still (at this date) broken due to the fact these versions have in their source code a pointer to a Minio version that does not exist anymore in the main index.yaml (fixed on v0.4.2).
Design Proposal
Alternatives or approaches considered (if any)
There are some ways to suppress this problem, each one with their pros x cons:
Every six months, we update our chart versions or validate these somehow, originally proposed here
We pin the repository source on each service with the last available hash for the index, the same as we did for Minio
Increase the release schedule to have monthly releases...
Title
Considerations around Bitnami retention policies
Summary
Just a note regarding using Bitnami as the repo source for helm charts, as happened in the past with Minio, they have a 6m retention policy for their repo index, which means that old versions will be dropped from the main index after that period. This is, in the future, our deployments are bound to break if the version is not found by Helm.
User benefit
v0.4.0
andv0.4.1
are still (at this date) broken due to the fact these versions have in their source code a pointer to a Minio version that does not exist anymore in the main index.yaml (fixed onv0.4.2
).Design Proposal
Alternatives or approaches considered (if any)
There are some ways to suppress this problem, each one with their pros x cons:
Best practices
User impact
Unresolved questions