Hey all, Following up on this feature discussion. I have put up an initial draft of the FS for this feature here: https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+Affinity-Anti-affinity+groups
As per discussions below, the scope of the feature now consists of a generic framework for defining affinity groups in CloudStack and a default implementation to support host affinity and anti-affinity. Please provide your comments. Thanks, Prachi -----Original Message----- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Monday, January 07, 2013 6:30 AM To: cloudstack-dev@incubator.apache.org Subject: Re: [DISCUSS] Affinity / Anti-affinity Rules On Mon, Jan 7, 2013 at 1:22 AM, Chris Sears <chris.x.se...@sungard.com> wrote: > Greetings, > > I understand the motivation for a feature like this, but I'm concerned > that the concepts of affinity and anti-affinity might not be > appropriate cloud-level abstractions to expose to end users. Also, it > might be difficult to effectively automate decisions about fault and > performance domains, both of which would vary greatly between deployments. > > Using anti-affinity rules to make sure HA-related VMs aren't placed on > the same host seems like the most critical use case. What if we > narrowed the scope of the feature to just address that issue? Building > on Chiradeep's idea, VMs could have an anti-affinity group attribute. > VMs in the same anti-affinity group must be placed on different hosts. > For the first implementation, the guarantee would only apply to initial > provisioning. It could actually apply any time a planner is used to select a host (which I think also includes CloudStack "HA"). > @Manan, would that be sufficient? > > Regards > > - Chris > > > On Fri, Jan 4, 2013 at 6:50 PM, Prachi Damle <prachi.da...@citrix.com>wrote: > >> Yes, requirements seem vague. What parameters define >> affinity/anti-affinity? >> >> Requirements mention >> >> For each VM, users should be able to provide both (Affinity VMs >> >> and >> Anti-affinity VMs) lists concurrently. For example, VM-A can have >> affinity with VMs B & C and anti-affinity with VMs D & E at the same time. >> >> When configuring Affinity / anti-affinity for a VM, users should >> >> be >> allowed to provide a list of affinity / anti-affinity VMs (via API) >> or select affinity /anti-affinity VMs from a list (via UI) >> >> When user specifies VM-A can have affinity with VMs B & C does that >> mean they should be placed on same pod or same hypervisor(cluster or >> host) by the allocation logic? >> >> -Prachi >> -----Original Message----- >> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] >> Sent: Thursday, January 03, 2013 6:06 PM >> To: CloudStack DeveloperList >> Subject: Re: [DISCUSS] Affinity / Anti-affinity Rules >> >> Actually the proposal is quite vague. >> What does affinity mean to the end-user? >> What guarantees are being asked for? >> - the vms are on the same hypervisor (affinity) >> - the vms are not on the same hypervisor (anti) >> - the vms are interconnected by a high-speed interconnect (affinity) >> - the vms are in different failure domains (host/cluster/pod) >> >> I find the concept of affinity groups useful. >> A possible workflow would be >> 1. Create an affinity group of type 'Foo' >> 1a. Group type indicates the guarantee 2. Create a VM in the group >> >> VMs can only leave groups on vm destruction. >> >> But without the specific type of guarantee, it is hard to discuss >> this proposal. >> >> On 1/3/13 4:23 PM, "Manan Shah" <manan.s...@citrix.com> wrote: >> >> >Hi, >> > >> >I would like to propose a new feature for enabling Affinity / >> >Anti-affinity rules in CS 4.1. I have created a JIRA ticket and >> >provided the requirements at the following location. Please provide >> >feedback on the requirements. >> > >> >JIRA Ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-739 >> >Requirements: >> >https://cwiki.apache.org/confluence/display/CLOUDSTACK/Affinity+-+An >> >ti- >> >aff >> >i >> >nity+rules >> > >> > >> >Regards, >> >Manan Shah >> > >> >> >>
