This appears to be another situation (also see [1]) where, during the upgrade, pacemaker is starting cinder-volume too soon. In [1] the problem was due to the DB not being migrated before starting cinder-volume.
Here, the problem is scenario002 is now testing encrypted volumes, and the upgrade process adds the barbican service. puppet-cinder is responsible for creating the necessary entries in cinder.conf, and it does, but this is happening _after_ pacemaker started cinder-volume. Once again, cinder-volume is starting up too soon, before puppet-cinder has had a chance to prepare the new configuration.
This appears to be another situation (also see [1]) where, during the upgrade, pacemaker is starting cinder-volume too soon. In [1] the problem was due to the DB not being migrated before starting cinder-volume.
Here, the problem is scenario002 is now testing encrypted volumes, and the upgrade process adds the barbican service. puppet-cinder is responsible for creating the necessary entries in cinder.conf, and it does, but this is happening _after_ pacemaker started cinder-volume. Once again, cinder-volume is starting up too soon, before puppet-cinder has had a chance to prepare the new configuration.
[1] https:/ /bugs.launchpad .net/tripleo/ +bug/1691851