Skip to content
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

StorageOS attach device before volume attach #69782

Merged
merged 2 commits into from
Feb 20, 2019

Conversation

darkowlzz
Copy link
Contributor

@darkowlzz darkowlzz commented Oct 14, 2018

What this PR does / why we need it:
This fixes an issue in StorageOS volume plugin where volume mount succeeds even if request to mount via StorageOS API fails, by adding an AttachDevice API, which is called before a volume is attached. Also, updates the StorageOS API library.

Which issue(s) this PR fixes:
Fixes #69580

Release note:

StorageOS volume plugin updated to fix an issue where volume mount succeeds even if request to mount via StorageOS API fails.

@k8s-ci-robot k8s-ci-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. needs-kind Indicates a PR lacks a `kind/foo` label and requires one. needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Oct 14, 2018
@k8s-ci-robot k8s-ci-robot added sig/storage Categorizes an issue or PR as relevant to SIG Storage. and removed needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels Oct 14, 2018
@idealhack
Copy link
Member

/kind bug
/ok-to-test

@k8s-ci-robot k8s-ci-robot added kind/bug Categorizes issue or PR as related to a bug. and removed needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. needs-kind Indicates a PR lacks a `kind/foo` label and requires one. labels Oct 18, 2018
@darkowlzz
Copy link
Contributor Author

darkowlzz commented Oct 18, 2018

Not sure why it failed. Some help would be appreciated.
Running it again.

/retest

@croomes
Copy link
Contributor

croomes commented Nov 14, 2018

Hi @rootfs - would you mind having a look when you have time?

Thanks!

@saad-ali
Copy link
Member

saad-ali commented Dec 6, 2018

/approve

Please move the volume expand to a separate PR.
Will let @gnufied review and lgtm

/assign @gnufied

@k8s-ci-robot k8s-ci-robot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Dec 10, 2018
@darkowlzz darkowlzz force-pushed the storageos-updates branch 2 times, most recently from a5150f9 to 6b5af9e Compare December 10, 2018 08:05
@idealhack
Copy link
Member

/test pull-kubernetes-verify

@darkowlzz
Copy link
Contributor Author

/retest

@darkowlzz
Copy link
Contributor Author

/test pull-kubernetes-e2e-kops-aws

@darkowlzz
Copy link
Contributor Author

/retest

@darkowlzz
Copy link
Contributor Author

I've removed the volume expand related changes from this PR. Will create a separate PR for that.
Thanks!

Copy link
Member

@gnufied gnufied left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also the title of the PR still says "Volume expansion" please remove it.

globalPDPath := makeGlobalPDName(b.plugin.host, b.pvName, b.podNamespace, b.volName)

