-
Notifications
You must be signed in to change notification settings - Fork 596
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
[cinder-csi-plugin] Fix filesystem resize #1434
Conversation
Build succeeded.
|
Build succeeded.
|
Build succeeded.
|
Build succeeded.
|
Build succeeded.
|
pkg/csi/cinder/nodeserver.go
Outdated
// If Kubernetes version < v1.19.0 the volume_path would be | ||
// having the staging_target_path information | ||
volumePath = req.GetVolumePath() | ||
} |
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.
@Fedosin could you explain your issue in more detail .
NodeExpandVolume can be called after nodePublish , in that case, in that case we cant use staging_target_path, volumepath stores the right value. please check here: https://github.com/kubernetes/kubernetes/blob/master/pkg/volume/csi/csi_client.go#L101
It would be more helpful if you could log the issue with details and the values you are receiving in volumePath and staging_target_path
@Fedosin pls add reference docs for the above as well would be helpful. From the CSI spec and the https://github.com/kubernetes/kubernetes/blob/master/pkg/volume/csi/csi_client.go#L101, we are using the right field IMO |
@ramineni something like this: I0824 09:24:45.735515 507082 utils.go:159] ID: 66 Req-ID: 0001-0011-openshift-storage-0000000000000001-cce6ebe3-e5ea-11ea-a920-0a580a810229 GRPC call: /csi.v1.Node/NodeExpandVolume Because of this, expansion is a no-op as getDevidePath() is not able to find the device path based on volume_path. |
shouldn't |
/hold |
Now we use "findmnt" command to find the device path. Unfortunately, this command may return multiple entries of the same mount, but in fact we need just the first one. To prevent this issue we add "--first-only" flag to the command.
c84a352
to
0ab91dc
Compare
Build succeeded.
|
Build succeeded.
|
Build succeeded.
|
/lgtm |
/hold cancel |
@Fedosin can you add release notes please? |
@gnufied as I know release notes are for public facing features. and this is just a bugfix, so I think |
Build succeeded.
|
Build failed.
|
I am not sure how release notes are prepared for openstack cloudprovider but in rest of kubernetes repository, we do capture important bugs in release notes. |
/test cloud-provider-openstack-e2e-test-csi-cinder |
@jichenjc: The specified target(s) for
Use In response to this:
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. |
I am +1 to list bug fixes in release notes as this seems best practices in other k8s ecosystem repo... |
Build failed.
|
/test cloud-provider-openstack-e2e-test-csi-cinder |
@jichenjc: The specified target(s) for
Use In response to this:
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. |
Build succeeded.
|
/approve thanks |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jichenjc 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 |
@ramineni Is this a candidate for backport? |
@lingxiankong right. I'll propose a PR for backport to 1.20 |
Now we use "findmnt" command to find the device path. Unfortunately, this command may return multiple entries of the same mount, but in fact we need just the first one. To prevent this issue we add "--first-only" flag to the command.
Now we use "findmnt" command to find the device path. Unfortunately, this command may return multiple entries of the same mount, but in fact we need just the first one. To prevent this issue we add "--first-only" flag to the command. Co-authored-by: Mike Fedosin <mfedosin@redhat.com>
Now we use "findmnt" command to find the device path. Unfortunately, this command may return multiple entries of the same mount, but in fact we need just the first one. To prevent this issue we add "--first-only" flag to the command.
Now we use "findmnt" command to find the device path. Unfortunately, this command may return multiple entries of the same mount, but in fact we need just the first one. To prevent this issue we add "--first-only" flag to the command.
Fixes #1436