toggle quoted messageShow quoted text
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.
On Aug 21, 2019, at 4:56 AM, Taylor Thomas <taylor@...
On Tue, Aug 20, 2019 at 10:19 AM Hang Yan <hangyan@...
Of course, this weekend’s developer calls should be ok. Just remember to give me some minutes on the meeting
Ok, I finally had a chance to take a look at this and it looks really good, especially for tracking along with the Helm 3 alpha releases. Is this something you'd like to demo during one of the Helm developer calls? I think it would be
good for others in the community to see it in action
I read through the source yesterday, and this is looking good! Several people from WeaveWorks were interested in pursuing this idea as well. Hopefully some are on this list and may be able to take a look.
Hello everyone, i want to introduce a new project https://github.com/alauda/captain related
to Helm3. It’s a controller based on the helm3 code, and defines several CRDs (HelmRequest, Release, ChartRepo..). At first, we were struggled to deal with the ‘resource conflicts’ problem in helm2, and after some research we thought create a controller based
on the helm3 proposal is a good idea, and we did it. Any suggestions are welcome.