There's some selinux/capability issue with docker 1.10. I'm not sure if it's a bug in 1.10 or just missing some capability. There are some related issues fixed in docker 1.12. Selinux doesn't complain. However, turning selinux off or to permissive gets around the issue.
I managed to get through the neo4j tests but docker 1.10 was terribly slow so I ended up upgrading to docker 1.12 which is about 3-4x faster but still slower than native. I'll let it run tonight and see if it gets all the way through. Robert Dale On Sun, Nov 6, 2016 at 6:37 PM, Stephen Mallette <[email protected]> wrote: > That stinks. Never got OOME with docker. Any other kinds of issues you can > recall or is it pretty much just that? > > On Nov 6, 2016 5:43 PM, "Robert Dale" <[email protected]> wrote: > > > One day I'll figure out why docker always fails for me. It's usually > > around some java.lang.OutOfMemoryError: unable to create new native > > thread. Usually happens in tinkergraph-gremlin. Sometimes it makes it to > > spark or hadoop, but inevitably fails miserably there. Tried latest > master > > and TINKERPOP-1434 but no joy. Even rebuilt docker containers from > scratch. > > > > Robert Dale > > > > On Fri, Oct 28, 2016 at 6:22 PM, Stephen Mallette <[email protected]> > > wrote: > > > > > That's probably fair. Perhaps that's a good rule. At least one person > > > should use CPU to do the docker build and mention that on the PR as > part > > of > > > their VOTE. I also suppose some PRs won't even need the docker run at > > all. > > > We can just use some common sense with that "rule". > > > > > > On Fri, Oct 28, 2016 at 5:29 PM, Daniel Kuppitz <[email protected]> > wrote: > > > > > > > Talking about sparing CPU cycles: docker/build.sh -t -i -n takes > time, > > > lots > > > > of time. I used to run it regardless of whether somebody else already > > did > > > > it or not. I won't do that anymore and instead rely on idempotent > > results > > > > (in the end that's why we originally created the Docker containers). > > > Hence, > > > > if anybody already ran the full build, I will only look through the > > code > > > > changes and if they look good to me - VOTE: +1. > > > > > > > > Cheers, > > > > Daniel > > > > > > > > > > > > On Fri, Oct 28, 2016 at 9:28 PM, Stephen Mallette < > > [email protected]> > > > > wrote: > > > > > > > > > We're backing up pretty heavily on pull request reviews/votes. > > > > > > > > > > https://github.com/apache/tinkerpop/pulls > > > > > > > > > > Can any committers help us along with some reviews/votes? > > > > > > > > > > Remember - you don't need to have full knowledge of the code to > > > > participate > > > > > in a code review. If the code comes from a core contributor (e.g. > > marko > > > > > submitting a gremlin-spark bug fix), you mostly need to focus on > the > > > big > > > > > picture and generalities of the change and then do a "mvn clean > > > install" > > > > or > > > > > better yet "docker.build.sh -t -i -n". If it all works then "VOTE > > +1". > > > > > > > > > > Most pull requests for review are super simple, like this one: > > > > > > > > > > https://github.com/apache/tinkerpop/pull/465 (removed deprecated > > > > classes) > > > > > > > > > > All you need to do is check if the classes are gone, if upgrade > docs > > > are > > > > > updated and if the thing builds...done. VOTE +1. > > > > > > > > > > Doing reviews is a huge help to the project (even for those who are > > not > > > > > committers and don't have binding votes, as it is a great way to > get > > > > > visibility in the project and learn more about how it works). It > > would > > > be > > > > > great if folks could make a habit of sparing a few CPU cycles for > > > > TinkerPop > > > > > at the end of a work day or while you sleep so that we can continue > > to > > > > stay > > > > > agile in our development. > > > > > > > > > > Thanks > > > > > > > > > > > > > > > -- null
