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