yetus-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Bayer <andrew.ba...@gmail.com>
Subject Re: /bin/ls permission issue on precommit tests
Date Wed, 02 Mar 2016 20:05:26 GMT
Speaking with my infra hat on -

I'd like to see us end up going in that direction. But yeah, it'll need
committed resources from infra, meaning cycles from paid infra staff and
those staff being able to handle the work without needing to resort to
volunteer assistance for day to day activities. Starting a discussion with
infra about the possibility would be a good idea.

A.
On Mar 2, 2016 12:00, "Sean Busbey" <busbey@apache.org> wrote:

> Another option would be to request that infra@asf provide "yetus based
> precommit testing" as an SLA governed service. Then they could
> maintain configuration management of running the tests with known good
> versions and rolling them out across projects.
>
> AFAIK, the backlog on infra is pretty severe though, so requests are
> likely to get backlogged if they don't come with a volunteer.
>
> On Wed, Mar 2, 2016 at 1:53 PM, Sean Busbey <busbey@apache.org> wrote:
> > Such a tag would be a distribution according to ASF rules. The Yetus
> > PMC would have to vote on it just as we do releases.
> >
> > The answer to the issue of blocking downstream folks is to release more
> often.
> >
> > The Yetus PMC has a release cadence goal of weekly. Other projects
> > that want access to more frequent releases can help the situation by
> > helping to vote on releases.
> >
> > On Wed, Mar 2, 2016 at 1:49 PM, Enis Söztutar <enis.soz@gmail.com>
> wrote:
> >> Thanks Chris,
> >>
> >> This came up before whether to run against a released yetus or not.
> >> Personally, I don't care a bit about whether the yetus release we are
> using
> >> by default is a released one or trunk or a tag. We are only depending on
> >> yetus for the precommit job and not for our distribution artifacts. I
> can
> >> understand the yetus release is taking some time, and voting etc, but we
> >> are affectively blocking progress on downstream projects, or making life
> >> very inconvenient at the least. The problem is that EVERY hadoopqa run
> has
> >> to be re-kicked, and it requires a committer with jenkins access to do
> it.
> >>
> >> Can we do something like this: yetus community can maintain a stable tag
> >> (not necessarily a release) where the tag is used by default for
> downstream
> >> projects. We can have USE_YETUS_RELEASE, USE_STABLE_YETUS and
> >> USE_YETUS_PRERELEASE, and have USE_STABLE_YETUS as the default in
> precommit
> >> jobs. For example, when the docker issue is fixed, the yetus community
> will
> >> just change the stable tag to be that point in time.
> >>
> >> Enis
> >>
> >> On Wed, Mar 2, 2016 at 11:33 AM, Ted Yu <yuzhihong@gmail.com> wrote:
> >>
> >>> Thanks for the information, Chris.
> >>>
> >>> For HBase precommit, there is checkbox 'USE_YETUS_PRERELEASE' which
> >>> uses current
> >>> HEAD of apache/yetus.
> >>>
> >>> Before Yetus 0.2.0 comes out, we can utilize this checkbox.
> >>>
> >>> Cheers
> >>>
> >>> On Wed, Mar 2, 2016 at 11:30 AM, Chris Nauroth <
> cnauroth@hortonworks.com>
> >>> wrote:
> >>>
> >>> > Hi Enis,
> >>> >
> >>> > Hadoop pre-commit was experiencing the same problem a few weeks ago:
> >>> >
> >>> > https://issues.apache.org/jira/browse/YETUS-286
> >>> >
> >>> >
> >>> > We resolved this as a duplicate of a patch that allows control of
> whether
> >>> > or not Docker runs in privileged mode:
> >>> >
> >>> > https://issues.apache.org/jira/browse/YETUS-285
> >>> >
> >>> >
> >>> > I have to admit I'm not enough of a Docker expert to understand this
> fix,
> >>> > but you can read through the issue comments from the contributors if
> you
> >>> > want details.
> >>> >
> >>> > Hadoop pre-commit currently runs off of Yetus master, which includes
> this
> >>> > patch, and we are no longer seeing the problem.  I see HBase
> pre-commit
> >>> is
> >>> > currently running with Yetus release 0.1.0, which does not have the
> fix.
> >>> >
> >>> > I think you have 2 options:
> >>> >
> >>> > 1. Switch HBase pre-commit to run Yetus from the master branch.
> (Please
> >>> > be aware that new Yetus commits will go to master though.)
> >>> > 2. If you don't like the idea of HBase pre-commit running Yetus code
> that
> >>> > is constantly in motion, then you can wait a few days for sign-off
> of our
> >>> > 0.2.0 release candidate, which is currently under [VOTE] and looking
> good
> >>> > so far.
> >>> >
> >>> > --Chris Nauroth
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > On 3/2/16, 10:47 AM, "Enis Söztutar" <enis@apache.org> wrote:
> >>> >
> >>> > >HBase precommit tests have been failing on some nodes for a couple
> of
> >>> days
> >>> > >related to this message:
> >>> > >
> >>> > >java.util.concurrent.ExecutionException: java.lang.RuntimeException:
> >>> > >Error while running command to get file permissions :
> >>> > >ExitCodeException exitCode=127: /bin/ls: error while loading shared
> >>> > >libraries: libacl.so.1: failed to map segment from shared object:
> >>> > >Permission denied
> >>> > >
> >>> > >
> >>> > >It is not clear to me whether this is a docker / yetus problem,
or
> an
> >>> > >INFRA
> >>> > >issue. Anybody familiar with this? Obviously, it makes it very
hard
> to
> >>> > >commit a patch without the precommit tests. I've seen this on at
> least 2
> >>> > >nodes.
> >>> > >
> >>> > >Sample output:
> >>> > >
> >>> >
> >>>
> https://builds.apache.org/job/PreCommit-HBASE-Build/789/artifact/patchproc
> >>> > >ess/patch-unit-hbase-server-jdk1.8.0_72.txt
> >>> > >
> >>> > >Enis
> >>> >
> >>> >
> >>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message