[Openstack-operators] [nova] Does anyone use the TypeAffinityFilter?

Matt Riedemann mriedemos at gmail.com
Fri Apr 7 03:21:23 UTC 2017

On 4/6/2017 7:34 PM, Matt Riedemann wrote:
> While working on trying to trim some RPC traffic between compute nodes
> and the scheduler [1] I came across the TypeAffinityFilter which relies
> on the instance.instance_type_id field, which is the original flavor.id
> (primary key) that the instance was created with on a given host. The
> idea being if I have an instance with type 20 on a host, then I can't
> schedule another host with type 20 on it.

Oops, "then I can't schedule another *instance* with type 20 on it (the 
same host)".

> The issue with this is that flavors can't be updated, they have to be
> deleted and recreated. This is why we're changing the flavor
> representation in the server response details in Pike [2] because the
> instance.instance_type_id can point to a flavor that no longer exists,
> so you can't look up the details on the flavor that was used to create a
> given instance via the API (you could figure it out in the database, but
> that's no fun).
> So the big question is, does anyone use this filter and if so, have you
> already hit the issue described here and if so, how are you working
> around it? If no one is using it, I'd like to deprecate it.
> [1]
> https://blueprints.launchpad.net/nova/+spec/put-host-manager-instance-info-on-a-diet
> [2]
> https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/instance-flavor-api.html




More information about the OpenStack-operators mailing list