PaulAngus commented on pull request #4493:
URL: https://github.com/apache/cloudstack/pull/4493#issuecomment-747950146
I think some people are not understanding what the state '_destroyed, but
not expunged_' is.
'not expunged' is the same as 'recycle bin'/'trash'/'deleted items'. It's
an intermediate state before 'gone forever' to give the opportunity to undo if
you made a mistake.
No user is going to think "I'll put this VM in the recycle bin just in case
I need it in the next _2_ days".
+ the user may not have the option expunge/recover as per global settings.
Therefore when a user destroys a VM, then CloudStack should behave like the
VM has been destroyed.
At this point, we have to remember that volumes are **first-class
citizens**, they do not _belong_ to a VM. Therefore data disks must be
detached from the destroyed VM and either be expunged (if that is what the user
requested) or be left detached and available for any volume actions - attach,
expunge, extract, etc.
A specific API parameter to _**try**_ to reattach previously attached data
volume has some merit, with a suitable error if the volume(s) aren't available.
Although it's only combining two operations:
'Recover VM' then 'attach data volume(s)'
But the premise that data volumes should automatically be reattached is
contrary to a core CloudStack principle that data volumes are first-class
citizens,
Anything that moves CloudStack further away from that principle is wrong.
If there are already instances where data disks are automatically attached,
then they are the bugs.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
