-
Notifications
You must be signed in to change notification settings - Fork 731
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
feat: support multiple sync sources #2852
feat: support multiple sync sources #2852
Conversation
447c40d
to
57ca58d
Compare
Signed-off-by: Alex Pana <8968914+acpana@users.noreply.github.com>
Signed-off-by: Alex Pana <8968914+acpana@users.noreply.github.com>
Signed-off-by: Alex Pana <8968914+acpana@users.noreply.github.com>
Signed-off-by: Alex Pana <8968914+acpana@users.noreply.github.com>
Signed-off-by: Alex Pana <8968914+acpana@users.noreply.github.com>
dirty, refactor: make cm watch aware Signed-off-by: Alex Pana <8968914+acpana@users.noreply.github.com> dirty: frontload with gvk aggregator Signed-off-by: Alex Pana <8968914+acpana@users.noreply.github.com> dirty: use gvk aggregator for config Signed-off-by: Alex Pana <8968914+acpana@users.noreply.github.com> dirty, refactor: replayData is async Signed-off-by: Alex Pana <8968914+acpana@users.noreply.github.com> dirty, refactor: wipe and replay are async Signed-off-by: Alex Pana <8968914+acpana@users.noreply.github.com> dirty, refactor: dual controllers Signed-off-by: Alex Pana <8968914+acpana@users.noreply.github.com> dirty, refactor: nil check props Signed-off-by: Alex Pana <8968914+acpana@users.noreply.github.com> dirty, refactor: cm.Start Signed-off-by: Alex Pana <8968914+acpana@users.noreply.github.com> dirty, fix: mark gvks to sync Signed-off-by: Alex Pana <8968914+acpana@users.noreply.github.com> tests Signed-off-by: Alex Pana <8968914+acpana@users.noreply.github.com>
dirty, squash: config_c changes Signed-off-by: Alex Pana <8968914+acpana@users.noreply.github.com>
Signed-off-by: Alex Pana <8968914+acpana@users.noreply.github.com>
Signed-off-by: Alex Pana <8968914+acpana@users.noreply.github.com>
Signed-off-by: Alex Pana <8968914+acpana@users.noreply.github.com>
Signed-off-by: Alex Pana <8968914+acpana@users.noreply.github.com>
Signed-off-by: Alex Pana <8968914+acpana@users.noreply.github.com>
Signed-off-by: Alex Pana <8968914+acpana@users.noreply.github.com>
57ca58d
to
21b92e9
Compare
@anlandu FYI |
Signed-off-by: Alex Pana <8968914+acpana@users.noreply.github.com>
Signed-off-by: Alex Pana <8968914+acpana@users.noreply.github.com>
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.
1 naming nit and a few write lock acquisitions that should be read lock acquisitions, after that LGTM
Signed-off-by: Alex Pana <8968914+acpana@users.noreply.github.com>
Signed-off-by: Alex Pana <8968914+acpana@users.noreply.github.com>
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.
LGTM, thank you for sticking with it!
✅ |
Signed-off-by: Alex Pana <8968914+acpana@users.noreply.github.com>
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.
Thank you! LGTM pending tests
AFAICT, the root cause is an internal controller race in config_c that triggers an additional reconcile request to be sent down the previous wrapped channel which will block as it's not being read. Signed-off-by: Alex Pana <8968914+acpana@users.noreply.github.com>
c.needToList = false | ||
relistStopChan = make(chan struct{}) | ||
|
||
go c.replayGVKs(ctx, gvksToRelist, relistStopChan) |
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.
This for loop can be spawning a lot of new goroutines. If the new goroutine blocks indefinitely or takes a long time to execute, you could run into a goroutine leak and/or lock contention. is this a concern?
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.
no error handling for c.replayGVKs ?
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 goroutine should stop when the relistStopChan
is closed or ctx
is Done. For now, we log the errors if there's a replay issue with a GVK but we also have a retry mechanism in the func to protect against transient errors.
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 going to merge this in for now but please feel free to reach out if things don't seem quite right.
|
||
// stop any goroutines that were relisting before | ||
// as we may no longer be interested in those gvks | ||
close(relistStopChan) |
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.
we are closing relistStopChan without checking whether it has already been closed, which could result in a panic.
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 invariant here should be that this codesite is the only place that opens/ closes the channel here so we should be good IIRC.
Signed-off-by: Alex Pana <8968914+acpana@users.noreply.github.com>
Signed-off-by: Alex Pana <8968914+acpana@users.noreply.github.com>
This patch introduces a
CacheManager
type to manage any constraint framework data caching needs.