Error in c-vol log after successful tempest run

[David Kranz]

From http://logs.openstack.org/33211/2/gate/gate-tempest-devstack-vm-postgres-full/31368/logs/screen-c-vol.txt.gz

2013-07-12 16:25:36.240 18985 ERROR cinder.volume.manager [req-5a566878-ecd1-498e-87d3-e4c5c8da6cf1 3c0d50f8e7644d3089d906514284d37a 1104a927112849f7bd7d7b50efd02bf3] Failed to update usages deleting volume
2013-07-12 16:25:36.240 18985 TRACE cinder.volume.manager Traceback (most recent call last):
2013-07-12 16:25:36.240 18985 TRACE cinder.volume.manager File "/opt/stack/new/cinder/cinder/volume/manager.py", line 480, in delete_volume
2013-07-12 16:25:36.240 18985 TRACE cinder.volume.manager volume_ref.get('volume_type_id'))
2013-07-12 16:25:36.240 18985 TRACE cinder.volume.manager File "/opt/stack/new/cinder/cinder/quota.py", line 882, in add_volume_type_opts
2013-07-12 16:25:36.240 18985 TRACE cinder.volume.manager volume_type = db.volume_type_get(context, volume_type_id)
2013-07-12 16:25:36.240 18985 TRACE cinder.volume.manager File "/opt/stack/new/cinder/cinder/db/api.py", line 389, in volume_type_get
2013-07-12 16:25:36.240 18985 TRACE cinder.volume.manager return IMPL.volume_type_get(context, id)
2013-07-12 16:25:36.240 18985 TRACE cinder.volume.manager File "/opt/stack/new/cinder/cinder/db/sqlalchemy/api.py", line 139, in wrapper
2013-07-12 16:25:36.240 18985 TRACE cinder.volume.manager return f(*args, **kwargs)
2013-07-12 16:25:36.240 18985 TRACE cinder.volume.manager File "/opt/stack/new/cinder/cinder/db/sqlalchemy/api.py", line 1626, in volume_type_get
2013-07-12 16:25:36.240 18985 TRACE cinder.volume.manager return _volume_type_get(context, id)
2013-07-12 16:25:36.240 18985 TRACE cinder.volume.manager File "/opt/stack/new/cinder/cinder/db/sqlalchemy/api.py", line 139, in wrapper
2013-07-12 16:25:36.240 18985 TRACE cinder.volume.manager return f(*args, **kwargs)
2013-07-12 16:25:36.240 18985 TRACE cinder.volume.manager File "/opt/stack/new/cinder/cinder/db/sqlalchemy/api.py", line 1617, in _volume_type_get
2013-07-12 16:25:36.240 18985 TRACE cinder.volume.manager raise exception.VolumeTypeNotFound(volume_type_id=id)
2013-07-12 16:25:36.240 18985 TRACE cinder.volume.manager VolumeTypeNotFound: Volume type 301e36d9-87cd-4d19-aa82-d9dfc6f366bc could not be found.
2013-07-12 16:25:36.240 18985 TRACE cinder.volume.manager
2

[John Griffith (john-griffith)]

So what's happening here is the test is creating a volume type and then creating a volume with that type.

next it deletes the volume type.

so now, when the volume is deleted and it tries to querie the quota for the volume-type associated with that volume we get an exception because the type no longer exists.

Number of options here:
1. Handle the exception by checking the deleted types when this is encountered
        This will lead to some other issues because of the way the quota resource checks are implemented, and could lead to a bit
         of refactoring in the quota code
2. Don't allow deletion of volume-types that are currently in use
        Rather than delete types that are in use, we error with "can't delete in use resource" or something like that
        We could offer up something like a "disable-type" so that a type that admins don't want used any longer will be disabled but
        still exist until they're no longer in use.

Personally I like option 2, it seems like more intuitive behavior, I'd like to get some input from folks and maybe throw out a proposal shortly to see what others think.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/36922

[John Griffith (john-griffith)]

Further thought, there's little distinction between those two actually... Just going with option 1 for now.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/36922
Committed: http://github.com/openstack/cinder/commit/18308807de7e7090854d6fde9ae06c7ffbf9b7ac
Submitter: Jenkins
Branch: master

commit 18308807de7e7090854d6fde9ae06c7ffbf9b7ac
Author: John Griffith <email address hidden>
Date: Fri Jul 12 17:43:27 2013 -0600

    Be sure to check deleted types on quota update.

    If a volume-type is deleted, and later a volume
    that's assigned that type is deleted the quota
    update will fail and result in a trace for
    VolumeTypeNotFound exception.

    The volume is succesfully deleted, however the
    quota information for the volume-type let alone
    the other quota items for the volume are not
    updated.

    Fixes bug: 1200709

    Change-Id: Idd687514be9d622df84aad54b1b33ddc6615851b