Unreleased Release Notes

4.8.0

Upgrade Notes

  • 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.

Bug Fixes

  • 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.

4.7.0

Upgrade Notes

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

Deprecation Notes

  • The oslo_service.version module and associated objects has been deprecated for removal. Prefer use of importlib.metadata to inspect version information for installed packages.

4.6.0

New Features

  • Adds pickle support for the threading backend service.

  • Added run_periodic_tasks_in_parallel() to allow services to run due periodic tasks concurrently when explicitly requested.

    This helper is supported only with the threading backend and requires the PeriodicTasks instance and execution context to be picklable.

4.5.1

Bug Fixes

  • The oslo.service threading mode checks if the service instance is picklable and based on that it selects the multiprocessing start method as ‘spawn’ or ‘fork’. But it did not account for the conf object which is passed by the cotyledon (via hook registered by oslo_config_glue.link()) to multiprocessing. Multiprocessing checks if that conf object is not picklable or not.

    In bug 2142122, oslo.service checked service instance picklable and selected the ‘spawn’ method but further multiprocessing failed when it found the conf object is not picklable. This bug is fixed by checking both service instance as well as the conf object.