Re: [Gluster-devel] [Gluster-infra] freebsd-smoke failures

[Polakis Vaggelis]

thx for the support!

by the way same problem also occurs in review
http://review.gluster.org/#/c/14045/

br, vangelis

On Tue, Apr 19, 2016 at 5:01 PM, Michael Scherer  wrote:
> Le mardi 19 avril 2016 à 09:58 -0400, Jeff Darcy a écrit :
>> > So can a workable solution be pushed to git, because I plan to force the
>> > checkout to be like git, and it will break again (and this time, no
>> > workaround will be possible).
>> >
>>
>> It has been pushed to git, but AFAICT pull requests for that repo go into
>> a black hole.
>
> Indeed, I even made the same PR twice:
> https://github.com/gluster/glusterfs-patch-acceptance-tests/pull/12
>
> I guess no one is officially taking ownership of it, which is kinda bad,
> but can be solved.
>
> No volunteer ?
>
> --
> Michael Scherer
> Sysadmin, Community Infrastructure and Platform, OSAS
>
>
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-infra] freebsd-smoke failures

[Michael Scherer]

Le mardi 19 avril 2016 à 09:58 -0400, Jeff Darcy a écrit :
> > So can a workable solution be pushed to git, because I plan to force the
> > checkout to be like git, and it will break again (and this time, no
> > workaround will be possible).
> > 
> 
> It has been pushed to git, but AFAICT pull requests for that repo go into
> a black hole.

Indeed, I even made the same PR twice:
https://github.com/gluster/glusterfs-patch-acceptance-tests/pull/12

I guess no one is officially taking ownership of it, which is kinda bad,
but can be solved.

No volunteer ?

-- 
Michael Scherer
Sysadmin, Community Infrastructure and Platform, OSAS




signature.asc
Description: This is a digitally signed message part
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-infra] freebsd-smoke failures

[Jeff Darcy]

> So can a workable solution be pushed to git, because I plan to force the
> checkout to be like git, and it will break again (and this time, no
> workaround will be possible).
> 

It has been pushed to git, but AFAICT pull requests for that repo go into
a black hole.
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-infra] freebsd-smoke failures

[Michael Scherer]

Le samedi 02 avril 2016 à 07:53 -0400, Jeff Darcy a écrit :
> > IIRC, this happens because in the build job use "--enable-bd-xlator"
> > option while configure
> 
> I came to the same conclusion, and set --enable-bd-xlator=no on the
> slave.  I also had to remove -Werror because that was also causing
> failures.  FreeBSD smoke is now succeeding.

But direct modification of the slave broke automated deployment however.

So can a workable solution be pushed to git, because I plan to force the
checkout to be like git, and it will break again (and this time, no
workaround will be possible). 


-- 
Michael Scherer
Sysadmin, Community Infrastructure and Platform, OSAS




signature.asc
Description: This is a digitally signed message part
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-infra] freebsd-smoke failures

[Michael Scherer]

Le lundi 04 avril 2016 à 08:54 -0400, Jeff Darcy a écrit :
> > Once this was done, I pushed to use the regular upstream change,
> > something that was not done before since the local change broke
> > automation to deploy test suite on Freebsd.
> 
> It looks like we have two options here:
> 
> (1) Fix configure so that it accurately detects whether the
> system can/should build BD, and stop forcing it on the command
> line.
> 
> (2) Leave it on the command line, but add a platform check to
> determine its proper value.
> 
> There's already a platform check in Prasanna's patch to set
> the parallelism level.  Should we just combine that with #2?

So from a end-user (read packager) perspective, we should strive at:

1) detect when people push unsupported option as soon as possible (ie,
if BD is not compiling or working on freebsd, detect in the configure,
not at build time)

2) enable features by default that we think to be beneficial, on
platform where they are supported.

In fact, i would go as far as enabling all by default, so we can get a
wide testing from the smoke test.

Or optionally, having a --enable-all-supported would permit to have
supported options in sync with the code. If someone add support to BD to
freebsd in some version, we wouldn't have to make anything special on
the slave to build the option on one branch and not the others. 


-- 
Michael Scherer
Sysadmin, Community Infrastructure and Platform, OSAS




signature.asc
Description: This is a digitally signed message part
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-infra] freebsd-smoke failures

[Jeff Darcy]

> Once this was done, I pushed to use the regular upstream change,
> something that was not done before since the local change broke
> automation to deploy test suite on Freebsd.

It looks like we have two options here:

(1) Fix configure so that it accurately detects whether the
system can/should build BD, and stop forcing it on the command
line.

(2) Leave it on the command line, but add a platform check to
determine its proper value.

