[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
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.
> -----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
> 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  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  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.
> > 
> > https://blueprints.launchpad.net/nova/+spec/put-host-manager-instance-
> > 
> > https://specs.openstack.org/openstack/nova-
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
More information about the OpenStack-operators