openerp-expert-framework team mailing list archive

[Xavier Morel <xmo@xxxxxxxxxxx>]

----------------
Rationale
=========

All in all, the `netsvc.Logger` API is pretty pointless: it's verbose — extremely so when repeatedly using the same channel — it doesn't clearly use the hierarchical nature of the `logging` package and it doesn't fundamentally have any advantage over using `logging` raw. Its configurability is also very limited compared to the options `logging` provides.

Solution
========

But because it's built on top of `logging`, any configuration performed for `netsvc.Logger ` by OpenERP is actually performed for `logging`, which means it's possible to use `logging` right now without any issue: `logging.getLogger('foo').info('bar')` is completely equivalent to `netsvc.Logger().notifyChannel('foo', netsvc.LOG_INFO, 'bar')`.

Path of evolution
=================

Phase 1 − 5.2
-------------
On calls to `netsvc.Logger().notifyChannel`, issue `PendingDeprecationWarning`. Because it's ignored by default, this won't change the behavior of the server unless using `-Wall`, `-Werror` or otherwise explicitly activating the display of PendingDeprecationWarning. Furthermore, even if activated as long as `-Werror` isn't used it will simply output a warning message to stderr (by default).

Strongly suggest that new logging be done via `logging` (by creating custom, hierarchical loggers), and that if existing logging code (trunk and addons alike) is touched `netsvc.Logger().notifyChannel` calls be replaced by the equivalent `logging` calls.

Phase 2 − next(5.2)
-------------------
Replace `PendingDeprecationWarning` by `DeprecationWarning`. `DeprecationWarning` is enabled by default (nb: except in Python 2.7, DeprecationWarning is now disabled by default unless using −3) which means it will appear to all developers unless explicitly silenced. As far as coding suggestions/standards go, same as phase 1.

Add a "regular" `logging` configuration to the current scheme (using `logging.config.fileConfig` to allow administrators and users to finely tune their logging via a logging config file, giving everybody full access to the `logging` API), optionally enable `logging`'s reconfiguration server (allows altering the logging configuration of a running system, useful to try to track issues without restarting the server as long as there is enough logging performed).

Mark the existing logging command-line switches (--log-level, --logfile, --syslog, --no-logrotate) as deprecated (issue `DeprecationWarning` when they're set), introduce a more standard set of log level switches (using multiple invocations of -q and -v switching between levels, with a default level of "WARNING" unless ortherwise configured in the logging file, `-vv` would be equvalent to `--log-level=debug`, `-qq` would be `--log-level=critical`).

Phase 3 - next(next(5.2))
-------------------------
Remove `netsvc.Logger` entirely, remove the existing python-based configuration scheme, replace it with an equivalent default logging.conf (logging can sequentially read several configuration files)

Remove logging configuration from the OpenERP configuration file (it moves entirely to "logging.conf"), remove the corresponding (deprecated) command-line switches entirely.

Future usage of logging
=======================

Ideally, there should be far more logging than currently in OpenERP (and with the finer-grained logging.conf file & conf server it becomes possible to selectively silence specific loggers and logger hierarchies and dynamically reconfigure a server instance). Furthermore each object should have its own logger with the naming form {addon}.{object_name} (which means, among other things, that the `stock.move` methods redefined in `purchase` would log as `purchase.stock.move`, not `stock.stock.move`, potentially making debuggings and post-mortems much easier).

Documentary needs
=================

The coding standard would need to be documented of course (where?), and a basic documentation for the creation of logging configuration files (as well as a way to send new configurations to a running server) should be created for phase 2 (the official `logging` configuration isn't bad per se, but it's a bit dense and aimed at Python programmers rather than e.g. system administrators).
----------------

So, what do you all think of this plan?

--
Xavier Morel
Developper
OpenERP - Tiny SPRL