Comment 21 for bug 1719333

Reviewed: https://review.openstack.org/533038
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=f965ff615e3d4df0a2b38477d5441604cd0b85e5
Submitter: Zuul
Branch: master

commit f965ff615e3d4df0a2b38477d5441604cd0b85e5
Author: Zane Bitter <email address hidden>
Date: Thu Jan 11 21:44:27 2018 -0500

    Eliminate errors getting TemplateResource OS::stack_id

    We want to avoid making an RPC call to get the OS::stack_id output in order
    to calculate the reference ID of a TemplateResource whenever possible -
    which should be most of the time given the limited use of this feature in
    the wild - since this happens virtually every time we load the stack.
    Previously, we were doing this by trying to load the template from the
    parent stack's environment, and combine it with the stored parameters
    (using live parameter values caused failures). However, this resulted in
    failures in the case that the template in the parent stack's environment
    differed from the one that was last used to update the resource if the
    parameter schema had been modified in an incompatible way.

    It transpires that we already determine what outputs are available at
    object instantiation time in order to populate the attributes_schema. So we
    can just use the attributes schema to infer the existence or otherwise of
    the output without doing any other calculation in get_reference_id() that
    could cause errors.

    This method doesn't fail-safe, in the sense that if there are any errors
    then we end up with an empty schema and won't fall back to making the RPC
    call. However, if there are any errors then probably all bets are off for
    the reference ID anyway. In common with the old method, it also has the
    drawback of using the latest template rather than the existing one
    (although again, once you do an update removing the OS::stack_id output
    then all bets are off in terms of continuing to see that value as the
    reference ID).

    Unlike the previous method, this doesn't take into account disabled outputs
    (since calculating conditions requires access to the parameters, which were
    the cause of the problem). Also, the code that calculates the attributes
    schema doesn't use a proper API but hackily dives into the raw template
    data, and fixing it would raise all of the same issues that we've had with
    trying to load the template properly here. So we are kicking the can down
    the road a bit or, alternatively, consolidating our issues into a single
    place, depending on your point of view.

    Change-Id: Ic63fe290249dba5bc00abbde1f4df608181d6a9c
    Closes-Bug: #1742646
    Related-Bug: #1719333