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

add block device support for azure disk #63841

Merged
merged 2 commits into from May 23, 2018

Conversation

Projects
None yet
5 participants
@andyzhangx
Copy link
Member

andyzhangx commented May 15, 2018

What this PR does / why we need it:
add block device support for azure disk

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #61821

Special notes for your reviewer:
detailed steps about how it work:
https://github.com/andyzhangx/demo/tree/master/linux/block/azuredisk

Release note:

add block device support for azure disk

@karataliu @feiskyer @khenidak

@andyzhangx

This comment has been minimized.

Copy link
Member Author

andyzhangx commented May 15, 2018

/sig azure
/sig storage

@andyzhangx

This comment has been minimized.

Copy link
Member Author

andyzhangx commented May 15, 2018

@andyzhangx

This comment has been minimized.

Copy link
Member Author

andyzhangx commented May 17, 2018

@mtanino do you have time take a look? thanks.

}

func (plugin *azureDataDiskPlugin) newUnmapperInternal(volName string, podUID types.UID, mounter mount.Interface) (volume.BlockVolumeUnmapper, error) {
disk := makeDataDisk("", podUID, "", plugin.host, plugin)

This comment has been minimized.

@mkimuram

mkimuram May 17, 2018

Contributor

Does volName need to be passed to makeDataDisk() here?

This comment has been minimized.

@andyzhangx

andyzhangx May 18, 2018

Author Member

good catch, fixed.

glog.V(5).Infof("got diskName(%s) from globalMapPath: %s", globalMapPath, diskName)
block := v1.PersistentVolumeBlock
pv := &v1.PersistentVolume{
Spec: v1.PersistentVolumeSpec{

This comment has been minimized.

@mkimuram

mkimuram May 17, 2018

Contributor

I found some plugins setting volumeName as Name in ObjectMeta on ConstructBlockVolumeSpec() call.
(local, iscsi, and fc set it, but aws_ebs, rbd, and gce don't. )
Should it be set here?

This comment has been minimized.

@andyzhangx

andyzhangx May 18, 2018

Author Member

No, here it's inside ConstructBlockVolumeSpec func:

	// ConstructBlockVolumeSpec constructs a volume spec based on the given
	// pod name, volume name and a pod device map path.
	// The spec may have incomplete information due to limited information
	// from input. This function is used by volume manager to reconstruct
	// volume spec by reading the volume directories from disk.

it does not have suffient volumeName value, e.g. following path only has disk name other than volumeName, while for local, iscsi, and fc, ConstructBlockVolumeSpec already provides volumeName parameter in the func call.

/var/lib/kubelet/plugins/kubernetes.io/azure-disk/volumeDevices/block-azuredisk-test

This comment has been minimized.

@mkimuram

mkimuram May 21, 2018

Contributor

Sorry for making you confuse.
I meant to say that we will be able to set volumeName to Name in metav1.ObjectMeta in getVolumeSpecFromGlobalMapPath(),
if we pass volumeName to getVolumeSpecFromGlobalMapPath() from ConstructBlockVolumeSpec().
(It seems that ConstructBlockVolumeSpec() allows the resulting spec to be incomplete, however, it would be better to try to make more complete.)

I would like to hear opinions from authors of other plugins whether above makes sense,
for the same logic can also be applied to RBD and GCE to make the resulting spec similar to that for local.

Local: @dhirajh
RBD: @sbezverk
GCE: @screeley44

This comment has been minimized.

@andyzhangx

andyzhangx May 22, 2018

Author Member

@mkimuram thanks, I have pushed a new commit to address this: 3683f3f, PTAL

This comment has been minimized.

@mkimuram

mkimuram May 22, 2018

Contributor

LGTM.

},
}

return volume.NewSpecFromPersistentVolume(pv, true), nil

This comment has been minimized.

@mkimuram

mkimuram May 17, 2018

Contributor

I found difference in readOnly flag for NewSpecFromPersistentVolume() call among plugins.
(local, iscsi, and fc set false, and aws_ebs, rbd, and gce set true.)
Do they choose it in some logics? If not, should we unify it to a good default?
(This won't be Azure specific topic, and ideally we might need to find a way to determine it on reconstruction path, though.)

This comment has been minimized.

@andyzhangx

andyzhangx May 18, 2018

Author Member

ConstructBlockVolumeSpec func would construct incomplete information, here true value does not make any sense, we cannot read from a globalMapPath to determine readOnly flag

	// ConstructBlockVolumeSpec constructs a volume spec based on the given
	// pod name, volume name and a pod device map path.
	// The spec may have incomplete information due to limited information
	// from input. This function is used by volume manager to reconstruct
	// volume spec by reading the volume directories from disk.

This comment has been minimized.

@mkimuram

mkimuram May 21, 2018

Contributor

Currently, there seems no way to determine whether it was readOnly from the path information,
as you mentioned.
So, I guess that I should file this issue and keep Azure plugin and all other plugins as they are,
until we find a good global way to solve it.

This comment has been minimized.

@mkimuram

mkimuram May 21, 2018

Contributor

I opened below issue.

  • ConstructBlockVolumeSpec() doesn't set proper readOnly flag #64101
    #64101

@andyzhangx andyzhangx force-pushed the andyzhangx:azuredisk-block-device branch from 973c964 to 9b2140b May 18, 2018

@andyzhangx

This comment has been minimized.

Copy link
Member Author

andyzhangx commented May 18, 2018

/test pull-kubernetes-integration

@andyzhangx
Copy link
Member Author

andyzhangx left a comment

@mkimuram PTAL, thanks

@andyzhangx

This comment has been minimized.

Copy link
Member Author

andyzhangx commented May 18, 2018

/test pull-kubernetes-e2e-kops-aws

@andyzhangx

This comment has been minimized.

Copy link
Member Author

andyzhangx commented May 18, 2018

/test pull-kubernetes-e2e-gce

1 similar comment
@andyzhangx

This comment has been minimized.

Copy link
Member Author

andyzhangx commented May 18, 2018

/test pull-kubernetes-e2e-gce

@andyzhangx

This comment has been minimized.

Copy link
Member Author

andyzhangx commented May 21, 2018

@mkimuram do you have time to take a look again, thanks

}
}

func getVolumeSource(spec *volume.Spec) (*v1.AzureDiskVolumeSource, error) {
func getVolumeSource(spec *volume.Spec) (*v1.AzureDiskVolumeSource, bool, error) {

This comment has been minimized.

@feiskyer

feiskyer May 21, 2018

Member

nit: add documentation of returned fields

This comment has been minimized.

@andyzhangx

andyzhangx May 21, 2018

Author Member

fixed, add a named parameter is enough, not necessary to add doc

if err != nil {
return nil, err
}
glog.V(5).Infof("globalMapPathUUID: %s", globalMapPathUUID)

This comment has been minimized.

@feiskyer

feiskyer May 21, 2018

Member

nit: use sentence for logs, e.g. constructing block volume spec from globalMapPathUUID %s

This comment has been minimized.

@andyzhangx

andyzhangx May 21, 2018

Author Member

fixed

add block device support for azure disk
add plugin field for azure dataDisk struct

add azure_dd_block_test

fix comments

fix comments

@andyzhangx andyzhangx force-pushed the andyzhangx:azuredisk-block-device branch from 9b2140b to 8259dcb May 21, 2018

@andyzhangx andyzhangx force-pushed the andyzhangx:azuredisk-block-device branch from 3683f3f to 541edb7 May 22, 2018

@andyzhangx

This comment has been minimized.

Copy link
Member Author

andyzhangx commented May 22, 2018

/test pull-kubernetes-e2e-kops-aws
/test pull-kubernetes-kubemark-e2e-gce
/test pull-kubernetes-verify

@feiskyer

This comment has been minimized.

Copy link
Member

feiskyer commented May 23, 2018

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm label May 23, 2018

@k8s-ci-robot

This comment has been minimized.

Copy link
Contributor

k8s-ci-robot commented May 23, 2018

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: andyzhangx, feiskyer

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-github-robot

This comment has been minimized.

Copy link
Contributor

k8s-github-robot commented May 23, 2018

Automatic merge from submit-queue (batch tested with PRs 64102, 63303, 64150, 63841). If you want to cherry-pick this change to another branch, please follow the instructions here.

@k8s-github-robot k8s-github-robot merged commit eacf6f0 into kubernetes:master May 23, 2018

18 checks passed

Submit Queue Queued to run github e2e tests a second time.
Details
cla/linuxfoundation andyzhangx authorized
Details
pull-kubernetes-bazel-build Job succeeded.
Details
pull-kubernetes-bazel-test Job succeeded.
Details
pull-kubernetes-cross Skipped
pull-kubernetes-e2e-gce Job succeeded.
Details
pull-kubernetes-e2e-gce-100-performance Job succeeded.
Details
pull-kubernetes-e2e-gce-device-plugin-gpu Job succeeded.
Details
pull-kubernetes-e2e-gke Skipped
pull-kubernetes-e2e-kops-aws Job succeeded.
Details
pull-kubernetes-integration Job succeeded.
Details
pull-kubernetes-kubemark-e2e-gce Job succeeded.
Details
pull-kubernetes-kubemark-e2e-gce-big Job succeeded.
Details
pull-kubernetes-local-e2e Skipped
pull-kubernetes-local-e2e-containerized Skipped
pull-kubernetes-node-e2e Job succeeded.
Details
pull-kubernetes-typecheck Job succeeded.
Details
pull-kubernetes-verify Job succeeded.
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.