If you pass a volume ID as a stack parameter to be used for a OS::Cinder::VolumeAttachment resource, any server replacement will cause the stack to hang. The reason is that when we detach the volume, we then check if the volume is available. But at that point, the volume has already been reattached to the other server, so we spin forever waiting for the status to change. The workaround is to use block_device_mapping instead, or to manage the volume in the stack (I think?).
That bz was already assigned and Rabi is working on it. no reasons for me to assign it to a DFG:DF moving to cloud-apps
Verified on puddle 2018-12-04.1
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:0076