weizhouapache commented on pull request #4493: URL: https://github.com/apache/cloudstack/pull/4493#issuecomment-748000166
> 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. it looks we need to reach an agreement what's the expected behavior at first. ---------------------------------------------------------------- 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]
