csi: adding new command csi-debug

[subhamkrai]

csi: adding new command csi-debug

command csi-debug dmesg <node_name> will help printing
the dmesg logs where pvc mounting is failing or the
csi-rbdplugin container of the csi-rbdplugin-xxxx pod on that node.

Signed-off-by: subhamkrai [email protected]

[subhamkrai]

part of #69

[Madhu-1]

Looks like i forgot to submit my last comment 🗡️

My idea was to keep it simple for this user as below. Let me know what do you think about it.

kubectl rook_ceph csi-debug dmesg <pod-name> <pod-namespace>

• Get the pod details and extract Node where it is scheduled
• Get the PVC details from the PVC Name in the pod spec and check its rbd or cephfs
• Now from the NodeID in the pod spec get to the exact csi driver nodeplugin
• Exec into the nodeplugin pod and run required command , In this case its dmesg

The above three steps will remain the same for pod debugging, and they can be reused. Good to have it as a helper function and only the last command will change most of the cases.

[subhamkrai]

Looks like i forgot to submit my last comment dagger

My idea was to keep it simple for this user as below. Let me know what do you think about it.

kubectl rook_ceph csi-debug dmesg <pod-name> <pod-namespace>

• Get the pod details and extract Node where it is scheduled
• Get the PVC details from the PVC Name in the pod spec and check its rbd or cephfs
• Now from the NodeID in the pod spec get to the exact csi driver nodeplugin
• Exec into the nodeplugin pod and run required command , In this case its dmesg

The above three steps will remain the same for pod debugging, and they can be reused. Good to have it as a helper function and only the last command will change most of the cases.

make sense, if we can keep the 1st and 2nd as helper method for most of the csi debug command and last one changes, will do the changes

[subhamkrai]

will add ci and doc for this command

[travisn]

The user may not even know about csi. What about a more generic command such as getting the volume health, which will go look for various issues that could contribute to the volume not being provisioned or mounted?

kubectl rook-ceph volume health <pod-name> <pod-namespace>

Running dmesg seems like a very specific command and could have a lot of output. What if instead we print some health info about the cluster, the csi pods, and then print the name of the pod where we suggest they run dmesg? Or maybe it is useful to run dmesg for them, I'm just looking for how we can make this as useful as possible for users. Some troubleshooting commands will need to be more advannced, and some should be simpler as well. Maybe dmseg just seems like the complex place to start.

[Madhu-1]

The user may not even know about csi. What about a more generic command such as getting the volume health, which will go look for various issues that could contribute to the volume not being provisioned or mounted?

kubectl rook-ceph volume health <pod-name> <pod-namespace>

Running dmesg seems like a very specific command and could have a lot of output. What if instead we print some health info about the cluster, the csi pods, and then print the name of the pod where we suggest they run dmesg? Or maybe it is useful to run dmesg for them, I'm just looking for how we can make this as useful as possible for users. Some troubleshooting commands will need to be more advannced, and some should be simpler as well. Maybe dmseg just seems like the complex place to start.

sounds good. we can add this command looks much simpler but we need to change the argument from pod name to PVC name as the PVC is created by not attached to a pod.

[subhamkrai]

We are moving the project to golang, so it is not a valid change. Closing!