[openstack-dev] [Nova] Hosts within two Availability Zones : possible or not ?

Day, Phil philip.day at hp.com
Wed Apr 9 10:20:30 UTC 2014


> -----Original Message-----
> From: Chris Friesen [mailto:chris.friesen at windriver.com]
> Sent: 08 April 2014 15:19
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [Nova] Hosts within two Availability Zones :
> possible or not ?
> 
> On 04/08/2014 07:25 AM, Jay Pipes wrote:
> > On Tue, 2014-04-08 at 10:49 +0000, Day, Phil wrote:
> >> On a large cloud you're protect against this to some extent if the
> >> number of servers is >> number of instances in the quota.
> >>
> >> However it does feel that there are a couple of things missing to
> >> really provide some better protection:
> >>
> >> -         A quota value on the maximum size of a server group
> >> -         A policy setting so that the ability to use service-groups
> >> can be controlled on a per project basis
> >
> > Alternately, we could just have the affinity filters serve as
> > weighting filters instead of returning NoValidHosts.
> >
> > That way, a request containing an affinity hint would cause the
> > scheduler to prefer placing the new VM near (or not-near) other
> > instances in the server group, but if no hosts exist that meet that
> > criteria, the filter simply finds a host with the most (or fewest, in
> > case of anti-affinity) instances that meet the affinity criteria.
> 
> I'd be in favor of this.   I've actually been playing with an internal
> patch to do both of these things, though in my case I was just doing it via
> metadata on the group and a couple hacks in the scheduler and the compute
> node.
> 
> Basically I added a group_size metadata field and a "best_effort" flag to
> indicate whether we should error out or continue on if the policy can't be
> properly met.
> 
I like the idea of the user being able to say if the affinity should be treated as a filter or weight.

In terms of group_size I'd want to able to impose a limit on that as an operator, not just have it in the control of the user (hence the quota idea)




More information about the OpenStack-dev mailing list