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. @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+-+Anti- > >aff > >i > >nity+rules > > > > > >Regards, > >Manan Shah > > > > >
