-
Notifications
You must be signed in to change notification settings - Fork 117
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
Consolidate updateAwaitConfig/createAwaitConfig #3139
Conversation
49579dd
to
1d398f2
Compare
edfb8bf
to
30d4147
Compare
Does the PR have any schema changes?Looking good! No breaking changes found. |
5322331
to
b1d2cfb
Compare
30d4147
to
3fc61eb
Compare
This change is part of the following stack: Change managed by git-spice. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #3139 +/- ##
==========================================
+ Coverage 36.34% 36.53% +0.18%
==========================================
Files 70 70
Lines 9258 9230 -28
==========================================
+ Hits 3365 3372 +7
+ Misses 5556 5527 -29
+ Partials 337 331 -6 ☔ View full report in Codecov by Sentry. |
b1d2cfb
to
6383aa6
Compare
f702f3d
to
535ace3
Compare
oldSpec, _ := openapi.Pluck(c.lastOutputs.Object, "spec") | ||
newSpec, _ := openapi.Pluck(c.currentOutputs.Object, "spec") | ||
if !reflect.DeepEqual(oldSpec, newSpec) { | ||
return untilCoreV1ResourceQuotaInitialized(c.createAwaitConfig) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The old logic seems to say, if nothing has changed, then skip waiting for anything. But waiting is harmless I suppose?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Confirmed this still works as expected. Tested by adding an annotation to a ResourceQuota to exercise this case where the spec is unchanged -- previously we would have short-circuited but awaiting works just as well.
535ace3
to
55283ce
Compare
55283ce
to
2bde7af
Compare
The `ServiceAccount` awaiter is the only one which uses `clusterVersion` to decide its behavior, and we were only populating this on creation. #3139 consolidated create/update wait logic, which introduced a panic in this case because we're now calling the init awaiter during update. This PR adds a `nil` check to be safe and also populates `clusterVersion` for update/delete/read in the off chance that another awaiter might want to use it later down the line. Fixes #3166
There's no functional difference between our "update" and "create" await logic
-- in every case, our update awaiters simply invoke the create awaiter, or vice
versa.
(The only minor exception to this is
untilCoreV1ResourceQuotaUpdated
, whichhas a little logic to short-circuit but otherwise still calls into the
corresponding create awaiter.)
This PR consolidates the create/update configs into one. This will make it more
straightforward to glue together our legacy awaiters.
The first commit replaces
updateAwaitConfig
withcreateAwaitConfig
, and thesecond commit is just renaming.
The third commit adds test coverage for the
Update
path, essentiallycopy-pasted from the
Creation
tests. This will help guarantee that subsequentPRs preserve existing behavior.
Fixes #2799.
Refs #2824.