Open Stack

2015-02-14 1:41 GMT+08:00 Nikola Đipanov <ndipanov at redhat.com>:

> On 02/12/2015 04:10 PM, Chris Friesen wrote:
> > On 02/12/2015 03:44 AM, Sylvain Bauza wrote:
> >
> >> Any action done by the operator is always more important than what the
> >> Scheduler
> >> could decide. So, in an emergency situation, the operator wants to
> >> force a
> >> migration to an host, we need to accept it and do it, even if it
> >> doesn't match
> >> what the Scheduler could decide (and could violate any policy)
> >>
> >> That's a *force* action, so please leave the operator decide.
> >
> > Are we suggesting that the operator would/should only ever specify a
> > specific host if the situation is an emergency?
> >
> > If not, then perhaps it would make sense to have it go through the
> > scheduler filters even if a host is specified.  We could then have a
> > "--force" flag that would proceed anyways even if the filters don't
> match.
> >
> > There are some cases (provider networks or PCI passthrough for example)
> > where it really makes no sense to try and run an instance on a compute
> > node that wouldn't pass the scheduler filters.  Maybe it would make the
> > most sense to specify a list of which filters to override while still
> > using the others.
> >
>
> Actually this kind of already happens on the compute node when doing
> claims. Even if we do force the host, the claim will fail on the compute
> node and we will end up with a consistent scheduling.
>


Agree with Nikola, the claim already checking that. And instance booting
must be failed if there isn't pci device. But I still think it should go
through the filters, because in the future we may move the claim into the
scheduler. And we needn't any new options, I didn't see there is any
behavior changed.


>
> This sadly breaks down for stuff that needs to use limits, as limits
> won't be set by the filters.
>
> Jay had a BP before to move limits onto compute nodes, which would solve
> this issue, as you would not need to run the filters at all - all the
> stuff would be known to the compute host that could then easily say
> "nice of you to want this here, but it ain't happening".
>
> It will also likely need a check in the retry logic to make sure we
> don't hit the host 'retry' number of times.
>
> N.
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150214/056e7150/attachment.html>