summaryrefslogtreecommitdiff
path: root/heat/rpc
diff options
context:
space:
mode:
authorZane Bitter <zbitter@redhat.com>2016-01-22 12:10:40 -0500
committerZane Bitter <zbitter@redhat.com>2016-01-22 12:10:40 -0500
commitf0fa7312a024266cf6a51638a9ea772128bc3b89 (patch)
tree9e263c7cfedb5323cba7ce8a406d51d10f98e48d /heat/rpc
parentbc4e5ffd15b7b2dbd6fb7272dfdb817d74ae3397 (diff)
downloadheat-f0fa7312a024266cf6a51638a9ea772128bc3b89.tar.gz
Don't calculate attributes for metadata request
The RPC API call describe_stack_resource is used by two separate ReST API calls and one CFN API call: Resource.show and Resource.metadata in heat-api and StackController.describe_stack_resource. The metadata call in particular throws away all of the results of the describe_stack_resource output except for the metadata itself. Either this call or the cfn one (depending on configuration) is also used very, very often: it's the one that every instance running os-collect-config polls for information about software deployments (so, to a first approximation, every server in every stack will be calling this once every 30s). Since blueprint detailed-resource-show merged in 6d8a5cb35cec81b23a71e8c6fa692f8e7b4dca1c, every call to the RPC describe_stack_resource API has resulted in Heat fetching the attribute values for every single attribute in the resource from its corresponding OpenStack API (including those calls originating from a request for just the metadata, or from the cfn API which similarly discards the attribute values). This is insanely inefficient (we're making OpenStack API calls to fetch data that we don't even return to the user). It's quite possibly a substantial part of the reason why we've had so much difficulty scaling up Heat to deal with large numbers of servers polling it for config. And it tends to leave a lot of annoying warnings in the log messages, not just of Heat but also the other services it is polling, since polling the metadata generally happens using the heat_stack_user's credentials, not those of the actual owner of the resource - it can't actually find the resource and returns a 404. The fix is to change the default "with_attr" value in the RPC client to False, and only pass None (the previous default) or a list of extra attributes to include in the specific case where the ReST API will actually return the attribute values to the user and not just discard them. Since the server previously treated any falsey value for the parameter (e.g. None, False or []) as equivalent, and since nothing was previously passing False, this change is safe to backport to stable branches. The api and engine can be updated in any order without change in behaviour until a new api is talking to a new server (at which point the bug is fixed). This change also updates the ReST API unit tests to accurately reflect the data returned from the engine. Change-Id: Ifffeaa552d3205ca06a79adda09d35a77099a2bf Closes-Bug: #1507568
Diffstat (limited to 'heat/rpc')
-rw-r--r--heat/rpc/client.py2
1 files changed, 1 insertions, 1 deletions
diff --git a/heat/rpc/client.py b/heat/rpc/client.py
index daabc3dde..fdc73e5f9 100644
--- a/heat/rpc/client.py
+++ b/heat/rpc/client.py
@@ -432,7 +432,7 @@ class EngineClient(object):
sort_dir=sort_dir))
def describe_stack_resource(self, ctxt, stack_identity, resource_name,
- with_attr=None):
+ with_attr=False):
"""Get detailed resource information about a particular resource.
:param ctxt: RPC context.