Messages in this thread | | | Date | Sat, 20 Aug 2016 15:45:30 -0400 | From | Theodore Ts'o <> | Subject | Re: [PATCH 6/6] Add dockerfile |
| |
On Sat, Aug 20, 2016 at 02:31:26PM +0300, Dmitry Monakhov wrote: > > 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. > I can not because I laptop from famous thinkpad t430 series with > flaky SSD which starts to return EIO after intensive load. > https://forums.lenovo.com/t5/ThinkPad-T400-T500-and-newer-T/T430s-Intel-SSD-520-180GB-issue/td-p/888083
Hmm, I never buy a Lenovo SSD; they're overpriced. So I always get my Thinkpads with a 500mb HDD, and then replace it with a Samsumg 840/850 EVO/PRO SSD.
> Also. What about RH/SUSE/Fedora or even Gentoo people? They are exit :) > And if we give them just chance to try debian w/o complexities > maybe they will become debian adepts.
You only need Debain to build the image. If you are just using the pre-built root_fs.img, you can just download it and go.
Speaking of which, that's one thing which I don't understand about your Dockerfile. In the build step you just download the prebuilt root_fs.img from kernel.org. There are comments in your Dockerfile which say:
# Fetch and build xfstests-bld # In order to build root_image from scratch privileged operation are required, # so it is impossible during build stage. # One can make it like this: # docker run -i -t --privileged --rm dmonakhov/xfstests-bld "cd kvm-xfstests/test-appliance && ./gen-image" # During build stage we simply fetch image precreated by tytso@
... but while this will create a new root_fs.img file, as soon as you're you're done the container will exit, and then the root_fs.img file will be blown away, right?
The other thing I'll note here is that the Dockerfile is serving two use cases. One is to user Docker to do automated build testing. The other is for people who want to run multiple instances of kvm-xfstests using the container services.
For the second, we don't really want to include all of the build artifacts and build and source trees in Docker image that the users will have to pull down over the network. And using kvm-xfstests --update-xfstests means a lot of extra wasted I/O, since we're packaging up the tar file, then copying it into file, and then unpacking it inside the guest VM, etc.
So for the second case, you'd really want to create a Docker image which had the minimum packages needed to actually *run* the tests, with the pre-installed root_fs image.
For the first case, all you need to do is to have the Dockerfile create the xfstests.tar.gz file. I suppose this could be used as a poor man's build engine if you don't want to run the build on your local machine. What I do is my top-level config.custom has:
BUILD_ENV="schroot -c jessie64 --" SUDO_ENV="schroot -c jessie64 -u root --"
That's my pristine build chroot, and so when I run ./do-all, what gets executed is:
schroot -c jessie64 -- make clean schroot -c jessie64 -- make schroot -c jessie64 -- make tarball cd kvm-xfstests/test-appliance schroot -c jessie64 -u root -- ./gen-image
I'm pretty sure this is going to be faster than waiting for Docker to build the image, and then for me to download the image and extract the xfststs.tar.gz file. (But then again, I have a fully working laptop with functional SSD's not sourced by Lenovo :-).
- Ted
| |