Repository navigation
[RFC] mechanism to configure the root channel capacity independently of other subchannels #857
Description
Is your feature request related to a problem?
The queue_job channels configurations (ODOO_QUEUE_JOB_CHANNELS) is used to configure the root channel capacity, which in turn is closely related to the number of available Odoo workers. It is also used to configure subchannels which is used to control concurrency across different job types.
When configuring different environments (prod, staging, ...) the number of available Odoo workers varies across environment so we want to change the root channel capacity per environment. However, to do that we also need to update the full subchannels configuration, which leads to duplication in configurations.
Describe the solution you'd like
A mechanism to configure the root channel capacity independently of the subchannels configuration.
Describe alternatives you've considered
Copy the full configuration in each environment.
Activity
amh-mw commentedon Dec 8, 2025
I use Terraform to configure my containers, with the environment getting set like:
{"name": "ODOO_QUEUE_JOB_CHANNELS", "value": "root:${max(local.web_workers - 2, 1)}:subcapacity=1"}Not sure what could be better than configuration management variable interpolation.
I had previously attempted to use
server_environmentfrom OCA/server-env, but suffered from copy pasta as described. A more general YAML merge or interpolation feature might fit well there.hoangtrann commentedon Dec 25, 2025
To me, managing root capacity is always about how much resources we want to borrow for queue job. It needs to tie with the web workers so something as @amh-mw suggest is definitely nice. Scaling subchannel capacity can be percentage of root to avoid configuration duplication. Capacity can be defined as fixed number or percentage, similar to what AWS has with their scaling policy. If we are introducing independent capacity to subchannel, then properly we need a
max_queue_workersto not exceeding the total web workers in any case, and control what contribute to the total capacity.github-actions commentedon Jun 28, 2026
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.
sbidoul commentedon Aug 18, 2026
Another reason to configure the root channel independently is if we want to update it dynamically in an autoscaling scenario.