[openstack-dev] [Openstack-docs] question about the scheduler filters

Lorin Hochstein lorin at nimbisservices.com
Sat Aug 18 03:15:06 UTC 2012


Michael:

I proposed some additional docs here: https://review.openstack.org/11603

Take care,

Lorin
--
Lorin Hochstein
Lead Architect - Cloud Services
Nimbis Services, Inc.
www.nimbisservices.com




On Aug 17, 2012, at 10:42 AM, Michael J Fork <mjfork at us.ibm.com> wrote:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120817/6a1a91ec/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4897 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120817/6a1a91ec/attachment-0001.bin>


More information about the OpenStack-dev mailing list