filtering the volume-list by status does not include all requested volumes
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Cinder |
In Progress
|
Undecided
|
haixin |
Bug Description
Background
----------
To fix a quota computation issue described in https:/
(We will call these the "managing statuses".)
The managing statuses were intentionally *not* exposed in the REST API, and do not occur in the list of possible volume statuses: https:/
So as far as operator/end-users are concerned, these statuses do not exist.
This is implemented in the cinder.
'managing': 'creating',
'error_managing': 'error',
'error_
so that only the "official" status will appear when a volume with one of the managing statuses is displayed.
As a result, if a user does:
GET /v3/{project_
GET /v3/{project_
GET /v3/{project_
the user can see a volume that's in a managing status, it's just that the status will be displayed as either 'creating', 'error', or 'deleting'.
The problem
-----------
A user makes the GET /v3/{project_
GET /v3/{project_
and receives a list of y volumes, where y < x.
The "missing" volumes are in the internal 'error_managing' status.
If the user picks one of the volumes in x but not y, and does a
GET /v3/{project_
the volume shows as having status 'error'. (A similar problem occurs if a user filters on status 'creating' or 'deleting'.)
This is confusing.
The situation
-------------
(1) Volumes in managing statuses are already displayed to end users as being in an "official" status. In other words, we already decided back in September 2016 with Change-Id I5887c5f2ded6d6
(2) When a user filters the volume list on status=error, they should see all volumes that are considered in error status from the REST API point of view regardless of what the purely internal status of the volume is.
Since it's a bug, I don't think that fixing this requires a special flag be added to the API or a microversion. In fact, if an end user can make the call:
GET /v3/{project_
and get only the volumes with internal status 'error_managing' (though they'll be displayed as 'error'), then that is also a bug, because as far as the REST API is concerned, there is no such status. This same bug covers these:
GET /v3/{project_
GET /v3/{project_
These calls should not return any volumes, there are no such statuses.
Note that using microversion 3.34,
GET /v3/{project_
should (properly) return the volumes in 'error_managing' (though they will be displayed as 'error'). It will also pull up volumes in internal status 'error_
OK, so what needs to be fixed?
(A) when a user filters on status=error, volumes in (internal) status error_managing should also be included
(B) when a user filters on status=creating, volumes in (internal) status managing should also be included
(C) when a user filters on status=deleting, volumes in (internal) status error_managing_
(D) when a user filters on any status that's not in the official list, they should get an empty list of volumes (need to verify that's the current behavior, but I'm pretty sure that if you GET /v3/v3/
(E) fixing the "like" operator from microversion 3.34 is going to be tricky. ?status~=error should include volumes in statuses error, error_deleting, error_backing-up, error_restoring, and error_extending (and error_managing), but NOT include volumes with status error_managing_
Changed in cinder: | |
assignee: | nobody → haixin (haixin77) |
Changed in cinder: | |
status: | New → In Progress |
this bug has reported by https:/ /bugs.launchpad .net/cinder/ +bug/1877028.