[xen-tools] Re: Multiple role scripts ..

Steve Kemp steve at steve.org.uk
Mon Sep 24 22:31:16 CEST 2007


On Mon Sep 24, 2007 at 13:24:27 -0700, C.J. Adams-Collier wrote:

> I didn't mean a *working* OS.  I meant something that would allow
> xen-create-image to complete its run with a $? == 0 status.  I bet we
> can fit this in 10M.  But still, increasing the distribution by 10M is
> not an optimal situation.

  Given that /etc/ contains the only real source of files that
 would be changed I'd be happy enough to have $dist.etc.tar.gz
 as an HTTP download, or similar.

> >   --install-method=debootstrap --install-source=http://us.debian...
> 
> I disagree.  In order to create a testable situation, we need a
> control environment.

  I agree.

  My understanding of your suggestion was that we would have:

    1. A minimal install which would be configured via xen-tools.

    2. A static MANIFEST file which would contain the results
       of running an install which we'd test against.

  From that point of view running --install-method=debootstrap
 would allow the minimal install to be completed and compared
 against the static MANIFEST you described.

> debootstrap will potentially generate a different filesystem every
> time it is run. 

  No it wouldn't.  (OK timestamps will be different, but everything
 else will be the same.)

  If you're just going to use a static static collection of files
 then the test becomes meaningless.

> If we have a tarball that we populate, we can create
> a controlled situation that we can test against.  Not to mention,
> debootstrap creates *many* more files than are strictly necessary for
> xen-create-image to successfully run.

  True, but a test is a test.  And the full install is a useful
 one which doesn't require any large download added.

> it *is* important to have a test case for debootstrap as well, of
> course.  I don't think we should use the live debian servers for this,
> however.  In order to create a control, we should take a snapshot of
> the mirror and strip it down to only those .deb files required for
> debootstrap to complete successfully.  We should use this control
> mirror as the argument to --install-source.  This is still not
> strictly a control situation, however, since the version of
> debootstrap on the builder's machine may vary.

  I see two ways forward:

    1.  Have a small tarball of just:

        /dev/
        /etc/

       That could be untarred and manipulated woth xen-create-image.
      This will allow us to test that $prefix/etc/hostname is setup,
      that $prefix/etc/inittab is setup, etc.


    2.  Test against http://debian.org, running a full debootstrap
       install.  This will be simple to test, and simple to code,
       but will be much slower and can't be done offline.

  You seem to be suggesting the first approach, I was interested
  in the second - but I think as soon as we reach the point where
  we're tarring up *debian packages* we might as well not bother
  and go straight for the second.

Steve
-- 
# Commercial Debian GNU/Linux Support
http://www.linux-administration.org/






More information about the xen-tools-discuss mailing list