Code review comment for lp://qastaging/~usc-isi/nova/extra_specs_sched

> The code as is looks good to me, but I'm a bit curious about the approach
> here.
>
> What I mean is that this seems like a very important feature if you want to
> run heterogeneous environments. In fact, I think it's such an important
> feature that it is almost beyond the scope of a single scheduler.
>
> Have we considered the fact that every scheduler might actually need to behave
> this way?
>
> Perhaps an alternate approach would be to somehow define (a flag?) to indicate
> that the zone itself is heterogeneous.
>
> What we have in this code is a simple random scheduler for a heterogeneous
> environment, and while that is progress, I think all schedulers should be made
> aware of heterogeneous environments.

The real work to support heterogeneity was implemented by changes to the InstanceTypeFilter. That functionality was added in a previous merge proposal <https://code.launchpad.net/~usc-isi/nova/instance_type_extra_specs/+merge/62728>.

Any scheduler that respects capabilities will automatically support heterogeneity. If the architecture request is conveyed through instance types, then any scheduler using the existing InstanceTypeFilter filter will have support for heterogeneity. The intent of the scheduler implementation here is just to show an example of how the filter can be used to support the heterogeneity.

It's not obvious to me how to support this in a more generic way. Alternatively, we could change the default filter in the zone_aware_scheduler to use the InstanceTypeFilter. Clients could opt not to use it by subclassing the filter and overriding the behavior. Would that be better?