Redfish Usecase Checkers script issues

[MaheshaHPE]

1. Power Control Checker python3 power_control.py -r : -u -p -S Always Found 1 system instances Resetting Partition0 using On Task is Done! Monitoring power state for Partition0... Resetting Partition0 using ForceOff Task is Done! Monitoring power state for Partition0... Resetting Partition0 using ForceRestart Task is Done! Monitoring power state for Partition0... ERROR: Partition0 was not in the On state after using ForceRestart as the reset type. Resetting Partition0 using GracefulRestart Task is Done! Monitoring power state for Partition0... ERROR: Partition0 was not in the On state after using GracefulRestart as the reset type. Resetting Partition0 using GracefulShutdown Task is Done! Monitoring power state for Partition0... Resetting Partition0 using PowerCycle Task is Done! Monitoring power state for Partition0...

Note: In partition power off state, npar GracefulRestart and ForceRestart are not allowed. Need a script modification to bring partition to ON state before doing GracefulRestart, ForceRestart and GracefulShutdown

2. Account Management Checker python3 account_management.py --r : -u -p -S Always Creating new user 'testuser0' ERROR: Failed to find user 'testuser0' with the role 'Administrator'. Logging in as 'testuser0' Logging in as 'testuser0', but with the wrong password Setting user 'testuser0' to role 'ReadOnly' ERROR: Failed to set user 'testuser0' to 'ReadOnly' (Operation failed: HTTP 400 A general error has occurred. See Resolution for information on how to resolve the error. The property RoleId is not in the list of valid properties for the resource.). Setting user 'testuser0' to role 'Operator' ERROR: Failed to set user 'testuser0' to 'Operator' (Operation failed: HTTP 400 A general error has occurred. See Resolution for information on how to resolve the error. The property RoleId is not in the list of valid properties for the resource.). Setting user 'testuser0' to role 'Administrator' ERROR: Failed to set user 'testuser0' to 'Administrator' (Operation failed: HTTP 400 A general error has occurred. See Resolution for information on how to resolve the error. The property RoleId is not in the list of valid properties for the resource.). Deleting user 'testuser0'

-Script is not parsing the password and it is appearing as 'null' while logging with new user created -We do not support modifying user roles

3. Query Parameter Checker python3 query_parameters_check.py --r : -u -p -S Always Performing $expand=* on /redfish/v1/ Performing $expand=. on /redfish/v1/ Performing $expand=! on /redfish/v1/ ERROR: Failed to perform $expand test (Operation failed: HTTP 400 A general error has occurred. See Resolution for information on how to resolve the error. The value ! for the parameter $expand is of a different format than the parameter can accept.).
   • Our product does not support $expand=! instead we support $expand=~

[mraineri]

For item 1, that is correct behavior. The best practices from the forum have been to not require clients to perform try/fail semantics on these types of operations. If the system is off and a user requests a resets, the end desired state is to have the system on. I will discuss this with others though, but from the last time the forum talked about this and added clarifications to the spec, the desired behavior was to not fail a client for these types of requests.

For item 2, that seems to be counter-intuitive to normal user management operations. I would expect clients might set the RoleId based on management decisions, hence the failure here. Also, the password being null in responses is correct; the Password property is essentially a write-only property and is not returned in GET responses.

For item 3, this is definitely a mistake; there is no such thing as "expand !" in the spec. I'll make a fix for this.

[MaheshaHPE]

Thank you for the quick fix. Please update on this whenever you get time on this item, "I will discuss this with others though, but from the last time the forum talked about this and added clarifications to the spec, the desired behavior was to not fail a client for these types of requests." -Mahesha M

[MaheshaHPE]

Few observation on,

Item 2: Pulling a created user is failing because of timing issue, if we add some delay, no ERROR is seen at this part, Creating new user 'testuser0' ERROR: Failed to find user 'testuser0' with the role 'Administrator'.

Item 3: └─# python3 query_parameters_check.py -r 10.229.128.217 -u administrator -p HPE1nnov -S Always Performing $expand= on /redfish/v1/ Performing $expand=. on /redfish/v1/ Performing $expand=~ on /redfish/v1/ Performing $expand=($levels=1) on /redfish/v1/ ERROR: Failed to perform $expand test (Operation failed: HTTP 400 A general error has occurred. See Resolution for information on how to resolve the error. The value *($levels=1) for the parameter $expand is of a different format than the parameter can accept.).

[mraineri]

Thank you for the quick fix. Please update on this whenever you get time on this item, "I will discuss this with others though, but from the last time the forum talked about this and added clarifications to the spec, the desired behavior was to not fail a client for these types of requests." -Mahesha M

I talked about this with some others and the behavior of the script is correct; while it's technically legal to return an error like that, we consider it to be a bad practice to put that type of burden on the client.

Few observation on,

Item 2: Pulling a created user is failing because of timing issue, if we add some delay, no ERROR is seen at this part, Creating new user 'testuser0' ERROR: Failed to find user 'testuser0' with the role 'Administrator'.

That's generally not good RESTful behavior. In cases where a service responds with 201 Created and a Location header for a new URI is provided, I would expect a client to be able to immediately go to the referenced URI.

Item 3: └─# python3 query_parameters_check.py -r 10.229.128.217 -u administrator -p HPE1nnov -S Always Performing $expand= on /redfish/v1/ Performing $expand=. on /redfish/v1/ Performing $expand=~ on /redfish/v1/ Performing $expand=($levels=1) on /redfish/v1/ ERROR: Failed to perform $expand test (Operation failed: HTTP 400 A general error has occurred. See Resolution for information on how to resolve the error. The value *($levels=1) for the parameter $expand is of a different format than the parameter can accept.).

That would indicate lack of parsing of the $levels parameter that can be provided with $expand. $levels is used to specify how deep the request can go (but if not specified, it will only go 1 level deep).

[mraineri]

It was brought up that there is an indicator in the ProtocolFeatures object to show whether or not $levels can be specified; will need to enhance the tool to check that flag.