<div dir="ltr"><div><br></div>Considering python3 is anyways the future, I vote for taking the patch we did in master for fixing regression tests with python3 into the release-6 and release-5 branch and getting over this deadlock.<div><br></div><div>Patch in discussion here is <a href="https://review.gluster.org/#/c/glusterfs/+/22829/">https://review.gluster.org/#/c/glusterfs/+/22829/</a> and if anyone notices, it changes only the files inside 'tests/' directory, which is not packaged in a release anyways.<div><br></div><div>Hari, can we get the backport of this patch to both the release branches?</div><div><br></div><div>Regards,</div><div>Amar</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 13, 2019 at 7:26 PM Michael Scherer <<a href="mailto:mscherer@redhat.com">mscherer@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Le jeudi 13 juin 2019 à 14:28 +0200, Niels de Vos a écrit :<br>
> On Thu, Jun 13, 2019 at 11:08:25AM +0200, Niels de Vos wrote:<br>
> > On Wed, Jun 12, 2019 at 04:09:55PM -0700, Kaleb Keithley wrote:<br>
> > > On Wed, Jun 12, 2019 at 11:36 AM Kaleb Keithley <<br>
> > > <a href="mailto:kkeithle@redhat.com" target="_blank">kkeithle@redhat.com</a>> wrote:<br>
> > > <br>
> > > > <br>
> > > > On Wed, Jun 12, 2019 at 10:43 AM Amar Tumballi Suryanarayan <<br>
> > > > <a href="mailto:atumball@redhat.com" target="_blank">atumball@redhat.com</a>> wrote:<br>
> > > > <br>
> > > > > <br>
> > > > > We recently noticed that in one of the package update on<br>
> > > > > builder (ie,<br>
> > > > > centos7.x machines), python3.6 got installed as a dependency.<br>
> > > > > So, yes, it<br>
> > > > > is possible to have python3 in centos7 now.<br>
> > > > > <br>
> > > > <br>
> > > > EPEL updated from python34 to python36 recently, but C7 doesn't<br>
> > > > have<br>
> > > > python3 in the base. I don't think we've ever used EPEL<br>
> > > > packages for<br>
> > > > building.<br>
> > > > <br>
> > > > And GlusterFS-5 isn't python3 ready.<br>
> > > > <br>
> > > <br>
> > > Correction: GlusterFS-5 is mostly or completely python3<br>
> > > ready. FWIW,<br>
> > > python33 is available on both RHEL7 and CentOS7 from the Software<br>
> > > Collection Library (SCL), and python34 and now python36 are<br>
> > > available from<br>
> > > EPEL.<br>
> > > <br>
> > > But packages built for the CentOS Storage SIG have never used the<br>
> > > SCL or<br>
> > > EPEL (EPEL not allowed) and the shebangs in the .py files are<br>
> > > converted<br>
> > > from /usr/bin/python3 to /usr/bin/python2 during the rpmbuild<br>
> > > %prep stage.<br>
> > > All the python dependencies for the packages remain the python2<br>
> > > flavors.<br>
> > > AFAIK the centos-regression machines ought to be building the<br>
> > > same way.<br>
> > <br>
> > Indeed, there should not be a requirement on having EPEL enabled on<br>
> > the<br>
> > CentOS-7 builders. At least not for the building of the glusterfs<br>
> > tarball. We still need to do releases of glusterfs-4.1 and<br>
> > glusterfs-5,<br>
> > until then it is expected to have python2 as the (only?) version<br>
> > for the<br>
> > system. Is it possible to remove python3 from the CentOS-7 builders<br>
> > and<br>
> > run the jobs that require python3 on the Fedora builders instead?<br>
> <br>
> Actually, if the python-devel package for python3 is installed on the<br>
> CentOS-7 builders, things may work too. It still feels like some sort<br>
> of<br>
> Frankenstein deployment, and we don't expect to this see in<br>
> production<br>
> environments. But maybe this is a workaround in case something<br>
> really,<br>
> really, REALLY depends on python3 on the builders.<br>
<br>
To be honest, people would be surprised what happen in production<br>
around (sysadmins tend to discuss around, we all have horrors stories,<br>
stuff that were supposed to be cleaned and wasn't, etc)<br>
<br>
After all, "frankenstein deployment now" is better than "perfect<br>
later", especially since lots of IT departements are under constant<br>
pressure (so that's more "perfect never"). <br>
<br>
I can understand that we want clean and simple code (who doesn't), but<br>
real life is much messier than we want to admit, so we need something<br>
robust.<br>
<br>
-- <br>
Michael Scherer<br>
Sysadmin, Community Infrastructure<br>
<br>
<br>
<br>
_______________________________________________<br>
<br>
Community Meeting Calendar:<br>
<br>
APAC Schedule -<br>
Every 2nd and 4th Tuesday at 11:30 AM IST<br>
Bridge: <a href="https://bluejeans.com/836554017" rel="noreferrer" target="_blank">https://bluejeans.com/836554017</a><br>
<br>
NA/EMEA Schedule -<br>
Every 1st and 3rd Tuesday at 01:00 PM EDT<br>
Bridge: <a href="https://bluejeans.com/486278655" rel="noreferrer" target="_blank">https://bluejeans.com/486278655</a><br>
<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br>
<a href="https://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/gluster-devel</a><br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Amar Tumballi (amarts)<br></div></div></div></div></div>