Unreleased Release Notes¶

4.8.0-25¶

Removal of the deprecated oslo_service.wsgi.Server class and the oslo_service.sslutils, oslo_service.eventlet_backdoor, and oslo_service.fixture modules is postponed from 2026.2 release to 2027.2 release to provide an extended migration period for consumers. These components remain deprecated.

oslo_service.sslutils can now be imported when Python is built against OpenSSL 4.0, where ssl.PROTOCOL_TLSv1 is not available. LP#2169555

In the threading backend, a service launched with no_fork=True whose start() fails is now stopped, and the process exits with status 1, as it exits on SIGTERM. Before, the process could hang at exit, waiting for thread pool workers that the service had started, so service managers did not restart it. See bug 2169754.

In the threading backend, a service launched with no_fork=True now handles SIGHUP as the restart_method of launch() says. With mutate, the configuration files are mutated and the service is reset. With reload, they are reloaded and the service is stopped and started again. Before, the process exited without stopping the service, and hung if one of its threads never ended, such as a timer of its thread group. A process in the foreground of a terminal now stops the service and exits on SIGHUP, as on SIGTERM.

Applications relying on the threading backend’s brief automatic selection of spawn must now request it explicitly. Existing applications that relied on workers inheriting parent-process state keep the historical fork behavior.

The threading backend once again uses fork by default on platforms where it is available. A service and its configuration being picklable does not guarantee that application state initialized in the parent process is available in a fresh spawn worker.

Applications that are fully spawn-safe can opt in with service.launch(..., start_method="spawn"). On platforms without fork, spawn remains the default. Explicit spawn requests validate that the service and ConfigOpts can be serialized.