quota usage is wrong after volume type rename

[craig]

we had our original volume-type. when we grew enough to add more tiers of storage we created a new type and deleted the old types. we did not remove the old tier of storage, just renamed the type it was specified as. cinder quota keeps these old references even though the volumes were giving a new type. so our guota for gigabytes is accurate, but we have mismatched numbers.

example
+------------------------+--------+----------+-------+
| Type | In_use | Reserved | Limit |
+------------------------+--------+----------+-------+
| gigabytes | 15 | 0 | 1001 |
| gigabytes_Standard-HDD | 13 | 0 | 1000 |
| snapshots | 0 | 0 | 10 |
| snapshots_Standard-HDD | 0 | 0 | 10 |
| volumes | 6 | 0 | 10 |
| volumes_Standard-HDD | 4 | 0 | 10 |
+------------------------+--------+----------+-------+

so I have 2 1GB volumes under that existed prior to the volume type change. the volumes themselves are all of type Standard-HDD, just 2 had their DB records updated to Standard-HDD from "block"

from the db
+---------------------+---------------------+---------------------+---------+-------+----------------------------------+------------------------+--------+----------+---------------+
| created_at | updated_at | deleted_at | deleted | id | project_id | resource | in_use | reserved | until_refresh |
+---------------------+---------------------+---------------------+---------+-------+----------------------------------+------------------------+--------+----------+---------------+
| 2015-05-11 17:39:26 | 2015-07-09 01:03:55 | 2015-07-08 19:26:30 | 0 | 20827 | 695263484ddf44939a972106d8bb6edc | gigabytes | 15 | 0 | NULL |
| 2015-05-11 17:39:26 | 2015-07-08 19:26:30 | 2015-07-08 19:26:30 | 0 | 20830 | 695263484ddf44939a972106d8bb6edc | gigabytes_block | 1 | 0 | 0 |
| 2015-05-11 17:39:26 | 2015-07-08 19:26:30 | 2015-07-08 19:26:30 | 0 | 20833 | 695263484ddf44939a972106d8bb6edc | volumes_block | 1 | 0 | 0 |
| 2015-05-11 17:39:27 | 2015-07-09 01:03:55 | 2015-07-08 19:26:30 | 0 | 20836 | 695263484ddf44939a972106d8bb6edc | volumes | 6 | 0 | NULL |
| 2015-05-11 17:39:43 | 2015-07-08 19:26:30 | 2015-07-08 19:26:30 | 0 | 20839 | 695263484ddf44939a972106d8bb6edc | volumes_ceph | 1 | 0 | 0 |
| 2015-05-11 17:39:43 | 2015-07-08 19:26:30 | 2015-07-08 19:26:30 | 0 | 20842 | 695263484ddf44939a972106d8bb6edc | gigabytes_ceph | 1 | 0 | 0 |
| 2015-05-11 18:46:53 | 2015-07-09 01:03:55 | 2015-07-08 19:26:30 | 0 | 20845 | 695263484ddf44939a972106d8bb6edc | volumes_Standard-HDD | 4 | 0 | NULL |
| 2015-05-11 18:46:53 | 2015-07-09 01:03:55 | 2015-07-08 19:26:30 | 0 | 20848 | 695263484ddf44939a972106d8bb6edc | gigabytes_Standard-HDD | 13 | 0 | NULL |
| 2015-06-09 12:55:53 | 2015-07-08 19:26:30 | 2015-07-08 19:26:30 | 0 | 25846 | 695263484ddf44939a972106d8bb6edc | snapshots_Standard-HDD | 0 | 0 | NULL |
| 2015-06-09 12:55:53 | 2015-07-08 19:26:30 | 2015-07-08 19:26:30 | 0 | 25849 | 695263484ddf44939a972106d8bb6edc | snapshots | 0 | 0 | NULL |
+---------------------+---------------------+---------------------+---------+-------+----------------------------------+------------------------+--------+----------+---------------+

