VolumeAttachment has attached status true but actual state false about external-attacher HOT 12 CLOSED

VA %s for volume %s has attached status %v but actual state %v comes from periodic sync of VolumeAttachment objects ("attached status") with result of ListVolumes() CSI call ("actual state"). It tries to attach volumes that were detached outside of the external-attacher, e.g. by a user. Or, on some clouds, a part of the cloud that's responsible for ListVolumes() CSI call does not have the information that corresponding ControllerPublishVolume() has succeeded (their "eventual consistency" pattern). Or there is a bug in the CSI driver or the attacher, of couse.

from external-attacher.

Hi @jsafrane,

thank you for your answer. 2 questions arise there with me.

• If I understand you correctly, the log entry should disappear if I remount the PersistentVolume once. The attachment should now come from the CSI driver and the necessary event/information should be available?
• So to know where the information from the ListVolumes comes from I would have to check where the concrete CSI implementation gets the values from?

from external-attacher.

If I understand you correctly, the log entry should disappear if I remount the PersistentVolume once. The attachment should now come from the CSI driver and the necessary event/information should be available?

Ideally, it should heal by itself - the attacher sees that something that should be attached (has VolumeAttachment) is not attached and attach it. Apparently, it does not happen in your case and I would be curious why.

So to know where the information from the ListVolumes comes from I would have to check where the concrete CSI implementation gets the values from?

Yes.

from external-attacher.

Hello @jsafrane,

The logs seem to occur when a PVC exists that has been mounted once in the past and then the pod is shut down (e.g. for autoscaling). As soon as you clean up the unused PVCs the log entry disappears.

So the log entry makes sense again, because an unused PVC has of course the status "attached: false". I would argue that this is actually unclean and an unused / unmounted PVC/PV should not show up in the logs.

How do you see it?

Thanks again for your support!

from external-attacher.

If you see volume XYZ has attached status true but actual state false, then VolumeAttachment.status.attached is true. Where do you see it as attached: false?

from external-attacher.

Hi @jsafrane ,

that was my original question and I couldn't really answer it until now. All I know now is that this log entry is created for PVCs that are created, were consumed in the past but do not have a pod as a consumer at the moment of the log entry.

We have gone through various OpenStack commands and kubectl commands but where the attached: false is read from we could not figure out.

from external-attacher.

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

This bot triages un-triaged 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:

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

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

/lifecycle stale

from external-attacher.

Hello @Payback159,

we are facing the same problem (Kube+Cinder/OpenStack), and the CSI Cinder logs are full of these messages and attaching/detaching volumes are longer and longer.

Do you find any solution ?

from external-attacher.

Hello @vhurtevent,

apparently the log entries occur when you have PVC's in the cluster that were mounted once in the past and then left and never cleaned up. In our case it was PVC's coming from multiple statefulsets scaled via horizontal pod autoscaler.

We were able to "remove" the logs by cleaning up the leftover PVCs.

However, since in our case they were not the cause of our problem at the time, we stopped further analysis of these log entries.

from external-attacher.

New findings in this issue : kubernetes/cloud-provider-openstack#2295

from external-attacher.

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

This bot triages un-triaged 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:

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

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

/lifecycle rotten

from external-attacher.

@vhurtevent has already pointed out in the previous comment that the problem is apparently solved in the cinder-csi-plugin. Only in the sense of a clean conclusion:

We were able to install the new version of the cinder-csi-plugin in our environment and can confirm that the log entries have also disappeared here.

In our larger clusters, this has also meant that pods with RWO volumes that have ended up on another node as a result of rescheduling can now mount their volume also more quickly.

Thank you very much @jsafrane and @vhurtevent !

from external-attacher.