RFD - Bitnami retention policy considerations

[viniciusdc]

Status	Draft 🚧
Author(s)	@viniciusdc
Date Created	08-12-2022
Date Last updated	08-12-2022
Decision deadline	NA

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

• 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...

Best practices

User impact

Unresolved questions

[viniciusdc]

This may be left as it is if we increase our release schedule, which will give the user freedom to use aways an "up-to-date" version of Nebari.

[Adam-D-Lewis]

I'm cleaning up the RFD's and I'm going to close this for now due to no activity, but feel free to re-open if needed!