-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Update OSFileWatcher to support symlinks #6172
Conversation
Thanks for your pull request. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please follow instructions at https://git.k8s.io/community/CLA.md#the-contributor-license-agreement to sign the CLA. It may take a couple minutes for the CLA signature to be fully registered; after that, please reply here with a new comment and we'll verify. Thanks.
Instructions 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. I understand the commands that are listed here. |
Hi @timmysilv. 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. Instructions 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. |
/ok-to-test |
/retest |
The new test being introduced passes without the patch:
Can you fix that first? The test should simulate the bug this PR is fixing. |
Fixed the test to drill a little deeper, the same way k8s does with secrets. Thanks for catching that - maybe I should start writing tests before writing patches 🤔 |
internal/watch/file_watcher_test.go
Outdated
|
||
if targetName != target1.Name() { | ||
t.Fatalf("expected symlink to point to %v, not %v", target1.Name(), targetName) | ||
} |
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'd move this assertion right below line 96. By reading the code I thought this assertion somehow depends on what is happening between line 97 and 113, but seems like they are unrelated.
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 put it here because I wanted to wait until everything was set up (including the fileWatcher itself) to assert this, but I'm fine to move it to line 97. I should hope the creation of the watcher doesn't do anything weird :)
} else if finfo.Mode()&os.ModeSymlink != 0 { | ||
if currentRealFile, err := filepath.EvalSymlinks(f.file); err == nil && | ||
currentRealFile != realFile { | ||
f.onEvent() |
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.
Do you not have to condition this on strings.HasSuffix(event.Name, file)
? Why?
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.
the FileWatcher watches the entire directory (that's not new behaviour). Using the example in the PR description, the watcher will watch $dir/ca.crt, which is a symlink to $dir/..data/ca.crt, which is a symlink to $dir/..<dated_dir>/ca.crt. The CREATE
event in $dir is not for a file called ca.crt
(which would have the correct suffix), but for a directory called ..data
which symlinks to the dated directory. However, the watcher should detect that the top-level symlink ($dir/ca.crt
) now points to a different file, and trigger an event.
tl;dr when any file is created in the directory being watched, this FileWatcher should confirm if the symlink it was told to monitor has been updated somewhere within the directory (maybe deeper than 1 level).
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.
More details: this comment shows the internal order of events.
/test pull-ingress-nginx-test |
/lgtm @aledbf can you also take a look? |
/hold until the second review |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: aledbf, ElvinEfendi, timmysilv 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 |
This is cherry-picked from PR: kubernetes#6172 , to backport the feature to auto-reload certs on k8s secrets changes to 0.35.0 , upstream merged thin in 0.40.0.
This PR modifies the wrapper around fsnotify's file Watcher to watch symlinks in a custom manner such that if the symlink itself triggers an event and the target has been updated since the last event, the event should be called.
What this PR does / why we need it:
This PR is needed because fsnotify auto-resolves symlinks internally. fsnotify/fsnotify#199 provides a little bit of context on their internals/decisions. The problem that results from this is that any watcher on a file which is a kubernetes secret will not detect updates, due to the symlink nature of them. Here's a glimpse of an example directory:
This change will allow for libraries that auto-update secrets (such as
cert-manager
for webhook server certs in the above example) to work without interference.Types of changes
How Has This Been Tested?
kind
deploy manifest, deleted and recreated theingress-validation-admission
secret and confirmed that the validation webhook server reloaded the TLS files as expected.Checklist: