commit bfb9d3f179607c25f91d77585f97df6d0704c253
Author: Matt Riedemann <email address hidden>
Date: Thu May 17 14:36:23 2018 -0400
Avoid unnecessary joins in HostManager._get_instances_by_host
While getting a HostState object for a given compute node during
scheduling, if the HostState does not have its instance info
set, either because it's out of date or because config option
"track_instance_changes" is False, the HostManager still pulls
the list of instances for that host from the database and stores
it in HostState.instances.
This is *only* used (in-tree) by the affinity filters and even
then the only thing those filters use from HostState.instances
is the set of keys from the dict, which is the list of instance
UUIDs on a given host. The actual Instance objects aren't used
at all. See blueprint put-host-manager-instance-info-on-a-diet
for more details on that.
The point of this change, is that when we go to pull the set
of instances from the database for a given host, we don't need
to join on the default columns (info_cache and security_groups)
defined in the _instance_get_all_query() method in the DB API.
This should be at least some minor optimization in scheduling
for hosts that have several instances on them in a large cloud.
As noted in the comment in the code, any out of tree filters
that rely on using the info_cache or security_groups from the
instance are now going to be hit with a lazy-load penalty
per instance, but we have no contract on out of tree filters
so if this happens, the people maintaining said filters can
(1) live with it (2) fork the HostManager code or (3) upstream
their filter so it's in-tree.
A more impactful change would be to refactor
HostManager._get_host_states to bulk query the instances on
the given set of compute nodes in a single query per cell. But
that is left for a later change.
Change-Id: Iccefbfdfa578515a004ef6ac718bac1a49d5c5fd
Partial-Bug: #1737465
(cherry picked from commit a1a335f19a986a593487a802d7b9448f7efc5bab)
Reviewed: https:/ /review. openstack. org/570083 /git.openstack. org/cgit/ openstack/ nova/commit/ ?id=bfb9d3f1796 07c25f91d77585f 97df6d0704c253
Committed: https:/
Submitter: Zuul
Branch: stable/queens
commit bfb9d3f179607c2 5f91d77585f97df 6d0704c253
Author: Matt Riedemann <email address hidden>
Date: Thu May 17 14:36:23 2018 -0400
Avoid unnecessary joins in HostManager. _get_instances_ by_host
While getting a HostState object for a given compute node during instance_ changes" is False, the HostManager still pulls instances.
scheduling, if the HostState does not have its instance info
set, either because it's out of date or because config option
"track_
the list of instances for that host from the database and stores
it in HostState.
This is *only* used (in-tree) by the affinity filters and even manager- instance- info-on- a-diet
then the only thing those filters use from HostState.instances
is the set of keys from the dict, which is the list of instance
UUIDs on a given host. The actual Instance objects aren't used
at all. See blueprint put-host-
for more details on that.
The point of this change, is that when we go to pull the set get_all_ query() method in the DB API.
of instances from the database for a given host, we don't need
to join on the default columns (info_cache and security_groups)
defined in the _instance_
This should be at least some minor optimization in scheduling
for hosts that have several instances on them in a large cloud.
As noted in the comment in the code, any out of tree filters
that rely on using the info_cache or security_groups from the
instance are now going to be hit with a lazy-load penalty
per instance, but we have no contract on out of tree filters
so if this happens, the people maintaining said filters can
(1) live with it (2) fork the HostManager code or (3) upstream
their filter so it's in-tree.
A more impactful change would be to refactor ._get_host_ states to bulk query the instances on
HostManager
the given set of compute nodes in a single query per cell. But
that is left for a later change.
Change-Id: Iccefbfdfa57851 5a004ef6ac718ba c1a49d5c5fd 93487a802d7b944 8f7efc5bab)
Partial-Bug: #1737465
(cherry picked from commit a1a335f19a986a5