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? -Prachi -----Original Message----- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Friday, February 22, 2013 2:00 PM To: cloudstack-dev@incubator.apache.org Cc: Manan Shah; Alex Huang Subject: Re: [DISCUSS] Affinity / Anti-affinity Rules On Fri, Feb 22, 2013 at 01:36:20PM -0800, Prachi Damle wrote: > Hey all, > > It seems that host affinity usecase has little value in reality and very less > guarantee of success given the current deployment planning mechanism. > > The feature requirement says host affinity = same host. So VM's in the host > affinity group, should get placed on the same host. But this is not required > in most of the real applications. > Also with Cloudstack's deployment mechanism, the affinity rules will not kick > in for the first VM. So it may get placed on a host which has not much > capacity left since at that point planners have no idea of the user's > intention. Thus if a user has a set of VMS and chooses host-affinity group, > it is possible that deployment of other VMS in the group start failing. > > So I am planning to not add the implementation for host affinity. Host > anti-affinity support however is important and needed. > > The feature will still include: > - framework for supporting affinity groups in general > - Default implementation for host anti-affinity > - DeploymentPlanningManager changes > > Any thoughts/comments? I will update the FS if this sounds correct. +1 from me. I think your analysis is spot-on. Anti-affinity is valuable, but affinity is questionable due to it's implications.
