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.
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: cfn(resource- show) -> heat-engine(parse the stack to get the server resource) -> heat-api( deployments- list) -> heat-engine( metadata_ software_ deployments)
occ -> heat-api-
And is no better for Server software_ config_ transport: POLL_SERVER_HEAT resource- show) -> heat-engine(parse the stack to get the server resource) -> heat-api( deployments- list) -> heat-engine( metadata_ software_ deployments)
occ -> heat-api(
What we need (and what I've been working towards) is a software_ config_ transport: POLL_DEPLOYMENTS: deployments- list) -> heat-engine( metadata_ software_ deployments)
occ -> heat-api(
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.