Open Stack

Jim Fehlig wrote:
> Mark McLoughlin wrote:
>   
>> 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
>>   
>>     
>
> Yep, understood.  The others are populated from
> _inherit_properties_from_image() iiuc.
>   

Actually, with my changes, architecture, hypervisor_type, and vm_mode
are taken from request_spec['instance_properties']['system_meta'], which
is populated from the image properties in
_populate_instance_for_create(), called by _create_instance().

I don't see any problems with this approach though, and will update the
patch soon.

Thanks again,
Jim