Re: [openstack-dev] [nova] Question about force_host skip filters

[Jay Pipes]

On 02/18/2015 01:19 AM, Joe Cropper wrote:

Along these lines—dare I bring up the topic of providing an enhanced
mechanism to determine which filter(s) contributed to NoValidHost
exceptions?  Do others ever hear about operators getting this, and then
having no idea why a VM deploy failed?  This is likely another thread,
but thought I’d pose it here to see if we think this might be a
potential blueprint as well.


I think that's a great idea, Joe. Definitely something we should tackle 
in Gantt once the scheduler is broken out of Nova.


Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Question about force_host skip filters

[Joe Cropper]

+1 to using a filter property to indicate whether the filter needs to be run on 
force_hosts.  As others have said, there are certain cases that need to be 
checked even if the admin is trying to intentionally place a VM somewhere such 
that we can fail early vs. letting the hypervisor blow up on the request in the 
future (i.e., to help prevent the user from stepping on their own toes).  :-)

Along these lines—dare I bring up the topic of providing an enhanced mechanism 
to determine which filter(s) contributed to NoValidHost exceptions?  Do others 
ever hear about operators getting this, and then having no idea why a VM deploy 
failed?  This is likely another thread, but thought I’d pose it here to see if 
we think this might be a potential blueprint as well.

- Joe

> On Feb 17, 2015, at 10:20 AM, Nikola Đipanov  wrote:
> 
> On 02/17/2015 04:59 PM, Chris Friesen wrote:
>> On 02/16/2015 01:17 AM, Nikola Đipanov wrote:
>>> On 02/14/2015 08:25 AM, Alex Xu wrote:
>> 
 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.
>> 
>> Yeah, that makes sense.  Also, I think that flag should be an attribute
>> of the filter itself, so that people adding new filters don't need to
>> also add the filter to a list somewhere.
>> 
> 
> This is basically what I had in mind - definitely a filter property!
> 
> N.
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Question about force_host skip filters

[Nikola Đipanov]

On 02/17/2015 04:59 PM, Chris Friesen wrote:
> On 02/16/2015 01:17 AM, Nikola Đipanov wrote:
>> On 02/14/2015 08:25 AM, Alex Xu wrote:
> 
>>> 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.
> 
> Yeah, that makes sense.  Also, I think that flag should be an attribute
> of the filter itself, so that people adding new filters don't need to
> also add the filter to a list somewhere.
> 

This is basically what I had in mind - definitely a filter property!

N.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Question about force_host skip filters

[Lingxian Kong]

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 :
> On 02/14/2015 08:25 AM, Alex Xu wrote:
>>
>>
>> 2015-02-14 1:41 GMT+08:00 Nikola Đipanov > >:
>>
>> 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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Regards!
---
Lingxian Kong

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Question about force_host skip filters

[Chris Friesen]

On 02/16/2015 01:17 AM, Nikola Đipanov wrote:

On 02/14/2015 08:25 AM, Alex Xu wrote:



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.


Yeah, that makes sense.  Also, I think that flag should be an attribute of the 
filter itself, so that people adding new filters don't need to also add the 
filter to a list somewhere.


Have the default meaning be "can be skipped", then the critical ones can set it 
to "can't be skipped".


Chris


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Question about force_host skip filters

[Vishvananda Ishaya]

If this feature is going to be added, I suggest it gets a different name. Force 
host is an admin command to force an instance onto a host. If you want to make 
a user-facing command that respects filters, perhaps something like 
requested-host might work. In general, however, the name of hosts are not 
exposed to users, so this is moving far away from cloud and into virtualization 
management.

Vish

On Feb 12, 2015, at 1:05 AM, Rui Chen  wrote:

