Oslo Context Library

6.3.0 · active · verified Mon Apr 13

The `oslo.context` library is a core OpenStack component providing helpers to manage and maintain useful information about a request context. This context is typically populated within a WSGI pipeline and utilized by various modules, such as `oslo.log`, for consistent data access throughout a request's lifecycle. The library is currently at version 6.3.0 and follows the OpenStack release cadence.

Warnings

breaking The `tenant` argument of `RequestContext` has been removed in version 6.x.x (specifically, from the Zed series). It was deprecated for a long time.
Fix: Migrate from using `tenant` to `project_id` or `project_name` when initializing or accessing context information. Review your `RequestContext` instantiations and update arguments accordingly.
deprecated Passing positional arguments to `RequestContext.__init__` has been deprecated since version 2.7.0. While it might still work, it can lead to unexpected behavior in future versions.
Fix: Always use keyword arguments when initializing `RequestContext` to ensure clarity and forward compatibility (e.g., `RequestContext(user_id='...', project_id='...')` instead of `RequestContext('...', '...')`).
gotcha The `get_logging_values` function (intended for logging) no longer outputs the `auth_token` directly but replaces it with `***` to prevent sensitive data leakage. If you rely on the `auth_token` for other purposes, retrieve it directly from the `RequestContext` object.
Fix: If your application explicitly uses `get_logging_values` and expects the full `auth_token`, be aware of this change. For non-logging purposes, access `context.auth_token` directly from your `RequestContext` instance.
gotcha The request context is stored in thread-local storage. If your application uses worker pools or asynchronous patterns that change the execution thread, the context might not be propagated automatically, leading to `None` being returned by `context.get_current()`.
Fix: For multi-threaded or asynchronous environments, ensure that the `RequestContext` is explicitly passed or re-established in the new thread/task context. Libraries like `oslo.privsep` and `oslo.middleware` handle this for specific use cases [8, 18].

Install

pip install oslo.context Install latest version

Imports

RequestContext
```
from oslo_context import context
```
The primary class for managing request-scoped context information.
get_current
```
from oslo_context import context
```
Used to retrieve the current request context from the thread-local storage.

Quickstart

This quickstart demonstrates how to create a `RequestContext` object, make it available globally within the current thread using `make_current()`, and retrieve it with `get_current()`. It also shows how to create a specialized admin context. For real-world applications, `RequestContext` is typically initialized by WSGI middleware and automatically managed.

from oslo_context import context

# Create a basic RequestContext
req_context = context.RequestContext(
    auth_token='fake_auth_token',
    user_id='fake_user_id',
    project_id='fake_project_id',
    is_admin=False
)

# Store the context for the current thread
req_context.make_current()

# Later in the application, retrieve the context
current_context = context.get_current()

if current_context:
    print(f"Current User ID: {current_context.user_id}")
    print(f"Is Admin: {current_context.is_admin}")

# Example of creating an admin context
admin_context = context.get_admin_context(show_deleted=True)
admin_context.make_current()
print(f"Admin Context User ID: {context.get_current().user_id}")
print(f"Admin Context is Admin: {context.get_current().is_admin}")

# Clean up the context (important in testing or if not in a WSGI app)
context.clear_current()

view raw JSON →