Need to be able to support larger #'s of servers, profiles, templates etc.

[ddefolo]

OneView automatically returns GET calls for resources in pages based on the "count" value requested or based on some level of internally determined size to assure a certain speed of response. See the "count" query parameter description in the API docs:

The number of resources to return. A count of -1 requests all the items. The actual number of items > in the response may differ from the requested count if the sum of start and count exceed the total > number of items, or if returning the requested number of items would take too long.

From testing a 2.0 DCS appliance we noted paging at the following boundaries:

• 32 for server-hardware
• 64 for server-profiles
• 64 for server-profile-templates
• 50 for index resources

ICsp is similar. Testing with ICsp 7.4 and 7.4.1 noted paging of OS build plans above 50 or 60.

At minimum the following files have API calls that don't account for paging:

• ov/profiles.go
• ov/profile-templates.go
• ov/server-hardware.go
• icsp/jobs.go
• icsp/servers.go
• icsp/build_plan.go

To workaround this every GET call needs to check nextPageUri in the response to see if additional GETs must be made to get the entire list. I worked around this in the CSA dynamic JSP files with the following subroutine wrapping every GET call where the value for query_url would start out with something like "/rest/server-hardware" and providerUrl was the part of the API call that goes before that (meaning https://):

JSONArray DoPagedGet (String providerUrl, String query_url, DefaultHttpClient client, String sessionID) throws Exception {
        String output = "";
        JSONArray fullMemberList = new JSONArray();

        while (!query_url.isEmpty()) {
            logger.debug("Doing paged query: " + query_url);
            output = OneView_Get(client, providerUrl+query_url, sessionID);

            JSONObject response_json = new JSONObject(output);
            int count = response_json.getInt("count");
            JSONArray currPageMembers = response_json.getJSONArray("members");
            logger.debug("Got " + count + " entries");

            for (int i = 0; i < currPageMembers.length(); i++) {
                fullMemberList.put(currPageMembers.getJSONObject(i));
            }
            String nextPage = response_json.getString("nextPageUri");
            query_url = "";
            if (nextPage != null && !nextPage.equalsIgnoreCase("null")) {
                logger.debug("Need to do query to get next page: " + nextPage);
                query_url = nextPage;
            }
        }
        return fullMemberList;
    }

[Edward Raigosa]

These are all the types that have a Count attribute, along with nextPage

icsp/build_plan.go
icsp/servers.go
icsp/jobs.go
ov/profiles.go
ov/server_hardware.go

We should also check

ov/server_hardwarev2.go:

[Miguel Quintero]

thanks @ddefolo (will reach out to one of the Andy's to get DCS)

[yuvirani]

@ddefolo, Our oneview team is working on it as we are facing this issue from OV appliance itself. Once it is fixed, we will update you.

[nabhajit-ray]

Closing the defect as this does not fall under SDK scope