[buildd-tools-devel] Some schroot (union) fixes

[Roger Leigh]

On Thu, Jul 30, 2009 at 09:10:49PM +0200, Jan-Marek Glogowski wrote:
> > The major recent change has been the merging of the union filesystem
> > support from Jan-Marek Glogowski.  I'd like to release a development
> > version (1.3.0) for further testing once I have confirmation that what
> > was merged is working.  Could anyone verify this?  Jan?
> 
> The following patches contain my patches on the top of current master.
> At least the patches 07-11 are needed to build a package with working
> union and sbuild support.

Great stuff, thanks!  I'll apply them as soon as I've got the facet
stuff I'm currently working on done (nearly finished, in fact).

> > Chroot Facets
> > ------------- 
> 
> Generally a good idea. We already added a lot of "base" classes, so the
> chroots inherit their "correct" features. I guess virtualisation would
> make the whole inheritance tree almost unmanageable. Interfacing the
> feature classes (union, source, mountable) helped a bit, but facets look
> much simpler to manage.
> 
> Do you really want to convert everything before the next release?

Not everything, just everything except the basic chroot storage types
(directory, file, loopback etc.).  They will only inherit from
sbuild::chroot, and everything else will be a facet.  I've now
converted everything except chroot_mountable (almost finished) and
chroot_union.  (Since chroot_union inherited from a few others, these
needed converting first.)

The conversion is very simple, requiring very few source changes.  The
changes are only related to removing assumptions about where certain
data and functions are located, mainly by adding in get_facet() calls.

The basic chroot storage types will also be converted into facets,
but I'll wait until your patches are merged before doing that.

The main advantage is that you don't need to explicitly call all the
methods in the parent class(es), making the code much simpler.
Some conditionals such as if sessions are active or not also just
become the presence or absence of a given facet.  This will make
serialisation more robust, as will adding new functionality.  I've
already found a few (minor) discrepancies between how different
chroot types handle SESSION_CLONE, for example.  But the testsuite
still passes, so it's all still working correctly!

> > I'd like > to support other types of virtualisation (kvm is my initial
> > aim), and this will require modular support for how we run commands,
> > since for kvm we can't just do an exec.
> 
> AFAIK there are already a few projects, which implement virtual machine
> managers for Xen / kvm (virt-manager, xen-tools, ...). How does 
> virtualisation fit into the schroot concept? VMs already have the normal
> access control from the installed OS.

This is true.  What we get is mainly a unified interface to accessing
such features.  Since sbuild uses schroot to access chroots, extending
the virtualisation functionality of schroot will automatically give
sbuild access to these features.

> > schroot client-server protocol using IETF secsh-filexfer protocol
> > -----------------------------------------------------------------
> 
> ...
> 
> > A design issue with schroot relating to its origins as a more
> > advanced dchroot replacement is that it is a setuid-root program
> > which runs in a single shot.
> 
> I don't think that's an issue - for me it's a good descition based on the
> the requirements.

It still is, for the current model of chroot virtualisation, but we
are starting to hit on certain limitations in the design.

Internally, it will make the locking and resource management much
simpler and more robust, since we can use RAII and the new facet-based
chroot properties to do this.  That is, "session = chroot->clone_session()"
will implicitly create the session file, locks etc. and these will be
removed on object destruction.

> ... <a lot of mor stuff for VM managments (as kind of chroots)>
> 
> I'm not using VMs except for testing our distributions installations. I
> guess cross-compiling would be easier using a qemu system, then building
> a complete cross-compiling chain (when used with sbuild).
> 
> So is there a good scenario, where a feature like that would help?

It will mean you can use qemu and kvm-qemu to work with sbuild, and
this would allow one to do cross building on a single system.  You
could use quad core opterons to build the m68k distribution!


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20090730/c248168b/attachment.pgp>