The python interpreter is decided by otopi before ovirt-host-deploy can do anything.
So ovirt-host-deploy can't use the package manager to request otopi to install the missing python2-dnf package to support python2 execution since the missing package is needed to perform the install.
Since python2-dnf is not there but python3-dnf is, the only way to solve this (other than asking user to manually install it) is to run otopi with python3.
Wouldn't this break all our other code that's not yet python3? engine-setup, hosted-engine-setup?
engine-setup and hosted-engine-setup should be already python3 compatible. If not, we should fix. I don't consider this a blocker for oVirt 4 but it's the only way to solve cleanly bug #1297835 and keep Fedora compatibility in the future.
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
Now tried to reproduce bug 1297835 on fedora 24 and failed. Instead of failing, it succeeded, but used yum, not dnf. The result is that I have some transactions done using dnf and soem using yum.
Will try tomorrow to check more stuff, including reproduction on fedora 23, and the pending patch for current bug. Even if/when we merge it, we should be aware of the above current behavior - not sure that's intended on fedora 24, didn't check yet if it's documented anywhere.
Several patches were merged for this bug, and later reverted because they broke too much stuff. Moving back to NEW for now.
When we eventually solve this bug, we should probably:
1. Follow fedora python packaging guidelines, including package naming.
2. In particular build for both python2 and python3.
3. Allow using both the python2 and the python3 as applicable, with whatever Known Issues relevant at the time (e.g. bug 1297835 if using python2).
is not installed on the host, but bundled, copied and ran from a temporary directory.
If it turns out that a single such bundle can run under both python2 and python3, we might default to python3 on fedora >= 23.
*** Bug 1426484 has been marked as a duplicate of this bug. ***
Moving to QE.
Most relevant patches merged several months ago, last one  was merged Nov 22 2018.
Current behavior is:
On el7, build only for python2. Also there, the package 'otopi' does not exist anymore. Instead, we build python2-otopi, which also Provides: otopi.
On fedora, build and package for both python2 and python3, mostly following Fedora's guidelines.
The script 'otopi' defaults to python3, and uses it if it seems to work. Otherwise it falls back to 'python' (which is normally python2).
User can force a specific python exec using the env var OTOPI_PYTHON. E.g.:
 https://gerrit.ovirt.org/95649 core: Default to python3
This bugzilla is included in oVirt 4.3.0 release, published on February 4th 2019.
Since the problem described in this bug report should be
resolved in oVirt 4.3.0 release, it has been closed with a resolution of CURRENT RELEASE.
If the solution does not work for you, please open a new bug report.
Please review the doc text. I gleaned it from the summary and the description of the bug.
(In reply to Steve Goodman from comment #9)
> Please review the doc text. I gleaned it from the summary and the
> description of the bug.
Thanks, but the the description is quite old and irrelevant anymore, I hope.
At some point we indeed considered installing python2-dnf, but gave up on this.
Now otopi fully supports python3.
Also note that it will use python3 also on el7, if built for it, but we do not build for it. But in principle a developer can use it also on el7.
Changed the doc text accordingly. Please refine/polish it :-), thanks.
Or you can simply decide to not mention that and set doc text flag to '-'.
We already have , which is probably enough.
Changing doc_text flag to '-', as per comment 10.