Unreleased Release Notes¶

4.4.1-8¶

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.

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.

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.