[RFC] Hot reload channels configuration (size, pause, ...) stored in DB

[guewen]

Is your feature request related to a problem?

The configuration of the channels is stored in a configuration file/environment variable and need a restart of the jobrunner to be applied. This proposition aims to bring the possibility to change the configuration on the fly from the UI, which also offers new options such as pausing/resuming a channel.

Describe the solution you'd like

Add fields on queue.job.channel: capacity, sequential, throttle, running (boolean).

In the jobrunner startup, read configuration from model queue.job.channel, fallback on the current implementation based on file/environment variable.

In the queue.job.channel model, when one of the configuration field that concerns the jobrunner is changed, send a pg_notify in the same postgres channel (queue_job), but instead of a job uuid, send reload.

In the Jobrunner, when the payload is reload, go through a cycle close databases/replace the channel manager by a fresh one/configure channels/initialize databases (maybe not necessary to close/initialize database but we have to go through the steps to load all pending jobs in the channels).

Add the "paused" support in the Channel:

• New is_paused=False parameter in Channel
• A method is_paused() returns True if the current channel or any parent is paused
• has_capacity() returns False if is_paused() returns True

Describe alternatives you've considered

/

Additional context

The cycle to update the channels can probably be optimized to prevent reloading all at once, but changes on the configuration should be are enough not to be a problem. Maybe if the only changes are in pause/resume, we can change the channels in place instead of recreating all the channels.

[guewen]

I missed the biggest point which is a problem for this implementation: channels configuration is loaded before loading databases, and it may be different from database to database.

[sbidoul]

Sometimes I have this idea of building a small web UI to view channels, some counters, and why not manage channels. This could take the form of a little web server thread in the job runner worker, serving a simple single page app.

Then we could think about persistence of the channels config.

[flotho]

@AmalBenAissa @DorianMAG @JulienMartinez @gaelTorrecillas

[simahawk]

I missed the biggest point which is a problem for this implementation: channels configuration is loaded before loading databases, and it may be different from database to database.

Question: why is the loading before db is ready needed? In any case you cannot run jobs until the instance is up and running and able to answer requests. No?

[sbidoul]

@simahawk the point is the s in databases. The job runner can schedule jobs from multiple databases. The channel config is at the odoo instance level, not per database, so it would not know in which database to read it's config.

[flotho]

maybe something like web/database/manager that will be able to update the conf file like when the admin_password is not set ?

[sbidoul]

maybe something like web/database/manager that will be able to update the conf file like when the admin_password is not set ?

That would need the conf file to be writable which is not the case in many environments.

So we'd need some sort of pluggable configuration storage mechanism.

[flotho]

maybe something like web/database/manager that will be able to update the conf file like when the admin_password is not set ?

That would need the conf file to be writable which is not the case in many environments.

So we'd need some sort of pluggable configuration storage mechanism.

(facepalm) to me ;-)

[simahawk]

@sbidoul but then it's "just" a design decision to be taken, no?. Eg: the env / system configuration should work only as backup if the database has no specific configuration. The ChannelManager can hold configuration by DB.
Then you have to handle the triggering of the update of the configuration (maybe using an hash + db trigger).
Am I missing anything?

[sbidoul]

The ChannelManager can hold configuration by DB

I'm not sure. At the very least, the capacity of the root channel cannot be defined by db, as it is closely relates to the number of workers of the instance. Also, what if the same channel is defined in multiple dbs? And in some multi-db cases we do mean that some channels are shared across dbs.

I would approach this with two work streams:

• Implement a queue job channels configuration provider plugin mechanism. We can then experiment several approaches: readonly configuration as it is now, read-write to $ODOO_RC, read-write to a selected odoo database, read-write to a dedicated configuration db, etc
• Work on a simple UI to display channels first, then manage them. That UI should be served by a server wide module and not tied to a specific db.

[github-actions]

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.