[18.0][ADD] queue_job: per DB channel managers with UI configuration and hot reload

[guewen]

Implements #765 (comment)

Introduction of new configuration parameters

With this in the config file, the job runner uses the static server-side configuration as before, with no hot-reload (single, shared channel manager):

[queue_job]
channels = root:10,root.p1:2

With this in the config file, the job runner uses the channels configured in the database (the job runner builds one channel manager per database):

[queue_job]
max_capacity = 10

When capacity or other options of a channel (or channels are created/deleted, paused) change, the channel manager for the concerned database is hot reloaded.

Capacity can be constrained by database:

[queue_job]
max_capacity = 10
db_max_capacity = 2

Or with patterns

[queue_job]
max_capacity = 10
db_max_capacity = prod_*:6,staging:3,*:1

When db_max_capacity is not configured, each database gets a max capacity of the global max_capacity.
When there is more jobs pending than max_capacity across the databases, a round-robin allows each database to enqueue jobs in turns.

The channels option for server-side configuration takes precedence over the new configuration.

What does this bring?

Using this, I can, for instance

• Pause and resume a channel
• Create a new channel, assign a job function this channel, set a capacity at 1 (or anything) or sequential, all from the UI and applied live by the job runner for a single database

Migration path

Since the server-side configuration (ODOO_QUEUE_JOB_CHANNELS or channels in config file) is used by default, updating the addon has no effect. It allows to configure the channels capacity and other options on the UI / by script of the databases, then the server-side configuration can be replaced by the parameters max_capacity and db_max_capacity (or their environment variables counterparts).

Caveat

When using per DB channel managers, we cannot have a shared channel for several databases since each database has its own channels (use case mentioned in #765 (comment)). It could be possible to implement it using a single channel manager that coexists with the db channel managers, yet to define the specifics, e.g. use another root (shared:3, shared.foo:2) or a new option shared_channels = root.shared where the subchannels defined in this option are excluded from the DB channels.
In the meantime, using the server-side channels instead of per-db channels is a trade-off to accept if this use case is essential for a server.

[OCA-git-bot]

Hi @sbidoul,
some modules you are maintaining are being modified, check this out!

[guewen]

Hi @sbidoul , can I have your thoughts on this, before I start completing the tests and docs?

[OCA-git-bot]

Hi @sbidoul,
some modules you are maintaining are being modified, check this out!

[sbidoul]

Hi Guewen,

I have not had time to do a proper review, but I think I'm on board with this.

Great solution!

I have some doubts about the round robin rule, but on the other hand I don't have serious multi-db use cases myself so this can be addressed later.

[sbidoul]

Handle the new default subchannel capacity too?

[amh-mw]

It looks like the subchannel pull request (#767) has a merge conflict. I'll take a look at it today.

[sbidoul]

Ah I thought that was merged already.