You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Prachi Damle <Pr...@citrix.com> on 2013/02/05 23:42:26 UTC
RE: [DISCUSS] Affinity / Anti-affinity Rules
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.childers@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 <ch...@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 <Pr...@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.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
>> this proposal.
>>
>> On 1/3/13 4:23 PM, "Manan Shah" <ma...@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
>> >
>>
>>
>>
RE: [DISCUSS] Affinity / Anti-affinity Rules
Posted by Alex Huang <Al...@citrix.com>.
Yup. Like Chip says. This can only be for placement or operations through CloudStack.
--Alex
> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: Wednesday, February 06, 2013 7:07 AM
> To: Murali Reddy
> Cc: Prachi Damle; cloudstack-dev@incubator.apache.org
> Subject: Re: [DISCUSS] Affinity / Anti-affinity Rules
>
> On Wed, Feb 06, 2013 at 06:59:10PM +0530, Murali Reddy wrote:
> > On 06/02/13 4:12 AM, "Prachi Damle" <Pr...@citrix.com> wrote:
> >
> > >
> > >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.
> >
> > Prachi,
> >
> > When the granularity of affinity/anti-affinity rule is at host level, will
> > the rules work in case of externally managed clusters (or integration with
> > native capabilites), like in case of vmware where it has its own
> > scheduling and HA behaviour?
> >
> > Thanks!
> >
> >
>
> The only way that would work, would be to build support for affinity /
> anti-affinity into the HV plugins themselves, and only use that when HA
> is delegated to the HV software. DRS is another concern.
>
> Sounds quite complex. Perhaps the only option for a reasonable
> implementation timeframe is to only support scenarios where the HV does
> not do HA or DRS.
Re: [DISCUSS] Affinity / Anti-affinity Rules
Posted by Chip Childers <ch...@sungard.com>.
On Wed, Feb 06, 2013 at 06:59:10PM +0530, Murali Reddy wrote:
> On 06/02/13 4:12 AM, "Prachi Damle" <Pr...@citrix.com> wrote:
>
> >
> >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.
>
> Prachi,
>
> When the granularity of affinity/anti-affinity rule is at host level, will
> the rules work in case of externally managed clusters (or integration with
> native capabilites), like in case of vmware where it has its own
> scheduling and HA behaviour?
>
> Thanks!
>
>
The only way that would work, would be to build support for affinity /
anti-affinity into the HV plugins themselves, and only use that when HA
is delegated to the HV software. DRS is another concern.
Sounds quite complex. Perhaps the only option for a reasonable
implementation timeframe is to only support scenarios where the HV does
not do HA or DRS.
RE: [DISCUSS] Affinity / Anti-affinity Rules
Posted by Prachi Damle <Pr...@citrix.com>.
Alex,
Thanks for the detailed review. I will couple the affinity design with the deployment planner refactoring I had next in line then. Will update the FS with these details.
-Prachi
-----Original Message-----
From: Alex Huang
Sent: Wednesday, February 06, 2013 12:00 PM
To: Prachi Damle; cloudstack-dev@incubator.apache.org
Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
Prachi,
If it's an elective option, then it shouldn't have options in the deployvm api. We can't decouple the code but then say it's coupled at deployvm api call.
I think it makes sense to have the affinity be part of orchestration. If so, then it makes sense to do this.
- Write DeploymentPlanningManager which contains planning for volume, vm, and network.
- For VM deployment, DPM goes through the following stages
- Affinity - to set deploymentplan scope and exclude list (we might think about merging the two).
- DeploymentPlanner - to use heuristics to find the best spot to place the vm/volume.
- Allocator - which matches the requirements to capabilities of the physical resource.
If you think about it, then it makes sense because each matches to the functionality it serves.
- Affinity - matches user preference to narrow down where to deploy.
- DeploymentPlanner - matches algorithms set by Administrator to give best performance/value/feature
- Allocator - matches physical requirements.
This would mean taking Allocator out of DeploymentPlanner implementations. It is very similar to your intent with an AffinityDeploymentPlanner.
I think actually this works out very well with the idea of reservations as well. You might think about doing the two together as a refactor of Deployment Planning.
--Alex
> -----Original Message-----
> From: Prachi Damle
> Sent: Tuesday, February 05, 2013 11:39 PM
> To: Alex Huang; cloudstack-dev@incubator.apache.org
> Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
>
> Hi Alex,
>
> Thanks for the review, I have answered inline. Please comment.
> I guess the FS needs more description reasoning the 2-component design
> to avoid confusion.
>
> -Prachi
>
> -----Original Message-----
> From: Alex Huang
> Sent: Tuesday, February 05, 2013 4:49 PM
> To: Prachi Damle; cloudstack-dev@incubator.apache.org
> Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
>
> Hi Prachi,
>
> A few comments about this spec.
>
> - What is the error when planning fails? What details will it give?
>
>
> [Prachi] I was planning to still rely on the deployment planner to
> throw exception since planner will be the component that will find out
> that placement is not possible.
> But it is a good point and I will add a custom exception that the
> AffinityProcessor can throw if upon analysis it finds the affinity
> rule cannot be followed. This will save the planner execution.
>
>
> - Why are HostAffinityProcessor and HostAntiAffinityProcessor
> different implementations? The requirements says they should be
> specified concurrently so shouldn't they be the same processor? Or
> are you planning for this adapter to be an adapter chain?
>
>
> [Prachi] Yes I am planning this to be a chain of adapters, each can
> handle a specific affinity type.
>
> - I'm not really sure I understand the design. It would seem like
> this can be designed in two ways.
> 1. Affinity Group is an integrated part of cloud-engine and
> AffinityGroupProcessor is ran before all DeploymentPlanners to set the
> scope of DeploymentPlan and ExcludeList. If this is the case, I don't
> understand why there is a AffinityGroupPlanner.
> 2. The entire thing is implemented as a DeploymentPlanner. If it is
> implemented as a DeploymentPlanner, then why do we need the
> AffinityGroupProcessor interface? Why not just have it as a property
> of that DeploymentPlanner implementation?
> After giving it some thought, I think it is important that affinity
> group is part of core orchestration. If so then I would prefer 1.
> The current spec has both so I'm confused on this.
> - The getType() of the AffinityGroupProcessor seems like it's more
> similar to the getName of the adapter already, which needs to be
> unique. I think you just need more descriptions on what the processor
> does so the end user can understand how to use it?
>
> [Prachi] Since use of the affinity groups will be done during VM
> placement, I wanted to stick to add all logic to DeploymentPlanner.
> This will make sure that anytime the planner gets called (deployment,
> restart, migration, HA) affinity groups are take care of. Still I see
> the need of being able to plugin custom implementations for various
> types of affinity/anti-affinity. So pushed out the handling of the affinityType to a separate adapter.
>
> Thus AffinityPlanner could be as simple as just running through the
> chain of AffinityGroupProcessor's and it will not change even if we
> introduce any new affinity types. It will be the hook in Cloudstack,
> for the plugins implementing affinity types
>
> As you say we could keep this part of cloud-engine and run through the
> chain of AffinityGroupProcessor before planners - but it will not take
> care of other usecases that directly call planners for placement.
>
> - Can you check with Min on her creation of the REST API? Can we
> start using the REST only API from here on?
> [Prachi ]Sure will sync up with Min on REST API.
>
> --Alex
>
> > -----Original Message-----
> > From: Prachi Damle [mailto:Prachi.Damle@citrix.com]
> > Sent: Tuesday, February 05, 2013 2:42 PM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
> >
> > 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.childers@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
> > <ch...@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
> > <Pr...@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.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
> > >> this proposal.
> > >>
> > >> On 1/3/13 4:23 PM, "Manan Shah" <ma...@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
> > >> >
> > >>
> > >>
> > >>
RE: [DISCUSS] Affinity / Anti-affinity Rules
Posted by Prachi Damle <Pr...@citrix.com>.
Yes, the list APIs should return the affinity group information. I will update the FS with the response details.
Thanks,
Prachi
-----Original Message-----
From: Sangeetha Hariharan [mailto:Sangeetha.Hariharan@citrix.com]
Sent: Wednesday, April 03, 2013 1:46 PM
To: dev@cloudstack.apache.org; cloudstack-dev@incubator.apache.org
Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
Thanks Prachi.
I had couple of more questions:
ListAffinityGroups API() - When affinity group is returned would it return all the Vms associated with it in the affinity group as well ?
Also listVm call should also include the list of affinity group it is associated with.
-Thanks
Sangeetha
-----Original Message-----
From: Prachi Damle [mailto:Prachi.Damle@citrix.com]
Sent: Tuesday, April 02, 2013 11:27 AM
To: dev@cloudstack.apache.org; cloudstack-dev@incubator.apache.org
Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
Hi Sangeetha,
Answered inline,
Prachi
-----Original Message-----
From: Sangeetha Hariharan [mailto:Sangeetha.Hariharan@citrix.com]
Sent: Tuesday, April 02, 2013 11:08 AM
To: dev@cloudstack.apache.org; cloudstack-dev@incubator.apache.org
Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
Prachi , Thanks for your response.
Had 1 follow up question :
5.DeleteAffinityGroup API:
Can this API be used to delete an Affinity Group / Can it be used to only to remove an existing VM from an affinity group?
Why is there a need to pass AccountName and DomainId for this API call ? Is Affinity Group Id not enough to uniquely identify this entity ?
[Prachi] It is for deleting groups of an account. The API also takes in the user-friendly group name too, in which case the account info is needed.
To delete VM's association to the group, updateVMAffinityGroup API will serve the purpose.
[Sangeetha] - How can I use updateVMAffinityGroup API() to remove the vm from an affinityGroup?
By calling this API with a affinityGroup and VM , I thought we will associate this VM to the affinity group ? Is that correct?
[Prachi] It is update the set of affinity groups of a VM. So this call will wipe out the existing group associations of the VM and create the new associations.
If you do not include some existing affinity group in this API call, it will get removed.
-Thanks
Sangeetha
-----Original Message-----
From: Prachi Damle [mailto:Prachi.Damle@citrix.com]
Sent: Monday, April 01, 2013 7:51 PM
To: dev@cloudstack.apache.org; cloudstack-dev@incubator.apache.org
Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
Comments inline.
Thanks,
Prachi
-----Original Message-----
From: Sangeetha Hariharan [mailto:Sangeetha.Hariharan@citrix.com]
Sent: Monday, April 01, 2013 5:45 PM
To: cloudstack-dev@incubator.apache.org
Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
Had the following questions after going over the spec - https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+Affinity-Anti-affinity+groups :
1.In the API changes section - For all the API calls listed can we include if the parameters are optional/Required?
2.Can new DB changes introduced by this feature be included ?
[Prachi] Will update FS with this info.
3.CreateAffinityGroup API:
Using this API can admin/domain admin user be able to create an affinity group for other accounts to use ? Or can it be created only for its own consumption?
[Prachi] No, affinity groups can be created and used by individual account only. Affinity groups are a way for the user to specify her/his deployment preference, so the visibility/usage is limited to the account only.
4.ListAffinityGroups API:
Will admin/domain admin user be able to list the affinity groups of the other regular users ?
[Prachi] No, same as above.
5.DeleteAffinityGroup API:
Can this API be used to delete an Affinity Group / Can it be used to only to remove an existing VM from an affinity group?
Why is there a need to pass AccountName and DomainId for this API call ? Is Affinity Group Id not enough to uniquely identify this entity ?
[Prachi] It is for deleting groups of an account. The API also takes in the user-friendly group name too, in which case the account info is needed.
To delete VM's association to the group, updateVMAffinityGroup API will serve the purpose.
6. Will Affinity rules apply when we stop and start the Vms? Will it be applied when CloudStack performs HA ?
[Prachi] Yes.
7.When User tries to migrate/live migrate the VM , will the action to migrate a VM to a host that does not satisfy the affinity rule fail ?
[Prachi] When root Admin lists hosts available for live migration, CS will indicate the hosts that do not fit the affinity rules as 'Not Suitable'. If admin still goes ahead and migrates to such a host, migration will proceed.
8.DeployVirtualMachine API: It is mentioned in the FS that affinitygroupids OR affinitygroupnames need to be passed. If both are passed will the API fail ?
[Prachi] yes
9.Is there any difference in implementation for this feature between a Basic Zone and Advanced zone ?
[Prachi] Nope
10. In cases where there is a mismatch between service offering (host tag and storage tag) and anti-affinity group that the Vm is being deployed with , will the error message provided to the user be informative enough to know why the deployment failure happened (due to service offerings vs anti-affinity group) to take corrective actions?
[Prachi] No, it will still throw out the generic InsufficentCapacity error - and this is correct, since the underlying error is still not enough compute or storage capacity in the datacenter to _match_ your needs.
The logs will however show that the affinity rules + tags are being applied - causing no match found.
11. When a VM is in "Stopped" state , will it continue to be part of the affinity group ? Or will its association with the affinity group be released immediately, so that new Vms deployed as part of this anti-affinity group can use the host on which the Vm was running before it was stopped.
[Prachi] Good point. The association with affinity group is maintained. We never remove it unless user removes. But yes, it makes sense to avoid deploying new VMs in the same group, on that host. So host-anti-affinity should also consider last_host_id of the VM's that are in stopped state.
Thanks
Sangeetha
-----Original Message-----
From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
Sent: Friday, March 01, 2013 2:12 PM
To: cloudstack-dev@incubator.apache.org
Cc: Manan Shah; Alex Huang
Subject: Re: [DISCUSS] Affinity / Anti-affinity Rules
On 3/1/13 7:14 AM, "Chip Childers" <ch...@sungard.com> wrote:
>On Thu, Feb 28, 2013 at 03:18:51PM -0800, Prachi Damle wrote:
>> 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?
>
>I spent time thinking about this, and I'm not sure I see a use-case for
>it. Others might though...
Me neither
RE: [DISCUSS] Affinity / Anti-affinity Rules
Posted by Sangeetha Hariharan <Sa...@citrix.com>.
Thanks Prachi.
I had couple of more questions:
ListAffinityGroups API() - When affinity group is returned would it return all the Vms associated with it in the affinity group as well ?
Also listVm call should also include the list of affinity group it is associated with.
-Thanks
Sangeetha
-----Original Message-----
From: Prachi Damle [mailto:Prachi.Damle@citrix.com]
Sent: Tuesday, April 02, 2013 11:27 AM
To: dev@cloudstack.apache.org; cloudstack-dev@incubator.apache.org
Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
Hi Sangeetha,
Answered inline,
Prachi
-----Original Message-----
From: Sangeetha Hariharan [mailto:Sangeetha.Hariharan@citrix.com]
Sent: Tuesday, April 02, 2013 11:08 AM
To: dev@cloudstack.apache.org; cloudstack-dev@incubator.apache.org
Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
Prachi , Thanks for your response.
Had 1 follow up question :
5.DeleteAffinityGroup API:
Can this API be used to delete an Affinity Group / Can it be used to only to remove an existing VM from an affinity group?
Why is there a need to pass AccountName and DomainId for this API call ? Is Affinity Group Id not enough to uniquely identify this entity ?
[Prachi] It is for deleting groups of an account. The API also takes in the user-friendly group name too, in which case the account info is needed.
To delete VM's association to the group, updateVMAffinityGroup API will serve the purpose.
[Sangeetha] - How can I use updateVMAffinityGroup API() to remove the vm from an affinityGroup?
By calling this API with a affinityGroup and VM , I thought we will associate this VM to the affinity group ? Is that correct?
[Prachi] It is update the set of affinity groups of a VM. So this call will wipe out the existing group associations of the VM and create the new associations.
If you do not include some existing affinity group in this API call, it will get removed.
-Thanks
Sangeetha
-----Original Message-----
From: Prachi Damle [mailto:Prachi.Damle@citrix.com]
Sent: Monday, April 01, 2013 7:51 PM
To: dev@cloudstack.apache.org; cloudstack-dev@incubator.apache.org
Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
Comments inline.
Thanks,
Prachi
-----Original Message-----
From: Sangeetha Hariharan [mailto:Sangeetha.Hariharan@citrix.com]
Sent: Monday, April 01, 2013 5:45 PM
To: cloudstack-dev@incubator.apache.org
Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
Had the following questions after going over the spec - https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+Affinity-Anti-affinity+groups :
1.In the API changes section - For all the API calls listed can we include if the parameters are optional/Required?
2.Can new DB changes introduced by this feature be included ?
[Prachi] Will update FS with this info.
3.CreateAffinityGroup API:
Using this API can admin/domain admin user be able to create an affinity group for other accounts to use ? Or can it be created only for its own consumption?
[Prachi] No, affinity groups can be created and used by individual account only. Affinity groups are a way for the user to specify her/his deployment preference, so the visibility/usage is limited to the account only.
4.ListAffinityGroups API:
Will admin/domain admin user be able to list the affinity groups of the other regular users ?
[Prachi] No, same as above.
5.DeleteAffinityGroup API:
Can this API be used to delete an Affinity Group / Can it be used to only to remove an existing VM from an affinity group?
Why is there a need to pass AccountName and DomainId for this API call ? Is Affinity Group Id not enough to uniquely identify this entity ?
[Prachi] It is for deleting groups of an account. The API also takes in the user-friendly group name too, in which case the account info is needed.
To delete VM's association to the group, updateVMAffinityGroup API will serve the purpose.
6. Will Affinity rules apply when we stop and start the Vms? Will it be applied when CloudStack performs HA ?
[Prachi] Yes.
7.When User tries to migrate/live migrate the VM , will the action to migrate a VM to a host that does not satisfy the affinity rule fail ?
[Prachi] When root Admin lists hosts available for live migration, CS will indicate the hosts that do not fit the affinity rules as 'Not Suitable'. If admin still goes ahead and migrates to such a host, migration will proceed.
8.DeployVirtualMachine API: It is mentioned in the FS that affinitygroupids OR affinitygroupnames need to be passed. If both are passed will the API fail ?
[Prachi] yes
9.Is there any difference in implementation for this feature between a Basic Zone and Advanced zone ?
[Prachi] Nope
10. In cases where there is a mismatch between service offering (host tag and storage tag) and anti-affinity group that the Vm is being deployed with , will the error message provided to the user be informative enough to know why the deployment failure happened (due to service offerings vs anti-affinity group) to take corrective actions?
[Prachi] No, it will still throw out the generic InsufficentCapacity error - and this is correct, since the underlying error is still not enough compute or storage capacity in the datacenter to _match_ your needs.
The logs will however show that the affinity rules + tags are being applied - causing no match found.
11. When a VM is in "Stopped" state , will it continue to be part of the affinity group ? Or will its association with the affinity group be released immediately, so that new Vms deployed as part of this anti-affinity group can use the host on which the Vm was running before it was stopped.
[Prachi] Good point. The association with affinity group is maintained. We never remove it unless user removes. But yes, it makes sense to avoid deploying new VMs in the same group, on that host. So host-anti-affinity should also consider last_host_id of the VM's that are in stopped state.
Thanks
Sangeetha
-----Original Message-----
From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
Sent: Friday, March 01, 2013 2:12 PM
To: cloudstack-dev@incubator.apache.org
Cc: Manan Shah; Alex Huang
Subject: Re: [DISCUSS] Affinity / Anti-affinity Rules
On 3/1/13 7:14 AM, "Chip Childers" <ch...@sungard.com> wrote:
>On Thu, Feb 28, 2013 at 03:18:51PM -0800, Prachi Damle wrote:
>> 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?
>
>I spent time thinking about this, and I'm not sure I see a use-case for
>it. Others might though...
Me neither
RE: [DISCUSS] Affinity / Anti-affinity Rules
Posted by Prachi Damle <Pr...@citrix.com>.
Hi Sangeetha,
Answered inline,
Prachi
-----Original Message-----
From: Sangeetha Hariharan [mailto:Sangeetha.Hariharan@citrix.com]
Sent: Tuesday, April 02, 2013 11:08 AM
To: dev@cloudstack.apache.org; cloudstack-dev@incubator.apache.org
Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
Prachi , Thanks for your response.
Had 1 follow up question :
5.DeleteAffinityGroup API:
Can this API be used to delete an Affinity Group / Can it be used to only to remove an existing VM from an affinity group?
Why is there a need to pass AccountName and DomainId for this API call ? Is Affinity Group Id not enough to uniquely identify this entity ?
[Prachi] It is for deleting groups of an account. The API also takes in the user-friendly group name too, in which case the account info is needed.
To delete VM's association to the group, updateVMAffinityGroup API will serve the purpose.
[Sangeetha] - How can I use updateVMAffinityGroup API() to remove the vm from an affinityGroup?
By calling this API with a affinityGroup and VM , I thought we will associate this VM to the affinity group ? Is that correct?
[Prachi] It is update the set of affinity groups of a VM. So this call will wipe out the existing group associations of the VM and create the new associations.
If you do not include some existing affinity group in this API call, it will get removed.
-Thanks
Sangeetha
-----Original Message-----
From: Prachi Damle [mailto:Prachi.Damle@citrix.com]
Sent: Monday, April 01, 2013 7:51 PM
To: dev@cloudstack.apache.org; cloudstack-dev@incubator.apache.org
Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
Comments inline.
Thanks,
Prachi
-----Original Message-----
From: Sangeetha Hariharan [mailto:Sangeetha.Hariharan@citrix.com]
Sent: Monday, April 01, 2013 5:45 PM
To: cloudstack-dev@incubator.apache.org
Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
Had the following questions after going over the spec - https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+Affinity-Anti-affinity+groups :
1.In the API changes section - For all the API calls listed can we include if the parameters are optional/Required?
2.Can new DB changes introduced by this feature be included ?
[Prachi] Will update FS with this info.
3.CreateAffinityGroup API:
Using this API can admin/domain admin user be able to create an affinity group for other accounts to use ? Or can it be created only for its own consumption?
[Prachi] No, affinity groups can be created and used by individual account only. Affinity groups are a way for the user to specify her/his deployment preference, so the visibility/usage is limited to the account only.
4.ListAffinityGroups API:
Will admin/domain admin user be able to list the affinity groups of the other regular users ?
[Prachi] No, same as above.
5.DeleteAffinityGroup API:
Can this API be used to delete an Affinity Group / Can it be used to only to remove an existing VM from an affinity group?
Why is there a need to pass AccountName and DomainId for this API call ? Is Affinity Group Id not enough to uniquely identify this entity ?
[Prachi] It is for deleting groups of an account. The API also takes in the user-friendly group name too, in which case the account info is needed.
To delete VM's association to the group, updateVMAffinityGroup API will serve the purpose.
6. Will Affinity rules apply when we stop and start the Vms? Will it be applied when CloudStack performs HA ?
[Prachi] Yes.
7.When User tries to migrate/live migrate the VM , will the action to migrate a VM to a host that does not satisfy the affinity rule fail ?
[Prachi] When root Admin lists hosts available for live migration, CS will indicate the hosts that do not fit the affinity rules as 'Not Suitable'. If admin still goes ahead and migrates to such a host, migration will proceed.
8.DeployVirtualMachine API: It is mentioned in the FS that affinitygroupids OR affinitygroupnames need to be passed. If both are passed will the API fail ?
[Prachi] yes
9.Is there any difference in implementation for this feature between a Basic Zone and Advanced zone ?
[Prachi] Nope
10. In cases where there is a mismatch between service offering (host tag and storage tag) and anti-affinity group that the Vm is being deployed with , will the error message provided to the user be informative enough to know why the deployment failure happened (due to service offerings vs anti-affinity group) to take corrective actions?
[Prachi] No, it will still throw out the generic InsufficentCapacity error - and this is correct, since the underlying error is still not enough compute or storage capacity in the datacenter to _match_ your needs.
The logs will however show that the affinity rules + tags are being applied - causing no match found.
11. When a VM is in "Stopped" state , will it continue to be part of the affinity group ? Or will its association with the affinity group be released immediately, so that new Vms deployed as part of this anti-affinity group can use the host on which the Vm was running before it was stopped.
[Prachi] Good point. The association with affinity group is maintained. We never remove it unless user removes. But yes, it makes sense to avoid deploying new VMs in the same group, on that host. So host-anti-affinity should also consider last_host_id of the VM's that are in stopped state.
Thanks
Sangeetha
-----Original Message-----
From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
Sent: Friday, March 01, 2013 2:12 PM
To: cloudstack-dev@incubator.apache.org
Cc: Manan Shah; Alex Huang
Subject: Re: [DISCUSS] Affinity / Anti-affinity Rules
On 3/1/13 7:14 AM, "Chip Childers" <ch...@sungard.com> wrote:
>On Thu, Feb 28, 2013 at 03:18:51PM -0800, Prachi Damle wrote:
>> 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?
>
>I spent time thinking about this, and I'm not sure I see a use-case for
>it. Others might though...
Me neither
RE: [DISCUSS] Affinity / Anti-affinity Rules
Posted by Sangeetha Hariharan <Sa...@citrix.com>.
Prachi , Thanks for your response.
Had 1 follow up question :
5.DeleteAffinityGroup API:
Can this API be used to delete an Affinity Group / Can it be used to only to remove an existing VM from an affinity group?
Why is there a need to pass AccountName and DomainId for this API call ? Is Affinity Group Id not enough to uniquely identify this entity ?
[Prachi] It is for deleting groups of an account. The API also takes in the user-friendly group name too, in which case the account info is needed.
To delete VM's association to the group, updateVMAffinityGroup API will serve the purpose.
[Sangeetha] - How can I use updateVMAffinityGroup API() to remove the vm from an affinityGroup?
By calling this API with a affinityGroup and VM , I thought we will associate this VM to the affinity group ? Is that correct?
-Thanks
Sangeetha
-----Original Message-----
From: Prachi Damle [mailto:Prachi.Damle@citrix.com]
Sent: Monday, April 01, 2013 7:51 PM
To: dev@cloudstack.apache.org; cloudstack-dev@incubator.apache.org
Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
Comments inline.
Thanks,
Prachi
-----Original Message-----
From: Sangeetha Hariharan [mailto:Sangeetha.Hariharan@citrix.com]
Sent: Monday, April 01, 2013 5:45 PM
To: cloudstack-dev@incubator.apache.org
Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
Had the following questions after going over the spec - https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+Affinity-Anti-affinity+groups :
1.In the API changes section - For all the API calls listed can we include if the parameters are optional/Required?
2.Can new DB changes introduced by this feature be included ?
[Prachi] Will update FS with this info.
3.CreateAffinityGroup API:
Using this API can admin/domain admin user be able to create an affinity group for other accounts to use ? Or can it be created only for its own consumption?
[Prachi] No, affinity groups can be created and used by individual account only. Affinity groups are a way for the user to specify her/his deployment preference, so the visibility/usage is limited to the account only.
4.ListAffinityGroups API:
Will admin/domain admin user be able to list the affinity groups of the other regular users ?
[Prachi] No, same as above.
5.DeleteAffinityGroup API:
Can this API be used to delete an Affinity Group / Can it be used to only to remove an existing VM from an affinity group?
Why is there a need to pass AccountName and DomainId for this API call ? Is Affinity Group Id not enough to uniquely identify this entity ?
[Prachi] It is for deleting groups of an account. The API also takes in the user-friendly group name too, in which case the account info is needed.
To delete VM's association to the group, updateVMAffinityGroup API will serve the purpose.
6. Will Affinity rules apply when we stop and start the Vms? Will it be applied when CloudStack performs HA ?
[Prachi] Yes.
7.When User tries to migrate/live migrate the VM , will the action to migrate a VM to a host that does not satisfy the affinity rule fail ?
[Prachi] When root Admin lists hosts available for live migration, CS will indicate the hosts that do not fit the affinity rules as 'Not Suitable'. If admin still goes ahead and migrates to such a host, migration will proceed.
8.DeployVirtualMachine API: It is mentioned in the FS that affinitygroupids OR affinitygroupnames need to be passed. If both are passed will the API fail ?
[Prachi] yes
9.Is there any difference in implementation for this feature between a Basic Zone and Advanced zone ?
[Prachi] Nope
10. In cases where there is a mismatch between service offering (host tag and storage tag) and anti-affinity group that the Vm is being deployed with , will the error message provided to the user be informative enough to know why the deployment failure happened (due to service offerings vs anti-affinity group) to take corrective actions?
[Prachi] No, it will still throw out the generic InsufficentCapacity error - and this is correct, since the underlying error is still not enough compute or storage capacity in the datacenter to _match_ your needs.
The logs will however show that the affinity rules + tags are being applied - causing no match found.
11. When a VM is in "Stopped" state , will it continue to be part of the affinity group ? Or will its association with the affinity group be released immediately, so that new Vms deployed as part of this anti-affinity group can use the host on which the Vm was running before it was stopped.
[Prachi] Good point. The association with affinity group is maintained. We never remove it unless user removes. But yes, it makes sense to avoid deploying new VMs in the same group, on that host. So host-anti-affinity should also consider last_host_id of the VM's that are in stopped state.
Thanks
Sangeetha
-----Original Message-----
From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
Sent: Friday, March 01, 2013 2:12 PM
To: cloudstack-dev@incubator.apache.org
Cc: Manan Shah; Alex Huang
Subject: Re: [DISCUSS] Affinity / Anti-affinity Rules
On 3/1/13 7:14 AM, "Chip Childers" <ch...@sungard.com> wrote:
>On Thu, Feb 28, 2013 at 03:18:51PM -0800, Prachi Damle wrote:
>> 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?
>
>I spent time thinking about this, and I'm not sure I see a use-case for
>it. Others might though...
Me neither
RE: [DISCUSS] Affinity / Anti-affinity Rules
Posted by Prachi Damle <Pr...@citrix.com>.
Comments inline.
Thanks,
Prachi
-----Original Message-----
From: Sangeetha Hariharan [mailto:Sangeetha.Hariharan@citrix.com]
Sent: Monday, April 01, 2013 5:45 PM
To: cloudstack-dev@incubator.apache.org
Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
Had the following questions after going over the spec - https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+Affinity-Anti-affinity+groups :
1.In the API changes section - For all the API calls listed can we include if the parameters are optional/Required?
2.Can new DB changes introduced by this feature be included ?
[Prachi] Will update FS with this info.
3.CreateAffinityGroup API:
Using this API can admin/domain admin user be able to create an affinity group for other accounts to use ? Or can it be created only for its own consumption?
[Prachi] No, affinity groups can be created and used by individual account only. Affinity groups are a way for the user to specify her/his deployment preference, so the visibility/usage is limited to the account only.
4.ListAffinityGroups API:
Will admin/domain admin user be able to list the affinity groups of the other regular users ?
[Prachi] No, same as above.
5.DeleteAffinityGroup API:
Can this API be used to delete an Affinity Group / Can it be used to only to remove an existing VM from an affinity group?
Why is there a need to pass AccountName and DomainId for this API call ? Is Affinity Group Id not enough to uniquely identify this entity ?
[Prachi] It is for deleting groups of an account. The API also takes in the user-friendly group name too, in which case the account info is needed.
To delete VM's association to the group, updateVMAffinityGroup API will serve the purpose.
6. Will Affinity rules apply when we stop and start the Vms? Will it be applied when CloudStack performs HA ?
[Prachi] Yes.
7.When User tries to migrate/live migrate the VM , will the action to migrate a VM to a host that does not satisfy the affinity rule fail ?
[Prachi] When root Admin lists hosts available for live migration, CS will indicate the hosts that do not fit the affinity rules as 'Not Suitable'. If admin still goes ahead and migrates to such a host, migration will proceed.
8.DeployVirtualMachine API: It is mentioned in the FS that affinitygroupids OR affinitygroupnames need to be passed. If both are passed will the API fail ?
[Prachi] yes
9.Is there any difference in implementation for this feature between a Basic Zone and Advanced zone ?
[Prachi] Nope
10. In cases where there is a mismatch between service offering (host tag and storage tag) and anti-affinity group that the Vm is being deployed with , will the error message provided to the user be informative enough to know why the deployment failure happened (due to service offerings vs anti-affinity group) to take corrective actions?
[Prachi] No, it will still throw out the generic InsufficentCapacity error - and this is correct, since the underlying error is still not enough compute or storage capacity in the datacenter to _match_ your needs.
The logs will however show that the affinity rules + tags are being applied - causing no match found.
11. When a VM is in "Stopped" state , will it continue to be part of the affinity group ? Or will its association with the affinity group be released immediately, so that new Vms deployed as part of this anti-affinity group can use the host on which the Vm was running before it was stopped.
[Prachi] Good point. The association with affinity group is maintained. We never remove it unless user removes. But yes, it makes sense to avoid deploying new VMs in the same group, on that host. So host-anti-affinity should also consider last_host_id of the VM's that are in stopped state.
Thanks
Sangeetha
-----Original Message-----
From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
Sent: Friday, March 01, 2013 2:12 PM
To: cloudstack-dev@incubator.apache.org
Cc: Manan Shah; Alex Huang
Subject: Re: [DISCUSS] Affinity / Anti-affinity Rules
On 3/1/13 7:14 AM, "Chip Childers" <ch...@sungard.com> wrote:
>On Thu, Feb 28, 2013 at 03:18:51PM -0800, Prachi Damle wrote:
>> 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?
>
>I spent time thinking about this, and I'm not sure I see a use-case for
>it. Others might though...
Me neither
RE: [DISCUSS] Affinity / Anti-affinity Rules
Posted by Sangeetha Hariharan <Sa...@citrix.com>.
Had the following questions after going over the spec - https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+Affinity-Anti-affinity+groups :
1.In the API changes section - For all the API calls listed can we include if the parameters are optional/Required?
2.Can new DB changes introduced by this feature be included ?
3.CreateAffinityGroup API:
Using this API can admin/domain admin user be able to create an affinity group for other accounts to use ? Or can it be created only for its own consumption?
4.ListAffinityGroups API:
Will admin/domain admin user be able to list the affinity groups of the other regular users ?
5.DeleteAffinityGroup API:
Can this API be used to delete an Affinity Group / Can it be used to only to remove an existing VM from an affinity group?
Why is there a need to pass AccountName and DomainId for this API call ? Is Affinity Group Id not enough to uniquely identify this entity ?
6. Will Affinity rules apply when we stop and start the Vms? Will it be applied when CloudStack performs HA ?
7.When User tries to migrate/live migrate the VM , will the action to migrate a VM to a host that does not satisfy the affinity rule fail ?
8.DeployVirtualMachine API: It is mentioned in the FS that affinitygroupids OR affinitygroupnames need to be passed. If both are passed will the API fail ?
9.Is there any difference in implementation for this feature between a Basic Zone and Advanced zone ?
10. In cases where there is a mismatch between service offering (host tag and storage tag) and anti-affinity group that the Vm is being deployed with , will the error message provided to the user be informative enough to know why the deployment failure happened (due to service offerings vs anti-affinity group) to take corrective actions?
11. When a VM is in "Stopped" state , will it continue to be part of the affinity group ? Or will its association with the affinity group be released immediately, so that new Vms deployed as part of this anti-affinity group can use the host on which the Vm was running before it was stopped.
Thanks
Sangeetha
-----Original Message-----
From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
Sent: Friday, March 01, 2013 2:12 PM
To: cloudstack-dev@incubator.apache.org
Cc: Manan Shah; Alex Huang
Subject: Re: [DISCUSS] Affinity / Anti-affinity Rules
On 3/1/13 7:14 AM, "Chip Childers" <ch...@sungard.com> wrote:
>On Thu, Feb 28, 2013 at 03:18:51PM -0800, Prachi Damle wrote:
>> 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?
>
>I spent time thinking about this, and I'm not sure I see a use-case for
>it. Others might though...
Me neither
Re: [DISCUSS] Affinity / Anti-affinity Rules
Posted by Chiradeep Vittal <Ch...@citrix.com>.
On 3/1/13 7:14 AM, "Chip Childers" <ch...@sungard.com> wrote:
>On Thu, Feb 28, 2013 at 03:18:51PM -0800, Prachi Damle wrote:
>> 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?
>
>I spent time thinking about this, and I'm not sure I see a use-case for
>it. Others might though...
Me neither
Re: [DISCUSS] Affinity / Anti-affinity Rules
Posted by Chip Childers <ch...@sungard.com>.
On Thu, Feb 28, 2013 at 03:18:51PM -0800, Prachi Damle wrote:
> 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?
I spent time thinking about this, and I'm not sure I see a use-case for
it. Others might though...
>
> -Prachi
>
> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@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.
>
>
RE: [DISCUSS] Affinity / Anti-affinity Rules
Posted by Prachi Damle <Pr...@citrix.com>.
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.childers@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.
Re: [DISCUSS] Affinity / Anti-affinity Rules
Posted by Chip Childers <ch...@sungard.com>.
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.
RE: [DISCUSS] Affinity / Anti-affinity Rules
Posted by Prachi Damle <Pr...@citrix.com>.
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.
Thanks,
Prachi
-----Original Message-----
From: Prachi Damle [mailto:Prachi.Damle@citrix.com]
Sent: Thursday, February 14, 2013 11:45 AM
To: Manan Shah; Alex Huang; cloudstack-dev@incubator.apache.org
Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
Hi Manan,
I assume affinity level means affinity type.
For 4.2, plan is to add a framework for processing affinity groups and provide implementation for types: host affinity and host anti-affinity Since the affinity implementations will be plugins, admin could support other types by adding the plugin implementations to the deployment.
-Prachi
-----Original Message-----
From: Manan Shah
Sent: Thursday, February 14, 2013 11:41 AM
To: Prachi Damle; Alex Huang; cloudstack-dev@incubator.apache.org
Subject: Re: [DISCUSS] Affinity / Anti-affinity Rules
Hi Prachi,
My understanding is that we would build a framework for allowing admins to specify the levels of affinity/anti-affinity but for CS 4.2, we will support only one level. Is that a correct assumption?
Regards,
Manan Shah
On 2/8/13 5:17 PM, "Prachi Damle" <Pr...@citrix.com> wrote:
>I have updated the FS with the addition of the
>DeploymentPlanningManager entity.
>
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+Affinity-An
>ti-
>affinity+groups
>
>-Prachi
>
>-----Original Message-----
>From: Prachi Damle
>Sent: Thursday, February 07, 2013 1:38 PM
>To: Alex Huang; cloudstack-dev@incubator.apache.org
>Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
>
>Alex,
>
>Thanks for the detailed review. I will couple the affinity design with
>the deployment planner refactoring I had next in line then. Will update
>the FS with these details.
>
>-Prachi
>
>-----Original Message-----
>From: Alex Huang
>Sent: Wednesday, February 06, 2013 12:00 PM
>To: Prachi Damle; cloudstack-dev@incubator.apache.org
>Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
>
>Prachi,
>
>If it's an elective option, then it shouldn't have options in the
>deployvm api. We can't decouple the code but then say it's coupled at
>deployvm api call.
>
>I think it makes sense to have the affinity be part of orchestration.
>If so, then it makes sense to do this.
>
>- Write DeploymentPlanningManager which contains planning for volume,
>vm, and network.
>- For VM deployment, DPM goes through the following stages
> - Affinity - to set deploymentplan scope and exclude list (we might
>think about merging the two).
> - DeploymentPlanner - to use heuristics to find the best spot to place
>the vm/volume.
> - Allocator - which matches the requirements to capabilities of the
>physical resource.
>
>If you think about it, then it makes sense because each matches to the
>functionality it serves.
> - Affinity - matches user preference to narrow down where to deploy.
> - DeploymentPlanner - matches algorithms set by Administrator to give
>best performance/value/feature
> - Allocator - matches physical requirements.
>
>This would mean taking Allocator out of DeploymentPlanner
>implementations. It is very similar to your intent with an
>AffinityDeploymentPlanner.
>
>I think actually this works out very well with the idea of reservations
>as well. You might think about doing the two together as a refactor of
>Deployment Planning.
>
>--Alex
>
>> -----Original Message-----
>> From: Prachi Damle
>> Sent: Tuesday, February 05, 2013 11:39 PM
>> To: Alex Huang; cloudstack-dev@incubator.apache.org
>> Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
>>
>> Hi Alex,
>>
>> Thanks for the review, I have answered inline. Please comment.
>> I guess the FS needs more description reasoning the 2-component
>> design to avoid confusion.
>>
>> -Prachi
>>
>> -----Original Message-----
>> From: Alex Huang
>> Sent: Tuesday, February 05, 2013 4:49 PM
>> To: Prachi Damle; cloudstack-dev@incubator.apache.org
>> Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
>>
>> Hi Prachi,
>>
>> A few comments about this spec.
>>
>> - What is the error when planning fails? What details will it give?
>>
>>
>> [Prachi] I was planning to still rely on the deployment planner to
>> throw exception since planner will be the component that will find
>> out that placement is not possible.
>> But it is a good point and I will add a custom exception that the
>> AffinityProcessor can throw if upon analysis it finds the affinity
>> rule cannot be followed. This will save the planner execution.
>>
>>
>> - Why are HostAffinityProcessor and HostAntiAffinityProcessor
>> different implementations? The requirements says they should be
>> specified concurrently so shouldn't they be the same processor? Or
>> are you planning for this adapter to be an adapter chain?
>>
>>
>> [Prachi] Yes I am planning this to be a chain of adapters, each can
>> handle a specific affinity type.
>>
>> - I'm not really sure I understand the design. It would seem like
>> this can be designed in two ways.
>> 1. Affinity Group is an integrated part of cloud-engine and
>> AffinityGroupProcessor is ran before all DeploymentPlanners to set
>> the scope of DeploymentPlan and ExcludeList. If this is the case, I
>> don't understand why there is a AffinityGroupPlanner.
>> 2. The entire thing is implemented as a DeploymentPlanner. If it is
>> implemented as a DeploymentPlanner, then why do we need the
>> AffinityGroupProcessor interface? Why not just have it as a property
>> of that DeploymentPlanner implementation?
>> After giving it some thought, I think it is important that affinity
>> group is part of core orchestration. If so then I would prefer 1.
>> The current spec has both so I'm confused on this.
>> - The getType() of the AffinityGroupProcessor seems like it's more
>> similar to the getName of the adapter already, which needs to be
>> unique. I think you just need more descriptions on what the
>> processor does so the end user can understand how to use it?
>>
>> [Prachi] Since use of the affinity groups will be done during VM
>>placement, I wanted to stick to add all logic to DeploymentPlanner.
>> This will make sure that anytime the planner gets called (deployment,
>>restart, migration, HA) affinity groups are take care of. Still I see
>>the need of being able to plugin custom implementations for various
>>types of affinity/anti-affinity. So pushed out the handling of the
>>affinityType to a separate adapter.
>>
>> Thus AffinityPlanner could be as simple as just running through the
>> chain of AffinityGroupProcessor's and it will not change even if we
>> introduce any new affinity types. It will be the hook in Cloudstack,
>> for the plugins implementing affinity types
>>
>> As you say we could keep this part of cloud-engine and run through
>> the chain of AffinityGroupProcessor before planners - but it will not
>> take care of other usecases that directly call planners for placement.
>>
>> - Can you check with Min on her creation of the REST API? Can we
>> start using the REST only API from here on?
>> [Prachi ]Sure will sync up with Min on REST API.
>>
>> --Alex
>>
>> > -----Original Message-----
>> > From: Prachi Damle [mailto:Prachi.Damle@citrix.com]
>> > Sent: Tuesday, February 05, 2013 2:42 PM
>> > To: cloudstack-dev@incubator.apache.org
>> > Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
>> >
>> > 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+-+Affinit
>> > y
>> > -
>> > 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.childers@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
>> > <ch...@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
>> > <Pr...@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.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 this proposal.
>> > >>
>> > >> On 1/3/13 4:23 PM, "Manan Shah" <ma...@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
>> > >> >
>> > >>
>> > >>
>> > >>
Re: [DISCUSS] Affinity / Anti-affinity Rules
Posted by Manan Shah <ma...@citrix.com>.
Yes, that's what I meant. Thanks for the clarification.
Regards,
Manan Shah
On 2/14/13 11:45 AM, "Prachi Damle" <Pr...@citrix.com> wrote:
>Hi Manan,
>
>I assume affinity level means affinity type.
>
>For 4.2, plan is to add a framework for processing affinity groups and
>provide implementation for types: host affinity and host anti-affinity
>Since the affinity implementations will be plugins, admin could support
>other types by adding the plugin implementations to the deployment.
>
>-Prachi
>
>-----Original Message-----
>From: Manan Shah
>Sent: Thursday, February 14, 2013 11:41 AM
>To: Prachi Damle; Alex Huang; cloudstack-dev@incubator.apache.org
>Subject: Re: [DISCUSS] Affinity / Anti-affinity Rules
>
>Hi Prachi,
>
>My understanding is that we would build a framework for allowing admins
>to specify the levels of affinity/anti-affinity but for CS 4.2, we will
>support only one level. Is that a correct assumption?
>
>Regards,
>Manan Shah
>
>
>
>
>On 2/8/13 5:17 PM, "Prachi Damle" <Pr...@citrix.com> wrote:
>
>>I have updated the FS with the addition of the
>>DeploymentPlanningManager entity.
>>
>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+Affinity-An
>>ti-
>>affinity+groups
>>
>>-Prachi
>>
>>-----Original Message-----
>>From: Prachi Damle
>>Sent: Thursday, February 07, 2013 1:38 PM
>>To: Alex Huang; cloudstack-dev@incubator.apache.org
>>Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
>>
>>Alex,
>>
>>Thanks for the detailed review. I will couple the affinity design with
>>the deployment planner refactoring I had next in line then. Will update
>>the FS with these details.
>>
>>-Prachi
>>
>>-----Original Message-----
>>From: Alex Huang
>>Sent: Wednesday, February 06, 2013 12:00 PM
>>To: Prachi Damle; cloudstack-dev@incubator.apache.org
>>Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
>>
>>Prachi,
>>
>>If it's an elective option, then it shouldn't have options in the
>>deployvm api. We can't decouple the code but then say it's coupled at
>>deployvm api call.
>>
>>I think it makes sense to have the affinity be part of orchestration.
>>If so, then it makes sense to do this.
>>
>>- Write DeploymentPlanningManager which contains planning for volume,
>>vm, and network.
>>- For VM deployment, DPM goes through the following stages
>> - Affinity - to set deploymentplan scope and exclude list (we might
>>think about merging the two).
>> - DeploymentPlanner - to use heuristics to find the best spot to place
>>the vm/volume.
>> - Allocator - which matches the requirements to capabilities of the
>>physical resource.
>>
>>If you think about it, then it makes sense because each matches to the
>>functionality it serves.
>> - Affinity - matches user preference to narrow down where to deploy.
>> - DeploymentPlanner - matches algorithms set by Administrator to give
>>best performance/value/feature
>> - Allocator - matches physical requirements.
>>
>>This would mean taking Allocator out of DeploymentPlanner
>>implementations. It is very similar to your intent with an
>>AffinityDeploymentPlanner.
>>
>>I think actually this works out very well with the idea of reservations
>>as well. You might think about doing the two together as a refactor of
>>Deployment Planning.
>>
>>--Alex
>>
>>> -----Original Message-----
>>> From: Prachi Damle
>>> Sent: Tuesday, February 05, 2013 11:39 PM
>>> To: Alex Huang; cloudstack-dev@incubator.apache.org
>>> Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
>>>
>>> Hi Alex,
>>>
>>> Thanks for the review, I have answered inline. Please comment.
>>> I guess the FS needs more description reasoning the 2-component
>>> design to avoid confusion.
>>>
>>> -Prachi
>>>
>>> -----Original Message-----
>>> From: Alex Huang
>>> Sent: Tuesday, February 05, 2013 4:49 PM
>>> To: Prachi Damle; cloudstack-dev@incubator.apache.org
>>> Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
>>>
>>> Hi Prachi,
>>>
>>> A few comments about this spec.
>>>
>>> - What is the error when planning fails? What details will it give?
>>>
>>>
>>> [Prachi] I was planning to still rely on the deployment planner to
>>> throw exception since planner will be the component that will find
>>> out that placement is not possible.
>>> But it is a good point and I will add a custom exception that the
>>> AffinityProcessor can throw if upon analysis it finds the affinity
>>> rule cannot be followed. This will save the planner execution.
>>>
>>>
>>> - Why are HostAffinityProcessor and HostAntiAffinityProcessor
>>> different implementations? The requirements says they should be
>>> specified concurrently so shouldn't they be the same processor? Or
>>> are you planning for this adapter to be an adapter chain?
>>>
>>>
>>> [Prachi] Yes I am planning this to be a chain of adapters, each can
>>> handle a specific affinity type.
>>>
>>> - I'm not really sure I understand the design. It would seem like
>>> this can be designed in two ways.
>>> 1. Affinity Group is an integrated part of cloud-engine and
>>> AffinityGroupProcessor is ran before all DeploymentPlanners to set
>>> the scope of DeploymentPlan and ExcludeList. If this is the case, I
>>> don't understand why there is a AffinityGroupPlanner.
>>> 2. The entire thing is implemented as a DeploymentPlanner. If it is
>>> implemented as a DeploymentPlanner, then why do we need the
>>> AffinityGroupProcessor interface? Why not just have it as a property
>>> of that DeploymentPlanner implementation?
>>> After giving it some thought, I think it is important that affinity
>>> group is part of core orchestration. If so then I would prefer 1.
>>> The current spec has both so I'm confused on this.
>>> - The getType() of the AffinityGroupProcessor seems like it's more
>>> similar to the getName of the adapter already, which needs to be
>>> unique. I think you just need more descriptions on what the
>>> processor does so the end user can understand how to use it?
>>>
>>> [Prachi] Since use of the affinity groups will be done during VM
>>>placement, I wanted to stick to add all logic to DeploymentPlanner.
>>> This will make sure that anytime the planner gets called (deployment,
>>>restart, migration, HA) affinity groups are take care of. Still I see
>>>the need of being able to plugin custom implementations for various
>>>types of affinity/anti-affinity. So pushed out the handling of the
>>>affinityType to a separate adapter.
>>>
>>> Thus AffinityPlanner could be as simple as just running through the
>>> chain of AffinityGroupProcessor's and it will not change even if we
>>> introduce any new affinity types. It will be the hook in Cloudstack,
>>> for the plugins implementing affinity types
>>>
>>> As you say we could keep this part of cloud-engine and run through
>>> the chain of AffinityGroupProcessor before planners - but it will not
>>> take care of other usecases that directly call planners for placement.
>>>
>>> - Can you check with Min on her creation of the REST API? Can we
>>> start using the REST only API from here on?
>>> [Prachi ]Sure will sync up with Min on REST API.
>>>
>>> --Alex
>>>
>>> > -----Original Message-----
>>> > From: Prachi Damle [mailto:Prachi.Damle@citrix.com]
>>> > Sent: Tuesday, February 05, 2013 2:42 PM
>>> > To: cloudstack-dev@incubator.apache.org
>>> > Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
>>> >
>>> > 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+-+Affinit
>>> > y
>>> > -
>>> > 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.childers@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
>>> > <ch...@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
>>> > <Pr...@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.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 this proposal.
>>> > >>
>>> > >> On 1/3/13 4:23 PM, "Manan Shah" <ma...@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
>>> > >> >
>>> > >>
>>> > >>
>>> > >>
>
RE: [DISCUSS] Affinity / Anti-affinity Rules
Posted by Prachi Damle <Pr...@citrix.com>.
Hi Manan,
I assume affinity level means affinity type.
For 4.2, plan is to add a framework for processing affinity groups and provide implementation for types: host affinity and host anti-affinity
Since the affinity implementations will be plugins, admin could support other types by adding the plugin implementations to the deployment.
-Prachi
-----Original Message-----
From: Manan Shah
Sent: Thursday, February 14, 2013 11:41 AM
To: Prachi Damle; Alex Huang; cloudstack-dev@incubator.apache.org
Subject: Re: [DISCUSS] Affinity / Anti-affinity Rules
Hi Prachi,
My understanding is that we would build a framework for allowing admins to specify the levels of affinity/anti-affinity but for CS 4.2, we will support only one level. Is that a correct assumption?
Regards,
Manan Shah
On 2/8/13 5:17 PM, "Prachi Damle" <Pr...@citrix.com> wrote:
>I have updated the FS with the addition of the
>DeploymentPlanningManager entity.
>
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+Affinity-An
>ti-
>affinity+groups
>
>-Prachi
>
>-----Original Message-----
>From: Prachi Damle
>Sent: Thursday, February 07, 2013 1:38 PM
>To: Alex Huang; cloudstack-dev@incubator.apache.org
>Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
>
>Alex,
>
>Thanks for the detailed review. I will couple the affinity design with
>the deployment planner refactoring I had next in line then. Will update
>the FS with these details.
>
>-Prachi
>
>-----Original Message-----
>From: Alex Huang
>Sent: Wednesday, February 06, 2013 12:00 PM
>To: Prachi Damle; cloudstack-dev@incubator.apache.org
>Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
>
>Prachi,
>
>If it's an elective option, then it shouldn't have options in the
>deployvm api. We can't decouple the code but then say it's coupled at
>deployvm api call.
>
>I think it makes sense to have the affinity be part of orchestration.
>If so, then it makes sense to do this.
>
>- Write DeploymentPlanningManager which contains planning for volume,
>vm, and network.
>- For VM deployment, DPM goes through the following stages
> - Affinity - to set deploymentplan scope and exclude list (we might
>think about merging the two).
> - DeploymentPlanner - to use heuristics to find the best spot to place
>the vm/volume.
> - Allocator - which matches the requirements to capabilities of the
>physical resource.
>
>If you think about it, then it makes sense because each matches to the
>functionality it serves.
> - Affinity - matches user preference to narrow down where to deploy.
> - DeploymentPlanner - matches algorithms set by Administrator to give
>best performance/value/feature
> - Allocator - matches physical requirements.
>
>This would mean taking Allocator out of DeploymentPlanner
>implementations. It is very similar to your intent with an
>AffinityDeploymentPlanner.
>
>I think actually this works out very well with the idea of reservations
>as well. You might think about doing the two together as a refactor of
>Deployment Planning.
>
>--Alex
>
>> -----Original Message-----
>> From: Prachi Damle
>> Sent: Tuesday, February 05, 2013 11:39 PM
>> To: Alex Huang; cloudstack-dev@incubator.apache.org
>> Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
>>
>> Hi Alex,
>>
>> Thanks for the review, I have answered inline. Please comment.
>> I guess the FS needs more description reasoning the 2-component
>> design to avoid confusion.
>>
>> -Prachi
>>
>> -----Original Message-----
>> From: Alex Huang
>> Sent: Tuesday, February 05, 2013 4:49 PM
>> To: Prachi Damle; cloudstack-dev@incubator.apache.org
>> Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
>>
>> Hi Prachi,
>>
>> A few comments about this spec.
>>
>> - What is the error when planning fails? What details will it give?
>>
>>
>> [Prachi] I was planning to still rely on the deployment planner to
>> throw exception since planner will be the component that will find
>> out that placement is not possible.
>> But it is a good point and I will add a custom exception that the
>> AffinityProcessor can throw if upon analysis it finds the affinity
>> rule cannot be followed. This will save the planner execution.
>>
>>
>> - Why are HostAffinityProcessor and HostAntiAffinityProcessor
>> different implementations? The requirements says they should be
>> specified concurrently so shouldn't they be the same processor? Or
>> are you planning for this adapter to be an adapter chain?
>>
>>
>> [Prachi] Yes I am planning this to be a chain of adapters, each can
>> handle a specific affinity type.
>>
>> - I'm not really sure I understand the design. It would seem like
>> this can be designed in two ways.
>> 1. Affinity Group is an integrated part of cloud-engine and
>> AffinityGroupProcessor is ran before all DeploymentPlanners to set
>> the scope of DeploymentPlan and ExcludeList. If this is the case, I
>> don't understand why there is a AffinityGroupPlanner.
>> 2. The entire thing is implemented as a DeploymentPlanner. If it is
>> implemented as a DeploymentPlanner, then why do we need the
>> AffinityGroupProcessor interface? Why not just have it as a property
>> of that DeploymentPlanner implementation?
>> After giving it some thought, I think it is important that affinity
>> group is part of core orchestration. If so then I would prefer 1.
>> The current spec has both so I'm confused on this.
>> - The getType() of the AffinityGroupProcessor seems like it's more
>> similar to the getName of the adapter already, which needs to be
>> unique. I think you just need more descriptions on what the
>> processor does so the end user can understand how to use it?
>>
>> [Prachi] Since use of the affinity groups will be done during VM
>>placement, I wanted to stick to add all logic to DeploymentPlanner.
>> This will make sure that anytime the planner gets called (deployment,
>>restart, migration, HA) affinity groups are take care of. Still I see
>>the need of being able to plugin custom implementations for various
>>types of affinity/anti-affinity. So pushed out the handling of the
>>affinityType to a separate adapter.
>>
>> Thus AffinityPlanner could be as simple as just running through the
>> chain of AffinityGroupProcessor's and it will not change even if we
>> introduce any new affinity types. It will be the hook in Cloudstack,
>> for the plugins implementing affinity types
>>
>> As you say we could keep this part of cloud-engine and run through
>> the chain of AffinityGroupProcessor before planners - but it will not
>> take care of other usecases that directly call planners for placement.
>>
>> - Can you check with Min on her creation of the REST API? Can we
>> start using the REST only API from here on?
>> [Prachi ]Sure will sync up with Min on REST API.
>>
>> --Alex
>>
>> > -----Original Message-----
>> > From: Prachi Damle [mailto:Prachi.Damle@citrix.com]
>> > Sent: Tuesday, February 05, 2013 2:42 PM
>> > To: cloudstack-dev@incubator.apache.org
>> > Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
>> >
>> > 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+-+Affinit
>> > y
>> > -
>> > 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.childers@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
>> > <ch...@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
>> > <Pr...@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.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 this proposal.
>> > >>
>> > >> On 1/3/13 4:23 PM, "Manan Shah" <ma...@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
>> > >> >
>> > >>
>> > >>
>> > >>
Re: [DISCUSS] Affinity / Anti-affinity Rules
Posted by Manan Shah <ma...@citrix.com>.
Hi Prachi,
My understanding is that we would build a framework for allowing admins to
specify the levels of affinity/anti-affinity but for CS 4.2, we will
support only one level. Is that a correct assumption?
Regards,
Manan Shah
On 2/8/13 5:17 PM, "Prachi Damle" <Pr...@citrix.com> wrote:
>I have updated the FS with the addition of the DeploymentPlanningManager
>entity.
>
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+Affinity-Anti-
>affinity+groups
>
>-Prachi
>
>-----Original Message-----
>From: Prachi Damle
>Sent: Thursday, February 07, 2013 1:38 PM
>To: Alex Huang; cloudstack-dev@incubator.apache.org
>Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
>
>Alex,
>
>Thanks for the detailed review. I will couple the affinity design with
>the deployment planner refactoring I had next in line then. Will update
>the FS with these details.
>
>-Prachi
>
>-----Original Message-----
>From: Alex Huang
>Sent: Wednesday, February 06, 2013 12:00 PM
>To: Prachi Damle; cloudstack-dev@incubator.apache.org
>Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
>
>Prachi,
>
>If it's an elective option, then it shouldn't have options in the
>deployvm api. We can't decouple the code but then say it's coupled at
>deployvm api call.
>
>I think it makes sense to have the affinity be part of orchestration. If
>so, then it makes sense to do this.
>
>- Write DeploymentPlanningManager which contains planning for volume, vm,
>and network.
>- For VM deployment, DPM goes through the following stages
> - Affinity - to set deploymentplan scope and exclude list (we might
>think about merging the two).
> - DeploymentPlanner - to use heuristics to find the best spot to place
>the vm/volume.
> - Allocator - which matches the requirements to capabilities of the
>physical resource.
>
>If you think about it, then it makes sense because each matches to the
>functionality it serves.
> - Affinity - matches user preference to narrow down where to deploy.
> - DeploymentPlanner - matches algorithms set by Administrator to give
>best performance/value/feature
> - Allocator - matches physical requirements.
>
>This would mean taking Allocator out of DeploymentPlanner
>implementations. It is very similar to your intent with an
>AffinityDeploymentPlanner.
>
>I think actually this works out very well with the idea of reservations
>as well. You might think about doing the two together as a refactor of
>Deployment Planning.
>
>--Alex
>
>> -----Original Message-----
>> From: Prachi Damle
>> Sent: Tuesday, February 05, 2013 11:39 PM
>> To: Alex Huang; cloudstack-dev@incubator.apache.org
>> Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
>>
>> Hi Alex,
>>
>> Thanks for the review, I have answered inline. Please comment.
>> I guess the FS needs more description reasoning the 2-component design
>> to avoid confusion.
>>
>> -Prachi
>>
>> -----Original Message-----
>> From: Alex Huang
>> Sent: Tuesday, February 05, 2013 4:49 PM
>> To: Prachi Damle; cloudstack-dev@incubator.apache.org
>> Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
>>
>> Hi Prachi,
>>
>> A few comments about this spec.
>>
>> - What is the error when planning fails? What details will it give?
>>
>>
>> [Prachi] I was planning to still rely on the deployment planner to
>> throw exception since planner will be the component that will find out
>> that placement is not possible.
>> But it is a good point and I will add a custom exception that the
>> AffinityProcessor can throw if upon analysis it finds the affinity
>> rule cannot be followed. This will save the planner execution.
>>
>>
>> - Why are HostAffinityProcessor and HostAntiAffinityProcessor
>> different implementations? The requirements says they should be
>> specified concurrently so shouldn't they be the same processor? Or
>> are you planning for this adapter to be an adapter chain?
>>
>>
>> [Prachi] Yes I am planning this to be a chain of adapters, each can
>> handle a specific affinity type.
>>
>> - I'm not really sure I understand the design. It would seem like
>> this can be designed in two ways.
>> 1. Affinity Group is an integrated part of cloud-engine and
>> AffinityGroupProcessor is ran before all DeploymentPlanners to set the
>> scope of DeploymentPlan and ExcludeList. If this is the case, I don't
>> understand why there is a AffinityGroupPlanner.
>> 2. The entire thing is implemented as a DeploymentPlanner. If it is
>> implemented as a DeploymentPlanner, then why do we need the
>> AffinityGroupProcessor interface? Why not just have it as a property
>> of that DeploymentPlanner implementation?
>> After giving it some thought, I think it is important that affinity
>> group is part of core orchestration. If so then I would prefer 1.
>> The current spec has both so I'm confused on this.
>> - The getType() of the AffinityGroupProcessor seems like it's more
>> similar to the getName of the adapter already, which needs to be
>> unique. I think you just need more descriptions on what the processor
>> does so the end user can understand how to use it?
>>
>> [Prachi] Since use of the affinity groups will be done during VM
>> placement, I wanted to stick to add all logic to DeploymentPlanner.
>> This will make sure that anytime the planner gets called (deployment,
>> restart, migration, HA) affinity groups are take care of. Still I see
>> the need of being able to plugin custom implementations for various
>> types of affinity/anti-affinity. So pushed out the handling of the
>>affinityType to a separate adapter.
>>
>> Thus AffinityPlanner could be as simple as just running through the
>> chain of AffinityGroupProcessor's and it will not change even if we
>> introduce any new affinity types. It will be the hook in Cloudstack,
>> for the plugins implementing affinity types
>>
>> As you say we could keep this part of cloud-engine and run through the
>> chain of AffinityGroupProcessor before planners - but it will not take
>> care of other usecases that directly call planners for placement.
>>
>> - Can you check with Min on her creation of the REST API? Can we
>> start using the REST only API from here on?
>> [Prachi ]Sure will sync up with Min on REST API.
>>
>> --Alex
>>
>> > -----Original Message-----
>> > From: Prachi Damle [mailto:Prachi.Damle@citrix.com]
>> > Sent: Tuesday, February 05, 2013 2:42 PM
>> > To: cloudstack-dev@incubator.apache.org
>> > Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
>> >
>> > 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.childers@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
>> > <ch...@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
>> > <Pr...@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.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
>> > >> this proposal.
>> > >>
>> > >> On 1/3/13 4:23 PM, "Manan Shah" <ma...@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
>> > >> >
>> > >>
>> > >>
>> > >>
RE: [DISCUSS] Affinity / Anti-affinity Rules
Posted by Prachi Damle <Pr...@citrix.com>.
I have updated the FS with the addition of the DeploymentPlanningManager entity.
https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+Affinity-Anti-affinity+groups
-Prachi
-----Original Message-----
From: Prachi Damle
Sent: Thursday, February 07, 2013 1:38 PM
To: Alex Huang; cloudstack-dev@incubator.apache.org
Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
Alex,
Thanks for the detailed review. I will couple the affinity design with the deployment planner refactoring I had next in line then. Will update the FS with these details.
-Prachi
-----Original Message-----
From: Alex Huang
Sent: Wednesday, February 06, 2013 12:00 PM
To: Prachi Damle; cloudstack-dev@incubator.apache.org
Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
Prachi,
If it's an elective option, then it shouldn't have options in the deployvm api. We can't decouple the code but then say it's coupled at deployvm api call.
I think it makes sense to have the affinity be part of orchestration. If so, then it makes sense to do this.
- Write DeploymentPlanningManager which contains planning for volume, vm, and network.
- For VM deployment, DPM goes through the following stages
- Affinity - to set deploymentplan scope and exclude list (we might think about merging the two).
- DeploymentPlanner - to use heuristics to find the best spot to place the vm/volume.
- Allocator - which matches the requirements to capabilities of the physical resource.
If you think about it, then it makes sense because each matches to the functionality it serves.
- Affinity - matches user preference to narrow down where to deploy.
- DeploymentPlanner - matches algorithms set by Administrator to give best performance/value/feature
- Allocator - matches physical requirements.
This would mean taking Allocator out of DeploymentPlanner implementations. It is very similar to your intent with an AffinityDeploymentPlanner.
I think actually this works out very well with the idea of reservations as well. You might think about doing the two together as a refactor of Deployment Planning.
--Alex
> -----Original Message-----
> From: Prachi Damle
> Sent: Tuesday, February 05, 2013 11:39 PM
> To: Alex Huang; cloudstack-dev@incubator.apache.org
> Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
>
> Hi Alex,
>
> Thanks for the review, I have answered inline. Please comment.
> I guess the FS needs more description reasoning the 2-component design
> to avoid confusion.
>
> -Prachi
>
> -----Original Message-----
> From: Alex Huang
> Sent: Tuesday, February 05, 2013 4:49 PM
> To: Prachi Damle; cloudstack-dev@incubator.apache.org
> Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
>
> Hi Prachi,
>
> A few comments about this spec.
>
> - What is the error when planning fails? What details will it give?
>
>
> [Prachi] I was planning to still rely on the deployment planner to
> throw exception since planner will be the component that will find out
> that placement is not possible.
> But it is a good point and I will add a custom exception that the
> AffinityProcessor can throw if upon analysis it finds the affinity
> rule cannot be followed. This will save the planner execution.
>
>
> - Why are HostAffinityProcessor and HostAntiAffinityProcessor
> different implementations? The requirements says they should be
> specified concurrently so shouldn't they be the same processor? Or
> are you planning for this adapter to be an adapter chain?
>
>
> [Prachi] Yes I am planning this to be a chain of adapters, each can
> handle a specific affinity type.
>
> - I'm not really sure I understand the design. It would seem like
> this can be designed in two ways.
> 1. Affinity Group is an integrated part of cloud-engine and
> AffinityGroupProcessor is ran before all DeploymentPlanners to set the
> scope of DeploymentPlan and ExcludeList. If this is the case, I don't
> understand why there is a AffinityGroupPlanner.
> 2. The entire thing is implemented as a DeploymentPlanner. If it is
> implemented as a DeploymentPlanner, then why do we need the
> AffinityGroupProcessor interface? Why not just have it as a property
> of that DeploymentPlanner implementation?
> After giving it some thought, I think it is important that affinity
> group is part of core orchestration. If so then I would prefer 1.
> The current spec has both so I'm confused on this.
> - The getType() of the AffinityGroupProcessor seems like it's more
> similar to the getName of the adapter already, which needs to be
> unique. I think you just need more descriptions on what the processor
> does so the end user can understand how to use it?
>
> [Prachi] Since use of the affinity groups will be done during VM
> placement, I wanted to stick to add all logic to DeploymentPlanner.
> This will make sure that anytime the planner gets called (deployment,
> restart, migration, HA) affinity groups are take care of. Still I see
> the need of being able to plugin custom implementations for various
> types of affinity/anti-affinity. So pushed out the handling of the affinityType to a separate adapter.
>
> Thus AffinityPlanner could be as simple as just running through the
> chain of AffinityGroupProcessor's and it will not change even if we
> introduce any new affinity types. It will be the hook in Cloudstack,
> for the plugins implementing affinity types
>
> As you say we could keep this part of cloud-engine and run through the
> chain of AffinityGroupProcessor before planners - but it will not take
> care of other usecases that directly call planners for placement.
>
> - Can you check with Min on her creation of the REST API? Can we
> start using the REST only API from here on?
> [Prachi ]Sure will sync up with Min on REST API.
>
> --Alex
>
> > -----Original Message-----
> > From: Prachi Damle [mailto:Prachi.Damle@citrix.com]
> > Sent: Tuesday, February 05, 2013 2:42 PM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
> >
> > 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.childers@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
> > <ch...@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
> > <Pr...@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.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
> > >> this proposal.
> > >>
> > >> On 1/3/13 4:23 PM, "Manan Shah" <ma...@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
> > >> >
> > >>
> > >>
> > >>
RE: [DISCUSS] Affinity / Anti-affinity Rules
Posted by Alex Huang <Al...@citrix.com>.
Prachi,
If it's an elective option, then it shouldn't have options in the deployvm api. We can't decouple the code but then say it's coupled at deployvm api call.
I think it makes sense to have the affinity be part of orchestration. If so, then it makes sense to do this.
- Write DeploymentPlanningManager which contains planning for volume, vm, and network.
- For VM deployment, DPM goes through the following stages
- Affinity - to set deploymentplan scope and exclude list (we might think about merging the two).
- DeploymentPlanner - to use heuristics to find the best spot to place the vm/volume.
- Allocator - which matches the requirements to capabilities of the physical resource.
If you think about it, then it makes sense because each matches to the functionality it serves.
- Affinity - matches user preference to narrow down where to deploy.
- DeploymentPlanner - matches algorithms set by Administrator to give best performance/value/feature
- Allocator - matches physical requirements.
This would mean taking Allocator out of DeploymentPlanner implementations. It is very similar to your intent with an AffinityDeploymentPlanner.
I think actually this works out very well with the idea of reservations as well. You might think about doing the two together as a refactor of Deployment Planning.
--Alex
> -----Original Message-----
> From: Prachi Damle
> Sent: Tuesday, February 05, 2013 11:39 PM
> To: Alex Huang; cloudstack-dev@incubator.apache.org
> Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
>
> Hi Alex,
>
> Thanks for the review, I have answered inline. Please comment.
> I guess the FS needs more description reasoning the 2-component design to
> avoid confusion.
>
> -Prachi
>
> -----Original Message-----
> From: Alex Huang
> Sent: Tuesday, February 05, 2013 4:49 PM
> To: Prachi Damle; cloudstack-dev@incubator.apache.org
> Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
>
> Hi Prachi,
>
> A few comments about this spec.
>
> - What is the error when planning fails? What details will it give?
>
>
> [Prachi] I was planning to still rely on the deployment planner to throw
> exception since planner will be the component that will find out that
> placement is not possible.
> But it is a good point and I will add a custom exception that the
> AffinityProcessor can throw if upon analysis it finds the affinity rule cannot be
> followed. This will save the planner execution.
>
>
> - Why are HostAffinityProcessor and HostAntiAffinityProcessor different
> implementations? The requirements says they should be specified
> concurrently so shouldn't they be the same processor? Or are you planning
> for this adapter to be an adapter chain?
>
>
> [Prachi] Yes I am planning this to be a chain of adapters, each can handle a
> specific affinity type.
>
> - I'm not really sure I understand the design. It would seem like this can be
> designed in two ways.
> 1. Affinity Group is an integrated part of cloud-engine and
> AffinityGroupProcessor is ran before all DeploymentPlanners to set the
> scope of DeploymentPlan and ExcludeList. If this is the case, I don't
> understand why there is a AffinityGroupPlanner.
> 2. The entire thing is implemented as a DeploymentPlanner. If it is
> implemented as a DeploymentPlanner, then why do we need the
> AffinityGroupProcessor interface? Why not just have it as a property of that
> DeploymentPlanner implementation?
> After giving it some thought, I think it is important that affinity group is part
> of core orchestration. If so then I would prefer 1. The current spec has both
> so I'm confused on this.
> - The getType() of the AffinityGroupProcessor seems like it's more similar to
> the getName of the adapter already, which needs to be unique. I think you
> just need more descriptions on what the processor does so the end user can
> understand how to use it?
>
> [Prachi] Since use of the affinity groups will be done during VM placement, I
> wanted to stick to add all logic to DeploymentPlanner. This will make sure
> that anytime the planner gets called (deployment, restart, migration, HA)
> affinity groups are take care of. Still I see the need of being able to plugin
> custom implementations for various types of affinity/anti-affinity. So pushed
> out the handling of the affinityType to a separate adapter.
>
> Thus AffinityPlanner could be as simple as just running through the chain of
> AffinityGroupProcessor's and it will not change even if we introduce any new
> affinity types. It will be the hook in Cloudstack, for the plugins implementing
> affinity types
>
> As you say we could keep this part of cloud-engine and run through the chain
> of AffinityGroupProcessor before planners - but it will not take care of other
> usecases that directly call planners for placement.
>
> - Can you check with Min on her creation of the REST API? Can we start using
> the REST only API from here on?
> [Prachi ]Sure will sync up with Min on REST API.
>
> --Alex
>
> > -----Original Message-----
> > From: Prachi Damle [mailto:Prachi.Damle@citrix.com]
> > Sent: Tuesday, February 05, 2013 2:42 PM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
> >
> > 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.childers@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
> > <ch...@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
> > <Pr...@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.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
> > >> this proposal.
> > >>
> > >> On 1/3/13 4:23 PM, "Manan Shah" <ma...@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
> > >> >
> > >>
> > >>
> > >>
RE: [DISCUSS] Affinity / Anti-affinity Rules
Posted by Prachi Damle <Pr...@citrix.com>.
Hi Alex,
Thanks for the review, I have answered inline. Please comment.
I guess the FS needs more description reasoning the 2-component design to avoid confusion.
-Prachi
-----Original Message-----
From: Alex Huang
Sent: Tuesday, February 05, 2013 4:49 PM
To: Prachi Damle; cloudstack-dev@incubator.apache.org
Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
Hi Prachi,
A few comments about this spec.
- What is the error when planning fails? What details will it give?
[Prachi] I was planning to still rely on the deployment planner to throw exception since planner will be the component that will find out that placement is not possible.
But it is a good point and I will add a custom exception that the AffinityProcessor can throw if upon analysis it finds the affinity rule cannot be followed. This will save the planner execution.
- Why are HostAffinityProcessor and HostAntiAffinityProcessor different implementations? The requirements says they should be specified concurrently so shouldn't they be the same processor? Or are you planning for this adapter to be an adapter chain?
[Prachi] Yes I am planning this to be a chain of adapters, each can handle a specific affinity type.
- I'm not really sure I understand the design. It would seem like this can be designed in two ways.
1. Affinity Group is an integrated part of cloud-engine and AffinityGroupProcessor is ran before all DeploymentPlanners to set the scope of DeploymentPlan and ExcludeList. If this is the case, I don't understand why there is a AffinityGroupPlanner.
2. The entire thing is implemented as a DeploymentPlanner. If it is implemented as a DeploymentPlanner, then why do we need the AffinityGroupProcessor interface? Why not just have it as a property of that DeploymentPlanner implementation?
After giving it some thought, I think it is important that affinity group is part of core orchestration. If so then I would prefer 1. The current spec has both so I'm confused on this.
- The getType() of the AffinityGroupProcessor seems like it's more similar to the getName of the adapter already, which needs to be unique. I think you just need more descriptions on what the processor does so the end user can understand how to use it?
[Prachi] Since use of the affinity groups will be done during VM placement, I wanted to stick to add all logic to DeploymentPlanner. This will make sure that anytime the planner gets called (deployment, restart, migration, HA) affinity groups are take care of. Still I see the need of being able to plugin custom implementations for various types of affinity/anti-affinity. So pushed out the handling of the affinityType to a separate adapter.
Thus AffinityPlanner could be as simple as just running through the chain of AffinityGroupProcessor's and it will not change even if we introduce any new affinity types. It will be the hook in Cloudstack, for the plugins implementing affinity types
As you say we could keep this part of cloud-engine and run through the chain of AffinityGroupProcessor before planners - but it will not take care of other usecases that directly call planners for placement.
- Can you check with Min on her creation of the REST API? Can we start using the REST only API from here on?
[Prachi ]Sure will sync up with Min on REST API.
--Alex
> -----Original Message-----
> From: Prachi Damle [mailto:Prachi.Damle@citrix.com]
> Sent: Tuesday, February 05, 2013 2:42 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
>
> 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.childers@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
> <ch...@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
> <Pr...@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.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
> >> this proposal.
> >>
> >> On 1/3/13 4:23 PM, "Manan Shah" <ma...@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
> >> >
> >>
> >>
> >>
RE: [DISCUSS] Affinity / Anti-affinity Rules
Posted by Alex Huang <Al...@citrix.com>.
Hi Prachi,
A few comments about this spec.
- What is the error when planning fails? What details will it give?
- Why are HostAffinityProcessor and HostAntiAffinityProcessor different implementations? The requirements says they should be specified concurrently so shouldn't they be the same processor? Or are you planning for this adapter to be an adapter chain?
- I'm not really sure I understand the design. It would seem like this can be designed in two ways.
1. Affinity Group is an integrated part of cloud-engine and AffinityGroupProcessor is ran before all DeploymentPlanners to set the scope of DeploymentPlan and ExcludeList. If this is the case, I don't understand why there is a AffinityGroupPlanner.
2. The entire thing is implemented as a DeploymentPlanner. If it is implemented as a DeploymentPlanner, then why do we need the AffinityGroupProcessor interface? Why not just have it as a property of that DeploymentPlanner implementation?
After giving it some thought, I think it is important that affinity group is part of core orchestration. If so then I would prefer 1. The current spec has both so I'm confused on this.
- The getType() of the AffinityGroupProcessor seems like it's more similar to the getName of the adapter already, which needs to be unique. I think you just need more descriptions on what the processor does so the end user can understand how to use it?
- Can you check with Min on her creation of the REST API? Can we start using the REST only API from here on?
--Alex
> -----Original Message-----
> From: Prachi Damle [mailto:Prachi.Damle@citrix.com]
> Sent: Tuesday, February 05, 2013 2:42 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: [DISCUSS] Affinity / Anti-affinity Rules
>
> 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.childers@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 <ch...@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
> <Pr...@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.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
> >> this proposal.
> >>
> >> On 1/3/13 4:23 PM, "Manan Shah" <ma...@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
> >> >
> >>
> >>
> >>
Re: [DISCUSS] Affinity / Anti-affinity Rules
Posted by Murali Reddy <Mu...@citrix.com>.
On 06/02/13 4:12 AM, "Prachi Damle" <Pr...@citrix.com> wrote:
>
>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.
Prachi,
When the granularity of affinity/anti-affinity rule is at host level, will
the rules work in case of externally managed clusters (or integration with
native capabilites), like in case of vmware where it has its own
scheduling and HA behaviour?
Thanks!