Skip to content

allow orchestratord to force a rollout to promote before it's ready #32177

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Apr 14, 2025

Conversation

doy-materialize
Copy link
Contributor

Motivation

this allows us to choose how to resolve a rollout which is stuck or taking too long - we can either cancel the rollout (by resetting the reconciliation_id to the last reconciliation id from the status) or now force it to complete by setting force_promote to the reconciliation_id value.

Tips for reviewer

not planning on porting this to the environment controller since it we're so close to getting rid of it

Checklist

  • This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
  • This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
  • If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
  • If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
  • If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.

this allows us to choose how to resolve a rollout which is stuck or
taking too long - we can either cancel the rollout (by resetting the
reconciliation_id to the last reconciliation id from the status) or now
force it to complete by setting force_promote to the reconciliation_id
value.
// generation to rehydrate before promoting the new environmentd to
// leader.
#[serde(default)]
pub force_promote: Uuid,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this need to be an Option<Uuid> to handle already existing CRs? What does K8S do in cases where a new CRD definition is incompatible with the old stored data?

The #[serde(default)] handles missing data on the controller side, but does K8S even allow you to upgrade the CRD in this way?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as far as i can tell from testing, this works as you would want it to

@doy-materialize doy-materialize merged commit f789b8b into main Apr 14, 2025
82 checks passed
@doy-materialize doy-materialize deleted the push-xspomtxvstww branch April 14, 2025 17:10
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.

2 participants