Comment 19 for bug 1684272

So I did a little digging locally, with a heatclient modified to show the time delta between IN_PROGRESS and COMPLETE:

http://paste.openstack.org/show/608682/

The results are interesting, in that the ServiceChain seems effectively serialized, despite setting concurrent: true - we put all the nested stacks IN_PROGRESS then get a serialized series of events while either RPC or the heat scheduler catches up and works through them not very concurrently, e.g compare:

0:00:08 [overcloud-ControllerServiceChain-zdhipc4gtgfs-ServiceChain-cybm26brd2kv.4]: CREATE_COMPLETE state changed

0:02:16 [overcloud-ControllerServiceChain-zdhipc4gtgfs-ServiceChain-cybm26brd2kv.80]: CREATE_COMPLETE state changed

The fastest nested stack completed in 8 seconds, then longest took well over 2 minutes, but the longest elapsed time is related to a nested stack that took zero seconds to actually create:

(undercloud) [stack@undercloud ~]$ openstack stack resource show 9e3270bc-603b-46d7-81ad-caa63c912395 80 | grep physical_resource_id
| physical_resource_id | 49f032a0-7ea2-4e8c-8633-34a19b16036d |

(undercloud) [stack@undercloud ~]$ openstack stack event list 49f032a0-7ea2-4e8c-8633-34a19b16036d
0:00:00 [overcloud-ControllerServiceChain-zdhipc4gtgfs-ServiceChain-cybm26brd2kv-80-vcwt5iqm4rvy]: CREATE_IN_PROGRESS Stack CREATE started
0:00:00 [overcloud-ControllerServiceChain-zdhipc4gtgfs-ServiceChain-cybm26brd2kv-80-vcwt5iqm4rvy]: CREATE_COMPLETE Stack CREATE completed successfully