Comment 1 for bug 1382300

Hmm, so a little history - when this was proposed to tempest, it was working fine for a while, then something changed in cinder such that, for some reason, it seems the volume attachment to the instance was not working, in which case the WaitCondition posts failure back to heat as it can't find the expected block device.

I was never able to reproduce this locally, it's always worked fine, so as you say it may be some gate-specific cinder->nova interaction.

As you say it's probably the backup restore part where Swift, Cinder and Nova all have to play nice together otherwise we'll fail. IIRC this scenario is not tested anywhere else so possibly we're just the messenger here for bugginess in other services.

Happy to skip this if it gets our job voting, but I would like to bottom out the reason why this has turned flaky since I first wrote it.

I was discussing with dkranz about a "soft failure" mode, where rather than skipping a test, we run it, collect stats about it's pass/fail and pass even if it fails. E.g a SKIP_FAIL assertion on test failure based on some decorator or something - is this something we could implement for our in-tree tests?