Redfish Coding Guidelines

  • For robot programs wishing to run Redfish commands, include the following in your robot file:

    *** Settings ***
    
    Resource                    bmc_redfish_resource.robot
    
  • This git repository has some redfish wrapper modules:

    • redfish_plus.py

    • bmc_redfish.py

    • bmc_redfish_utils.py

    • Redfish wrapper module features:

      For all Redfish REST requests (get, head, post, put, patch, delete):

      • Support for python-like strings for all arguments which allows callers to easily specify complex arguments such as lists or dictionaries.

        So instead of coding this:

            ${ldap_type_dict}=  Create Dictionary  ServiceEnabled=${False}
            ${body}=  Create Dictionary  ${LDAP_TYPE}=${ldap_type_dict}
            Redfish.Patch  ${REDFISH_BASE_URI}AccountService  body=${body}
        

        You can do it in one fell swoop like this:

            Redfish.Patch  ${REDFISH_BASE_URI}AccountService  body={'${LDAP_TYPE}': {'ServiceEnabled': ${False}}}
        
      • Support for valid_status_codes argument and auto-failure:

        As mentioned above, this argument may be either an actual robot/python list or it may be a string value which python can translate into a list.

        The default value is [${HTTP_OK}].

        This means that the Redfish REST request will fail automatically if the resulting status code is not found in the valid_status_codes list.

        So instead of having to do this:

            ${resp}=  Redfish.Get  ${EVENT_LOG_URI}Entries
            Should Be Equal As Strings  ${resp.status_code}  ${HTTP_OK}
        

        You can simply do this:

            ${resp}=  Redfish.Get  ${EVENT_LOG_URI}Entries
        

        If, for some reason, you expect your command to fail, you can specify the expected status code or codes:

        Redfish.Patch  ${REDFISH_BASE_URI}UpdateService  body={'ApplyTime' : 'Invalid'}  valid_status_codes=[${HTTP_BAD_REQUEST}]
        
    • Login defaults for path, username and password are https://${OPENBMC_HOST}, ${OPENBMC_USERNAME}, ${OPENBMC_PASSWORD}.

    • Many utility functions are available. Examples:;

      • get_properties
      • get_attributes
      • get_session_info
      • list_request
      • enumerate_request

Rules for use of Redfish.Login and Redfish.Logout

It is desirable to avoid excessive redfish logins/logouts for the following reasons:

  • It simplifies the code base.

  • It allows calling keywords and testcases to keep control over login paramters like USERNAME, PASSWORD, etc. Consider the following example:

    # Login to redfish with non-standard username/password.
    Redfish.Login  ${LDAP_USER}  ${LDAP_USER_PASSWORD}
    # Run 'Some Keyword' while logged in as ${LDAP_USER}/${LDAP_USER_PASSWORD}.
    Some Keyword
    

    If 'Some Keyword' in the example above does its own Redfish.Login, it will thwart the stated purpose of the caller.

Rules:

  • Login should be done once in Suite Setup:

    *** Keywords ***
    Suite Setup Execution
        Redfish.Login
    
  • Logout should be done once in Suite Teardown:

    *** Keywords ***
    Suite Teardown Execution
        Redfish.Logout
    
  • As a result of the first two rules, all keywords and testcases that call upon redfish functions (e.g. Redfish.Get, Redfish.Patch, etc.) have a right to expect that login/logout have already been handled. Therefore, such keywords and testcases should NOT do logins and logouts themselves.

  • There may be exceptions to the above but they require justification (e.g. a test whose purpose is to verify that it can login with an alternate username, etc.).

  • Any keyword or test case which breaks the above rules is responsible for setting things right (i.e. back to a logged in state).