@@ -44,10 +44,14 @@ After implementation, the --timout parameter will be stored in the helm release
44
44
have an indirect impact on possible parallel processes.
45
45
46
46
` helm ls -a ` shows two new columns, regular ` helm ls ` does NOT show those:
47
- - LOCKED TILL
48
- <datetime > calculated by the helm client: k8s server time + timeout parameter value
49
- - SESSION ID
50
- Unique, random session id generated by the client
47
+ - ` LOCKED TILL `
48
+ datetime calculated by the helm client: current time + timeout parameter value
49
+ Originally k8s server time was intended as "current time", but since helm exclusively uses the
50
+ client time everywhere else, we do not change that via this HIP, such a refactoring would need
51
+ to be performed via a separate HIP against the entire codebase.
52
+ - ` SESSION ID `
53
+
54
+ Unique, random session id generated by the client.
51
55
52
56
Furthermore, if the helm client process gets killed (SIGTERM), it tries to clear the LOCKED TILL value,
53
57
SESSION ID and sets the release into a failed state before terminating in order to free the lock.
88
92
- [ ] HIP status `accepted'
89
93
- [x] Reference implementation
90
94
- [x] Test for concurrent upgrade (valid lock should still block concurrent upgrade attempts)
91
- - [ ] Test for kill scenario (forever stuck in pending)
95
+ - [x] Test for upgrading from pending state
96
+ - [x] Test for upgrading from failed state
97
+ - [ ] Decision: Helm ls -> which flag should show the new fields ` LOCKED TILL ` and ` SESSION ID ` ?
98
+ - [ ] Decision: k8s Lease object vs helm relesae secret for storing the ` LOCKED TILL ` and ` SESSION ID `
92
99
- [ ] Backwards compatibility check (looking good already)
100
+
101
+ ## References
102
+
103
+ https://github.com/helm/helm/issues/7476
93
104
https://github.com/rancher/rancher/issues/44530
94
105
https://github.com/helm/helm/issues/11863
0 commit comments