Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of Prachi.Damle@citrix.com
 designates 66.165.176.63 as permitted sender)
From: Prachi Damle <Prachi.Damle@citrix.com>
To: "cloudstack-dev@incubator.apache.org"
	<cloudstack-dev@incubator.apache.org>
Date: Tue, 5 Feb 2013 14:42:26 -0800
Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
Thread-Topic: [DISCUSS] Affinity / Anti-affinity Rules
Thread-Index: Ac3s44s539bwrEr0Te65OEEIKXqUiAXDipEA
Message-ID: 
 <7A92FF96DF135843B4B608FB576BFC3E012DA4102EE1@SJCPMAILBOX01.citrite.net>
References: <CD0B60EF.1676E%manan.shah@citrix.com>
	<CD0B77D0.3EEF2%chiradeep.vittal@citrix.com>
	<7A92FF96DF135843B4B608FB576BFC3E012DA300DF9C@SJCPMAILBOX01.citrite.net>
	<CAFtUSEzBja4UAnyHgWqCU8T1+HSaTJ-F2op4XmoRTcXhq-S=Mg@mail.gmail.com>
 <CA+96GG4VypZwu6vyVmg1RkgOb0GMiNu_8SOnT8JFrJhQF1jCow@mail.gmail.com>
In-Reply-To: 
 <CA+96GG4VypZwu6vyVmg1RkgOb0GMiNu_8SOnT8JFrJhQF1jCow@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

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-a=
ffinity+groups

As per discussions below, the scope of the feature now consists of a generi=
c framework for defining affinity groups in CloudStack and a default implem=
entation to support host affinity and anti-affinity.

Please provide your comments.

Thanks,
Prachi

-----Original Message-----
From: Chip Childers [mailto:chip.childers@sungard.com]=20
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.sears@sungard.com> wro=
te:
> Greetings,
>
> I understand the motivation for a feature like this, but I'm concerned=20
> that the concepts of affinity and anti-affinity might not be=20
> appropriate cloud-level abstractions to expose to end users. Also, it=20
> might be difficult to effectively automate decisions about fault and=20
> performance domains, both of which would vary greatly between deployments=
.
>
> Using anti-affinity rules to make sure HA-related VMs aren't placed on=20
> the same host seems like the most critical use case. What if we=20
> narrowed the scope of the feature to just address that issue? Building=20
> on Chiradeep's idea, VMs could have an anti-affinity group attribute.=20
> VMs in the same anti-affinity group must be placed on different hosts.=20
> For the first implementation, the guarantee would only apply to initial p=
rovisioning.

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.Damle@citrix.com>wro=
te:
>
>> Yes, requirements seem vague. What parameters define=20
>> affinity/anti-affinity?
>>
>> Requirements mention
>> >>  For each VM, users should be able to provide both (Affinity VMs=20
>> >> and
>> Anti-affinity VMs) lists concurrently. For example, VM-A can have=20
>> affinity with VMs B & C and anti-affinity with VMs D & E at the same tim=
e.
>> >> When configuring Affinity / anti-affinity for a VM, users should=20
>> >> be
>> allowed to provide a list of affinity / anti-affinity VMs (via API)=20
>> 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=20
>> mean they should be placed on same pod or same hypervisor(cluster or=20
>> host) by the allocation logic?
>>
>> -Prachi
>> -----Original Message-----
>> From: Chiradeep Vittal [mailto:Chiradeep.Vittal@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=20
>> this proposal.
>>
>> On 1/3/13 4:23 PM, "Manan Shah" <manan.shah@citrix.com> wrote:
>>
>> >Hi,
>> >
>> >I would like to propose a new feature for enabling Affinity /=20
>> >Anti-affinity rules in CS 4.1. I have created a JIRA ticket and=20
>> >provided the requirements at the following location.  Please provide=20
>> >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
>> >
>>
>>
>>