-
Notifications
You must be signed in to change notification settings - Fork 202
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
Use an alternative CNI lock for read-only config dirs #1122
Use an alternative CNI lock for read-only config dirs #1122
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mheon The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Please don't merge yet, validating in Podman to ensure this works as expected. |
e00abda
to
cc3e192
Compare
Good to merge, verified this works with Podman |
When the configuration directory is on a read-only filesystem, there's no risk of concurrency issues as there's no possibility of changing anything. As such, while it prevents the use of our default lock location, it also removes any need for a lock at all. Making the lock entirely optional is a lot of code, so instead of doing that let's just put it in our temporary files directory, where it can't hurt anything. Signed-off-by: Matthew Heon <mheon@redhat.com>
cc3e192
to
50c2c97
Compare
CI does not seem to have realized I pushed a fresh commit... Github seems to be in a bad way. |
CI is failing trying to download a package from Github. Probably related to the issues GH is having this afternoon? |
@containers/podman-maintainers PTAL |
lgtm, if you end up repushing, mind added the bz #? |
} | ||
} else { | ||
return nil, err | ||
} |
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.
I'm probably overthinking this. But if you establish a lock file in the RunDir due to the CNIConfigDir being readonly, and then that file in CNIConfigDir becomes writeable, could we end up with two lock files, and what does that mean?
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.
Future Podman invocations will use the new read-write lock, so everything should be fine.
Tests green, should be good to merge |
/lgtm |
@mheon I think we would need the same for the netavark backend as well? |
@Luap99 Only requested for CNI for now... Frankly, I don't know how sane a read-only network directory is, so I'm a little hesitant to keep making changes related to it. |
When the configuration directory is on a read-only filesystem, there's no risk of concurrency issues as there's no possibility of changing anything. As such, while it prevents the use of our default lock location, it also removes any need for a lock at all.
Making the lock entirely optional is a lot of code, so instead of doing that let's just put it in our temporary files directory, where it can't hurt anything.