Set session scanning to manual to avoid discovering all iSCSI devices…#90985
Set session scanning to manual to avoid discovering all iSCSI devices…#90985k8s-ci-robot merged 1 commit intokubernetes:masterfrom
Conversation
|
Hi @mrobson. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions 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. |
|
/release-note-none |
|
/assign humblec |
|
/ok-to-test |
|
This approach is something I didn't know was possible. I will definitely do some testing of my own to see if this does what I think it does. If so, then we definitely want this change. |
|
Thanks @bswartz - I did some local testing but would appreciate the verification! You can also do it at the session level like: |
|
/retest |
|
Yeah, the approach looks good to me. But lets wait for verification. |
|
For completeness, here is the basic test I ran with 3 LUNs: Preform current discovery / login steps, minus CHAP: All 3 LUNs are discovered: Logout All gone Preform discovery / login steps, minus CHAP, setting Empty Discover one LUN Discover another LUN |
f6856c0 to
ea0fdca
Compare
ea0fdca to
0389209
Compare
|
/retest |
1 similar comment
|
/retest |
|
I'm completed my initial tests and this does indeed seem to work as expected. Just need to make sure this is called on the write codepaths inside kubelet. |
|
@mrobson wrote:
Based on my understanding, there is no session until after you log in, and by the time you log in, it's too late to set this option, so that would not be a viable approach. Setting at the node level does seem to be exactly what we want though. |
|
/retest |
@bswartz From the testing / reproducer we ran, the only time this appears to be an issue is when AttachDisk is called and there is no existing login. Login only occurs again when a server is drained (all pod removed triggering logout), rebooted or when a logout happens naturally when the last mount in use is removed. |
|
The "iscsiadm -o update" command will fail on Ubuntu and Debian because they don't support the "node.session.scan" config option yet. I see that the code handles that case properly by logging a warning. |
|
/lgtm |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jsafrane, mrobson The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/retest |
|
/retest Review the full test history for this PR. Silence the bot with an |
2 similar comments
|
/retest Review the full test history for this PR. Silence the bot with an |
|
/retest Review the full test history for this PR. Silence the bot with an |
|
/retest |
1 similar comment
|
/retest |
|
/retest Review the full test history for this PR. Silence the bot with an |
2 similar comments
|
/retest Review the full test history for this PR. Silence the bot with an |
|
/retest Review the full test history for this PR. Silence the bot with an |
… during login
What type of PR is this?
/kind bug
What this PR does / why we need it:
This PR sets node.session.scan to manual to avoid unused LUNs being discovered and mapped on a node when it does its initial login. If that happens, the devices are never removed.
Which issue(s) this PR fixes:
Fixes #90982
Special notes for your reviewer:
Some older iscsi package may not support node.session.scan - it was added here: open-iscsi/open-iscsi#40
This will not negatively impact anyone and would log a warning letting them know.
Does this PR introduce a user-facing change?:
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: