Messages in this thread | | | Date | Fri, 19 Aug 2016 19:29:53 -0400 | From | Theodore Ts'o <> | Subject | Re: [PATCH 6/6] Add dockerfile |
| |
On Fri, Aug 19, 2016 at 12:27:43PM +0300, Dmitry Monakhov wrote: > Actually main idea is to have build environment for xfstests-bld development > plus automatic builds gives us CI. This is important because > xfstests-blk build is silently broken since May 30 due to 82c3a179 > (fix proposed: https://github.com/dmonakhov/xfsprogs/commit/5dc7a0805d6b7a265863413a8e1b7acb191d5280) > But this was uncovered because most people do not build xfstests-bld > from scratch very often, we all too busy. Let's machine do that :) > In fact other good candidate for CI is https://travis-ci.com/
Actually, I'm rebuilding all the time, but I'm not upgrading to the latest bleeding edge version of xfsprogs all the time. In fact, I'm currently still using xfsprogs v4.5.0, since that's plenty for the testing I'm doing. I have historically pinned the commit Id's for certain projects where newer versions were either (a) known to be flaky, or (b) known to be broken in some way -- that's why we currently have explicit commit ID's for fio and quota. Perhaps I should add one for xfsprogs as well, so that we only upgrade to newer versions when it known to be needed and where it's helpful.
> Once we have Dockerfile which encapsulates all dependencies > one can create xfstets-blk from scratch simply typing > $ docker build -t my-xfstests-bld-image --file Dockerfile > Or use precreated environment > $ docker pull XXX/xfstests-bld
If you use the precreated environment that will have a fixed commit ID. So the advantage of doing continuous integration of the bleeding edge version of xfsprogs only works if you are using the "docker build" line, right.
> Once image is created > Log in to container and start hacking xfstest or e2fsprogs etc. > $ docker run -i -t XXX/xfstests-bld > $ emacs xfstest/tests/ext4/023 .... > $ kvm-xfstests --update-xfstest ext4/023 > ...
I'm not sure I see the advantage of doing this in a container, I guess. I just do in my standard laptop environment today.
> Other useful feature is ability to speed xfstests-bld by splitting > full test-set to groups and run kvm-xfstests instances in parallel. > For example: > docker run -v my-kernel:/my-kernel XXX/xfstests-bld \ > kvm-xfstests.sh --kernel /my-kernel/bzImage -c 1k > 1k.log & > docker run -v my-kernel:/my-kernel XXX/xfstests-bld \ > kvm-xfstests.sh --kernel /my-kernel/bzImage -c 4k > 4k.log & > docker run -v my-kernel:/my-kernel XXX/xfstests-bld \ > kvm-xfstests.sh --kernel /my-kernel/bzImage -c dax > dax.log & > ..... > w/o sand box they will conflict due to net ports (localhost:7500 etc)
... and because you will need separate scratch disks for each of the docker runs.
OK, I can see how that's certainly an advantage.. This is what I use gce-xfstests for, myself. :-)
The main thing I don't really like about the Dockerfile is that with the exception of the last use case, everyone would really need to have their own customized version of the Docker file, right? And for someone who isn't Docker aware, I'm concerned that it might be very confusing to use, especially compared to all of the documentation I currently have for kvm-xfstests and gce-xfstests.
Hmm, I'll have to think about this and play with it a bit more...
- Ted
| |