DMTF/python-redfish-library

So trying to use the example and I keep getting time outs.

tdwitham opened this issue · 47 comments

So I get a timeout response - can go to the browser and it all works fine, any hints?

`import sys
import redfish

login_host = "https://10.250.2.2"
login_account = "root"
login_password = "tester"

sys.stdout.write("Before OBJ host=%s account=%s password=%s\n" % (login_host, login_account, login_password))
REDFISH_OBJ = redfish.redfish_client(base_url=login_host, username=login_account, password=login_password,
timeout=5, max_retry=3, default_prefix='/redfish/v1/Systems')
sys.stdout.write("After OBJ\n")

REDFISH_OBJ.login(auth="session")

response = REDFISH_OBJ.get("/redfish/v1/Systems", None)

sys.stdout.write("%s\n" % response)

REDFISH_OBJ.logout()
`

Is there an exception shown from the sample that could be shared? I would like to see where exactly the timeouts are coming from.

Can you also try changing "session" to "basic" in the login method? Browsers would use Basic Auth instead of Redfish Sessions, so that would give us a bit of consistency between the two for testing.

Some other things you can try with curl that might help; can you share the responses for these?

  • curl -k -u root:tester -D - "https://https://10.250.2.2/redfish/v1/"
  • curl -k -u root:tester -D - "https://https://10.250.2.2/redfish/v1/Systems"
  • curl -k -u root:tester -D - "https://https://10.250.2.2/redfish/v1/SessionService"
  • curl -k -u root:tester -D - "https://https://10.250.2.2/redfish/v1/SessionService/Sessions"

Are your proxy settings configured via the following environment variables like this, or is there something else your browser is using?

export HTTP_PROXY="http://192.168.1.10:8888"
export HTTPS_PROXY="http://192.168.1.10:8888"

No, installing a certificate isn't needed for the interface to work (but it is encouraged since most services come with a self-signed certificate by default).

At least from the messages in your latest response, that would indicate to me the credentials "root" and "tester" are not valid. Were those same credentials working in the browser when you tried accessing Redfish resources via that path?

The library itself doesn't contain that level of logic; it stops at producing a Python dictionary from the the JSON response, and leaves it up to the caller to extract the dictionary values that are relevant to their usage.

We do have a separate set of scripts that consumes this library and does more of the higher order types of operations (like collecting and displaying log data), and could be used as a sample for how to walk a Redfish service to find the data of interest. That project can be found here: https://github.com/DMTF/Redfish-Tacklebox

You need to specify the scheme with the address; instead of --rhost 10.250.2.2 it should be --rhost http://10.250.2.2

Probably worth adding some validation in the library to make the exception more clear to the user, since it's ultimately the library that consumes the value passed in the rhost argument.

It's hard to tell without the payload in question, but it appears the service is not rendering the mandatory @odata.id property in one or more of its Drive resources. If this is the case, we might need to consider adding some workaround flags to bypass services that are not implementing mandatory properties to Tacklebox.

It could be that there was an error in getting the resource in question (and error payloads do not have @odata.id properties). This might be a good time for me to revisit this tool and improve the error handling.

You should be able to get it from a browser and paste it here. From the trace, it's following the links through Systems, Storage, and Drives.

Depending on the number of storage subsystems, it might get difficult to track down the exact culprit. I would start with trying to find the first drive reported in the first storage subsystem.

  • Go to /redfish/v1/Systems
  • Go to the first system instance in the Members array
  • Go to the Storage collection found in the first system (look for the "Storage" property)
  • Go to the first storage instance in the Members array
  • Go to the first drive listed in the "Drives" property

I'm hoping the payload found at that last step will tell us what's going on, but if it's not clear, I can make a debug branch in Tacklebox for tracing what's going on.

So, it is the latter case; the Storage resource is presenting links to Drives that result in a 404. I can certainly add better error handling to not crash in these cases, but it would be good to understand why the service you're working with isn't accepting the Drive URIs its presenting. It could be a case where the drive itself is absent, but we have modeling guidance in Redfish to render the resource with the "State" property inside of "Status" as "Absent" rather than returning a 404.

What do you get when you issue a GET /redfish/v1/Systems/............/Storage/1/Drives/0 via Postman? Anything you do via the library, you can debug by walking the resource tree manually.

@tdwitham I just released some changes that might help; rf_sys_inventory has a "workaround" flag added to bypass that issue you hit.

In this case it looks like you can't even log into the system; it's trying to access /redfish/v1/ but getting a 400. Can you access the resource in the browser?

I just noticed the URI given is not correct. You're missing a / in the rhost argument: http:/10.250.2.2.

For --rhost, you would leave off the resource URI (it's just the scheme + IP address). So, it should be --rhost https://10.250.2.2.

Would it be possible to try https instead of http? Services tend to reject Redfish Session Login when using http since it's not a secure communication channel.

rf_sys_inventory.py --user test --password tester --rhost https://10.250.2.2

Okay, can you add the new --workaround argument to attempt to bypass service-side issues?

It also doesn't seem like you've pulled down the latest updates to Tacklebox; the line reported in the exception trace doesn't match the updates we've pushed last week and it correlates with the older version prior to the introduction of the --workaround flag for the script.

How long did you wait? Depending on the size of the service and its responsiveness to requests, it may take a minute for the inventory to be collected.

Sure, that would be good to see for me to compare with what I'm currently expecting. It might need to be provided back to the service vendor.

What happens when you try to access URIs like "/redfish/v1/Chassis/PCIeRiser3" in your browser?

What do you get back as a response in your browser?

I may need to add more info info to the warning messages to show what exactly went wrong.

I don't think email attachments come through on the GitHub issue; only the text gets posted as far as I know.

The latter; "/redfish/v1/Chassis/RackMount/PwrSupply1FRU" is an illegal URI

Closing; the issues here are related to non-conformant URIs from the service. Tacklebox has an enhancement opened to allow for a user to control whether the tools dynamically adjust to non-conformant URIs or make 1.6.0 assumptions about URIs (DMTF/Redfish-Tacklebox#75), which is the remainder of the problem in this issue.