<html><body>
<p><font size="2" face="sans-serif">This is a great summary of the different Filters and their capabilities and would be a great addition to the docs.  I had searched for this detail before and ultimately ended up looking through code.  In particular, two places:</font><br>
<br>
<a href="http://docs.openstack.org/essex/openstack-compute/admin/content/scheduler-filters.html"><font size="3" color="#0000FF" face="serif"><u>http://docs.openstack.org/essex/openstack-compute/admin/content/scheduler-filters.html</u></font></a><font size="3" face="serif"> </font><br>
<a href="http://docs.openstack.org/developer/nova/devref/filter_scheduler.html"><font size="3" color="#0000FF" face="serif"><u>http://docs.openstack.org/developer/nova/devref/filter_scheduler.html</u></font></a><font size="3" face="serif"> </font><font size="2" face="sans-serif"><br>
<br>
On a similar thread, a one sentence summary of the filters in the docs guide on the parent "Filters" page would be very helpful.</font><br>
<br>
<font size="2" face="sans-serif">Michael<br>
<br>
-------------------------------------------------<br>
Michael Fork<br>
Cloud Architect, Emerging Solutions<br>
IBM Systems & Technology Group</font><br>
<br>
<tt><font size="2">Mark McLoughlin <markmc@redhat.com> wrote on 08/17/2012 07:42:17 AM:<br>
<br>
> From: Mark McLoughlin <markmc@redhat.com></font></tt><br>
<tt><font size="2">> To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>, </font></tt><br>
<tt><font size="2">> Date: 08/17/2012 07:46 AM</font></tt><br>
<tt><font size="2">> Subject: Re: [openstack-dev] question about the scheduler filters</font></tt><br>
<tt><font size="2">> <br>
> On Thu, 2012-08-16 at 20:22 -0600, Jim Fehlig wrote:<br>
> > While merging the recent ComputeFilter additions with the ArchFilter, I<br>
> > spent too much time agonizing over the name ArchFilter, which I was now<br>
> > making filter on more than just architecture.  ComputeCapabilitiesFilter<br>
> > seems like better name, but this is already taken.<br>
> > <br>
> > Looking at ComputeCapabilitiesFilter again, I realize it is filtering on<br>
> > some of the same properties as the combined ArchFilter [1], but from a<br>
> > different source.  IIUC, ComputeCapabilitiesFilter filters on properties<br>
> > that originate from the instance type/flavor.  The combined ArchFilter<br>
> > filters on properties that originate from the image.  It seems this<br>
> > could be a source of confusion for users, but at the same time seems<br>
> > necessary, particularly for properties such as architecture, preferred<br>
> > hypervisor and virtual machine mode, which I tend to think are<br>
> > properties of an image more so than a flavor.  E.g. I could select my<br>
> > "Xen arm" flavor, but unless I also selected a "Xen arm" image, I could<br>
> > have an instance that doesn't boot.<br>
> > <br>
> > Do folks have any issues with filters using both image and flavor<br>
> > properties?  Being relatively new here, this may very well be intended<br>
> > :).  If so, I'd like to change the name of ArchFilter to better reflect<br>
> > its new additions.  What do you think of ImagePropertiesFilter?  It<br>
> > filters hosts based on compute properties defined on the image.  Or<br>
> > ImageComputePropertiesFilter, to accommodate a future class of<br>
> > filterable image properties?<br>
> <br>
> Ok, stepping back for a minute. Before your patch, we had:<br>
> <br>
> ComputeFilter<br>
>   simply matches enabled compute hosts<br>
> <br>
> ArchFilter<br>
>   match the architecture from the image properties against the compute <br>
>   node's permitted_instance_types<br>
> <br>
>   it's using instance_properties['architecture'] which is taken from the<br>
>   image's architecture property in _create_instance() - see how<br>
>   base_options is populated<br>
> <br>
>   permitted_instance_types is just the list of guest archs<br>
> <br>
> ComputeCapabilitiesFilter<br>
>   matches properties defined in an instance type's extra specs against <br>
>   compute capabilities<br>
> <br>
> AggregateInstanceExtraSpecsFilter<br>
>   matches properties defined in an instance type's extra specs against<br>
>   admin-defined properties on a host aggregate<br>
> <br>
> And then you added:<br>
> <br>
>   match the arch, hypervisor type and vm type from the image properties <br>
>   against those supported by the compute node<br>
> <br>
> It looks to me like what you've added is a complete superset of<br>
> ArchFilter - i.e. if you just specify the architecture property on the<br>
> image, the behaviour should be identical.<br>
> <br>
> So, IMHO, it should be fine to move your new matching into<br>
> ImagePropertiesFilter and just delete ArchFilter.<br>
> <br>
> Cheers,<br>
> Mark.<br>
> <br>
> <br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.org<br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> <br>
</font></tt></body></html>