Message-ID: <20160820194530.GA9693@thunk.org>
Date:   Sat, 20 Aug 2016 15:45:30 -0400
From:   Theodore Ts'o <tytso@....edu>
To:     Dmitry Monakhov <dmonakhov@...nvz.org>
Cc:     linux-kernel@...r.kernel.org
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

Powered by blists - more mailing lists