On Wed, May 29, 2013 at 09:59:40PM +0000, Prachi Damle wrote: > Hi Prasanna, > deleteAffinityGroup API should not take the VM Id parameter - I have > updated the FS. This API is supposed to disassociate all VMs from > the group and delete the affinity group entity in the DB. >
Thanks Prachi, I saw your checkin for this. But wouldn't this mean disocciation is complete only when those VMs get rebooted? The VMs remain attached to the affinity-group they were deployed in. Am I correct? Similarly for update(VM)AffinityGroup, only a reboot will truly change the affinity on the VMs? > So for this API, the entity operated on is the affinity group - not > the VM. > > Thanks, > Prachi > > -----Original Message----- > From: Prasanna Santhanam [mailto:t...@apache.org] > Sent: Tuesday, May 28, 2013 6:55 AM > To: CloudStack Dev; Prachi Damle > Subject: Re: Renaming updateVMAffinityGroup -> updateAffinityGroup > > On Wed, May 01, 2013 at 09:28:20AM +0530, Prasanna Santhanam wrote: > > On Tue, Apr 30, 2013 at 10:31:46AM -0700, Prachi Damle wrote: > > > Hi Prasanna, > > > > > > The API is to update a VirtualMachine's affinity group associations > > > - it's not really an update operation on an affinity group - hence > > > the odd naming. The resource the API is acting on is a VM. > > > > > Please suggest any other name that seems meaningful and fits the > > > conventions... > > > > Yes I imagined it would be something to do with the VM. But > > deleteAffinityGroup&vmid=<uuid> then got me wondering. If it is > > 'updateVmAffinity' then it should be 'deleteVmAffinity' as well? Or > > does the delete also remove the affinity group after dissociating the > > group from the VM? I think not - because the affinity group could be > > associated with multiple VMs? > > :wq > > > Bump Prachi - looking for your thoughts on this one. > > -- > Prasanna., > > ------------------------ > Powered by BigRock.com -- Prasanna., ------------------------ Powered by BigRock.com
