Prasanna, Actually the PRD or the FS lists some other placement planning usecases this can facilitate: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Affinity+-+Anti-affinity+rules
-Prachi -----Original Message----- From: Prachi Damle [mailto:prachi.da...@citrix.com] Sent: Tuesday, April 09, 2013 10:40 AM To: dev@cloudstack.apache.org Subject: RE: [ACS42][QA]Test Plan for "Affinity / Anti-affinity Rules" Comments Inline. Thanks, Prachi -----Original Message----- From: prasanna [mailto:srivatsav.prasa...@gmail.com] On Behalf Of Prasanna Santhanam Sent: Monday, April 08, 2013 11:17 PM To: dev@cloudstack.apache.org 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? [1] http://s.apache.org/FQU [2] http://s.apache.org/CSs >> 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. -- Prasanna.,
