Re: A Helm3 Controller
|
Hang Yan
We have encounter one design issue that is hard to decide: rollback
In helm2, it’s easy to do, because all the states are stored in Release. But in Helm3’s CRD, it’s both stored in HelmRequest and Release. It will cause inconsistent
if we still rollback the release object, because we also need to find a way to update the HelmRequest. It’s especially hard after we add support for multi cluster, which the release object and HelmRequest may not exist in the same cluster.
If we do this the kubernetes way, like Deployment, it’s history is in the
ReplicaSet object, then we will need to have a CRD like HelmRquestHistory, thus the Release Version object will be totally useless, one release would be sufficient for on HelmRequestHistory. I think the Helm3 Design proposal should consider this again.
|
|
|