Comment 6 for bug 1837877

This is indeed an API response. I have researched this and I think we're safe (from a provider perspective):

{'message': "internal error: process exited while connecting to monitor: lc=,keyid=masterKey0,iv=jHURYcYDkXqGBu4pC24bew==,format=base64 -drive 'file=rbd:volumes/volume-41553c15-6b12-4137-a318-7caf6a9eb44c:id=cinder:auth_supported=cephx\\;none:mon_host=172.24.0.56\\:6789", 'code': 500, 'created': '2019-07-25T07:27:21Z'}

There are two concerns here:

"lc=,keyid=masterKey0,iv=jHURYcYDkXqGBu4pC24bew==,format=base64"
There is a generated key for every single VM booted inside QEMU, this points to that specific key ID and includes the initialization vendor (iv). It does not include the key that decrypts the cephx secret

"file=rbd:volumes/volume-41553c15-6b12-4137-a318-7caf6a9eb44c:id=cinder:auth_supported=cephx\\;none:mon_host=172.24.0.56\\:6789"
This actually is a bit more concerning because it leaks out the IP address of the Ceph monitor. In our case, it lives in an entirely different network that cannot be accessed but that's not the case for everyone...

"Timed out during operation: cannot acquire state change lock (held by monitor=remoteDispatchDomainCreateWithFlags)"
This is a libvirt exception that is getting bubbled up.

IMHO: We should *never* leak exceptions that bubble up in this way to the API layer, especially to a non-admin user.