Configure uWSGI Workers for OpenStack API Services¶

Overview

Several OpenStack services deployed by StarlingX OpenStack serve their REST APIs through Universal Web Server Gateway Interface (uWSGI). Each service runs a pool of worker processes that handle incoming API requests. On systems with high API load, you can scale this pool up to improve throughput; on resource-constrained systems, you can scale it down to reduce the service footprint.

Scale the worker pool with the processes parameter. Each additional process is an independent worker that increases concurrent request capacity.

The following services run under uWSGI and expose a configurable worker pool through their Helm overrides:

Service	uWSGI configuration key(s)
Nova (Compute API)	`conf.nova_api_uwsgi.uwsgi`, `conf.nova_metadata_uwsgi.uwsgi`
Neutron (Networking API)	`conf.neutron_api_uwsgi.uwsgi`
Cinder (Block Storage API)	`conf.cinder_api_uwsgi.uwsgi`
Glance (Image API)	`conf.glance_api_uwsgi.uwsgi`
Heat (Orchestration API)	`conf.heat_api_uwsgi.uwsgi`, `conf.heat_api_cfn_uwsgi.uwsgi`
Placement (Placement API)	`conf.placement_api_uwsgi.uwsgi`

The parameter that controls the worker pool under each *_uwsgi.uwsgi block is:

Parameter	Description
`processes`	Number of uWSGI worker processes serving the API. Each worker is an independent process that increases concurrent request capacity.

Procedure

Create an override file (for example, nova-osapi-workers-override.yaml):
```
conf:
  nova_api_uwsgi:
    uwsgi:
      processes: 2
```

Apply the override:

~(keystone_admin)]$ system helm-override-update stx-openstack nova openstack --values /path/to/nova-osapi-workers-override.yaml

Reapply the application for the changes to take effect:

~(keystone_admin)]$ system application-apply stx-openstack

The same conf.<service>_api_uwsgi.uwsgi structure shown here for Nova applies to the other services listed in the table above.

Note

Concurrent request capacity scales with processes and with the number of pod replicas. Increasing processes raises CPU and memory usage proportionally, so size it against the controller resources and the expected API load.

Warning

Do not set the threads parameter above 1. These services are not compatible with multiple uWSGI threads per worker, and increasing it causes API requests to fail with gateway timeouts. Scale capacity with processes only.