Zed Series (4.2.0 - 4.3.x) Release Notes¶
4.3.3-8¶
Bug Fixes¶
Fixes bug where sushy would not pass a read/connect timeout through to requests when making requests to a redfish service. This means that an ill-timed failure could cause python processes calling sushy to freeze indefinately.
Add retries on iDRAC error with code SYS518 and message “iDRAC is currently unable to display any information because data sources are unavailable.” for all request types in addition to existing GET methods. This helps to fix a known intermittent issue when deleting set of volumes one after another and iDRAC is reloading after deleting each volume.
Fixes ‘Unsupported parameter name @Redfish.OperationApplyTime’ error on iDRAC firmware version 6.00.02.00 or newer when deleting volumes.
Correctly handles error code
Base.1.5.PropertyMissing
when dealing with hardware that requiresTransferProtocolType
for virtual media operations.
An issue was encountered on some HPE iLO supported machines where the Baseboard Management Controller would respond with a HTTP 400 error and an error message indicating the requested operation was invalid for the then system state. For example, attempting to change the power state via the BMC shortly after previously changing the power state. We now attempt to retry within the permitted number of retries when this error is encountered.
Workaround for https://github.com/psf/requests/issues/3829 If the env
REQUESTS_CA_BUNDLE
is set therequests.Session()
ignores the verify parameter. Therefore the verify parameter is moved directly into the function call of requests.
4.3.3¶
Bug Fixes¶
Adds an extra check for cases where the BMC provides a SettingsObject URI through @Redfish.Settings but this URI does not allow setting boot related attributes. Prior to sending a PATCH request to SettingsURI, a GET request is issued to verify if it contains the attributes to be updated. In case these attributes are missing, the request is made against System URI instead. Issues such as the one addressed with this change usually manifest themselves with a Redfish response containing an error message similar to the following:
MessageId: Base.1.8.PropertyNotWritable, Message: The property BootSourceOverrideEnabled is a read only property and cannot be assigned a value.
4.3.2¶
Bug Fixes¶
To avoid timeouts with recent versions of firmwares we need to increase the number of server side retries. For example, in idrac firmware series 5.x the time gap between operations is almost 20 seconds instead of the 10 seconds in the 4.x series.
4.3.1¶
Bug Fixes¶
Alters eTag handling in PATCH requests: First, the original eTag is used. In case of a failure, if the eTag provided was weak, it is converted to a strong format by removing the weak prefix. If this approach is not applicable or fails, the final attempt is made omitting the eTag entirely. By taking this approach, no workarounds are applied if BMC is handling eTags as expected and in case of failures, known workarounds are attempted, improving overall resiliency.
4.3.0¶
New Features¶
Adds
controllers
property ofStorage
class that was introduced in Redfish v1.9 to replacestorage_controllers
deprecated in Redfish v1.13.
Bug Fixes¶
Fixes potential cases where exceptions from the underlying
requests
library may be raised up throughsushy
, resulting in client applications possibly not understanding that an error has occurred. The sushyConnectionError
exception is now returned upon any exception falling underRequestException
from therequests
library.
4.2.2¶
Bug Fixes¶
Fixes unreliable behavior with ETag interactions with some BMCs as opportunistic use of compressed responses may cause the BMC to change an ETag response to “Weak”, which is to be expected as an ETag represents an absolute byte-by-byte response consistency, and compression cannot reliably honor that contract. Introduction of a client perceiving a “Weak” ETag may not be expected by the server, and the server may reject responses because the ETag is not a “Strong” ETag when we respond or interact with a resource.
As a result, requests no longer offer oppurtunistic compression of responses as an acceptable possibility, which overall has minimal impact, espescially when compared to the value of consistent BMC behavior and interaction.
4.2.1¶
Bug Fixes¶
Fixes an issue in the sushy connector object handling where a Sushy client utilizing
basic
authentication would not raise an AccessError exception once the credentials stopped working. We now explicitly check to see ifbasic
authentication is in use, and raise the exception if an AccessError is encountered.
4.2.0¶
Bug Fixes¶
Fixes issues with the refresh of
Session
based authentication where a previous refresh attempt failing could result in a fallback toBasic
authentication and would silently fail. The client library now attempts to re-authenticate.
Fixes silent failures when a refresh of an authentication
Session
fails and was unable to be re-established due to anAccessError
. Should this occur, now theAccessError
exception is explicitly raised as opposed to attempting to fall back toBasic
authentication.
Fixes issues where the
Session
andBasic
auth interface would fallback toBasic
authentication should aConnectionError
exception occur while attempting to perform an authentication action.ConnectionError
exceptions are signs of networking transport issues, and should be investigated. AConnectionError
exception is now raised.
Prevents the combined
Session
andBasic
authentication support from falling back toBasic
authentication onceSession
based authentication has been established. This should be considered a potential security issue or an environmental change requiring potential client re-initialization. This is exposed as anAccessError
exception. Continued operations against the Sushy library will attempt to reauthenticate, if possible.