224cdd726c
Especially in a single-conductor environment, the number of threads should be larger than max_concurrent_deploy, otherwise the latter cannot be reached in practice or will cause issues with heartbeats. On the other hand, this change fixes an issue with how we use futurist. Due to a misunderstanding, we ended up setting the workers pool size to 100 and then also allowing 100 more requests to be queued. To be it shortly, this change moves from 100 threads + 100 queued to 300 threads and no queue. Partial-Bug: #2038438 Change-Id: I1aeeda89a8925fbbc2dae752742f0be4bc23bee0
26 lines
1.2 KiB
YAML
26 lines
1.2 KiB
YAML
---
|
|
issues:
|
|
- |
|
|
When configuring a single-conductor environment, make sure the number
|
|
of worker pools (``[conductor]worker_pool_size``) is larger than the
|
|
maximum parallel deployments (``[conductor]max_concurrent_deploy``).
|
|
This was not the case by default previously (the options used to be set
|
|
to 100 and 250 accordingly).
|
|
upgrade:
|
|
- |
|
|
Because of a fix in the internal worker pool handling, you may now start
|
|
seeing requests rejected with HTTP 503 under a very high load earlier than
|
|
before. In this case, try increasing the ``[conductor]worker_pool_size``
|
|
option or consider adding more conductors.
|
|
- |
|
|
The default worker pool size (the ``[conductor]worker_pool_size`` option)
|
|
has been increased from 100 to 300. You may want to consider increasing
|
|
it even further if your environment allows that.
|
|
fixes:
|
|
- |
|
|
Fixes handling new requests when the maximum number of internal workers
|
|
is reached. Previously, after reaching the maximum number of workers
|
|
(100 by default), we would queue the same number of requests (100 again).
|
|
This was not intentional, and now Ironic no longer queues requests if
|
|
there are no free threads to run them.
|