Koushik, I'm not very familiar with fullsync/deltaSync. I saw you removed following line:
'if (VirtualMachineName.isValidVmName(left.name)) continue; // if the vm follows cloudstack naming ignore it for stopping' What if someone migrates a VM, and restart management server immediately, then the VM is in migrating state in DB when mgmt-server is back, but fullSync does not take care of VMs in Migrating state. Removing above line leads the VM in migrating state get stopped, I'm not sure this is the desired behavior of fullSync, should this be handled in deltaSync or compareState? Regards Mice -----Original Message----- From: Koushik Das [mailto:koushik....@citrix.com] Sent: Tuesday, August 14, 2012 2:27 AM To: cloudstack-dev@incubator.apache.org Subject: RE: Review Request: Fix CS-15603 Matthew, You have a valid point and the regular delete operation does exactly what you have mentioned, in case the HV is not reachable it fails with error. But in case of a forced delete, CS cleans up the db state even though it is unable to perform the actual delete. In this scenario when the HV connectivity resumes then CS syncs up its state with that of the HV. It may be argued if the option of forced delete be there or not. This feature has been there in CS for quite some time and I assume that there are users who find it useful. As far as CS is concerned it provides both options, it is up to the users what they want to choose. -Koushik -----Original Message----- From: Matthew Patton [mailto:mpat...@inforelay.com] Sent: Monday, August 13, 2012 7:06 PM To: cloudstack-dev@incubator.apache.org Subject: RE: Review Request: Fix CS-15603 This it's yet another case of misleading the user and lying about system state. The deletion flat out failed. CS should say so. if anything create a job in the queue and retry the operation a number of times if you want. But the state is "pending deletion" until it actually executes.