// Attach the device to the host.
if err := b.manager.AttachDevice(b, globalPDPath); err != nil {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can the AttachDevice be called from control-plane rather than being called from kubelet?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think there's a need for that. It just creates a virtual volume by calling a StorageOS API.

// Attach the device to the host.
if err := b.manager.AttachDevice(b, globalPDPath); err != nil {
klog.Errorf("Failed to attach device at %s: %s", globalPDPath, err.Error())
return err
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lets not use capitalization for error messages.

Copy link
Contributor Author

@darkowlzz darkowlzz Jan 1, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was just being consistent with the existing format in the same file and the other plugins. Should I change all the existing error messages to be non-capitalized?

@@ -277,6 +277,8 @@ type storageosManager interface {
CreateVolume(provisioner *storageosProvisioner) (*storageosVolume, error)
// Attaches the disk to the kubelet's host machine.
AttachVolume(mounter *storageosMounter) (string, error)
// Attaches the device to the host at a mount path.
AttachDevice(mounter *storageosMounter, deviceMountPath string) error
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is also a AttachVolume defined above and it isn't immediately obvious how is AttachDevice different from AttachVolume.

There is another bigger design issue with this plugin which I am not quite sure about is - it implements mounting the device to global path and unmounting from it, without implementing MountDevice and UnmountDevice functions. It is expected that a plugin that mounts the volume to a global path implements these functions (for various reasons).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AttachDevice calls a StorageOS API for the virtual volumes which are created on the host and it doesn't actually attaches a device. The StorageOS virtual volume is then used by AttachVolume to attach the volume to the kubelet.

@darkowlzz darkowlzz changed the title StorageOS attach device before volume attach & volume expansion support StorageOS attach device before volume attach Dec 12, 2018
@@ -347,6 +349,14 @@ func (b *storageosMounter) SetUp(fsGroup *int64) error {
b.volNamespace = b.podNamespace
}

globalPDPath := makeGlobalPDName(b.plugin.host, b.pvName, b.podNamespace, b.volName)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does access pattern of storageOS works on multiple pods using same volume on same node. Can the volume be attached multiple times on the node with different paths?

In general I am not sure why this volume uses pod's namespace in something that it calls "GlobalPDPath". That implies this path can only be reused if another pod within same namespace uses same volume. What happens if another pod but in different namespace uses the volume? I am not super familiar with StorageOS and hence these questions.

Copy link
Contributor Author

@darkowlzz darkowlzz Jan 28, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, a volume can be used by multiple pods on the same node if they are in the same namespace as the PVC.

b.podNamespace looks to be incorrect there. Should be b.volNamespace. I'll change that.

The variable name globalPDPath can be changed too. It does sounds misleading. It's just the target path where a loop device is mounted and made accessible to a pod.
I'll rename it to target path.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

okay, once tests are fixed I will lgtm.

AttachDevice() ensures that the volume device is attached to the
host before they are used.
@darkowlzz
Copy link
Contributor Author

/retest

2 similar comments
@darkowlzz
Copy link
Contributor Author

/retest

@darkowlzz
Copy link
Contributor Author

/retest

@k8s-ci-robot
Copy link
Contributor

@darkowlzz: The following test failed, say /retest to rerun them all:

Test name Commit Details Rerun command
pull-kubernetes-e2e-kops-aws 835183a link /test pull-kubernetes-e2e-kops-aws

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

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 understand the commands that are listed here.

@darkowlzz
Copy link
Contributor Author

Can someone help with this test failure?
It doesn't look like it's related to this change at all: waiting for ready nodes timed out.

@gnufied
Copy link
Member

gnufied commented Jan 30, 2019

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jan 30, 2019
@gnufied
Copy link
Member

gnufied commented Feb 7, 2019

/approve

@darkowlzz
Copy link
Contributor Author

/assign @thockin

@thockin
Copy link
Member

thockin commented Feb 20, 2019

Punting to newly minted dep-approver @apelisse !

@apelisse
Copy link
Member

Godeps: Updating StorageOS dependency, no other new dependencies. Seems reasonable to me.

/approve

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: apelisse, darkowlzz, gnufied, saad-ali

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Feb 20, 2019
@k8s-ci-robot k8s-ci-robot merged commit 23a0850 into kubernetes:master Feb 20, 2019
croomes added a commit to croomes/kubernetes that referenced this pull request May 30, 2019
kubernetes#69782 introduced a change
to register the device attachment (in the StorageOS API) prior to the
volume attachment.  The volume attachment code would clear any mount
info, causing the StorageOS API to register the mount and then
immediately de-register it.

The code to clear the mount info on volume attach is no longer needed.
It was used to force-mount a volume if StorageOS thought it was already
mounted.  In practice it was not needed, and administrators have other
ways of clearing stale mount information if required.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/bug Categorizes issue or PR as related to a bug. lgtm "Looks good to me", indicates that a PR is ready to be merged. release-note Denotes a PR that will be considered when it comes time to generate release notes. sig/storage Categorizes an issue or PR as relevant to SIG Storage. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

StorageOS volume mount succeeds even if request to mount via api fails
8 participants