Open Stack

Good idea, it really makes sense. Just like the option
'run_filter_once_per_request' does.

2015-02-16 15:17 GMT+08:00 Nikola Đipanov <ndipanov at redhat.com>:
> On 02/14/2015 08:25 AM, Alex Xu wrote:
>>
>>
>> 2015-02-14 1:41 GMT+08:00 Nikola Đipanov <ndipanov at redhat.com
>> <mailto: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.
>>
>
> I think that it's not as simple as just re-running all the filters. When
> we want to force a host - there are certain things we may want to
> disregard (like aggregates? affinity?) that the admin de-facto overrides
> by saying they want a specific host, and there are things we definitely
> need to re-run to set the limits and for the request to even make sense
> (like NUMA, PCI, maybe some others).
>
> So what I am thinking is that we need a subset of filters that we flag
> as - "we need to re-run this even for force-host", and then run them on
> every request.
>
> thoughts?
>
> N.
>
>>
>>
>>     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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> __________________________________________________________________________
>> 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
>>
>
>
> __________________________________________________________________________
> 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



-- 
Regards!
-----------------------------------
Lingxian Kong