-
Notifications
You must be signed in to change notification settings - Fork 113
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
Add await logic for DaemonSets #2953
Conversation
Does the PR have any schema changes?Looking good! No breaking changes found. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2953 +/- ##
==========================================
+ Coverage 32.34% 35.97% +3.63%
==========================================
Files 69 70 +1
Lines 8954 9156 +202
==========================================
+ Hits 2896 3294 +398
+ Misses 5791 5530 -261
- Partials 267 332 +65 ☔ View full report in Codecov by Sentry. |
@blampe thanks for the await logic, this will be a big help. Did you happen to test the two following scenarios:
|
@rshade I added a failing e2e test here which should cover both of these scenarios. This step in particular captures scenario (2) by updating to an invalid image. Previously the operation would succeed, but after this PR it will fail after it times out waiting for the broken pods to come up. Let me know if there are any other test cases you have in mind! |
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.
I don't know the awaiters too well but everything seemed good to me.
provider/pkg/await/daemonset.go
Outdated
// If done=true and err is non-nil then this is an OnDelete rollout. | ||
msg, done, err = dsa.onDeleteRolloutStatus() |
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.
This is a pretty awkward handoff, and given how little code is in DaemonSetStatusViewer
, maybe we shouldn't use it.
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.
I switched this over to use kstatus since it's essentially the same logic and doesn't distinguish between Rolling or OnDelete rollouts.
plugins: | ||
providers: | ||
- name: kubernetes | ||
path: ../../../../bin |
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.
I thought the provider linking happened automatically but I frankly don't know how. And why don't we see it in the other steps?
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.
Yeah it happens automatically in tests, although sometimes I will manually run examples in which case this helps. I took it out since I don't need to test it manually anymore.
I noticed as part of #2953 that the `tests/convert` and `tests/provider` directories aren't currently getting exercised in CI, and as a result one of them is failing on master. This PR moves `tests/provider` and `tests/convert` under `sdk/java`, which is currently executed in CI but doesn't contain any tests. We also fix the convert test along the way. "sdk/java" is admittedly an odd namespace to put these under, but our CI targets don't give us much flexibility at the moment, and at the end of the day it's just an arbitrary way of sharding things.
Tests flaked due to pulumi/ci-mgmt#933 / pulumi/schema-tools#64. |
This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [@pulumi/kubernetes](https://pulumi.com) ([source](https://togithub.com/pulumi/pulumi-kubernetes)) | dependencies | minor | [`4.11.0` -> `4.12.0`](https://renovatebot.com/diffs/npm/@pulumi%2fkubernetes/4.11.0/4.12.0) | --- > [!WARNING] > Some dependencies could not be looked up. Check the Dependency Dashboard for more information. --- ### Release Notes <details> <summary>pulumi/pulumi-kubernetes (@​pulumi/kubernetes)</summary> ### [`v4.12.0`](https://togithub.com/pulumi/pulumi-kubernetes/blob/HEAD/CHANGELOG.md#4120-May-21-2024) [Compare Source](https://togithub.com/pulumi/pulumi-kubernetes/compare/v4.11.0...v4.12.0) ##### Added - Added a new Helm Chart v4 resource. ([pulumi/pulumi-kubernetes#2947) - Added support for deletion propagation policies (e.g. Orphan). ([pulumi/pulumi-kubernetes#3011) - Server-side apply conflict errors now include the original field manager's name. ([pulumi/pulumi-kubernetes#2983) ##### Changed - Pulumi will now wait for DaemonSets to become ready. ([pulumi/pulumi-kubernetes#2953) - The Release resource's merge behavior for `valueYamlFiles` now more closely matches Helm's behavior. ([pulumi/pulumi-kubernetes#2963) ##### Fixed - Helm Chart V3 previews no longer fail when the cluster is unreachable. ([pulumi/pulumi-kubernetes#2992) - Fixed a panic that could occur when a missing field became `null`. ([pulumi/pulumi-kubernetes#1970) </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Renovate Bot](https://togithub.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy4zNzEuMSIsInVwZGF0ZWRJblZlciI6IjM3LjM3MS4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJ0eXBlL21pbm9yIl19--> Co-authored-by: lumiere-bot[bot] <98047013+lumiere-bot[bot]@users.noreply.github.com>
Proposed changes
This adds await logic for DaemonSets with RollingUpdate or OnDelete update strategies.
The implementation is largely based on the existing StatefulSet logic with two high-level simplifications:
PodAggregator
to handle reporting pod statuses.Importantly, unlike StatefulSet this means we do not currently inspect pods to decide readiness -- we only use them for informational purposes. I think this is sufficient but I could easily be missing something. I haven't been able to simulate situations where this logic doesn't fully capture readiness and we would need to inspect pod statuses.
A failing e2e test was added in YAML. I noticed we didn't have any YAML tests yet, and
I've found YAML to be quick and easy to crank out for very simple test cases like this.
Unit tests were added around the public
Creation
,Update
, etc. methods in order to more fully exercise timeouts and retries. To that end I introduced a mock clock package which might be controversial. IMO Go doesn't have a great OSS mock clock but something like this can be very helpful for testing.I'm still somewhat confused by the role of
await.Read
since it doesn't actually await anything, but it's implemented similar to StatefulSet as a one-shot read + readiness check.Related issues
Fixes #609
Refs #2800
Refs #2799
Refs #2798