<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 20, 2019 at 2:35 PM Niels de Vos <<a href="mailto:ndevos@redhat.com">ndevos@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">On Thu, Jun 20, 2019 at 02:11:21PM +0530, Amar Tumballi Suryanarayan wrote:<br>
> On Thu, Jun 20, 2019 at 1:13 PM Niels de Vos <<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a>> wrote:<br>
> <br>
> > On Thu, Jun 20, 2019 at 11:36:46AM +0530, Amar Tumballi Suryanarayan wrote:<br>
> > > Considering python3 is anyways the future, I vote for taking the patch we<br>
> > > did in master for fixing regression tests with python3 into the release-6<br>
> > > and release-5 branch and getting over this deadlock.<br>
> > ><br>
> > > Patch in discussion here is<br>
> > > <a href="https://review.gluster.org/#/c/glusterfs/+/22829/" rel="noreferrer" target="_blank">https://review.gluster.org/#/c/glusterfs/+/22829/</a> and if anyone<br>
> > notices, it<br>
> > > changes only the files inside 'tests/' directory, which is not packaged<br>
> > in<br>
> > > a release anyways.<br>
> > ><br>
> > > Hari, can we get the backport of this patch to both the release branches?<br>
> ><br>
> > When going this route, you still need to make sure that the<br>
> > python3-devel package is available on the CentOS-7 builders. And I<br>
> > don't know if installing that package is already sufficient, maybe the<br>
> > backport is not even needed in that case.<br>
> ><br>
> ><br>
> I was thinking, having this patch makes it compatible with both python2 and<br>
> python3, so technically, it allows us to move to Fedora30 if we need to run<br>
> regression there. (and CentOS7 with only python2).<br>
> <br>
> The above patch made it compatible, not mandatory to have python3. So,<br>
> treating it as a bug fix.<br>
<br>
Well, whatever Python is detected (python3 has preference over python2),<br>
needs to have the -devel package available too. Detection is done by<br>
probing the python<X> executable. The Matching header files from -devel<br>
need to be present in order to be able to build glupy (and others?).<br>
<br>
I do not think compatibility for python3/2 is the problem while<br>
building the tarball. </blockquote><div><br></div><div>Got it! True. Compatibility is not the problem to build the tarball.</div><div><br></div><div>I noticed the issue of smoke is coming only from strfmt-errors job, which checks for 'epel-6-i386' mock, and fails right now.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The backport might become relevant while running<br>
tests on environments where there is no python2.<br>
<br></blockquote><div><br></div><div>Backport is very important if we are running in a system where we have only python3. Hence my proposal to include it in releases.</div><div><br></div><div>But we are stuck with strfmt-errors job right now, and looking at what it was intended to catch in first place, mostly our <a href="https://build.gluster.org/job/32-bit-build-smoke/">https://build.gluster.org/job/32-bit-build-smoke/</a> would be doing same. If that is the case, we can remove the job altogether. Also note, this job is known to fail many smokes with 'Build root is locked by another process' errors.</div><div><br></div><div>Would be great if disabling strfmt-errors is an option.</div><div><br></div><div>Regards,</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Niels<br>
<br>
<br>
> <br>
> <br>
> > Niels<br>
> ><br>
> ><br>
> > ><br>
> > > Regards,<br>
> > > Amar<br>
> > ><br>
> > > On Thu, Jun 13, 2019 at 7:26 PM Michael Scherer <<a href="mailto:mscherer@redhat.com" target="_blank">mscherer@redhat.com</a>><br>
> > wrote:<br>
> > ><br>
> > > > 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>
> > > ><br>
> > ><br>
> > > --<br>
> > > Amar Tumballi (amarts)<br>
> ><br>
> <br>
> <br>
> -- <br>
> Amar Tumballi (amarts)<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></div>