[GREP-291] OnDelete implementation for standalone PodCliques and PodCliqueScalingGroups#438
Conversation
b6b43a8 to
b4f05da
Compare
40e3c45 to
e1ba9ba
Compare
|
All E2E tests are failing currently due to: Tests passed pre-rebase. Will wait and re-trigger. |
Code Review — Combined CodeRabbit + Manual AnalysisCriticalNil pointer dereference on The OnDelete code paths bypass the nil guard that protects the RollingRecreate path, causing a panic if
Suggested fix: Add a nil guard on Suggestions
|
|
@Ronkahn21 I've fixed all suggestions posted in your comment. However, I don't know how to go about fixing the following suggestion:
The event object only contains the PCS, not the PCSG. We don't really have access to that resource in the watcher on PCS. |
|
@renormalize I think for now we could ignore the comment, I will try to finish the review the fix today |
|
@unmarshall I've not yet rebased on the latest changes in master since that will make it harder to review the changes I made to address the PR feedback. Will rebase at the end of the PR. |
Signed-off-by: Saketh Kalaga <saketh.kalaga@sap.com>
Signed-off-by: Saketh Kalaga <saketh.kalaga@sap.com>
Signed-off-by: Saketh Kalaga <saketh.kalaga@sap.com>
… events * PodCliqueSet update events when the update strategy is `OnDelete` will enqueue corresponding events for PodCliqueScalingGroup resources. Signed-off-by: Saketh Kalaga <saketh.kalaga@sap.com>
* Support `OnDelete` in update logic * Fix unsatisfied expectation on PodCliqueSet delete Signed-off-by: Saketh Kalaga <saketh.kalaga@sap.com>
* `RollingUpdateProgress` structs are reintroduced fully and not made aliases of `UpdateProgress` since we intend to discourage usage of `RollingUpdateProgress`, and any new field introduced to `UpdateProgress` should not be introduced to `RollingUpdateProgress` as well, as there might be cases where consumers continue to use the old struct with newly introduced fields. Signed-off-by: Saketh Kalaga <saketh.kalaga@sap.com>
Signed-off-by: Saketh Kalaga <saketh.kalaga@sap.com>
…or backwards compatibility Signed-off-by: Saketh Kalaga <saketh.kalaga@sap.com>
…ues in-place for `OnDelete` * PodCliques that belong to PodCliqueScalingGroups can be updated through the OnDelete strategy by deleting member pods of the PodCliques. This is achieved by updating the specifications of the PodCliques in-place, similar to how it is done already for standalone PodCliques. Signed-off-by: Saketh Kalaga <saketh.kalaga@sap.com>
* `initOrResetUpdate()` is introduced for PodCliqueScalingGroup making it consistent with the other controllers. * Correct comments in PodClique reconcilespec. Signed-off-by: Saketh Kalaga <saketh.kalaga@sap.com>
Signed-off-by: Saketh Kalaga <saketh.kalaga@sap.com>
…h the PodClique's Signed-off-by: Saketh Kalaga <saketh.kalaga@sap.com>
Signed-off-by: Saketh Kalaga <saketh.kalaga@sap.com>
Signed-off-by: Saketh Kalaga <saketh.kalaga@sap.com>
Signed-off-by: Saketh Kalaga <saketh.kalaga@sap.com>
Signed-off-by: Saketh Kalaga <saketh.kalaga@sap.com>
…tions, add unit tests Signed-off-by: Saketh Kalaga <saketh.kalaga@sap.com>
Signed-off-by: Madhav Bhargava <madhav.bhargava@sap.com>
Signed-off-by: Saketh Kalaga <saketh.kalaga@sap.com>
…iqueSet Signed-off-by: Saketh Kalaga <saketh.kalaga@sap.com>
…`PodCliqueScalingGroup`s (ai-dynamo#438) * Introduce `PodCliqueSetUpdateStrategy` * Introduce `UpdateProgress` which eventually will replace `RollingUpdateProgress` * Enhance update logic to support `OnDelete` * Modify `PodCliqueScalingGroup` controller to update all replica `PodClique`s in-place for `OnDelete` * `PodClique`s that belong to `PodCliqueScalingGroup`s can be updated through the `OnDelete` strategy by deleting member pods of the `PodClique`s. This is achieved by updating the specifications of the `PodClique`s in-place, similar to how it is done already for standalone `PodClique`s * Introduce unit tests for changes made for OnDelete * Modify the deletion sorter to prefer pods with specs that do not match the `PodClique`'s * Make `CurrentlyUpdating` a slice of `PodCliqueSetReplicaUpdateProgress` * Fix possible nil panics, and typos in comments --------- Signed-off-by: Saketh Kalaga <saketh.kalaga@sap.com> Signed-off-by: Madhav Bhargava <madhav.bhargava@sap.com> Co-authored-by: Madhav Bhargava <madhav.bhargava@sap.com> Signed-off-by: Erez Freiberger <enoodle@gmail.com>
What type of PR is this?
What this PR does / why we need it:
/kind api feature
This PR introduces the implementation for the
OnDeleteupdate strategy as proposed in the GREP #403.Which issue(s) this PR fixes:
Fixes #291
Special notes for your reviewer:
I have not yet finished unit tests and E2E tests. I'm planning to bring along the unit tests in this PR itself, and the E2E tests in a subsequent PR.
Does this PR introduce a API change?
Additional documentation e.g., enhancement proposals, usage docs, etc.: