Bug 882127
| Summary: | The python binary should be able to be overridden in gsyncd | ||
|---|---|---|---|
| Product: | [Community] GlusterFS | Reporter: | Joe Julian <joe> |
| Component: | geo-replication | Assignee: | Csaba Henk <csaba> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | mainline | CC: | gluster-bugs, rwheeler |
| Target Milestone: | --- | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | glusterfs-3.5.0 | Doc Type: | Enhancement |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-04-17 11:39:39 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. 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. 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. I was just thinking more along the lines of http://review.gluster.org/4252 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)? CHANGE: http://review.gluster.org/4252 (gsyncd: allow the override of the compiled-in python path) merged in master by Anand Avati (avati) 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 |
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