GutoVeronezi commented on PR #6868: URL: https://github.com/apache/cloudstack/pull/6868#issuecomment-1339987731
@weizhouapache, I tested the PR and had the following results: First I configured the environment to run the cleanup tasks every 5 seconds, with a delay before expunging the resources of 45 seconds for volumes and 90 seconds for VMs: ``` storage.cleanup.interval = 5 expunge.interval = 5 storage.cleanup.delay = 45 expunge.delay = 90 ``` I then created a specific account for the tests. --- With the configuration `destroy.root.volume.on.vm.destruction` as `false` (i.e.: the current behavior), I did 3 tests: 1. I created a VM with a data disk and verified that the account was consuming 2 volumes. Then, I destroyed the VM along with the data disk (without expunging); the data disk was put in `Destroy` state and it was detached from the VM. The ROOT disk stayed in `Ready` state and attached to the VM. After deleting the VM, I verified that the account was consuming 1 volume. Two records of type `VOLUME.DELETE` were persisted in table `cloud.usage_event`. After 45 seconds, the data disk was expunged[^data-disk-current-behavior] and the ROOT disk stayed in `Ready` state and attached to the VM. After 90 seconds, the ROOT volume was expunged along with the VM. Finally, I verified that the account was consuming 0 volumes. 2. I created a VM with a data disk and verified that the account was consuming 2 volumes. Then, I destroyed the VM along with the data disk (without expunging); the data disk was put in `Destroy` state and it was detached from the VM while the ROOT disk stayed in `Ready` state and attached to the VM. After deleting the VM, I verified that the account was consuming 1 volume. Two records of type `VOLUME.DELETE` were persisted in table `cloud.usage_event`. Then, I recovered the VM and a record of type `VOLUME.CREATE` was persisted in table `cloud.usage_event` for the ROOT disk. The account was still consuming 1 volume. Finally, I recovered the data disk and a record of type `VOLUME.CREATE` was persisted in table `cloud.usage_event` for the data disk. Also, I verified that the account was consuming 2 volumes after recovering both ROOT and data disks. 3. I created a VM with a data disk and verified that the account was consuming 2 volumes. Then, I destroyed the VM along with the data disk (without expunging); the data disk was put in `Destroy` state and it was detached from the VM. The ROOT disk stayed in `Ready` state and attached to the VM. After deleting the VM, I verified that the account was consuming 1 volume. Two records of type `VOLUME.DELETE` were persisted in table `cloud.usage_event`. I changed the configuration `destroy.root.volume.on.vm.destruction` to `true`. Like the first test, after 45 seconds, the data disk was expunged[^data-disk-current-behavior] and the ROOT disk stayed in `Ready` state and attached to the VM. After 90 seconds, the ROOT volume was expunged along with the VM. Finally, I verified that the account was consuming 0 volumes. Both tests presented the expected result: ROOT volume stayed in `Ready` state until the VM expunge and the account kept consuming 1 volume until the ROOT disk was expunged. --- With the configuration `destroy.root.volume.on.vm.destruction` as `true` (i.e.: the current behavior), I did 3 tests: 1. I created a VM with a data disk and verified that the account was consuming 2 volumes. Then, I destroyed the VM along with the data disk (without expunging); the ROOT and the data disks were put in `Destroy` state and were detached from the VM. After deleting the VM, I verified that the account was consuming 0 volumes. Two records of type `VOLUME.DELETE` were persisted in table `cloud.usage_event`. After 45 seconds, the data disk was expunged[^data-disk-current-behavior] and the ROOT disk stayed in `Destroy` state. After 90 seconds, the ROOT volume was expunged along with the VM. 2. I created a VM with a data disk and verified that the account was consuming 2 volumes. Then, I destroyed the VM along with the data disk (without expunging); the ROOT and the data disks were put in `Destroy` state and were detached from the VM. After deleting the VM, I verified that the account was consuming 0 volumes. Two records of type `VOLUME.DELETE` were persisted in table `cloud.usage_event`. Then, I recovered the VM and a record of type `VOLUME.CREATE` was persisted in table `cloud.usage_event` for the ROOT disk and the account was consuming 1 volume. Finally, I recovered the data disk and a record of type `VOLUME.CREATE` was persisted in table `cloud.usage_event` for the data disk. Also, I verified that the account was consuming 2 volumes after recovering both ROOT and data disks. 3. I created a VM with a data disk and verified that the account was consuming 2 volumes. Then, I destroyed the VM along with the data disk (without expunging); the ROOT and the data disks were put in `Destroy` state and were detached from the VM. After deleting the VM, I verified that the account was consuming 0 volumes. Two records of type `VOLUME.DELETE` were persisted in table `cloud.usage_event`. I changed the configuration `destroy.root.volume.on.vm.destruction` to `false`. Like the first test, after 45 seconds, the data disk was expunged[^data-disk-current-behavior] and the ROOT disk stayed in `Ready` state and attached to the VM. After 90 seconds, the ROOT volume was expunged along with the VM. Finally, I verified that the account was consuming 0 volumes. Both tests presented the expected result: ROOT volume was put in `Destroy` state and was properly expunged only with the VM expunge task, and the account was consuming 0 volumes. --- Based on the results of the manual test, [Trillian](https://github.com/apache/cloudstack/pull/6868#issuecomment-1327034590)[^error-trillian] tests results, Travis results, [packaging results](https://github.com/apache/cloudstack/pull/6868#issuecomment-1326501535) and approvals, I will merge this PR. [^data-disk-current-behavior]: as the data disks are detached from the VM, the disk expunge task will expunge it. This is the current behavior and was not touched by the PR. [^error-trillian]: error in Trillian does not seem related to the PR changes: `AssertionError: Expected '1' routers at state 'PRIMARY', but found '0'!`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
