@pkutishch There are no sig labels on this issue. Please add a sig label by:
(1) mentioning a sig: @kubernetes/sig-<team-name>-misc
(2) specifying the label manually: /sig <label>

Note: method (1) will trigger a notification to the team. You can find the team list here and label list here

@kubernetes/sig-storage

/sig storage

The only function AccessModes has right now is at binding time, for ensuring a PVC gets a PV with the AccessModes it wants: think of it as a first-class labelselector. And the way kubernetes thinks of it is that RWO is a subset of RWM, so a provisioned RWM glusterfs volume satisfies your claim. But I agree this is a bug, we should provision ReadOnly when ReadOnly is explicitly requested.

The value of the ReadOnly setting of PersistentVolumeSource (which is what says "mount w/ ro") can be totally independent of the AccessModes, i.e. you can have a PV with RWM AccessModes but ReadOnly set true. But the provisioners are in a position to be smarter and set ReadOnly according to what AccessModes were requested.

Let me plug #47274, when it's merged provisioners will stop ignoring AccessModes, they will start parsing it on per-plugin basis, but for a different reason than what's requested here. Like this, when implemented it will be a "breaking bugfix," & so we will need approval before we break stuff

@pkutishch what does your pod definition looks like? You can specify read-only: true when specify claimName in your pod specs and that should be honored during mount-time (if it isn't , it is a bug).

@wongma7 yeah, I think we can indeed set ReadOnly field of PersistentVolumeSource depending on requested AccessMode in PVC.

@wongma7 and @gnufied, any plans to fully enforce the access mode? I submitted a ticket on this before #37465. If we specify RWO, it means that we should only attach this volume to only one node.

There are 2 separate issues here.

a. AccessMode is not applied at mount time. So if user specifies ROX, volumes are still mounted as RW. As @wongma7 said, this is because AccessMode is only used during binding phase and forgotten later on. This problem is relatively easier to solve and I think we can set ReadOnly on volumes if ROX accessmode is specified in PVC.

b. Another problem of course is, k8s doesn't enforces accessMode check during pod creation/scheduling. i.e - a RWO PVC can be used from multiple pods and that inevitably fails (unless with some luck, 2 pods land on same node). We have merged #45346 PR, which prevents attach operation from happening if volume is attached elsewhere. That PR only applies to Cinder and Azure. The problem that we are seeing is - in many cases users aren't aware that they aren't supposed to use same PVC in 2 pods or they are scaling the deployment with PVC to 2 or more replicas. This state usually leads to a huge number of invalid CloudProvider API calls and is I think undesirable.

We have 2 choices to fix problem#b:

1. Extend current solution that @codablock implemented to other volume types, such as - EBS, NFS etc. It could work. But I think a problem with merged solution is - it relies on ActualStateOfWorld to verify if volume is attached somewhere. I think checking ASOW is not a strong guarantee and check can return false negatives, in cases like controller restart.
2. We can check if PVC being requested is used elsehwhere via some sort of scheduler predicate and make such pods unschedulable. I don't know, if people actually rely on current behaviour which allows attaching same PVC to 2 or more pods, as long as, all pods are scheduled on same node.

@saad-ali @kubernetes/sig-storage-pr-reviews

@gnufied, if we detect the multi-pod usage from scheduler side, is there any way for the scheduler to know whether or not a PVC is already bound to a pod?

@xingzhou as per my understanding the way is check pod spec where binding pvc defined in volume block.
Anyway but i think in future would be nice to have such info in PVC/PV status that i has bound to POD and pod name for example, this will help check whether it was assigned to some resources.
But it only my view

yes, that's my concern, as the PVC status does not include the bound pod info, so it might be not easy to stop the pod scheduling at schedule phase at present, if check from pod spec, I don't know if there is any way to "lock" the resource efficiently, as in a cluster, I think we can run multiple schedulers simultaneously.

@xingzhou as i know k8s storing information in etcd, not sure if it stores information regarding storage but you may setup lock flag in etcd, and during assigning PVC to POD it will check for lock flag in case you using RWO mode. and not to set lock flag for RWX and ROX, but not sure that this case is suitable.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close