On 16/06/2025 14:24, Dmitriy Rabotyagov wrote:
In case you try to use a 32gb box with 16 cores as a controller for OpenStack - it will blow off with default amount of workers for wsgi and /or eventlet apps.
i think you are conflating workers and eventlet tuneign which are two very diffent things. the default for nova api depens on how you deploy it but normaly you start with 1-2 worker process for the api. we do seam to be defaulting to 1 worker proceess per core for conductor, scheduler which likely shoudl be set to 1 aswell https://github.com/openstack-k8s-operators/nova-operator/blob/main/templates... https://github.com/openstack/kolla-ansible/blob/master/ansible/roles/nova/te... https://github.com/openstack/kolla-ansible/blob/master/ansible/roles/nova/te... those have nothing to do with eventlet however the only eventlet specific tunable nova has are the following https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.def... https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.syn... https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.exe... Thsese are what i and gibi were refering to when we said there will be new tuning option for theaded mode. those exisitng greenthread pools will be replaced with new executors that wil need to be configured diffently. the worker options are not being removed or changed as part of eventlet removal. although they probably should be updated to default to 1 instead of $(nproc) and then be overried by the deployer based on there own knowlage of the aviable resouces.
While you can argue this should not be used as production setup, this can be totally valid for sandboxes and we wanna provide consistent and reliable behavior for users.
But my argument was not in if/how we want to fine-tune deployments, but also understand and provide means to define what's needed as well as potential ability to revert in worst case scenario as a temporary workaround. So still some variables and logic would be introduced from what I understand today.
On Mon, 16 Jun 2025, 14:43 Sean Mooney, <smooney@redhat.com> wrote:
On 16/06/2025 13:27, Dmitriy Rabotyagov wrote: > > > > sayint its FUD is not helpful. > > we got a driect ask form operator and soem core to not do a hard > switch > over. > > and while i wanted to only support one model for each binary at a > time > we were sepcificly ask to make it configurable. > > > In the later case, your only available action is help fixing > bugs. It > > is not up to the operators to double-guess what may or may not > work. > > correct we are not planning to document how to change mode we were > planning to only use this configuration in ci and operator would be > > > Well, we'd need to have that communicated so that deployment toolings > could adopt their setup to changes, as, for instance, in OSA amount of > eventlet workers are calculated based on the system facts, so we'd > need to change the logic and also suggest how users should treat this > new logic for their systems.
why is OSA doing that at all today? we generally don't recommend changing those values from the default unless you really know what your doing. i don't think other installer do that. tripleo, kolla-ansbile and our new golang based installer do not, nor does devstack so its surprising to me that OSA would change such low level values by default.
we will document any new config options we and and we are documentation how to tune the new options for thread pools but we do not expect installation tools to modify them by default. we are explicitly not making the options based on the amount of resources on the host i.e. dynamically calculated based on the number of CPU cores.
for example we are explicitly setting the number of scatter_gather thread in the the dedicated thread pool to 5 why its a nice small number that will work for most people out of the box.
can you adjust it, yes but it scale based on the number of nova cells you have an 99% wont have more then 5 cells.
using information about the host where the API is deployed to infer the value of that would be incorrect.
you can really only make an informed decision about how to tune that based on monitoring the usage of the pool.
that how we expect most of the other tuning options to go as well.
our defaults in nova tend to be higher then you would actually need in a real environment so while it may make sense to reduce them we try to make sure the work out of the box for most people.
gibi id building up https://review.opendev.org/c/openstack/nova/+/949364/13/doc/source/admin/con...
as part of nova move to encode this but our goal is that deployment tools shoudl not need to be modifyed to tune these valued by defualt.
> > So it will be kinda documented in a way after all. > > > told for a given release deploy this way. > > this is an internal impelation detail however we are not prepared to > deprecate usign eventlet until we are convicned > > that we can run properly without it. > > > For beginners, this would be a horrible nightmare if default > options > > simply wouldn't work. We *must* ship OpenStack working by default. > no one is suggesting we do otherwise. > > > > Cheers, > > > > Thomas Goirand (zigo) > > >