Skip to content

Extend the lifetime of cached redfish sessions when using them #350

Description

@OoYo0uto

Describe the solution you would like

Currently, redfish sessions time out after the SessionTimeout specified by the redfish device. The redfish standard specifies, that

For Redfish sessions, as long a client continues to send requests for the session more often than the session timeout period, the session will remain open and the session auth token remains valid.
Redfish Standard - 9.3.4.5 Session Lifetime

While the current session caching already greatly reduces the number of "A redfish session was created" log messages, extending the session lifetime each time the session is used would reduce the number of created sessions to an absolute minimum.

One possibility of implementing this would be to extend the cache expiration time as long as the session is used. I see here two variants:

  1. The simple variant would be to simply extend the expiration time of the session token when get_auth_header() is called. This has the assumption, that a session is used in the close future after get_auth_header is called.
  2. A more sophisticated variant would be to extend the lifetime of the session after it is used. A possible implementation would be:
    • Add the SessionTimeout to the cache in get_auth_header with a very long timeout (e.g., 30 days). The value can be stored after it is fetched and parsed successfully get_auth_header. If no session timeout could be fetched anymore (the except (TypeError, ValueError):-case), remove it from the cache if it is there.
    • Implement a function like _extend_session which fetches the session timeout from the cache and sets a new TTL of "current time + cached session timeout - some safety margin (e.g., 20 seconds)". If no session timeout can be found in the cache, don't extend the session.
    • Call the _extend_session function in _fetch_json, if a request with a X-Auth-Token header was successfully

I can provide a PR if this would be helpful.

Alternatives considered

Yes, an alternative would be to either increase the redfish SessionTimeout of the device, so it is renewed less often or to just accept the existing number of log messages.

Additional context

No response

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions