Thanks Matt, Affinity and anti-affinity for an instance sure are basic Telco requirements. Instead of TypeAffinityFilter one is able to use the server-groups (ServerGroupAffinityFilter and ServerGroupAntiAffinityFilter). Just that you can only define server-group for an instance when creating a server, so it causes problems when the TypeAffinityFilter is deprecated and you happened to use it. Already existing instances are properly placed, but if the server-group information is not added to them, the new instances using server-groups instead might land to hypervisor that is against the existing instance placement according to TypeAffinityFilter.
I have internally checked that we should not be using TypeAffinityFilter. Br, Tomi > -----Original Message----- > From: Matt Riedemann [mailto:[email protected]] > Sent: Friday, April 07, 2017 6:21 AM > To: [email protected] > Subject: Re: [Openstack-operators] [nova] Does anyone use the > TypeAffinityFilter? > > 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators _______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
