12 Commits (ff4877e69634d659d1949bd27fe313dcd589af61)

Author	SHA1	Message	Date
Matt Farina	c042264a9d	Fix issues when verify generation readiness was merged ... CI, tests, and building failed after #10920 was merged. This change fixes the issues that were introduced. Signed-off-by: Matt Farina <matt.farina@suse.com>	12 months ago
Matt Farina	b299359f66	Merge pull request #10920 from muang0/readiness-generation-check ... Verify generation in readiness checks	12 months ago
Joe Julian	99e1dce8c8	Merge pull request #9950 from jeffrosenberg/error-on-failed-jobs-9285 ... Throw an error from jobReady() if the job exceeds its BackoffLimit	1 year ago
Joe Julian	dcd54d59e6	Merge branch 'main' into readiness-generation-check ... Signed-off-by: Joe Julian <me@joejulian.name>	2 years ago
Aman Nijhawan	eea2f27bab	Fixes Readiness Check for statefulsets using partitioned rolling update. (#11774) ... * Fixes Readiness Check for statefulsets using partitioned rolling update. Fixes #11773 This change updates readiness check in ready.go to correctly account for statefulsets that are utilizing a partitioned upgrade. These statefulsets only upgrade a subset of the managed pods with each call to helm upgrade. This causes the upgrade to legitimately hit the condition where sts.status.CurrentRevision != sts.Status.UpdateRevision which causes helm to mark the upgrade has failed when in fact it is successful. This change fixes that behavior to only check when partition is unspecified or 0. Signed-off-by: Aman Nijhawan <anijhawan@yugabyte.com> * Adding a unit test to verify that partitioned rolling upgrade for a statefulset works. Signed-off-by: Aman Nijhawan <anijhawan@yugabyte.com> --------- Signed-off-by: Aman Nijhawan <anijhawan@yugabyte.com> Co-authored-by: Aman Nijhawan <anijhawan@yugabyte.com>	2 years ago
Dominic Evans	7c74f1dd02	fix: improve logging & safety of statefulSetReady ... Confirm that the current and updated revision numbers also match as part of the readiness check. Add coverage for readiness scenarios where StatefulSet status does not reflect the most recent generation of the StatefulSet yet. Also add additional logging around the sts transitions from non-ready to ready. Fixes: #10163 Signed-off-by: Dominic Evans <dominic.evans@uk.ibm.com>	3 years ago
James Oden	d94c5094f6	Verify generation in readiness checks ... Signed-off-by: James Oden <james.oden.dev@gmail.com>	3 years ago
Bhavin Gandhi	c3310bb724	fix(pkg/kube): statefulSetReady: handle partition cases correctly ... The partition value can be greater than number of replicas, in that case no pods are rolled out. The expectedReplicas becomes a negative number. https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#partitions In the cases where the update does not change anything in the pod template, the updatedReplicas value from StatefulSet status remains unchanged. Such updates can still set some partition value, and UpdatedReplicas is always greater than expectedReplicas. Basically, the StatefulSet is ready / rolled-out. In both the above scenarios, providing `--wait` flag causes it to timeout waiting indefinitely. Because updatedReplicas can never be negative, or be equal to the expectedReplicas for the second case. This commit handles both the scenarios by checking if UpdatedReplicas is smaller than expectedReplicas. If it is, then the StatefulSet is not ready yet. Based on the code from kubectl rollout: a450ebd59c/pkg/polymorphichelpers/rollout_status.go (L138-L141) Closes #8674 Signed-off-by: Bhavin Gandhi <bhavin7392@gmail.com>	3 years ago
Jeff Rosenberg	b13f3a13d4	Merge branch 'main' into error-on-failed-jobs-9285	3 years ago
lsowen	249d1b5fb9	Fix SIGSEGV when job.Spec.Completions is nil ... Signed-off-by: lsowen <logan@s1network.com>	3 years ago
Rosenberg, Jeff	cd04e3f418	Throw an error from jobReady() if the job exceeds its BackoffLimit ... Closes #9285 Signed-off-by: Rosenberg, Jeff <jeff.rosenberg@icfnext.com>	3 years ago
Joe Lanford	98d98369ed	Add ReadyChecker to decouple ready check logic from --wait ... Signed-off-by: Joe Lanford <joe.lanford@gmail.com>	4 years ago