There's already a platform check in Prasanna's patch to set
the parallelism level.  Should we just combine that with #2?
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-infra] freebsd-smoke failures

[Niels de Vos]

On Sat, Apr 02, 2016 at 11:04:48AM -0400, Jeff Darcy wrote:
> > Please make sure that this change also gets included in the repository:
> > 
> >   https://github.com/gluster/glusterfs-patch-acceptance-tests
> 
> Looks like we're getting a bit of a queue there.  Who can merge some of
> these?

I normally leave that for the people that maintain the test
infrastructure. Raghavendra Talur, Kaushal and MS are the ones that
should merge most of these changes.

I can help with the ones that are related to tests in the CentOS CI :)

Niels


signature.asc
Description: PGP signature
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-infra] freebsd-smoke failures

[Jeff Darcy]

> Please make sure that this change also gets included in the repository:
> 
>   https://github.com/gluster/glusterfs-patch-acceptance-tests

Looks like we're getting a bit of a queue there.  Who can merge some of
these?
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-infra] freebsd-smoke failures

[Jeff Darcy]

- Original Message -
> On Sat, Apr 02, 2016 at 07:53:32AM -0400, Jeff Darcy wrote:
> > > IIRC, this happens because in the build job use "--enable-bd-xlator"
> > > option while configure
> > 
> > I came to the same conclusion, and set --enable-bd-xlator=no on the
> > slave.  I also had to remove -Werror because that was also causing
> > failures.  FreeBSD smoke is now succeeding.
> 
> Please make sure that this change also gets included in the repository:
> 
>   https://github.com/gluster/glusterfs-patch-acceptance-tests
> 
> I always thought the bd-xlator was Linux only because it depends on LVM.
> Does anyone have an idea why this suddenly(?) got enabled on FreeBSD?

At first I thought it might have been because a Linux-specific version
got restored when the slave was rebooted a few days ago (something to
do with network changes at Rackspace IIRC).  The timing's right; that's
when the tests started failing consistently.  OTOH, that version also
has -Werror which has never worked on Linux AFAIK.  So it's still a bit
of a mystery.
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-infra] freebsd-smoke failures

[Niels de Vos]

On Sat, Apr 02, 2016 at 07:53:32AM -0400, Jeff Darcy wrote:
> > IIRC, this happens because in the build job use "--enable-bd-xlator"
> > option while configure
> 
> I came to the same conclusion, and set --enable-bd-xlator=no on the
> slave.  I also had to remove -Werror because that was also causing
> failures.  FreeBSD smoke is now succeeding.

Please make sure that this change also gets included in the repository:

  https://github.com/gluster/glusterfs-patch-acceptance-tests

I always thought the bd-xlator was Linux only because it depends on LVM.
Does anyone have an idea why this suddenly(?) got enabled on FreeBSD?

Thanks,
Niels


signature.asc
Description: PGP signature
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-infra] freebsd-smoke failures

[Jeff Darcy]

> IIRC, this happens because in the build job use "--enable-bd-xlator"
> option while configure

I came to the same conclusion, and set --enable-bd-xlator=no on the
slave.  I also had to remove -Werror because that was also causing
failures.  FreeBSD smoke is now succeeding.
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-infra] freebsd-smoke failures

[Prasanna Kalever]

On Sat, Apr 2, 2016 at 2:13 AM, Jeff Darcy  wrote:
>
> I've seen a lot of patches blocked lately by this:
>
> > BD xlator requested but required lvm2 development library not found.
>
Hi Jeff,

IIRC, this happens because in the build job use "--enable-bd-xlator"
option while configure;
but looks like bd library dependencies were missing in this slave.

/me looking into configure.ac

[part of configure.ac]

if test "x$enable_bd_xlator" != "xno"; then
  AC_CHECK_LIB([lvm2app],
   [lvm_init,lvm_lv_from_name],
   [HAVE_BD_LIB="yes"],
   [HAVE_BD_LIB="no"])
[...]

if test "x$enable_bd_xlator" = "xyes" -a "x$HAVE_BD_LIB" = "xno"; then
   echo "BD xlator requested but required lvm2 development library not found."
   exit 1
fi

>From above I can say liblvm2app.so doesn't have
lvm_init/lvm_lv_from_name functions or
there is no liblvm2app.so in this slave, hence 'HAVE_BD_LIB' will be set to 'no'

IMO, no one really uses "BD-xlator" and I think we need to remove this
option In the build script while we configure.


Thanks,
-- Prasanna

> It doesn't happen all the time, so there must be something about
> certain patches that triggers it.  Any thoughts?
> ___
> Gluster-infra mailing list
> gluster-in...@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-infra
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel