<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 3:20 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:56:51PM +0530, Amar Tumballi Suryanarayan wrote:<br>
> On Thu, Jun 20, 2019 at 2:35 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 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<br>
> > wrote:<br>
> > > > > Considering python3 is anyways the future, I vote for taking the<br>
> > patch we<br>
> > > > > did in master for fixing regression tests with python3 into the<br>
> > 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<br>
> > packaged<br>
> > > > in<br>
> > > > > a release anyways.<br>
> > > > ><br>
> > > > > Hari, can we get the backport of this patch to both the release<br>
> > 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<br>
> > and<br>
> > > python3, so technically, it allows us to move to Fedora30 if we need to<br>
> > 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.<br>
> <br>
> <br>
> Got it! True. Compatibility is not the problem to build the tarball.<br>
> <br>
> I noticed the issue of smoke is coming only from strfmt-errors job, which<br>
> checks for 'epel-6-i386' mock, and fails right now.<br>
> <br>
> The backport might become relevant while running<br>
> > tests on environments where there is no python2.<br>
> ><br>
> ><br>
> Backport is very important if we are running in a system where we have only<br>
> python3. Hence my proposal to include it in releases.<br>
<br>
I am sure CentOS-7 still has python2. The newer python3 only gets pulled<br>
in by some additional packages that get installed from EPEL.<br>
<br>
> But we are stuck with strfmt-errors job right now, and looking at what it<br>
> was intended to catch in first place, mostly our<br>
> <a href="https://build.gluster.org/job/32-bit-build-smoke/" rel="noreferrer" target="_blank">https://build.gluster.org/job/32-bit-build-smoke/</a> would be doing same. If<br>
> that is the case, we can remove the job altogether. Also note, this job is<br>
> known to fail many smokes with 'Build root is locked by another process'<br>
> errors.<br>
<br>
This error means that there are multiple concurrent jobs running 'mock'<br>
with this buildroot. That should not happen and is a configuration error<br>
in one or more Jenkins jobs.</blockquote><div> Adding to this, this error occurs when the last running job using mock has been aborted and no proper cleaning/killing in the build root has happened.</div><div> I'm planning to call up a cleanup function on abort.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Would be great if disabling strfmt-errors is an option.<br>
<br>
I think both jobs do different things. The smoke is functional, where as<br>
strfmt-errors catches incorrect string formatting (some maintainers<br>
assume always 64-bit, everywhere) that has been missed in reviews.<br></blockquote><div>Is there any specific reason to use 64-bit for strfmt-errors?</div><div>Also I have a doubt here, if it needs python3-devel package to build glupy it should have failed for basic smoke testing where we do source build install? </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Niels<br>
<br>
<br>
> <br>
> Regards,<br>
> <br>
> > 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>
> > ><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<br>
> > 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<br>
> > 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<br>
> > 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<br>
> > 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<br>
> > 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<br>
> > 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<br>
> > enabled on<br>
> > > > > > > > the<br>
> > > > > > > > CentOS-7 builders. At least not for the building of the<br>
> > 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?)<br>
> > version<br>
> > > > > > > > for the<br>
> > > > > > > > system. Is it possible to remove python3 from the CentOS-7<br>
> > builders<br>
> > > > > > > > and<br>
> > > > > > > > run the jobs that require python3 on the Fedora builders<br>
> > instead?<br>
> > > > > > ><br>
> > > > > > > Actually, if the python-devel package for python3 is installed<br>
> > on the<br>
> > > > > > > CentOS-7 builders, things may work too. It still feels like some<br>
> > 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<br>
> > 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),<br>
> > but<br>
> > > > > > real life is much messier than we want to admit, so we need<br>
> > 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>
> ><br>
> <br>
> <br>
> -- <br>
> Amar Tumballi (amarts)<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></div>