Comment 3 for bug 1306743

Currently every os-collect-config metadata poll will cause the entire stack to be parsed and loaded, but ultimately just returns the results of a list-deployments query. This is not scalable in the long term.

The chain is currently this for the default Server software_config_transport: POLL_SERVER_CFN:
occ -> heat-api-cfn(resource-show) -> heat-engine(parse the stack to get the server resource) -> heat-api(deployments-list) -> heat-engine(metadata_software_deployments)

And is no better for Server software_config_transport: POLL_SERVER_HEAT
occ -> heat-api(resource-show) -> heat-engine(parse the stack to get the server resource) -> heat-api(deployments-list) -> heat-engine(metadata_software_deployments)

What we need (and what I've been working towards) is a software_config_transport: POLL_DEPLOYMENTS:
occ -> heat-api(deployments-list) -> heat-engine(metadata_software_deployments)

I'll continue to work towards POLL_DEPLOYMENTS, but Zane's optimisation process would still be helpful. If the first API calls could be directed to the heat-engine which is already IN_PROGRESS with that stack then we could find a way of reusing the existing stack rather than reloading it from the database.