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