[Gluster-devel] Removing glupy from release 5.7

[Niels de Vos]

On Thu, Jun 20, 2019 at 03:42:06PM +0530, Deepshikha Khandelwal wrote:
> On Thu, Jun 20, 2019 at 3:20 PM Niels de Vos <ndevos at redhat.com> wrote:
> 
> > On Thu, Jun 20, 2019 at 02:56:51PM +0530, Amar Tumballi Suryanarayan wrote:
> > > On Thu, Jun 20, 2019 at 2:35 PM Niels de Vos <ndevos at redhat.com> wrote:
> > >
> > > > On Thu, Jun 20, 2019 at 02:11:21PM +0530, Amar Tumballi Suryanarayan
> > wrote:
> > > > > On Thu, Jun 20, 2019 at 1:13 PM Niels de Vos <ndevos at redhat.com>
> > wrote:
> > > > >
> > > > > > On Thu, Jun 20, 2019 at 11:36:46AM +0530, Amar Tumballi
> > Suryanarayan
> > > > wrote:
> > > > > > > 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.
> > > > > > >
> > > > > > > Patch in discussion here is
> > > > > > > https://review.gluster.org/#/c/glusterfs/+/22829/ and if anyone
> > > > > > notices, it
> > > > > > > changes only the files inside 'tests/' directory, which is not
> > > > packaged
> > > > > > in
> > > > > > > a release anyways.
> > > > > > >
> > > > > > > Hari, can we get the backport of this patch to both the release
> > > > branches?
> > > > > >
> > > > > > When going this route, you still need to make sure that the
> > > > > > python3-devel package is available on the CentOS-7 builders. And I
> > > > > > don't know if installing that package is already sufficient, maybe
> > the
> > > > > > backport is not even needed in that case.
> > > > > >
> > > > > >
> > > > > I was thinking, having this patch makes it compatible with both
> > python2
> > > > and
> > > > > python3, so technically, it allows us to move to Fedora30 if we need
> > to
> > > > run
> > > > > regression there. (and CentOS7 with only python2).
> > > > >
> > > > > The above patch made it compatible, not mandatory to have python3.
> > So,
> > > > > treating it as a bug fix.
> > > >
> > > > Well, whatever Python is detected (python3 has preference over
> > python2),
> > > > needs to have the -devel package available too. Detection is done by
> > > > probing the python<X> executable. The Matching header files from -devel
> > > > need to be present in order to be able to build glupy (and others?).
> > > >
> > > > I do not think compatibility for python3/2 is the problem while
> > > > building the tarball.
> > >
> > >
> > > Got it! True. Compatibility is not the problem to build the tarball.
> > >
> > > I noticed the issue of smoke is coming only from strfmt-errors job, which
> > > checks for 'epel-6-i386' mock, and fails right now.
> > >
> > > The backport might become relevant while running
> > > > tests on environments where there is no python2.
> > > >
> > > >
> > > Backport is very important if we are running in a system where we have
> > only
> > > python3. Hence my proposal to include it in releases.
> >
> > I am sure CentOS-7 still has python2. The newer python3 only gets pulled
> > in by some additional packages that get installed from EPEL.
> >
> > > But we are stuck with strfmt-errors job right now, and looking at what it
> > > was intended to catch in first place, mostly our
> > > https://build.gluster.org/job/32-bit-build-smoke/ 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.
> >
> > This error means that there are multiple concurrent jobs running 'mock'
> > with this buildroot. That should not happen and is a configuration error
> > in one or more Jenkins jobs.
> 
>  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.
>  I'm planning to call up a cleanup function on abort.

Ah, right, that is a possibility too. Jobs should cleanup after
themselves and if that is not happening, it is a bug in the job (or
missing cleanup on boot).

> > > Would be great if disabling strfmt-errors is an option.
> >
> > I think both jobs do different things. The smoke is functional, where as
> > strfmt-errors catches incorrect string formatting (some maintainers
> > assume always 64-bit, everywhere) that has been missed in reviews.
> >
> Is there any specific reason to use 64-bit for strfmt-errors?

No, we still support several 32-bit architectures.

> 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?

I do not know if smoke enables/disables building of glupy.

Niels