Create loggers in controllers main function.#303
Conversation
|
/assign @mattmoor |
| // If configuration is empty, a fallback configuration is used. | ||
| // If configuration cannot be used to instantiate a logger, | ||
| // the same fallback configuration is used. | ||
| func NewLogger(configJSON string, levelOverride string) (*zap.SugaredLogger, zap.AtomicLevel) { |
There was a problem hiding this comment.
Why wrap these? Just to avoid repeating components...?
| limitations under the License. | ||
| */ | ||
|
|
||
| package logkey |
There was a problem hiding this comment.
What about putting just this and the yaml in pkg/logconfig (and then callers would import knative/pkg/logging and knative/eventing/pkg/logconfig)?
There was a problem hiding this comment.
you may hate the new change more... Lets see. I moved the relevant keys to apis.
|
/assign evankanderson |
|
The following is the coverage report on pkg/.
|
|
Ready. PTAL @evankanderson |
|
/retest |
|
|
||
| // Watch the logging config map and dynamically update logging levels. | ||
| configMapWatcher := configmap.NewDefaultWatcher(kubeClient, system.Namespace) | ||
| configMapWatcher.Watch(logconfig.ConfigName, logging.UpdateLevelFromConfigMap(logger, atomicLevel, logconfig.Controller, logconfig.Controller)) |
There was a problem hiding this comment.
That is very cool and will be extremely useful :)
pmorie
left a comment
There was a problem hiding this comment.
LGTM, one thing I noticed
| @@ -44,10 +56,46 @@ type ProvideFunc func(manager.Manager) (controller.Controller, error) | |||
|
|
|||
| func main() { | |||
| flag.Parse() | |||
There was a problem hiding this comment.
Not an issue w/ your PR, but we should consider renaming these binaries slightly; 'controller' runs the bus controllers and 'controller-manager' runs the flow, feed, etc controllers.
There was a problem hiding this comment.
I'll create an issue for this.
There was a problem hiding this comment.
I have some code that combines these into a single deployment, but haven't PR'd it: master...grantr:combine-controllers
| if err != nil { | ||
| log.Fatalf("Error parsing logging configuration: %v", err) | ||
| } | ||
| logger, atomicLevel := logging.NewLoggerFromConfig(config, logconfig.ControllerManager) |
There was a problem hiding this comment.
where do we use atomicLevel?
There was a problem hiding this comment.
configMapWatcher.Watch(logging.ConfigName, logging.UpdateLevelFromConfigMap(logger, atomicLevel, logLevelKey))
|
|
||
| // Watch the logging config map and dynamically update logging levels. | ||
| configMapWatcher := configmap.NewDefaultWatcher(kubeClient, system.Namespace) | ||
| configMapWatcher.Watch(logconfig.ConfigName, logging.UpdateLevelFromConfigMap(logger, atomicLevel, logconfig.ControllerManager, logconfig.ControllerManager)) |
There was a problem hiding this comment.
It would be nice to be able to encapsulate the 35 new lines in pkg/logging, but I think that's a follow-on PR.
There was a problem hiding this comment.
I agree. Had the same thought as I was adding this.
|
|
||
| // Setup a Manager | ||
| mrg, err := manager.New(config.GetConfigOrDie(), manager.Options{}) | ||
| mrg, err := manager.New(clientconfig.GetConfigOrDie(), manager.Options{}) |
There was a problem hiding this comment.
I presume this rename is to distinguish from logconfig?
There was a problem hiding this comment.
yes but it could go back now...
| defer cancel() | ||
| srv.Shutdown(ctx) | ||
|
|
||
| glog.Flush() |
There was a problem hiding this comment.
Hah, I think you caught a bug here. Nice!
|
|
||
| logger.Info("Starting the Controller Manager") | ||
|
|
||
| logf.SetLogger(logf.ZapLogger(false)) |
There was a problem hiding this comment.
Add a comment that this doesn't do anything yet.
There was a problem hiding this comment.
@grantr for details, this does nothing yet right?
There was a problem hiding this comment.
This tells controller-runtime to use zap to log internal messages. We could eventually use the https://github.com/go-logr/logr abstraction for controller logging also, but there's no need for it right now.
| volumeMounts: | ||
| - name: config-logging | ||
| mountPath: /etc/config-logging | ||
| volumes: |
There was a problem hiding this comment.
It looks like we're both mounting a ConfigMap, and using the k8s watcher on the ConfigMap object (because you're feeding in a k8s client). We should just be able to use inotify on the file:
https://github.com/fsnotify/fsnotify looks promising.
There was a problem hiding this comment.
The autoscaling group found that inotify on configmaps is very slow, normally taking 30+ seconds to propagate updates to volumes. I think we can probably drop the volume mount now that we have the configmap watch.
There was a problem hiding this comment.
I vote make this an issue and do a followup pass. Having loggers is more valuable than optimizing i think
There was a problem hiding this comment.
Yes, this was intended to be a followup, not a blocker.
|
/test pull-knative-eventing-integration-tests |
|
Ready to go in @evankanderson PTAL? |
evankanderson
left a comment
There was a problem hiding this comment.
/lgtm
/approve
One minor nit, but it doesn't block getting this in.
| log.Fatalf("Error parsing logging configuration: %v", err) | ||
| } | ||
| logger, atomicLevel := logging.NewLoggerFromConfig(config, logconfig.ControllerManager) | ||
| logger, atomicLevel := logging.NewLoggerFromConfig(cfg, logconfig.ControllerManager) |
There was a problem hiding this comment.
Do we use atomicLevel anywhere? If not, should we name it "_"?
There was a problem hiding this comment.
it is used in the watch call
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: evankanderson, n3wscott 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 |
|
/retest |
* Starting to add webhook. * Adding logging config for eventing to be used with knative/pkg/logging. * Revert webhook change. * Revert webhook change. * Add a test to make sure happy path is happy for getting logger in eventing. * Adding config-logging to the main config. * Remove owners file. * Moving to just use named loggers in the controllers. * Use logging config for controller name. * Add newlines to the yaml. * Adding logging creation and config reading to the controllers now. * Don't dep on glog in cmd. * Cleanup based on review.
* Starting to add webhook. * Adding logging config for eventing to be used with knative/pkg/logging. * Revert webhook change. * Revert webhook change. * Add a test to make sure happy path is happy for getting logger in eventing. * Adding config-logging to the main config. * Remove owners file. * Moving to just use named loggers in the controllers. * Use logging config for controller name. * Add newlines to the yaml. * Adding logging creation and config reading to the controllers now. * Don't dep on glog in cmd. * Cleanup based on review.
There is a small amount of config that needs to be in our repo to integrate with knative/pkg/logging. This is that config.
Also creating the loggers (but not passing them to the controller impls.)