From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753067AbcHUMCs (ORCPT ); Sun, 21 Aug 2016 08:02:48 -0400 Received: from mail-lf0-f49.google.com ([209.85.215.49]:35201 "EHLO mail-lf0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751694AbcHUMCq (ORCPT ); Sun, 21 Aug 2016 08:02:46 -0400 From: Dmitry Monakhov To: "Theodore Ts'o" Cc: linux-kernel@vger.kernel.org Subject: Re: [PATCH 6/6] Add dockerfile In-Reply-To: <20160820194530.GA9693@thunk.org> References: <1471553651-9547-1-git-send-email-dmonakhov@openvz.org> <1471553651-9547-7-git-send-email-dmonakhov@openvz.org> <20160819052106.GC10888@thunk.org> <87eg5l6rcg.fsf@openvz.org> <20160819232953.GB12834@thunk.org> <87lgzrptgx.fsf@openvz.org> <20160820194530.GA9693@thunk.org> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Sun, 21 Aug 2016 15:02:38 +0300 Message-ID: <87y43ql481.fsf@openvz.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Theodore Ts'o 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 requ= ired, > # so it is impossible during build stage. > # One can make it like this: > # docker run -i -t --privileged --rm dmonakhov/xfstests-bld "cd kvm-xfste= sts/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}-xfste= sts.sh docker/docker-kvm-xfstests.sh=20 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=3D"schroot -c jessie64 --" > SUDO_ENV=3D"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 bui= ld 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 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCgAGBQJXuZheAAoJELhyPTmIL6kBqksH/19kGPICs+77WDxpkm6gMMuY iipmcF5SUV6kdPRDo49pr26wq/qgiQiKnePNEs1wBfatCOGsV5CQymzUinBuDEq6 BSol+iDS4R3RNzdDMtPoaMrWUDPgKiZchJ7BxacToLSXZGWpRcpwxcCAtWfp8q9O wXtiSaMlp98lp4C9I+zgnZlSNsxSwcAQi1DBQRJGYRUtqAO3ucnyfAjzFVQn/Mzf L9t8yNQ9/lTvyZZP+9aQ7jGGFC/m8Y2VrE+wOxm72wguMzVCeT7vtvVtYOCe91S+ i1AKCXKD4jRZhlWHaDdEO0iz71coNvx3dWxXlyxizn/WRW3DFmZko8w8HQ5tON0= =uGY6 -----END PGP SIGNATURE----- --=-=-=--