Emit events on detach errors about external-attacher HOT 18 CLOSED

I find it odd that attach errors are sent to pods and detach errors would be PVC... I wonder if it's possible / common to send events to deleted Pods. The only way how to get the event would be kubect get event.

from external-attacher.

I played around with it yesterday and it certainly is possible to create events for objects that don't exist. It would provide some sort of symmetry when using kubectl get events --field-selector involvedObject.name for example.

from external-attacher.

Wouldn't that be kind of far from the error source?

It is a generic place where all attach errors are reported and thus detach error should be there too. While we're migrating most volume plugins to CSI, there are still some that are in-tree and may benefit from the improved error reporting.

I guess the error in the VA status could somehow be turned into an event, but would also affect other types of volumes which I can't test or verify.

That is the goal, common place for all detach errors. We can help with in-tree error verification.

And yes, you can just improve our docs! You're more that welcome.

from external-attacher.

@humblec Sorry, I kind of lost track of this. I think we came to the conclusion that the issue is somewhat misplaced here. Work to improve things should probably be done in k/k and k/website. Issues in those repos can still link back here for documentation purposes, but I think it can be closed.

nw.. and thanks for revisiting this issue @avorima . If we have nt opened the trackers in k/k or k/website, I can take that up and close this issue for now.

from external-attacher.

I think volume attachment errors are available in kubectl describe pod (events on pods, not on PVCs).

from external-attacher.

The errors on the pod are not very detailed AFAIK, just some generic "failed" message. The attacher would able to publish the actual CSI errors for example.

from external-attacher.

In Pod events I can see:
Warning FailedAttachVolume 0s attachdetach-controller AttachVolume.Attach failed for volume "pvc-510f4944-e913-4af8-b20b-3e96ee7be428" : rpc error: code = Internal desc = unknown Attach error: failed when waiting for zonal op: operation operation-1655453091238-5e1a0357213a9-e777d0de-01bc9636 failed (RESOURCE_IN_USE_BY_ANOTHER_RESOURCE): The disk resource 'projects/xxx/zones/us-east1-d/disks/pvc-510f4944-e913-4af8-b20b-3e96ee7be428' is already being used by 'projects/xxx/zones/us-east1-d/instances/jsafrane-1-tlsxz-master-2'

Where the part starting with rpc error: is actually the error from VolumeAttachment.Status.AttachError

from external-attacher.

Let me see if I can reproduce my issue. The errors that I was looking for were detach errors and IIRC they were only present on the VA.

from external-attacher.

Indeed, detach errors are different - the pod that would be linked to the events already does not exists.I am not sure if it's correct to link them to a PVC, because in-line volumes do not have PVC.

from external-attacher.

Ah ok, then my issue title was wrong. It's only about detach errors.
Wouldn't it be alright if the event linking only happens when it's not an in-line volume?

from external-attacher.

Alright, then the real fix should be in kubernetes/kubernetes.

A/D controller sends events on volume attach errors here and here. And it does not send anything on detach errors. I am not sure there any ScheduledPods at that time though. Still, it should give you an idea where to start.

from external-attacher.

Wouldn't that be kind of far from the error source? This detach operation executor for CSI basically just deletes the VA, so it doesn't directly see the error that the CSI driver produces. I guess the error in the VA status could somehow be turned into an event, but would also affect other types of volumes which I can't test or verify.

In the end this is just to make these errors more visible for users which maybe aren't as aware of VA's. So I could also look into turning this into a documentation enhancement.

from external-attacher.

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

from external-attacher.

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

from external-attacher.

@avorima are you working on this ?

from external-attacher.

@humblec Sorry, I kind of lost track of this. I think we came to the conclusion that the issue is somewhat misplaced here. Work to improve things should probably be done in k/k and k/website. Issues in those repos can still link back here for documentation purposes, but I think it can be closed.

from external-attacher.

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

from external-attacher.

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

from external-attacher.