Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
chart version range specifications #62
In order to keep a Chart ecosystem healthy, it is important for some range of Chart updates to be applied quickly and consistently. Encoding a specific version into Application objects and then updating it with every change means that new versions are unlikely to be applied across the whole population of Application objects: the Chart maintainers might release a new version, but only some Application owners will action the upgrade, which represents toil for them.
To address this, we think it makes sense for Shipper to develop the ability to work with semver version range specifications for Charts. In this way, Application owners can specify a version constraint that they're comfortable with (for example, upwards float on minor or bugfix versions), and get those updates automatically.
Allow a version range specification as part of the
Release will not support version range constraints: Releases must always have a concrete version. This ensures that aborts and rollbacks always go back to a predictable version. Version range resolution is a feature of the higher level Application interface.
Become a real Helm repo client
In order to resolve the version range spec, Shipper will need to become a fully fledged Helm repo client which processes
Shipper should check for an updated
Robustness to repo unavailability
Shipper currently caches Charts aggressively. This is in order to prevent rollouts with a previously-deployed Chart from failing due to a broken Chart repository. We want to maintain this property as much as possible: we'd like to avoid going over the wire to contact the chart repo unless absolutely required. As such:
This means that a version range resolution may not return the latest possible version if the Chart repo is down. In this case Shipper should indicate the resolution failure or fallback using a Condition on the Application (or similar).
It is worth to mention that in the case of a rollback that the user is responsible for adding a range specification for the next rollout, otherwise the Application's chart will be pinned (resolved to a single version) for subsequent rollouts and this might not be what the user expects.
Regarding helm repo availability, what about supporting having a docker registry and helm repo per cluster by allowing some king of pattern or templating in the manifest? For example having an https://github.com/goharbor/harbor on each application cluster being synced from another one running on the manager cluster?
release-0.5 exposed a significant flaw in the implementation. In the worst case scenario application releases were re-creating by Shipper uncontrollably causing an extensive resource consumption. The root cause is in the env hashing strategy: in the proposed solution app.spec.template.chart.version stays the original one (read: unresolved), whereas the release.spec.environment.chart.version contains a resolved chart version. On a resync cycle Shipper detected env hash mismatch between the app and the contender and decided to create another release right away. The history repeats until the resource limit is exhausted.
I'm reopening this issue for the sake of connecting it to an upcoming release. Once the development group is convinced on the newly proposed implementation, we can close this issue "for real".
The recent release 0.5.0-alpha.4 is closing this issue (https://github.com/bookingcom/shipper/releases/tag/v0.5.0-alpha.4)