commit a1a335f19a986a593487a802d7b9448f7efc5bab
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.
Reviewed: https:/ /review. openstack. org/569218 /git.openstack. org/cgit/ openstack/ nova/commit/ ?id=a1a335f19a9 86a593487a802d7 b9448f7efc5bab
Committed: https:/
Submitter: Zuul
Branch: master
commit a1a335f19a986a5 93487a802d7b944 8f7efc5bab
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
Partial-Bug: #1737465