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
6d8a5cb35c, 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
(cherry picked from commit f0fa7312a0)
a3bc0962a9