Open Stack

+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 <ndipanov at redhat.com> 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-request at lists.openstack.org <mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <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/20150218/0122782e/attachment.html>