feat: allow for a range of 2 controller ids when publishing #524
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Previously we had a strict limit of only 1 controller range. This effectively means only 1 initiator can connect to our volume target. However it seems that when an initiator times out before the target "notices" this we end up getting a new connection whilst the old one is still in place, and thus the new connect call fails! Why were we so strict? Because the current code in the dataplane can not guarantee that older initiators connected with allow_any set to true will be disconnected when we set a new allowed list! So is it safe to bump this? We believe so, because currently CSI sets allowed list of 1 for all published volumes, so when updating this list the previous one should be booted out! todo: update dataplane to boot out any connected host! Signed-off-by: Tiago Castro <[email protected]>
mtzaurus
approved these changes
May 16, 2023
|
bors merge |
|
Build succeeded! The publicly hosted instance of bors-ng is deprecated and will go away soon. If you want to self-host your own instance, instructions are here. If you want to switch to GitHub's built-in merge queue, visit their help page. |
bors bot
pushed a commit
that referenced
this pull request
May 17, 2023
525: Cherry-pick #524 r=tiagolobocastro a=tiagolobocastro feat: allow for a range of 2 controller ids when publishing Previously we had a strict limit of only 1 controller range. This effectively means only 1 initiator can connect to our volume target. However it seems that when an initiator times out before the target "notices" this we end up getting a new connection whilst the old one is still in place, and thus the new connect call fails! Why were we so strict? Because the current code in the dataplane can not guarantee that older initiators connected with allow_any set to true will be disconnected when we set a new allowed list! So is it safe to bump this? We believe so, because currently CSI sets allowed list of 1 for all published volumes, so when updating this list the previous one should be booted out! todo: update dataplane to boot out any connected host! Co-authored-by: Tiago Castro <[email protected]>
bors bot
pushed a commit
that referenced
this pull request
May 17, 2023
525: Cherry-pick #524 r=tiagolobocastro a=tiagolobocastro feat: allow for a range of 2 controller ids when publishing Previously we had a strict limit of only 1 controller range. This effectively means only 1 initiator can connect to our volume target. However it seems that when an initiator times out before the target "notices" this we end up getting a new connection whilst the old one is still in place, and thus the new connect call fails! Why were we so strict? Because the current code in the dataplane can not guarantee that older initiators connected with allow_any set to true will be disconnected when we set a new allowed list! So is it safe to bump this? We believe so, because currently CSI sets allowed list of 1 for all published volumes, so when updating this list the previous one should be booted out! todo: update dataplane to boot out any connected host! Co-authored-by: Tiago Castro <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously we had a strict limit of only 1 controller range. This effectively means only 1 initiator can connect to our volume target.
However it seems that when an initiator times out before the target "notices" this we end up getting a new connection whilst the old one is still in place, and thus the new connect call fails!
Why were we so strict? Because the current code in the dataplane can not guarantee that older initiators connected with allow_any set to true will be disconnected when we set a new allowed list!
So is it safe to bump this? We believe so, because currently CSI sets allowed list of 1 for all published volumes, so when updating this list the previous one should be booted out!
todo: update dataplane to boot out any connected host!