so basically either we need a way to update the quota-usage properly, or have a method to do a type-modify

[David Medberry (med)]

While this may be viewed as an enhancement it is a real big operator issue.

[Lisa Li (lisali)]

I think this is a bug, and needs code change.

This is the test.
cinder quota-usage 570c6bc94706439c9e7622e3041ba0d1
+-----------------------+--------+----------+-------+
| Type | In_use | Reserved | Limit |
+-----------------------+--------+----------+-------+
| backup_gigabytes | 2 | 0 | 1000 |
| backups | 2 | 0 | 10 |
| gigabytes | 9 | 0 | 1000 |
| gigabytes_LUKS | 8 | 0 | -1 |
| gigabytes_lvmdriver-2 | 0 | 0 | -1 |
| per_volume_gigabytes | 0 | 0 | -1 |
| snapshots | 0 | 0 | 10 |
| snapshots_LUKS | 0 | 0 | -1 |
| snapshots_lvmdriver-2 | 0 | 0 | -1 |
| volumes | 9 | 0 | 10 |
| volumes_LUKS | 8 | 0 | -1 |
| volumes_lvmdriver-2 | 0 | 0 | -1 |
+-----------------------+--------+----------+-------+

Before changing type LUKS, there are 8 1G-volume with the type.
| volumes_LUKS | 8 | 0 | -1 |
| gigabytes_LUKS | 8 | 0 | -1 |

And after rename the type to LUKS2,
cinder type-update --name LUKS2 f5d4b8b4-0928-4877-84e9-1f3be74d32b1

cinder quota-usage 570c6bc94706439c9e7622e3041ba0d1
+-----------------------+--------+----------+-------+
| Type | In_use | Reserved | Limit |
+-----------------------+--------+----------+-------+
| backup_gigabytes | 2 | 0 | 1000 |
| backups | 2 | 0 | 10 |
| gigabytes | 9 | 0 | 1000 |
| gigabytes_LUKS2 | 0 | 0 | -1 |
| gigabytes_lvmdriver-2 | 0 | 0 | -1 |
| per_volume_gigabytes | 0 | 0 | -1 |
| snapshots | 0 | 0 | 10 |
| snapshots_LUKS2 | 0 | 0 | -1 |
| snapshots_lvmdriver-2 | 0 | 0 | -1 |
| volumes | 9 | 0 | 10 |
| volumes_LUKS2 | 0 | 0 | -1 |
| volumes_lvmdriver-2 | 0 | 0 | -1 |
+-----------------------+--------+----------+-------+

The quota usage changes to 0, which is not correct.
| volumes_LUKS2 | 0 | 0 | -1 |
| gigabytes_LUKS2 | 0 | 0 | -1 |

cinder list
+--------------------------------------+-----------+------+------+-------------+----------+-------------+
| ID | Status | Name | Size | Volume Type | Bootable | Attached to |
+--------------------------------------+-----------+------+------+-------------+----------+-------------+
| 101dda44-3319-417f-af9f-8415a659c351 | available | - | 1 | LUKS2 | false | |
| 186f86be-95e5-4928-8d9f-4e3842392c7e | error | - | 1 | LUKS2 | false | |
| 428d2e86-8469-4c39-8390-f9d3d8bf11d4 | error | - | 1 | LUKS2 | false | |
| 47601619-0076-47b9-9b34-a0f02f904cf4 | available | - | 1 | lvmdriver-2 | false | |
| 4efc2b1b-f69c-4200-84c5-5c90cbc17d14 | available | - | 1 | LUKS2 | false | ...

[Lisa Li (lisali)]

The following quota can be corrected once creating/deleting volumes in this volume type.

Another worse case is:
1. Create a volume type with name1.
2. Create 3 volumes with type name1.
3. Update the name of above type to name2.
4. Create another new volume type with name1.

