Refactor the way our Controllers watch ConfigMaps#1351
Refactor the way our Controllers watch ConfigMaps#1351google-prow-robot merged 4 commits intoknative:masterfrom
Conversation
There was a problem hiding this comment.
I'd rather this package be called configuration and this interface be called Watcher
There was a problem hiding this comment.
What about configmap for the package, Interface => Watcher and Watcher => Observer?
I'd like to avoid confusion with our Configuration resources. Yay, naming!
There was a problem hiding this comment.
I went with this, but also renamed New[Fixed] => New{Default,Fixed}Watcher for clarity.
There was a problem hiding this comment.
We can follow the client-go convention and not perform a DeepCopy - but I would expect each controller storing said ConfigMap to perform a DeepCopy themselves.
It would be worth documenting this on the configurationmanager interface
There was a problem hiding this comment.
Might be useful to add a check to see whether this instance is already started or not and return an error in case it is already started.
There was a problem hiding this comment.
I like the wording here :-) But might since we are logging below and since we are going to be public soon, might be better off to remove this line.
There was a problem hiding this comment.
My debugging snuck in! Will remove, good catch. 😊
|
/lgtm |
a6ceb7a to
58817da
Compare
Previously the Revision and Route controllers used a ConfigMap informer directly to watch for changes. This generalizes that pattern into a slightly higher level abstraction under `pkg/configmap`.
With this `configmap.Watcher` abstraction, Controllers simply register to `Watch` particular `ConfigMap`s for changes via a callback:
```go
cm.Watch("configmap-name", c.receiveSomeConfig)
```
Once `Start()` is called on the `configmap.Watcher` all of the registered `configmap.Observers` will be invoked with the initial state of their `ConfigMap`s, and if any are not found the call to `Start()` will return an error. This consolidates the setup and update logic for the various configurations behind a single interface.
This transitions the `NetworkConfig` and `DomainConfig` logic, which already employ this pattern (sans abstraction) to this abstraction.
Fixes: knative/serving#1242
Rename `network_config.go` to have a consistent filename with `domainconfig.go`.
Also renamed defaultImpl's `watchers` field to `observers` to be consistent with the original intent.
|
/test pull-knative-serving-go-coverage |
3 similar comments
|
/test pull-knative-serving-go-coverage |
|
/test pull-knative-serving-go-coverage |
|
/test pull-knative-serving-go-coverage |
There was a problem hiding this comment.
It looks like this doesn't block so no need for go
https://github.com/kubernetes/client-go/blob/master/informers/factory.go#L124
Unless you meant to start the di.informer explicitly?
There was a problem hiding this comment.
In that case you can remove the shared informer factory sif from defaultImpl
There was a problem hiding this comment.
Interesting. I copied what we do in ./cmd/controller/main.go, which copied: https://github.com/kubernetes/sample-controller/blob/master/main.go#L68-L69.
TIL.
There was a problem hiding this comment.
For readability assign the lambda to a some var
ie.
startInformerFunc := func() error {
...
}
if err := startInformerFunc(); err != nil {
...
}or maybe it just simply warrants a separate function
There was a problem hiding this comment.
I split this into a couple sub-functions which I definitely thinks helps this self-document a bit better.
There was a problem hiding this comment.
Based on prior comments it seems like you could just take in just a single ConfigMapInformer
There was a problem hiding this comment.
Given that the Watch method only takes a name (read: no namespace), I'd like the interface for constructing a Watcher to bear the responsibility of filtering to a single namespace, which AFAIK is only possibly if we own the construction of the SharedInformerFactory that creates the informer.
split Start into a handful of descriptively named helpers. Don't Start in a go routine, since it doesn't block on SharedInformerFactory.
|
The following is the coverage report on pkg/. Say
*TestCoverage feature is being tested, do not rely on any info here yet |
|
Going to remove WIP. I'd started to migrate the Controller usage of (my current thinking) // Load reads a mounted ConfigMap from disk, returns the equivalent of it's `Data` field.
func Load(path string) (map[string]string, error) {...}Then as I refactor the various parts of |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mattmoor, mdemirhan The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/hold remove |
|
/hold cancel |
Previously the Revision and Route controllers used a ConfigMap informer directly to watch for changes. This generalizes that pattern into a slightly higher level abstraction under
pkg/configurationmanager.With this
configurationmanager.Interfaceabstraction, Controllers simply register toWatchparticularConfigMaps for changes via a callback:Once
Start()is called on theconfigurationmanager.Interfaceall of the registered watchers will be invoked with the initial state of their configs, and if any are missing the call toStart()will return an error. This consolidates the setup and update logic for the various configurations behind a single interface.This transitions the NetworkConfig and DomainConfig logic, which already employ this pattern (sans abstraction) to this abstraction.
Fixes: #1242