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

Juvonen, Tomi (Nokia - FI/Espoo) tomi.juvonen at nokia.com
Tue Apr 11 06:11:27 UTC 2017


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:mriedemos at gmail.com]
> Sent: Friday, April 07, 2017 6:21 AM
> To: openstack-operators at lists.openstack.org
> 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
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


More information about the OpenStack-operators mailing list