Bug 1316950

Summary:	[RFE][CodeChange] - OTOPI should use python3 interpreter on Fedora
Product:	[oVirt] otopi	Reporter:	Sandro Bonazzola <sbonazzo>
Component:	Core	Assignee:	Yedidyah Bar David <didi>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Lukas Svaty <lsvaty>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	master	CC:	bugs, dfediuck, didi, lsvaty, sgoodman, weiwang, yturgema
Target Milestone:	ovirt-4.3.0	Keywords:	CodeChange, FutureFeature
Target Release:	---	Flags:	rule-engine: ovirt-4.3+ lsvaty: testing_plan_complete- ylavi: planning_ack+ rule-engine: devel_ack+ pstehlik: testing_ack+
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:	The oVirt Task Oriented Pluggable Installer (OTOPI) uses the python3 interpreter when available, which is the default case on Fedora. Please note that Fedora support is still considered to be in "Tech Preview" in oVirt.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-02-13 07:43:04 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Integration	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1365751
Bug Blocks:	1460625

Description Sandro Bonazzola 2016-03-11 14:03:17 UTC

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.

Comment 1 Yedidyah Bar David 2016-03-22 14:45:18 UTC

Wouldn't this break all our other code that's not yet python3? engine-setup, hosted-engine-setup?

Comment 2 Sandro Bonazzola 2016-03-22 16:21:53 UTC

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.

Comment 3 Red Hat Bugzilla Rules Engine 2016-07-03 10:25:29 UTC

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.

Comment 4 Yedidyah Bar David 2016-07-31 14:25:52 UTC

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.

Comment 5 Yedidyah Bar David 2017-03-06 10:31:47 UTC

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).

Host-deploy:
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.

Comment 6 Sandro Bonazzola 2017-03-07 09:20:21 UTC

*** Bug 1426484 has been marked as a duplicate of this bug. ***

Comment 7 Yedidyah Bar David 2019-01-24 11:22:18 UTC

Moving to QE.

Most relevant patches merged several months ago, last one [1] 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.:

OTOPI_PYTHON=python3 engine-setup

[1] https://gerrit.ovirt.org/95649 core: Default to python3

Comment 8 Sandro Bonazzola 2019-02-13 07:43:04 UTC

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.

Comment 9 Steve Goodman 2019-02-21 16:06:00 UTC

Please review the doc text. I gleaned it from the summary and the description of the bug.

Comment 10 Yedidyah Bar David 2019-02-24 06:56:51 UTC

(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 [1], which is probably enough.

[1] https://ovirt.org/release/4.3.0/#fedora-tech-preview

Comment 11 Steve Goodman 2019-02-24 16:03:26 UTC

Changing doc_text flag to '-', as per comment 10.