-
Notifications
You must be signed in to change notification settings - Fork 545
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
rbd: add support for network namespaces (Multus CNI) #1450
Conversation
98f80c7
to
2c05d44
Compare
E2E tests are failing with
as expected. |
We could add this mount option to example SC of RBD in |
This is not a mount option, this is the rbd map specific options passed when we are mapping and unmapping the rbd devices |
Ah.. Discard.. I read |
Once we get the backport in Octopus, we can temporarily switch the Ceph base image for ceph-csi to use: |
@leseb As mentioned elsewhere, I would like to get the whole thing smoke tested with Multus before merging ceph/ceph#36927 into master and release branches. |
@leseb Did you mean nautilus instead of octopus? |
Upstream pulls from the |
Side note to this PR: Currently the mount options can be passed and its adjusted dynamically , but we dont have a mechanism to have map options for rbd mapping . We have to hardcode it for now. Ideally this should be configurable . |
the issue already exists to provide support for map options #291 |
We would need this PR for that or a ceph-csi build of that branch. Also, ceph-csi needs to be able to detect that it's being configured with Multus, we can check the pod annotations for that. And if multus then we map with I don't want to disrupt too much ceph-csi with this that's why it's probably best to map with |
OK, I'll prepare the octopus backport. (As mentioned elsewhere, the nautilus backport is at ceph/ceph-ci@6b5a851, but the container didn't get built because nautilus |
I hard-coded I don't see a reason to wait for Multus to become fully supported before rolling out |
Sure, as long as
Sure. That would be good. |
Yeah, making it possible to supply custom |
The octopus backport is at ceph/ceph-ci@21998a2 and the container is at quay.ceph.io/ceph-ci/ceph:wip-krbd-noudev-octopus. |
Now I believe this should detect whether Multus annotations are present, if so, then we turn on the noudev flag on mapping. |
No, I think CSI should default to |
This pull request now has conflicts with the target branch. Could you please resolve conflicts and force push the corrected changes? 🙏 |
The bottom line is that this is going to need to wait for 15.2.8, unless someone produces a multi-arch container (either based on octopus branch or just 15.2.6 + rbd change) that ceph-csi CI can be temporarily switched to. We have an x86 container which was successfully used by multiple people for testing and benchmarking, but ceph-csi CI needs a multi-arch (x86 + arm64) one. |
463f551
to
298593f
Compare
So 15.2.8 is out, but I'm hitting the same issue: it's there on docker.io but not in registry-ceph-csi.apps.ocp.ci.centos.org. In fact, the internal registry is still on 15.2.6, meaning we missed 15.2.7 -- it looks like @nixpanic's bdf8fe7 ("build: use docker.io/ceph/ceph:v15 as BASE_IMAGE") change isn't working (or maybe I'm misinterpreting it)... Is pushing images to the internal registry really supposed to be a manual process? Why not set it up to act as a cache? |
@nixpanic Ping, can we get ceph v15.2.8 pushed to registry-ceph-csi.apps.ocp.ci.centos.org? |
Done! ceph/ceph:v15.2.8 has been pushed, and ceph/ceph:v15 has been updated too. |
There were (and possibly still are) issues when using a registry mirror, as that connects to Docker Hub a lot too, and caused failures since Docker reduced the image-pull limits. Doing this manual is a pain, and I hope we can setup an automated job that checks for updated images (daily or so). |
With the new support for passing --options, referring to ExecCommand() argument slices as mapOptions and options is confusing. Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Fix "ndb" typo. Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Factor out --device-type and --options formatting. Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Make rbdplugin pod work in a non-initial network namespace (i.e. with "hostNetwork: false") by skipping waiting for udev events when mapping and unmapping images. CSI use case is very simple: all that is needed is a device node which is immediately fed to mkfs, so we should be able to tolerate udev not being finished with the device just fine. Fixes: ceph#1323 Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
298593f
to
795d68b
Compare
With ceph:v15.2.8 pushed, this is good to go! |
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.
LGTM, unit tests for appendDeviceTypeAndOptions()
would have certainly been a good addition but I'm not familiar enough with the repo to request them.
Hi all, I believe I've run into a race condition resulting in data loss following this patch whereby, when re-attaching a PVC with The basic idea of the race condition is that:
Detailed diagnostics are in Issue #1820. I am new to ceph-csi, so could be missing something obvious. Please feel free to challenge my test cases and diagnostics. |
Replied in #1820. |
Depends on ceph/ceph#36927, see discussion in #1323.
Only compile tested at this point.