cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Prachi Damle <Prachi.Da...@citrix.com>
Subject RE: [DISCUSS] Affinity / Anti-affinity Rules
Date Tue, 02 Apr 2013 18:26:50 GMT
Hi Sangeetha,

Answered inline,

Prachi

-----Original Message-----
From: Sangeetha Hariharan [mailto:Sangeetha.Hariharan@citrix.com] 
Sent: Tuesday, April 02, 2013 11:08 AM
To: dev@cloudstack.apache.org; cloudstack-dev@incubator.apache.org
Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules

Prachi , Thanks for your response.
Had 1 follow up question :

5.DeleteAffinityGroup API:
Can this API  be used to delete an Affinity Group / Can it be used to only to remove an existing
VM from an affinity group? 
Why is there a need to pass AccountName and DomainId for this API call ? Is Affinity Group
Id not enough to uniquely identify this entity ?

[Prachi] It is for deleting groups of an account. The API also takes in the user-friendly
group name too, in which case the account info is needed.
To delete VM's association to the group, updateVMAffinityGroup API will serve the purpose.

[Sangeetha] - How can I use updateVMAffinityGroup API() to remove the vm from an affinityGroup?

By calling this API with a affinityGroup and VM , I thought we will associate this VM to the
affinity group ? Is that correct?

[Prachi] It is update the set of affinity groups of a VM. So this call will wipe out the existing
group associations of the VM and create the new associations.
If you do not include some existing affinity group in this API call, it will get removed.

-Thanks
Sangeetha

-----Original Message-----
From: Prachi Damle [mailto:Prachi.Damle@citrix.com] 
Sent: Monday, April 01, 2013 7:51 PM
To: dev@cloudstack.apache.org; cloudstack-dev@incubator.apache.org
Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules

Comments inline. 

Thanks,
Prachi

-----Original Message-----
From: Sangeetha Hariharan [mailto:Sangeetha.Hariharan@citrix.com] 
Sent: Monday, April 01, 2013 5:45 PM
To: cloudstack-dev@incubator.apache.org
Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules

Had the following questions after going over the spec - https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+Affinity-Anti-affinity+groups
:

1.In the API changes section - For all the API calls listed can we include if the parameters
are optional/Required?

2.Can new DB changes introduced by this feature be included  ?

[Prachi] Will update FS with this info.

3.CreateAffinityGroup API: 
Using this API can admin/domain admin user be able to create an affinity group for other accounts
to use ? Or can it be created only for its own consumption?

[Prachi] No, affinity groups can be created and used by individual account only. Affinity
groups are a way for the user to specify her/his deployment preference, so the visibility/usage
is limited to the account only.

4.ListAffinityGroups API:
Will admin/domain admin user be able to list the affinity groups of the other regular users
?

[Prachi] No, same as above.

5.DeleteAffinityGroup API:
Can this API  be used to delete an Affinity Group / Can it be used to only to remove an existing
VM from an affinity group? 
Why is there a need to pass AccountName and DomainId for this API call ? Is Affinity Group
Id not enough to uniquely identify this entity ?

[Prachi] It is for deleting groups of an account. The API also takes in the user-friendly
group name too, in which case the account info is needed.
To delete VM's association to the group, updateVMAffinityGroup API will serve the purpose.

6. Will Affinity rules apply when we stop and start the Vms? Will it be applied when CloudStack
performs HA ? 

[Prachi] Yes. 

7.When User tries to migrate/live migrate the VM , will the action to migrate a VM to a host
that does not satisfy the affinity rule fail ?

[Prachi] When root Admin lists hosts available for live migration, CS will indicate the hosts
that do not fit the affinity rules as 'Not Suitable'. If admin still goes ahead and migrates
to such a host, migration will proceed.

8.DeployVirtualMachine API:  It is mentioned in the FS that  affinitygroupids OR affinitygroupnames
need to be passed. If both are passed will the API fail ?

[Prachi] yes

9.Is there any difference in implementation for this feature between a Basic Zone and Advanced
zone ?  

[Prachi] Nope

10. In cases where there is a mismatch between service offering (host tag and storage tag)
and anti-affinity group that the Vm is being deployed with , will the error message provided
to the user be informative enough to know why the deployment failure happened (due to service
offerings vs anti-affinity group) to take corrective actions?

[Prachi] No, it will still throw out the generic InsufficentCapacity error - and this is correct,
since the underlying error is still not enough compute or storage capacity in the datacenter
to _match_ your needs.
The logs will however show that the affinity rules + tags are being applied - causing no match
found.

11. When a VM is in "Stopped" state , will it continue to be  part of the affinity group ?
 Or will its association with the affinity group be released immediately, so that new Vms
deployed as part of this anti-affinity group can use the host on which the Vm was running
before it was stopped.  

[Prachi] Good point. The association with affinity group is maintained. We never remove it
unless user removes. But yes, it makes sense to avoid deploying new VMs in the same group,
on that host. So host-anti-affinity should also consider last_host_id of the VM's that are
in stopped state.

Thanks
Sangeetha

-----Original Message-----
From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com] 
Sent: Friday, March 01, 2013 2:12 PM
To: cloudstack-dev@incubator.apache.org
Cc: Manan Shah; Alex Huang
Subject: Re: [DISCUSS] Affinity / Anti-affinity Rules



On 3/1/13 7:14 AM, "Chip Childers" <chip.childers@sungard.com> wrote:

>On Thu, Feb 28, 2013 at 03:18:51PM -0800, Prachi Damle wrote:
>> So far per the scope of the feature, Affinity groups is an entity 
>>created by an individual account and can be used, listed only by that 
>>account.
>> 
>> Wanted to know if we see any use case where one would need to create 
>>domain-level affinity groups that  all accounts in that domain can 
>>access? I can see that this may not be useful, since users would want 
>>to have VM placement preferences exclusive to their accounts and not 
>>shared with other accounts.
>> 
>> Any thoughts?
>
>I spent time thinking about this, and I'm not sure I see a use-case for 
>it.  Others might though...
Me neither


Mime
View raw message