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
-- Thanks, Matt _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
