Sandro, FYI we are not against cinderlib integration, more than we are upgrade 4.3 to 4.4 due movement to cinderlib. But (!) current Managed Storage Block realization support only krbd (kernel RBD) driver - it's also not a option, because kernel client is always lagging behind librbd, and every update\bugfix we should reboot whole host instead simple migration of all VMs and then migrate it back. Also with krbd host will be use kernel page cache, and will not be unmounted if VM will crash (qemu with librbd is one userland process).

So for me current situation look like this: 1. We update deprecated OpenStack code? Why, Its for delete?.. Nevermind, just update this code... 2. Hmm... auth tests doesn't work, to pass test just disable any OpenStack project_id related things... and... Done... 3. I don't care how current cinder + qemu code works, just write new one for linux kernel, it's optimal to use userland apps, just add wrappers (no, it's not); 4. Current Cinder integration require zero configuration on oVirt hosts. It's lazy, why oVirt administrator do nothing? just write manual how-to install packages - oVirt administrators love anything except "reinstall" from engine (no, it's not); 5. We broke old code. New features is "Cinderlib is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs), might not be functionally complete, and Red Hat does not recommend to use them for production". 6. Oh, we broke old code. Let's deprecate them and close PRODUCTION issues (we didn't see anything). And again, we are not hate new cinderlib integration. We just want that new technology don't break all PRODUCTION clustes. Almost two years ago I write on this issue https://bugzilla.redhat.com/show_bug.cgi?id=1539837#c6 about "before deprecate, let's help to migrate". For now I see that oVirt totally will disable QEMU RBD support and want to use kernel RBD module + python os-brick + userland mappers + shell wrappers. Thanks, I hope I am writing this for a reason and it will help build bridges between the community and the developers. We have been with oVirt for almost 10 years and now it is a crossroads towards a different virtualization manager. k So I see only regressions for now, hope we'll found some code owner who can catch this oVirt 4.4 only bugs.