Refs #12715 - decoupled logs API from core #367
Conversation
|
@witlessbird could you give it a quick read? |
lzap
force-pushed
the
log-buffer-module
branch
from
98b4df5
to
0cb3e46
Compare
| @@ -5,7 +5,7 @@ config/settings.d/*.yml | |||
| config/migration_state | |||
| config_*/* | |||
| .idea | |||
| logs | |||
| /logs | |||
There was a problem hiding this comment.
Because it ignores all logs subdirectories, we want only the proxy logs.
| # Can be true, false, or http/https to enable just one of the protocols | ||
| :enabled: false | ||
|
|
||
| # Log buffer configuration is in core file (settings.yml) |
There was a problem hiding this comment.
If log buffer is only used to show it in the Foreman smart proxy page - can we move the log_buffer and log_buffer errors to this file instead?
There was a problem hiding this comment.
This config file deals with log api only (exposing events over http). This module may or may not be enabled, but internal logging is always available.
I think the main settings file is a good spot for these.
lzap
force-pushed
the
log-buffer-module
branch
from
0cb3e46
to
6613a72
Compare
theforeman-bot
added
Needs re-review
Needs testing
and removed
Waiting on contributor
labels
|
I get a very strange stack trace after this change, and I can't start the proxy after this change. Not sure what does this module have to do with Puppet initialization though... |
|
Don't think this is related to that change -- this appears to be a conflict between two versions of puppet: one from /usr/share/ruby/vendor_ruby and another /usr/local/share/gems/gems/puppet-3.6.2. I suspect this is happening when puppet_proxy or puppet_ca module is being loaded... |
This decouples the log buffer API from core. It has two main purposes. First,
it's a cleaner design. Second, clients can now use the standard Features API to
detect, if Logs API is enabled. Therefore integration with older version of
Smart Proxies is easier.