Re: [PATCH 6/6] Add dockerfile

[Dmitry Monakhov]

Theodore Ts'o <tytso@xxxxxxx> writes:

> 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?
Yes. This is my typo. Generated image should be saved somewhere
before container stopped. So command should be
docker run -i -t --privileged -v ~/my-data:/shared --rm dmonakhov/xfstests-bld \
    "cd kvm-xfstests/test-appliance \
    && ./gen-image \
    && cp root_fs.img /shared/"
Probably it should be moved to dedicated script, see later.
>
> 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.
Yes. That is reasonable idea. Actually I already have it in my queue.
Probably it it reasonable to create dedicated directory ./docker
and place all docker related crap there:
# build scripts
docker/Dockerfile.build-env
docker/Dockerfile.run-env
# And some run scripts
# Build all environment from scratch
docker/docker-build.sh
# Move config, kernel, root_fs.img inside container and run {gce,kvm}-xfstests.sh
docker/docker-kvm-xfstests.sh 
docker/docker-gce-xfstests.sh
> 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 :-).
Definitely. But in your case we still need jessie64's chroot.
It should be prepared somehow. My point is that if we give an automated build
script this may help people to start with xfstests with less pain.
In my experience time spend on investigation of installation process
always longer than time to download precreated VM/container :)
Let's call this approach "Lazy developers are welcome"
>      		      	  	     	    - Ted

Attachment: signature.asc
Description: PGP signature