You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Prasanna Santhanam <ts...@apache.org> on 2013/05/01 05:58:20 UTC
Re: Renaming updateVMAffinityGroup -> updateAffinityGroup
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
--
Prasanna.,
------------------------
Powered by BigRock.com
Re: Renaming updateVMAffinityGroup -> updateAffinityGroup
Posted by Prasanna Santhanam <ts...@apache.org>.
On Thu, May 30, 2013 at 05:46:11AM +0000, Prachi Damle wrote:
> Yes, disassociation means on future restarts the VM will not follow
> the affinity group rule.
So the API has implicitly affected the VM I guess then. Should be
fine.
Thanks for entertaining the discussion on this,
--
Prasanna.,
------------------------
Powered by BigRock.com
RE: Renaming updateVMAffinityGroup -> updateAffinityGroup
Posted by Prachi Damle <Pr...@citrix.com>.
Yes, disassociation means on future restarts the VM will not follow the affinity group rule.
-----Original Message-----
From: Prasanna Santhanam [mailto:tsp@apache.org]
Sent: Wednesday, May 29, 2013 9:45 PM
To: dev@cloudstack.apache.org
Subject: Re: Renaming updateVMAffinityGroup -> updateAffinityGroup
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:tsp@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
Re: Renaming updateVMAffinityGroup -> updateAffinityGroup
Posted by Prasanna Santhanam <ts...@apache.org>.
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:tsp@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
RE: Renaming updateVMAffinityGroup -> updateAffinityGroup
Posted by Prachi Damle <Pr...@citrix.com>.
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.
So for this API, the entity operated on is the affinity group - not the VM.
Thanks,
Prachi
-----Original Message-----
From: Prasanna Santhanam [mailto:tsp@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
Re: Renaming updateVMAffinityGroup -> updateAffinityGroup
Posted by Prasanna Santhanam <ts...@apache.org>.
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