Comment 10 for bug 1525259

Hi Stuart, Erno,

We have looked at the solution and we understand it like this:

Every API method which is making an http request will be passed a list by the caller.

If the ‘request’ is successful then the request id (extracted from the response object) will be *appended* to this list. Although the request is successful but the corresponding operation maybe a failure. For e.g. calling delete for an invalid image id.

If the ‘request’ fails for some reason(for e.g. toke authentication failure or glance service is down) then there will
be no request id in the response received so list will not be modified.

By analyzing various API methods we can categorize them based on the no. of requests made:

1. Methods making only a single ‘request’:
This is the simplest case. Examples: images.create(), image_members.list() etc. Here after the call request id list will look like: [‘request-id’]

2. Methods making 2 to 3 ‘requests’:
Here after the call request id list will look like: [‘request-id1’, ‘request-id2’, ‘request-id3’]. Example: images.update_locations()
Here first we fetch the image's model via get()[1st req id] then we make a patch request to update the image[2nd req id] at last we fetch the updated image model[3rd req id]

3. Methods making n number of ‘requests’:
Here after the call request id list will look like: [‘request-id1’, ‘request-id2’, ‘request-id3’, …]. For example: images.list()
Here no. of request ids returned depends on page_size and limit factors. If no. of images to list is 5 and page_size=1 then no. of request ids returned is 6. First five for each page request(1 image per page). An extra request id is returned while calling paginate() one last time to raise StopIeration.

Some concerns:

For case #2 many intermediate requests are being made so should the caller get all the request ids or just one?