Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The Linode kernel appears to only fail the AUFS portion, as expected:

https://gist.github.com/akerl/8245192

I'm not sure how the Docker devs handle non-AUFS-related contributions from contributors whose systems don't have AUFS (whether a failure on any tests means they refuse to consider patches, or whether they consider the tests relevant to the patch).



> I'm not sure how the Docker devs handle non-AUFS-related contributions from contributors whose systems don't have AUFS

We kindly point them to our use of libdevmapper, the other storage driver for Docker.

And I should add, we should probably refactor those tests to detect storage capabilities like the Engine does.


That's what I figured, and I'm glad to have it confirmed.

I've seen enough projects that have a rigid "if your dev environment isn't perfect, your code's no good to us" mindset that I was wary.

Also, just wanted to say that the Docker installation process and the rest of the Docker docs have been amazing. Originally, I was looking at writing a quick guide on getting up and running with Docker on Linode, but we decided linking the official docs made more sense considering how comprehensive they are.


That's awesome to hear! If you have any feedback on the documentation or would like to see other material please reach out to me: james.turnbull@docker.com. Or log a ticket and cc me on GitHub: jamtur01.


Thanks for the kind words, we're really happy to have Linode support!


Don't the tests use the engine for the most part?


All storage drivers are unit-tested, but our integration tests (./integration/ in the repo) are currently tied to a specific host environment: namely, ubuntu 12.04 with an aufs-patched 3.8 kernel, version 0.8 of the lxc scripts, etc).

We are working on upgrading the integration test harness to handle a wider matrix of target systems, including those that don't handle aufs.

If you are interested in helping us out on this, come say hi on #docker-dev on freenode :) We are always looking for help and love to get new contributors and maintainers up and running.


Well, I think the answer to your question is complicated.

But thanks for that! Are the integration tests not included? No insult, just wondering if they ran.

It's tough. Docker integration tests currently fail on stock Ubuntu from what I can tell. Trying to figure that one out...


Docker integration tests should not fail on an ubuntu system with all the dependencies installed (ubuntu-standard 3.8 kernel, lxc version 0.8, tar, git..), and when using the correct build environment (see http://docs.docker.io/en/latest/contributing/devenvironment/)

If tests still fail for you would you mind filing an issue? Thanks!


I actually did file one! But don't check it out until I install that exact build ;)


Can you clarify which integration tests you're referring to? I'd be happy to run them and provide the output.

I ran through the whole process linked from the Github repo (http://docs.docker.io/en/latest/contributing/devenvironment/), though I only gist'd step 5


http://github.com/dotcloud/docker/integration should be the link, thank you!


That 404s for me. I did some googling, and am not able to find any tests outside of the ones linked from the contributions guide

EDIT: It looks like the integration tests reside here:

https://github.com/dotcloud/docker/tree/master/integration

They're called when you run make test, via this chain:

https://github.com/dotcloud/docker/blob/master/Makefile https://github.com/dotcloud/docker/blob/master/hack/make.sh https://github.com/dotcloud/docker/blob/master/hack/make/tes...

It looks like the integration tests may not be running because the AUFS test failed?

I manually adjusted the Makefile to run the integration tests anyways, and here's the result:

https://gist.github.com/akerl/8251863

It appears to have a very unhappy time, primarily because the memory cgroup is not enabled. That was a deliberate choice because from what I can see there is a performance hit for enabling that (as well as the swap cgroup), and we decided to leave that disabled rather than give all users a performance hit in order to benefit docker users.


That's completely understandable. Sorry for not catching the broken link! I don't know what happened there for me doing that.

Linode looks like it's in a lot better shape than DO currently. DO has some issues with Docker that prevent it from being very viable.

I'll have to give it a try, thanks again for being so diligent with the tests! The information is useful.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: