Skip to content
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

Merged
merged 3 commits into from
Aug 9, 2024
Merged

Conversation

blampe
Copy link
Contributor

@blampe blampe commented Jul 29, 2024

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, which
has 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 with createAwaitConfig, and the
second commit is just renaming.

The third commit adds test coverage for the Update path, essentially
copy-pasted from the Creation tests. This will help guarantee that subsequent
PRs preserve existing behavior.

Fixes #2799.
Refs #2824.

@blampe blampe marked this pull request as ready for review July 29, 2024 22:04
@blampe blampe changed the base branch from blampe/2996-await-delete to master July 29, 2024 22:05
@blampe blampe changed the base branch from master to blampe/2996-await-delete July 29, 2024 22:05
@blampe blampe added the impact/no-changelog-required This issue doesn't require a CHANGELOG update label Jul 29, 2024
Copy link

Does the PR have any schema changes?

Looking good! No breaking changes found.
No new resources/functions.

Copy link

codecov bot commented Jul 31, 2024

Codecov Report

Attention: Patch coverage is 53.70370% with 25 lines in your changes missing coverage. Please review.

Project coverage is 36.53%. Comparing base (96592b6) to head (2bde7af).

Files Patch % Lines
provider/pkg/await/awaiters.go 26.08% 17 Missing ⚠️
provider/pkg/await/pod.go 0.00% 3 Missing ⚠️
provider/pkg/await/ingress.go 33.33% 2 Missing ⚠️
provider/pkg/await/service.go 33.33% 2 Missing ⚠️
provider/pkg/await/job.go 0.00% 1 Missing ⚠️
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.
📢 Have feedback on the report? Share it here.

Comment on lines -452 to -682
oldSpec, _ := openapi.Pluck(c.lastOutputs.Object, "spec")
newSpec, _ := openapi.Pluck(c.currentOutputs.Object, "spec")
if !reflect.DeepEqual(oldSpec, newSpec) {
return untilCoreV1ResourceQuotaInitialized(c.createAwaitConfig)
}
Copy link
Contributor

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?

Copy link
Contributor Author

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.

@blampe blampe changed the base branch from blampe/2996-await-delete to master August 9, 2024 22:13
@blampe blampe merged commit 7c31739 into master Aug 9, 2024
34 checks passed
@blampe blampe deleted the blampe/await-config branch August 9, 2024 22:50
@mjeffryes mjeffryes added this to the 0.108 milestone Aug 16, 2024
blampe added a commit that referenced this pull request Aug 16, 2024
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
impact/no-changelog-required This issue doesn't require a CHANGELOG update
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Unittests for await logic (Update)
3 participants