> Hi:
> 
>If we boot instance with 'force_hosts', the force host will skip all 
> filters, looks like that it's intentional logic, but I don't know the reason.
> 
>I'm not sure that the skipping logic is apposite, I think we should remove 
> the skipping logic, and the 'force_hosts' should work with the scheduler, 
> test whether the force host is appropriate ASAP. Skipping filters and 
> postponing the booting failure to nova-compute is not advisable.
> 
> On the other side, more and more options had been added into flavor, like 
> NUMA, cpu pinning, pci and so on, forcing a suitable host is more and more 
> difficult.
> 
> 
> Best Regards.
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Question about force_host skip filters

[Nikola Đipanov]

On 02/14/2015 08:25 AM, Alex Xu wrote:
> 
> 
> 2015-02-14 1:41 GMT+08:00 Nikola Đipanov  >:
> 
> 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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Question about force_host skip filters

[Alex Xu]

2015-02-14 1:41 GMT+08:00 Nikola Đipanov :

> 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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Question about force_host skip filters

[Nikola Đipanov]

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.

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Question about force_host skip filters

[Rui Chen]

Append blueprint link:
https://blueprints.launchpad.net/nova/+spec/verifiable-force-hosts

2015-02-13 10:48 GMT+08:00 Rui Chen :

> I agree with you @Chris
> '--force' flag is a good idea, it keep backward compatibility and
> flexibility.
> We can select whether the filters was applied for force_hosts.
> I will register blueprint to trace the feature.
>
> The 'force_hosts' feature is so age-old that I don't know how many users
> had used it.
> Like @Jay says. Removing it is once and for all idea, but I'm not sure
> that it's a suitable occasion.
>
> 2015-02-12 23:10 GMT+08:00 Chris Friesen :
>
>> 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.
>>
>> Chris
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Question about force_host skip filters

[Rui Chen]

I agree with you @Chris
'--force' flag is a good idea, it keep backward compatibility and
flexibility.
We can select whether the filters was applied for force_hosts.
I will register blueprint to trace the feature.

The 'force_hosts' feature is so age-old that I don't know how many users
had used it.
Like @Jay says. Removing it is once and for all idea, but I'm not sure that
it's a suitable occasion.

2015-02-12 23:10 GMT+08:00 Chris Friesen :

> 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.
>
> Chris
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Question about force_host skip filters

[Jay Pipes]

On 02/12/2015 10:10 AM, 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.


FWIW, I completely agree with you, Chris. The force_hosts functionality 
is antithetical to cloud provisioning, (IMO it's a relic of managed 
hosting operations thinking) and should be removed from the Nova 
scheduler's "feature" list.


Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Question about force_host skip filters

[Chris Friesen]

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.


Chris

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Question about force_host skip filters

[Gary Kotton]

I understand the fact that an opertaor can and should be able to place the VM 
where she/he wants. The VM should just adhere to the scheduling constraints :) 
(which are defined in the filters)
:)

From: Rui Chen mailto:chenrui.m...@gmail.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, February 12, 2015 at 1:51 PM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [nova] Question about force_host skip filters

 filters should be applied to the list of hosts that are in 'force_hosts'.

Yes, @Gray, it's my point.

Operator can live-migrate a instance to a specified host and skip filters,  
it's apposite and important, I agree with you.

But when we boot instance, we always want to launch a instance successfully or 
get a clear failure reason, if the filters are applied for the force host, 
operator maybe find out that he is doing something wrong at earlier time. For 
example, he couldn't boot a pci instance on a force host that don't own pci 
device.

and I don't think 'force_hosts' is operator action, the default value is 
'is_admin:True' in policy.json, but in some case the value may be changed so 
that the regular user can boot instance on specified host.

2015-02-12 17:44 GMT+08:00 Sylvain Bauza 
mailto:sba...@redhat.com>>:

Le 12/02/2015 10:05, Rui Chen a écrit :
Hi:

   If we boot instance with 'force_hosts', the force host will skip all 
filters, looks like that it's intentional logic, but I don't know the reason.

   I'm not sure that the skipping logic is apposite, I think we should remove 
the skipping logic, and the 'force_hosts' should work with the scheduler, test 
whether the force host is appropriate ASAP. Skipping filters and postponing the 
booting failure to nova-compute is not advisable.

