Bug 882127 - The python binary should be able to be overridden in gsyncd
The python binary should be able to be overridden in gsyncd
Product: GlusterFS
Classification: Community
Component: geo-replication (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Csaba Henk
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2012-11-30 03:09 EST by Joe Julian
Modified: 2014-04-17 07:39 EDT (History)
2 users (show)

See Also:
Fixed In Version: glusterfs-3.5.0
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-04-17 07:39:39 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Joe Julian 2012-11-30 03:09:28 EST
Description of problem:
In a machine with python3 and python2 both installed, the hardcoded /usr/bin/python defined at build time in configure may point to python3 on the installed host. This causes 

  File "/usr/libexec/glusterfs/python/syncdaemon/ipaddr.py", line 1468
    ip_int = 0L
SyntaxError: invalid syntax

There should be a way to override which python is used, ie. /usr/bin/python2.6
Comment 1 Csaba Henk 2012-11-30 15:06:31 EST
The path/executable name of the python to be used can be set at build time; namely, configure picks it up from the $PYTHON environment variable.

If, indeed, you want run-time configurability, please provide rationale. As of my understanding, I don't see a case where one would attempt to build a binary without sufficient knowledge about and expectable expectations against the installation environment, much enough to know where the appropriate python interpreter resides.
Comment 2 Joe Julian 2012-11-30 16:22:22 EST
python 2.6 or 2.7 is installed by default on most RHEL/Fedora distros.

For some new custom app that is being deployed by Acme Widgets, they need python3

yum install python3 

make python3 the default

/usr/sbin/alternatives --install /usr/bin/python python /usr/bin/python3 90

Start glusterd. That error will occur. 

With the increased push to update apps to python3 this is becoming a growing problem.

The user that brought this to my attention was running gentoo.
Comment 3 Csaba Henk 2012-11-30 16:58:28 EST
While we have put in the effort to keep the codebase as close to python3 compliance as possible, as a matter of fact, we support only python2 as of the time being.

python3 is not the focus of current development efforts; we need a managerial decision to change this (the main concern being that introducing python3 support would imply a duplicated load on our sorely scarce Q/A resources).

That said, we would welcome community contributed py3 compliance patches if they don't break things with py2.
Comment 4 Joe Julian 2012-11-30 19:11:43 EST
I was just thinking more along the lines of

Comment 5 Csaba Henk 2012-12-03 05:31:42 EST
How, where would you set $PYTHON?

To make your scheme work properly, the setting should be effective in the sshd process (ie. shell level setting does not suffice). That, AFAICS, needs fiddling with sshd_config. Chances are therefore that people left on their own will still have difficulties with getting it right.

Also this would be used in systems which are hybrid wrt. python; so a system-wide setting for PYTHON does not seem to scale. And if not system-wide, do you have any proposal for setting it per-app?

So I'm not yet convinced this feature is general enough to propagate to mainline. Is there any kind of product level support for python3 in RHEL? If it's the case of a customer with special needs, shouldn't we consider giving them a custom rpm (with a suitable compile time PYTHON setting)?
Comment 6 Vijay Bellur 2013-02-07 20:17:32 EST
CHANGE: http://review.gluster.org/4252 (gsyncd: allow the override of the compiled-in python path) merged in master by Anand Avati (avati@redhat.com)
Comment 7 Niels de Vos 2014-04-17 07:39:39 EDT
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.5.0, please reopen this bug report.

glusterfs-3.5.0 has been announced on the Gluster Developers mailinglist [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/6137
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user

Note You need to log in before you can comment on or make changes to this bug.