Unreleased Release Notes¶

4.4.1-13¶

The oslo.service implements the required signal hanlders when service is launched in the main process. The below signals are captured and their respective handles are called:
- SIGTERM
- SIGINT
- SIGHUP
- SIGALRM

Added oslo_service._multiprocessing module providing get_spawn_context() and get_spawn_pool() utilities. These enforce the spawn start method to avoid fork-inherited lock deadlocks, as explained in: https://pythonspeed.com/articles/python-multiprocessing/

The threading backend now supports the spawn multiprocessing start method. If a service is spawn-safe (picklable), spawn will be used as the default start method. Otherwise, the backend will automatically fall back to fork if available. This prevents inherited threading locks during worker respawn and improves compatibility with Python 3.12+.

For more information about spawn-safe services, see spawn.

Added new register_service_opts and set_service_opts_defaults() methods that allows OpenStack services to register and override a new default values for the below service_opts:
- graceful_shutdown_timeout
- log_options

oslo.service SignalHanlder in Threading backend execute the signal handlers in a new thread, which does not work because the signal only works in the main thread. This issue has been fixed now by executing the signal handlers in the main thread.

Fixed a bug to launch the multiple workers with different service instance. If the first service instance was picklable the spawn multiprocessing context was selected. Any subsequent non-picklable service instance also used the spawn multiprocessing context and raised the error. The launcher now re-evaluates the spawn-safe service and if it is not spawn-safe then fallback to fork multiprocessing context.

See bug 2141304.

In the threading backend, completed threads were never removed from the group’s tracking. Long-lived services that repeatedly add threads could see unbounded growth. Completed threads are now removed when they finish, matching the documented behavior and eventlet. No caller changes needed.

The ThreadGroup.max_threads attribute has been restored for backward compatibility. It previously disappeared during the backend refactor (commit 8c74d0718dc11ed5), which caused consumers such as Heat to fail when upgrading to oslo.service 4.4.0. The attribute now maps to thread_pool_size and emits a DeprecationWarning. Applications should migrate to thread_pool_size. The deprecated attribute may be removed in a future release.

Support for Python 3.9 has been removed. Now the minimum python version supported is 3.10.

The oslo.service.wsgi.Server class now includes backend compatibility checks to prevent improper usage with the threading backend. Applications using the threading backend that attempt to instantiate the WSGI Server will now receive an immediate UnsupportedBackendError exception with a clear error message.

This is an intentional breaking change to prevent potential runtime issues and security concerns that could arise from using a component designed for eventlet in a threading environment. The fail-fast behavior ensures that applications using the threading backend are guided towards the correct deployment patterns.

Migration Path: Users should migrate to deploying their WSGI applications using standard WSGI servers such as uwsgi, gunicorn, or similar alternatives instead of relying on the deprecated oslo.service WSGI server.