-
Notifications
You must be signed in to change notification settings - Fork 39.9k
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
scheduler: more informative generic ephemeral volume events #104605
Conversation
@pohly: This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/sig storage |
Thanks @pohly, I don't think the second commit is necessary, I think it is better for debugging to have the events consistent with pod conditions. |
c17055f
to
9be6eac
Compare
Okay. I've taken out that second part and updated the PR description accordingly. /assign @msau42 |
These events are currently emitted for a pod using a generic ephemeral volume: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 3s default-scheduler 0/1 nodes are available: 1 persistentvolumeclaim "my-csi-app-inline-volume-my-csi-volume" not found. Warning FailedScheduling 2s default-scheduler 0/1 nodes are available: 1 pod has unbound immediate PersistentVolumeClaims. The one about "persistentvolumeclaim not found" is potentially confusing. It occurs because the scheduler typically checks the pod before the ephemeral volume controller had a chance to create the PVC. This is a bit easier to understand: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 4s default-scheduler 0/1 nodes are available: 1 waiting for ephemeral volume controller to create the persistentvolumeclaim "my-csi-app-inline-volume-my-csi-volume". Warning FailedScheduling 2s default-scheduler 0/1 nodes are available: 1 pod has unbound immediate PersistentVolumeClaims.
9be6eac
to
89cb4d0
Compare
// but we can do better for generic ephemeral inline volumes where that situation | ||
// is normal directly after creating a pod. | ||
if ephemeral && apierrors.IsNotFound(err) { | ||
err = fmt.Errorf("waiting for ephemeral volume controller to create the persistentvolumeclaim %q", pvcName) |
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.
is it always the case that this type of PVC is created by the ephemeral volume controller?
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.
In practice, yes. It would be possible to set up a cluster where that controller is disabled and some other entity creates the PVCs, but that seems very unlikely.
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ahg-g, pohly The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/lgtm |
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
Typically, pods using generic ephemeral inline volumes trigger two events:
The first now is more informative:
Which issue(s) this PR fixes:
Fixes #104525
Special notes for your reviewer:
Originally, this PR also contained a second commit which delayed the first event and, as a result, typically never showed it because the condition for it is short-lived. This was taken out based on review feedback but could be brought back if desired: https://github.com/pohly/kubernetes/commits/ephemeral-volume-events-delay
Does this PR introduce a user-facing change?