Summary
Would the DMTF be open to an additive asynchronous Redfish client implemented with aiohttp?
I am willing to contribute the implementation, tests, and documentation if the proposed direction is acceptable. This request is not intended to replace or change the existing synchronous API.
Motivation
Full disclosure; I'm trying to avoid creating a new library in order to meet a Home Assistant requirement. I'm in the process of opening PRs to add Redfish integration to Home Assistant:
Home Assistant requires nonblocking communication and uses a shared aiohttp.ClientSession for connection pooling, TLS configuration, proxy behavior and lifecycle management. The same requirements apply to other asyncio-based services and management applications.
Proposed direction
Add a separate asynchronous API while leaving the existing synchronous client fully backward compatible.
A possible structure would be:
redfish/
├── rest/
│ └── v1.py # Existing synchronous implementation
└── aio/
├── client.py # New asynchronous implementation
├── response.py
└── exceptions.py
The asynchronous client would:
- Use aiohttp.
- Accept a caller-provided aiohttp.ClientSession.
- Never create or close a caller-provided session.
- Provide coroutine-based HTTP methods such as get, post, put, patch, and delete.
- Support Redfish HTTP Basic authentication initially.
- Allow the caller to control TLS verification through the provided session.
- Support configurable request timeouts.
- Prevent credentials from being forwarded to a different origin.
- Preserve advertised Redfish resource and action URLs rather than constructing vendor-specific paths.
- Include complete asynchronous unit tests with a mocked Redfish service.
For example:
async with aiohttp.ClientSession() as session:
client = AsyncRedfishClient(
base_url="https://bmc.example",
username="user",
password="password",
session=session,
)
service_root = await client.get("/redfish/v1/")
The asynchronous dependency could potentially be optional, for example:
pip install redfish[aiohttp]
Backward compatibility
The existing synchronous client and its public API would remain unchanged. The async client would be exposed through a separate module and class, so current users would not need to make any changes.
Summary
Would the DMTF be open to an additive asynchronous Redfish client implemented with
aiohttp?I am willing to contribute the implementation, tests, and documentation if the proposed direction is acceptable. This request is not intended to replace or change the existing synchronous API.
Motivation
Full disclosure; I'm trying to avoid creating a new library in order to meet a Home Assistant requirement. I'm in the process of opening PRs to add Redfish integration to Home Assistant:
Home Assistant requires nonblocking communication and uses a shared
aiohttp.ClientSessionfor connection pooling, TLS configuration, proxy behavior and lifecycle management. The same requirements apply to other asyncio-based services and management applications.Proposed direction
Add a separate asynchronous API while leaving the existing synchronous client fully backward compatible.
A possible structure would be:
The asynchronous client would:
For example:
The asynchronous dependency could potentially be optional, for example:
pip install redfish[aiohttp]
Backward compatibility
The existing synchronous client and its public API would remain unchanged. The async client would be exposed through a separate module and class, so current users would not need to make any changes.