Comment 11 for bug 1507568

Reviewed: https://review.openstack.org/271431
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=f0fa7312a024266cf6a51638a9ea772128bc3b89
Submitter: Jenkins
Branch: master

commit f0fa7312a024266cf6a51638a9ea772128bc3b89
Author: Zane Bitter <email address hidden>
Date: Fri Jan 22 12:10:40 2016 -0500

    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