Revert "Create xtables.lock as a file if it doesn't already exist" #2889
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
skitt
added
the
backport
skitt
requested review from
Oats87,
sridhargaddam and
tpantelis
as code owners
|
🤖 Created branch: z_pr2889/skitt/revert-xtables-lock-mount |
This reverts commit 93f8d3a. The xtables.lock mount was fixed to specify its type: it must exist as a file, or be created as a file. xtables.lock is only used with legacy iptables. On platforms using iptables-nft, the file isn't used and doesn't exist. As a result, previous versions of Submariner created it as a directory (this is the default behaviour for volume mounts in Kubernetes: if the mount doesn't exist, it is created as a directory). When the volume mount type is specified as a file, the existence of a directory causes the mount to fail and the corresponding pod is never scheduled. To avoid this, revert to the default behaviour. On systems where the lock is important, it already exists so the directory isn't created and the correct behaviour is guaranteed. On systems where the lock isn't needed, it is created as a directory but that doesn't matter. Future releases of Submariner will have to deal with this correctly, and handle upgrades, ideally without mounting all of /run permanently. Signed-off-by: Stephen Kitt <[email protected]>
skitt
force-pushed
the
revert-xtables-lock-mount
branch
from
ea3ae55 to
62f56e6
Compare
sridhargaddam
approved these changes
Nov 14, 2023
tpantelis
approved these changes
Nov 14, 2023
|
🤖 Closed branches: [z_pr2889/skitt/revert-xtables-lock-mount] |
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.
This reverts commit 93f8d3a.
The xtables.lock mount was fixed to specify its type: it must exist as a file, or be created as a file.
xtables.lock is only used with legacy iptables. On platforms using iptables-nft, the file isn't used and doesn't exist. As a result, previous versions of Submariner created it as a directory (this is the default behaviour for volume mounts in Kubernetes: if the mount doesn't exist, it is created as a directory). When the volume mount type is specified as a file, the existence of a directory causes the mount to fail and the corresponding pod is never scheduled.
To avoid this, revert to the default behaviour. On systems where the lock is important, it already exists so the directory isn't created and the correct behaviour is guaranteed. On systems where the lock isn't needed, it is created as a directory but that doesn't matter.
Future releases of Submariner will have to deal with this correctly, and handle upgrades, ideally without mounting all of /run permanently.