You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
However, the philosophy of the dispatcher dictates that the main process should never connect to the database for any reason other than listening. We reserve the option to operate without other python imports before starting the main loop.
This proposes that the main process buffers logs in the form in which they are originally called. Thus, it would keep info like
main, debug, "this is a message"
pool, info, "this is another message"
Then, it would periodically flush the buffered log messages by running a task in a worker. The worker will log these using normal python logging calls.
The main process will dual-log to some other file (optionally), which can be configured, but not by normal python utilities. If you configuring logging of disaptcher path using normal python utilities, then this configures where the worker will send the logs. This main-process log will also use some intentionally weird logger, like hazmat_dispatcher, to help make it clear to people that they should not configure it by normal python logging config. This would ideally be file-based logging for desperation logging.
The text was updated successfully, but these errors were encountered:
Right now, all dispatcher modules log to
__name__
logger.This will be a problem for AWX. Why?
Because for any logs received by AWX, these will be sent to a logging that uses a filter that requires access to the database.
https://github.com/ansible/awx/blob/68055bb89f74bd4284da7f9ac55f9813e8936d6d/awx/settings/defaults.py#L750-L755
However, the philosophy of the dispatcher dictates that the main process should never connect to the database for any reason other than listening. We reserve the option to operate without other python imports before starting the main loop.
This proposes that the main process buffers logs in the form in which they are originally called. Thus, it would keep info like
Then, it would periodically flush the buffered log messages by running a task in a worker. The worker will log these using normal python logging calls.
The main process will dual-log to some other file (optionally), which can be configured, but not by normal python utilities. If you configuring logging of
disaptcher
path using normal python utilities, then this configures where the worker will send the logs. This main-process log will also use some intentionally weird logger, likehazmat_dispatcher
, to help make it clear to people that they should not configure it by normal python logging config. This would ideally be file-based logging for desperation logging.The text was updated successfully, but these errors were encountered: