The python2-oslo-concurrency RPM requires both Python 2 and Python 3.
Except in very special circumstances, there is no need for one package
to drag in both Python stacks. Usually, this is a packaging error: for
example, a stray "/usr/bin/python" shebang in a Python 3 package can
introduce a Python 2 dependency.
Please split your package, or remove the stray dependencies.
There is a section on shebangs in the Python RPM Porting Guide 
which covers this issue.
It's ok to do this in Rawhide only, however, it would be greatly
appreciated if you could push it to Fedora 24 as well.
If anything is unclear, or if you need any kind of assistance, you can
ask on IRC (#fedora-python on Freenode), or reply here. We'll be happy
to help investigating or fixing this issue!
PS: It would be great if you could also change the name of the subpackage `python-oslo-concurrency-tests` to start with `python2-`, so that it follows the naming convention. You can use the tags Provides: and Obsoletes: so that basically nothing will change for the users.
Fixed in rawhide, default binary is still python2 as python3 is not yet production-ready according upstream.
Thank you, Haïkel!
We've been tracking https://wiki.openstack.org/wiki/Python3 where oslo-concurrency is green. Is there some better place where OpenStack upstream says if Python 3 support is ready?
Sadly, no. Victor Stinner has sent recently a message on the openstack-dev mailing list tracking efforts to convert core services but it's unlikely to be finished for Newton (release schedule for late october). Python3 support is not that well-tested for the other projects.
Regardless, I'll make sure that we ship all OpenStack clients with python3 variant so that we can help detecting flaws and get them fixed upstream.
During the Tokyo Summit, vendors agreed to target Python 3.5 as the min runtime for the big jump, but it's unlikely to happen before late 2017 so for the P release (Not N, nor O).
Fedora ships with latest stable (Mitaka) versions of oslo libs and clients, and considering upstream/downstream CI, I wouldn't try Newton as they're utterly broken.
The good news is that most OpenStack clients will drop their custom binary clients to ship plugins for the generic OpenStackClient and simple python libraries. So by then, we'll just have to fix python-openstackclient to use python3 variant by default.
For now, I'm reviewing the python3 tracker and will fix/close as many tickets as possible (OpenStack or non-OpenStack just for the sake of getting good karma :) ).
Alright! Thank you for the information, and for all your hard work!