[WIP] Add secret monitor for Routes#1518
Conversation
|
Skipping CI for Draft Pull Request. |
|
Hi @thejasn, I would like to get some context before I start reviewing this PR (or reading the KEP). |
1b5e110 to
75490f9
Compare
75490f9 to
24c65a5
Compare
24c65a5 to
88b71e4
Compare
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: thejasn The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
Fixes one-to-many mapping of secret to multiple routes
|
/cc @deads2k |
pkg/route/monitor/monitor.go
Outdated
| } | ||
|
|
||
| type Object struct { | ||
| RefCount int |
There was a problem hiding this comment.
This seems more suitable as a property tracked by the caller.
There was a problem hiding this comment.
Yeah I would agree, will rework this bit.
pkg/route/monitor/monitor.go
Outdated
| type objectKey struct { | ||
| namespace string | ||
| name string | ||
| uid types.UID |
There was a problem hiding this comment.
top-to-bottom, I'm surprised to see UID.
pkg/route/secret/secret_monitor.go
Outdated
|
|
||
| // Monitor manages Kubernetes secrets. This includes retrieving | ||
| // secrets or registering/unregistering them via Routes. | ||
| type Monitor interface { |
There was a problem hiding this comment.
I think we need something like
type SecretEventHandlerRegistration interface{
ResourceEventHandlerRegistration
UID() string
}
type SecretMonitor interface{
AddEventHandler(namespace, name string, handler ResourceEventHandler) (SecretEventHandlerRegistration, error)
RemoveEventHandler(SecretEventHandlerRegistration) error
}This will allow an eventHandler for every route (overlapping secrets). It's not perfectly efficient, but it is easy. And handler passed in could wire back to a route to be queued in a different controller. Need a link to your calling code to see how to wire that back in.
We might also need a way to get a list of all known eventHandlers to diff against the current state (re-list after an outage), but if the caller correctly handles deletes we may not need it. It is a potential spot for a leak.
There was a problem hiding this comment.
See the 1.27 SharedInformer interface for where I got inspiration and how can you wire it up through a sharedinformer versus a regular informer.
There was a problem hiding this comment.
So I understand your suggestion as, we need an abstraction between the secret watching logic and And the caller (the component that interfaces with Routes) in form of (do correct me if I understood it incorrectly)
type SecretMonitor interface{
AddEventHandler(namespace, name string, handler ResourceEventHandler) (SecretEventHandlerRegistration, error)
RemoveEventHandler(SecretEventHandlerRegistration) error
}See the 1.27 SharedInformer interface for where I got inspiration and how can you wire it up through a sharedinformer versus a regular informer.
Are you also suggesting I replace the use of the regular informer in the implementation with a sharedinformer?
Add SecretEventHandlerRegistration and SecretMonitor interface as an abstraction for secret watchers and consume the SecretMonitor via a Manager that interfaces with routes
|
opened #1554 to adjust the secretmonitor. see if it makes sense. |
Replace informer with sharedinformer
|
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
|
Stale issues rot after 30d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle rotten |
|
Rotten issues close after 30d of inactivity. Reopen the issue by commenting /close |
|
@openshift-bot: Closed this PR. DetailsIn response to this:
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. |
Related: CFE-866
Implements: openshift/enhancements#1307