[Gluster-devel] Removing glupy from release 5.7

Thu Jun 20 10:12:06 UTC 2019

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.

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

>
> Niels
>
>
> >
> > Regards,
> >
> > > Niels
> > >
> > >
> > > >
> > > >
> > > > > Niels
> > > > >
> > > > >
> > > > > >
> > > > > > Regards,
> > > > > > Amar
> > > > > >
> > > > > > On Thu, Jun 13, 2019 at 7:26 PM Michael Scherer <
> mscherer at redhat.com
> > > >
> > > > > wrote:
> > > > > >
> > > > > > > Le jeudi 13 juin 2019 à 14:28 +0200, Niels de Vos a écrit :
> > > > > > > > On Thu, Jun 13, 2019 at 11:08:25AM +0200, Niels de Vos wrote:
> > > > > > > > > On Wed, Jun 12, 2019 at 04:09:55PM -0700, Kaleb Keithley
> wrote:
> > > > > > > > > > On Wed, Jun 12, 2019 at 11:36 AM Kaleb Keithley <
> > > > > > > > > > kkeithle at redhat.com> wrote:
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Jun 12, 2019 at 10:43 AM Amar Tumballi
> > > Suryanarayan <
> > > > > > > > > > > atumball at redhat.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > We recently noticed that in one of the package
> update on
> > > > > > > > > > > > builder (ie,
> > > > > > > > > > > > centos7.x machines), python3.6 got installed as a
> > > dependency.
> > > > > > > > > > > > So, yes, it
> > > > > > > > > > > > is possible to have python3 in centos7 now.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > EPEL updated from python34 to python36 recently, but C7
> > > doesn't
> > > > > > > > > > > have
> > > > > > > > > > > python3 in the base. I don't think we've ever used EPEL
> > > > > > > > > > > packages for
> > > > > > > > > > > building.
> > > > > > > > > > >
> > > > > > > > > > > And GlusterFS-5 isn't python3 ready.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Correction: GlusterFS-5 is mostly or completely python3
> > > > > > > > > > ready.  FWIW,
> > > > > > > > > > python33 is available on both RHEL7 and CentOS7 from the
> > > Software
> > > > > > > > > > Collection Library (SCL), and python34 and now python36
> are
> > > > > > > > > > available from
> > > > > > > > > > EPEL.
> > > > > > > > > >
> > > > > > > > > > But packages built for the CentOS Storage SIG have never
> > > used the
> > > > > > > > > > SCL or
> > > > > > > > > > EPEL (EPEL not allowed) and the shebangs in the .py
> files are
> > > > > > > > > > converted
> > > > > > > > > > from /usr/bin/python3 to /usr/bin/python2 during the
> rpmbuild
> > > > > > > > > > %prep stage.
> > > > > > > > > > All the python dependencies for the packages remain the
> > > python2
> > > > > > > > > > flavors.
> > > > > > > > > > AFAIK the centos-regression machines ought to be
> building the
> > > > > > > > > > same way.
> > > > > > > > >
> > > > > > > > > Indeed, there should not be a requirement on having EPEL
> > > enabled on
> > > > > > > > > the
> > > > > > > > > CentOS-7 builders. At least not for the building of the
> > > glusterfs
> > > > > > > > > tarball. We still need to do releases of glusterfs-4.1 and
> > > > > > > > > glusterfs-5,
> > > > > > > > > until then it is expected to have python2 as the (only?)
> > > version
> > > > > > > > > for the
> > > > > > > > > system. Is it possible to remove python3 from the CentOS-7
> > > builders
> > > > > > > > > and
> > > > > > > > > run the jobs that require python3 on the Fedora builders
> > > instead?
> > > > > > > >
> > > > > > > > Actually, if the python-devel package for python3 is
> installed
> > > on the
> > > > > > > > CentOS-7 builders, things may work too. It still feels like
> some
> > > sort
> > > > > > > > of
> > > > > > > > Frankenstein deployment, and we don't expect to this see in
> > > > > > > > production
> > > > > > > > environments. But maybe this is a workaround in case
> something
> > > > > > > > really,
> > > > > > > > really, REALLY depends on python3 on the builders.
> > > > > > >
> > > > > > > To be honest, people would be surprised what happen in
> production
> > > > > > > around (sysadmins tend to discuss around, we all have horrors
> > > stories,
> > > > > > > stuff that were supposed to be cleaned and wasn't, etc)
> > > > > > >
> > > > > > > After all, "frankenstein deployment now" is better than
> "perfect
> > > > > > > later", especially since lots of IT departements are under
> constant
> > > > > > > pressure (so that's more "perfect never").
> > > > > > >
> > > > > > > I can understand that we want clean and simple code (who
> doesn't),
> > > but
> > > > > > > real life is much messier than we want to admit, so we need
> > > something
> > > > > > > robust.
> > > > > > >
> > > > > > > --
> > > > > > > Michael Scherer
> > > > > > > Sysadmin, Community Infrastructure
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > >
> > > > > > > Community Meeting Calendar:
> > > > > > >
> > > > > > > APAC Schedule -
> > > > > > > Every 2nd and 4th Tuesday at 11:30 AM IST
> > > > > > > Bridge: https://bluejeans.com/836554017
> > > > > > >
> > > > > > > NA/EMEA Schedule -
> > > > > > > Every 1st and 3rd Tuesday at 01:00 PM EDT
> > > > > > > Bridge: https://bluejeans.com/486278655
> > > > > > >
> > > > > > > Gluster-devel mailing list
> > > > > > > Gluster-devel at gluster.org
> > > > > > > https://lists.gluster.org/mailman/listinfo/gluster-devel
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > Amar Tumballi (amarts)
> > > > >
> > > >
> > > >
> > > > --
> > > > Amar Tumballi (amarts)
> > >
> >
> >
> > --
> > Amar Tumballi (amarts)
> _______________________________________________
>
> Community Meeting Calendar:
>
> APAC Schedule -
> Every 2nd and 4th Tuesday at 11:30 AM IST
> Bridge: https://bluejeans.com/836554017
>
> NA/EMEA Schedule -
> Every 1st and 3rd Tuesday at 01:00 PM EDT
> Bridge: https://bluejeans.com/486278655
>
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20190620/0da77ced/attachment-0001.html>