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 <[email protected]> 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 <[email protected]> > 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" <[email protected]> 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 > > > > >
