The list of volumes that are queried with an error state does not contain the error_managing state

Bug #1877028 reported by haixin
This bug affects 2 people
Affects Status Importance Assigned to Milestone
In Progress

Bug Description

When we fail to manage a volume, we use cinder list to view the volume list, or use cinder show to view the volume details, We can see that the volume state is error.
   But when we filter the list of volumes by specifying the status as error,We found that there were no manage failed volumes in the screening results.

   This is because the state of the volumes in which the manage failed is error_managing in the database, and in, in line 62 ,that is why cinder lit or cinder show
tell us the state of manage failed volume is error, but not error_managing.

  I think this will confuse the user,user may not care whether the state of the volume is error or error_managing,We only distinguish the error_managing state when deleting volumes and handling quotas. So i think error_managing should be included when querying volumes with an error status.
    To query creating or deleting status of volumes as same.


To fix a quota computation issue described in, some internal volume statuses were introduced: 'managing', 'error_managing', and 'error_managing_deleting'.
(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:
So as far as operator/end-users are concerned, these statuses do not exist.

This is implemented in the cinder.api.v2.views.volumes.ViewBuilder class (which is the base class of cinder.api.v3.views.volumes.ViewBuilder). What it does is map the managing statuses to "official" statuses as follows:
'managing': 'creating',
'error_managing': 'error',
'error_managing_deleting': 'deleting',
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_id}/volumes
GET /v3/{project_id}/volumes/detail
GET /v3/{project_id}/volumes/{volume_id}
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_id}/volumes/detail call and notices x volumes in 'error' status. The user then makes the call
GET /v3/{project_id}/volumes/detail?status=error
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_id}/volumes/{volume_id}
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 I5887c5f2ded6d6a18f497a018d5bf6105bc5afd7 that for the purposes of the REST API, a volume with internal status 'managing' was "really" in the status 'creating', and the same for the other managing statuses.
(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_id}/volumes/detail?status=error_managing
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_id}/volumes/detail?status=managing
GET /v3/{project_id}/volumes/detail?status=error_managing_deleting
These calls should not return any volumes, there are no such statuses.

Note that using microversion 3.34,
GET /v3/{project_id}/volumes/detail?status~=error
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_managing_deleting' (though they will be displayed as having status 'deleting', and should not actually be included in the response; this is the third bug associated with this issue).

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_deleting should also be included
(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/{project_id}/volumes/detail?status=not-a-status you get the response { "volumes": [] }, not a 400). Currently we rely on the database for this, but we may need to handle it in the REST API layer.
(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_deleting. ?status~=creating should include volumes with (internal) status 'managing'. ?status~=deleting (I think) probably works as expected. I think the "like" operator is handled in the DB layer right now.

haixin (haixin77)
Changed in cinder:
assignee: nobody → haixin (haixin77)
description: updated
haixin (haixin77)
description: updated
Changed in cinder:
status: New → In Progress
haixin (haixin77)
description: updated
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on cinder (master)

Change abandoned by haixin (<email address hidden>) on branch: master

haixin (haixin77)
description: updated
Revision history for this message
haixin (haixin77) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.