@leseb @elsonrodriguez

I am considering support the following rbd options as part of the provisioning parameters

--object-size B/K/M
Specifies the object size in B/K/M, it will be rounded up the nearest power of two. The default object size is 4 MB, smallest is 4K and maximum is 32M.

--stripe-unit size-in-B/K/M
Specifies the stripe unit size in B/K/M. See striping section (below) for more details.

--stripe-count num
Specifies the number of objects to stripe over before looping back to the first object. See striping section (below) for more details.

@rootfs is it possible to also control the RBD features via the StorageClass? (fast-diff, deep-flatten, object-map, exclusive-lock etc) is StorageClass the right place for those RBD features?

Also, would it make sense to specify multiple pools in the StorageClass, and have provisioning round-robin the pools?

Side note, I'm in the process of reworking the documentation: https://github.com/elsonrodriguez/kubernetes/tree/rbd-prov3-docs/examples/experimental/persistent-volume-provisioning

I'll send a follow-up PR after this is merged.

edit:
Changed URL from commit to branch URL: https://github.com/elsonrodriguez/kubernetes/tree/rbd-prov3-docs/examples/experimental/persistent-volume-provisioning

@rootfs This is working pretty good.

Provisioning, Mounting, Remounting after pod deletion, all works.

Going to run through some more scenarios.

@elsonrodriguez I think we can introduce the support of more features later. As discussed with @rootfs krbd doesn't support all the image features yet, it really depends on the kernel you're using.
It's basically playing catchup with librbd.

@rootfs thanks for addressing my comments!

Reviewed 7 of 9 files at r1, 2 of 2 files at r2.
Review status: all files reviewed at latest revision, 16 unresolved discussions, some commit checks failed.

Comments from Reviewable

Reviewed 6 of 6 files at r3.
Review status: all files reviewed at latest revision, 10 unresolved discussions.

Comments from Reviewable

I am happy with overall quality of the PR. @elsonrodriguez, @leseb, can you check please Ceph-related parts?

@jsafrane LGTM (from a Ceph angle)
Thanks!

@jsafrane Tested the latest commit and functionality looks good as before, however there is still no unlocking mechanism for dead kubelets.

I think we need this feature, but if the unlocking is out of scope for this PR(thoughts, @rootfs?), then LGTM.

@pwittrock @jsafrane Hi, this is 500+ LOC. Is this a bug fix? Should it be in 1.4? Thanks

@pwittrock @saad-ali @matchstick Is this something we should make an exception for?
@goltermann I know there is a link for the exception process, do you have that link?

Here is the link to the exceptions process for adding features or large refactors post feature freeze date. @rootfs @pmorie @saad-ali @thockin @jsafrane @childsb Is there a case why to add this in the 1.4 window? If so please follow the application for an exception procedures which are outlined in the link above.

Will remove 1.4 milestone from the PR. If exception process determines we want this in v1.4, it can be re-added.

Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test".
(Note: "add to whitelist" is no longer supported. Please update configurations in kubernetes/test-infra/jenkins/job-configs/kubernetes-jenkins-pull instead.)

This message will repeat several times in short succession due to jenkinsci/ghprb-plugin#292. Sorry.

Will update after #31886

GCE e2e build/test passed for commit 0c3b2f4.

• Test Results
• Build Log
• Test Artifacts
• Internal Jenkins Results

@apelisse can you get rid of do-not-merge label so it can merge to 1.5?

@k8s-bot test this [submit-queue is verifying that this PR is safe to merge]

GCE e2e build/test passed for commit 0c3b2f4.

• Test Results
• Build Log
• Test Artifacts
• Internal Jenkins Results

Automatic merge from submit-queue