On the other side, more and more options had been added into flavor, like 
NUMA, cpu pinning, pci and so on, forcing a suitable host is more and more 
difficult.


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.

-Sylvain



Best Regards.



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<mailto:openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Question about force_host skip filters

[Rui Chen]

 filters should be applied to the list of hosts that are in ‘force_hosts’.

Yes, @Gray, it's my point.

Operator can live-migrate a instance to a specified host and skip filters,
 it's apposite and important, I agree with you.

But when we boot instance, we always want to launch a instance successfully
or get a clear failure reason, if the filters are applied for the force
host, operator maybe find out that he is doing something wrong at earlier
time. For example, he couldn't boot a pci instance on a force host that
don't own pci device.

and I don't think 'force_hosts' is operator action, the default value is
'is_admin:True' in policy.json, but in some case the value may be changed
so that the regular user can boot instance on specified host.

2015-02-12 17:44 GMT+08:00 Sylvain Bauza :

>
> Le 12/02/2015 10:05, Rui Chen a écrit :
>
> Hi:
>
> If we boot instance with 'force_hosts', the force host will skip all
> filters, looks like that it's intentional logic, but I don't know the
> reason.
>
> I'm not sure that the skipping logic is apposite, I think we should
> remove the skipping logic, and the 'force_hosts' should work with the
> scheduler, test whether the force host is appropriate ASAP. Skipping
> filters and postponing the booting failure to nova-compute is not advisable.
>
>  On the other side, more and more options had been added into flavor,
> like NUMA, cpu pinning, pci and so on, forcing a suitable host is more and
> more difficult.
>
>
> 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.
>
> -Sylvain
>
>
>
>  Best Regards.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Question about force_host skip filters

[Sylvain Bauza]

Le 12/02/2015 10:05, Rui Chen a écrit :

Hi:

   If we boot instance with 'force_hosts', the force host will skip 
all filters, looks like that it's intentional logic, but I don't know 
the reason.


   I'm not sure that the skipping logic is apposite, I think we should 
remove the skipping logic, and the 'force_hosts' should work with the 
scheduler, test whether the force host is appropriate ASAP. Skipping 
filters and postponing the booting failure to nova-compute is not 
advisable.


On the other side, more and more options had been added into 
flavor, like NUMA, cpu pinning, pci and so on, forcing a suitable host 
is more and more difficult.




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.

-Sylvain




Best Regards.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Question about force_host skip filters

[Gary Kotton]

Hi,
I think that the filters should be applied to the list of hosts that are in 
'force_hosts'. I am not sure if this is what you are suggesting. If this is not 
then case then it sounds like a bug.
Thanks
Gary

From: Rui Chen mailto:chenrui.m...@gmail.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, February 12, 2015 at 11:05 AM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [nova] Question about force_host skip filters

Hi:

   If we boot instance with 'force_hosts', the force host will skip all 
filters, looks like that it's intentional logic, but I don't know the reason.

   I'm not sure that the skipping logic is apposite, I think we should remove 
the skipping logic, and the 'force_hosts' should work with the scheduler, test 
whether the force host is appropriate ASAP. Skipping filters and postponing the 
booting failure to nova-compute is not advisable.

On the other side, more and more options had been added into flavor, like 
NUMA, cpu pinning, pci and so on, forcing a suitable host is more and more 
difficult.


Best Regards.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Question about force_host skip filters

[Rui Chen]

Hi:

   If we boot instance with 'force_hosts', the force host will skip all
filters, looks like that it's intentional logic, but I don't know the
reason.

   I'm not sure that the skipping logic is apposite, I think we should
remove the skipping logic, and the 'force_hosts' should work with the
scheduler, test whether the force host is appropriate ASAP. Skipping
filters and postponing the booting failure to nova-compute is not advisable.

On the other side, more and more options had been added into flavor,
like NUMA, cpu pinning, pci and so on, forcing a suitable host is more and
more difficult.


Best Regards.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev