Separate router_v1 and router

[zeripath]

Make the old router available as router_v1, clarify docs and set the
log levels coloring.

Signed-off-by: Andrew Thornton art27@cantab.net

[wxiaoguang]

I can not understand why should we introduce so many setting options to keep the router_v1.

What's the Pros/Cons of using these options instead of ROUTER_LOG_LEVEL + ROUTER_LOG_HANDLER ? Is there any real case I can learn from?

And in my mind we might want to deprecate (remove) router v1 in future, but these options (code/document) make it more complex.

[zeripath]

I think it's clearer to separate out the old logger instead of overloading the meaning of the configuration parameters.

For example, your PR proposed changing the meaning of ROUTER_LOG_LEVEL to do something very different from what it does on the original router.

Then we simply deprecate these and remove them in 1.17 leaving in code that checks for the existence of the configuration - which causes a warning that this has been removed and finally in 1.18 remove even the check.

If we use the ROUTER_LOG_HANDLER=v2 then we're gonna end up having to keep checking that version and there's no way for a user to have both routers running for a while so they can migrate more easily.

[wxiaoguang]

IMO, we should unify and simplify the logger system, instead of introducing new specialized settings to make it more complex. Maybe we can narrow down the changes to:

1. Keep router v1 in 1.16
2. Deprecate v1 and ROUTER_LOG_LEVEL (the remove them in 1.17 or 1.18)
3. Only introduce one setting option ROUTER_LOG_HANDLER
4. In v2, we do not use ROUTER_LOG_LEVEL anymore, instead, we only show logs at Debug/Info/Warning levels.

I can not imagine a real use case for users to use v1 and v2 and the same time.

[wxiaoguang]

@zeripath bump ~~

[zeripath]

Adding suffices of V1 to the configuration of the ROUTER_V1 is the right thing to do here. It means that if you want the old router behaviour - or need it whilst you're migrating you configure it as ROUTER_V1 and ROUTER_V1_LOG_LEVEL.

• In version 1 almost all users of the ROUTER logger will not have set ROUTER_LOG_LEVEL so the change of name won't negatively affect them.
• In version 2 there is no use of ROUTER_LOG_LEVEL so we can easily deprecate it and ROUTER_V1_*
• We immediately deprecate ROUTER_V1_* ROUTER_V1_LOG_LEVEL

I don't see any benefit to ROUTER_LOG_HANDLER.

I can easily imagine a use case for v1 and v2 - temporarily - I wouldn't have written this code if I couldn't see it.

[wxiaoguang]

I don't see any benefit to ROUTER_LOG_HANDLER.

ROUTER_LOG_HANDLER is much easier and simpler than introducing many new setting options like ENABLE_ROUTER_V1 / ROUTER_V1 / ROUTER_V1_LOG_LEVEL.

I can easily imagine a use case for v1 and v2 - temporarily - I wouldn't have written this code if I couldn't see it.

To be honest, I still can not get the point why v1 and v2 should co-exist.

Even if the v1 and v2 co-exist temporarily, that should be for development and refactoring purpose. After this PR gets merged (and we finish the refactoring), are there still users who need to see v1 and v2 logs at the same time? What could they do after reading v1 and v2 logs? If they want to see the differences, they can simply first use v1 to collect some logs and then use v2 to collect logs. If they decide to stay with v1, just set ROUTER_LOG_HANDLER=v1, if they decide to migrate to v2, just set ROUTER_LOG_HANDLER=v2, no need to make v1 and v2 co-exist.