cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Prachi Damle <>
Subject RE: [ACS42][QA]Test Plan for "Affinity / Anti-affinity Rules"
Date Tue, 09 Apr 2013 18:40:48 GMT

Actually the PRD or the FS lists some other placement planning usecases this can facilitate:


-----Original Message-----
From: Prachi Damle [] 
Sent: Tuesday, April 09, 2013 10:40 AM
Subject: RE: [ACS42][QA]Test Plan for "Affinity / Anti-affinity Rules"

Comments Inline.

-----Original Message-----
From: prasanna [] On Behalf Of Prasanna Santhanam
Sent: Monday, April 08, 2013 11:17 PM
Subject: Re: [ACS42][QA]Test Plan for "Affinity / Anti-affinity Rules"

On Mon, Apr 08, 2013 at 01:56:55PM -0700, Prachi Damle wrote:
> Prasanna,
> Affinity Group Processing is a pre-planning step. It will set the 
> scope for the deployment planners, there is no conflict between the 
> planner strategies and affinity groups. These are separate steps of 
> deployment planning.

My only confusion stems from the fact that we have two steps that do the same thing - pre-planning
by affinty/anti-affinity rules and the deployment planning that does the same using concentration/dispersion.
The only difference being the latter is in the control of the administrator. And if I enable
vm-host, vm-vm affinity rules on my vmware cluster [1], say, then that's another layer of
filtering to make placement decisions. Other providers [2] use affinity rules to place vms
in the same physical group (pod, cluster, storage) to help with costs, latency etc which cloudstack
can do using tags (more confusion for end users).

>> They are not doing the same thing. As mentioned in the FS, Affinity is a way to specify
user preference Vs deployment planners are admin decided heuristics to order the available
set of resources. Planners are not visible to the user. Also setting tags on backend and using
them in service offering is not in the hands of a user. There is no way for a user to let
us know any deployment preference. Affinity Groups is one way of facilitating that.
Affinity groups just narrows down the scope of searching the required resources. And under
the given scope(a zone or a pod or a cluster etc) a planner will try to order the rest of
the resources based on the heuristics admin wants. Thus Affinity is just modifying the input
of the planners and not conflicting with any  planner algorithm.

OTOH, I think that the pluginizing of the deployment planner steps in this feature is useful.
But beyond the placement decisions on host, storage what other kind of placement planning
can exploit this plugin?

>> Again its letting user provide a preference Vs admin deciding- Host anti-affinity
plugin in this feature is letting user set a relation between VMs - it is not choosing any
particular host or pool, just lets CS know that keep this set of VMs on different hosts. 


View raw message