Description of problem: For DC level 3.6, the only place we still do the PV creation test when executing GetDeviceList verb is through the REST API. When getting the LUNs list, we need to provide the "Status" of the LUN. It was kept for backward compatibility with 3.x and we can remove\change in 4.0. Scale setups will timeout as before fixing BZ #1217401. We need to provide alternative to this REST call that will work for scale. Steps to Reproduce: 1. Run engine with many direct luns. For example: total luns available: 383 total paths: 1,532 2. Call GetDeviceList verb through the REST API Actual results: real 9m37.496s user 0m1.905s sys 0m0.047s Expected results: Should not time out. Additional info:
Note that the reporting of the status of the LUN can be removed or made optional in version 4 of the API. But as version 4 of the engine has to support versions 3 and 4 of the API the capability can't be removed from the backend. Thus it is easier to just keep it in version 4 of the API. I'd suggest to add a parameter that can be used to enable/disable this reporting of the status of the LUN: GET /hosts/{host:id}/storage;report_status=true|false The default value of this parameter should be "true" in version 3 of the API, to preserve backwards compatibility. In version 4 of the API it can be "false".
This bug was fixed and is slated to be in the upcoming version. As we are focusing our testing at this phase on severe bugs, this bug was closed without going through its verification step. If you think this bug should be verified by QE, please set its severity to high and move it back to ON_QA
Megan, the term "host storage domain" is confusing. Storage domains are DC level entities, not host level entities. The correct term would be something like "The report_status parameter is available when getting a list of storage devices visible to a host or when getting a specific storage device via a host".
Hi Allon, Thanks for picking that up. Not sure what I was thinking yesterday. Corrected now. Megan