Skip to content

controllers: set Complete condition on terminal RollingUpgrade states#556

Open
SAY-5 wants to merge 2 commits into
keikoproj:masterfrom
SAY-5:fix/rollingupgrade-complete-condition-321
Open

controllers: set Complete condition on terminal RollingUpgrade states#556
SAY-5 wants to merge 2 commits into
keikoproj:masterfrom
SAY-5:fix/rollingupgrade-complete-condition-321

Conversation

@SAY-5

@SAY-5 SAY-5 commented Apr 20, 2026

Copy link
Copy Markdown

Description

The controller sets .status.currentStatus when a RollingUpgrade reaches a terminal state (success or failure) but never touches .status.conditions. That keeps kubectl wait rollingupgrade/x --for condition=Complete blocked until timeout even after the upgrade has already finished. The CRD already declares Conditions []RollingUpgradeCondition and UpgradeComplete as a type, so the plumbing exists, it's just not being written.

The reporter notes the behaviour regressed between 0.13 (conditions were set) and 1.0.4 (conditions are not).

Fixes #321.

Change

  • controllers/upgrade.go:
    • On the "scaling group is no longer drifted" branch (line ~121), in addition to SetCurrentStatus(StatusComplete), emit Status.SetCondition({Type: UpgradeComplete, Status: ConditionTrue}).
    • On the Cloud.Discover failure branch, emit Status.SetCondition({Type: UpgradeComplete, Status: ConditionFalse}).
  • controllers/rollingupgrade_controller.go:
    • On the RotateNodes failure branch (line ~227), emit the same ConditionFalse variant alongside the existing SetCurrentStatus(StatusError).

RollingUpgradeStatus.SetCondition already upserts by type, so re-entry is a no-op.

Testing

  • make test passes locally.
  • Manually exercised:
    • Successful rollout: .status.conditions[?(@.type==\"Complete\")].status now flips to "True" at completion; kubectl wait --for condition=Complete returns immediately.
    • Discover/RotateNodes failure: the same condition lands with "False", so --for condition=Complete=False also works.

Checklist

  • I've read the CONTRIBUTING doc
  • I've run make test locally and all tests pass
  • I've signed-off my commits with git commit -s for DCO verification
  • Code follows the style guidelines of this project

@SAY-5 SAY-5 force-pushed the fix/rollingupgrade-complete-condition-321 branch from df14921 to 5ae0076 Compare May 31, 2026 02:40
@SAY-5 SAY-5 requested review from a team as code owners May 31, 2026 02:40
The controller writes .status.currentStatus on completion and
failure but never touches .status.conditions, so
`kubectl wait rollingupgrade/x --for condition=complete` never
observes a transition and times out even though the resource has
already reached a terminal state (keikoproj#321). The behaviour regressed
somewhere between 0.13 and 1.0.4.

Set a RollingUpgradeCondition of Type UpgradeComplete alongside the
existing SetCurrentStatus calls:

  * ConditionTrue when the scaling group is no longer drifted,
  * ConditionFalse on Cloud.Discover / RotateNodes failure.

The condition list already exists in the CRD and SetCondition
upserts rather than duplicates, so existing callers just start
seeing the condition flip through.

Signed-off-by: SAY-5 <SAY-5@users.noreply.github.com>

Fixes keikoproj#321

Signed-off-by: Sai Asish Y <say.apm35@gmail.com>
@SAY-5 SAY-5 force-pushed the fix/rollingupgrade-complete-condition-321 branch from 3453dc3 to 30acac7 Compare June 2, 2026 21:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Condition not set for RollingUpgrade upon completion

1 participant