I found that "cinder quota-usage" shows volumes in type name1 created in step 4 has 3 in-use voluems. This is not correct, and can't be corrected in current codes.

[Sean McGinnis (sean-mcginnis)]

Volume types should not be renamed. In the situation given, it would have been better to create a new volume type with the new name but similar settings to the original, then retyped the volumes over to the new volume type.

[craig (craig-delatte)]

Sean,
  2 things. first, when this ticket was opened re-type was not working 100% for re-typing between rbd and solidfire and vice versa. Second, when I have over 1000 volumes I have to take time to script something out to re-type all my volumes and hope something doesn't go wrong? I would think running one command to rename a volume type would be more efficient than running hundreds or thousands of re-type commands. Not to mention easier on the infrastructure

[Lisa Li (lisali)]

I am going to rename the resource in quota_usage when name of a volume type is changed. Meanwhile, set until_fresh as 1 so that the in-use value can be synced and rechecked when next reservation.

Meanwhile, delete invalid resources in quota_usages when upgrading.

[Lisa Li (lisali)]

The fix is https://review.openstack.org/#/c/267999/

[Huang Zhiteng (zhiteng-huang)]

I second Sean's opinion about volume type shouldn't be renamed. Back to Craig's bug report, I'm confused because if the only difference between new type and old type is the name, then 'retype' should be really quick (at backend level it's a no-op [https://github.com/openstack/cinder/blob/master/cinder/volume/manager.py#L2169-L2170] although it has to go through scheduler). Why would it involve retype volumes between two different backends?

[craig (craig-delatte)]

Huang,

it is not whether volume retype will work. I guess I am not painting the picture correctly. imagine you have over 1000 volumes that you need to retype per environment. so instead of having a volume type (modify/rename) to do once and it set everything, basically by changing the name of the volume type.

instead the team is recommending to create a new volume type, run 1000 volume retype commands which will have go through the api/scheduler/rabbitmq, to basically only change the name. this seems really inefficient to me. If I can change the description for a volume type and add/remove specs at will, then why not add the ability to change the volume type name?

I would also need you to explain to me out the retype would only be doing a scheduler call. if I am reading the code correctly (am I am sure I am missing something here), but how would the old volume type id and new volume type id ever be the same? I need to create a new volume type just so I have somewhere to retype it to? again, I am sure I am missing something, but would like someone to weigh in on this.

as in terms of two different backend, that was just an example of a point in time when testing re-type that it was another thing not working 100%.

[Huang Zhiteng (zhiteng-huang)]

Craig,

Yes, 'retyping' between two different backends didn't work before generic volume migration was ready if one backend was ceph. While this was true, it doesn't seem like related to the problem you tried to solve - changing the name of the volume type and nothing else, meaning the if this is done through 'retype', new type has exact same type exra specs as old type, the only different is type name (and type UUID of course, I made a mistake in previous comment implying retype can leave type id unchanged). Retyping will be no-op at backend level as you can see from https://github.com/openstack/cinder/blob/master/cinder/volume/manager.py#L2169-L2170 The only gotcha for 'retype' is, if your type definition allows one type to map to multiple backends, a no-op retype could turn into a migration. But I am pretty sure most people don't define type that way.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/267999
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=b1a322cf8fbf97a48f8fff07f70d2d32c83c9ea6
Submitter: Jenkins
Branch: master

commit b1a322cf8fbf97a48f8fff07f70d2d32c83c9ea6
Author: LisaLi <email address hidden>
Date: Fri Jan 15 16:12:45 2016 +0800

    Update quota when volume type renames

    When customers rename volume type, the corresponding quota_usages
    should be changed. Or else quota_usage shows incorrect data.

    Meanwhile, it deletes quota_usages whose corresponding volume
    types don't exist. These invalid data are left when renaming
    volume types in old versions.

    Closes-bug: #1473183

    Change-Id: I9071821f8c1a95fccef214868e5cea026fed9657
    Co-Authored-By: wanghao <email address hidden>