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