[xen-tools] Re: Various potential modifications

[Steve Kemp]

On Mon Oct 01, 2007 at 17:50:23 -0400, Jeff Forcier wrote:

> Got a handful of comments/questions and didn't feel it would be
> prudent to make a separate mail for each - let me know if I should
> split any of these off into its own thread for some reason. I'll
> number them to make it easier to reference - please don't take this as
> some sort of demands list :D

  Probably ok this once, but generally it is easier to keep track
 with one mail per subject..

> Apologies for the length - I've tried to include enough backstory so
> that it's clear where these queries are coming from, and that I tried
> to do at least a little homework before posting.

  That's fine.

> 1. domU user accounts: an issue I mentioned to Steve a few weeks ago,

> I tried a 'users' role script, only to realize that it doesn't work
> because role scripts are executed via runCommand() which eats/logs
> stdout, thus causing problems during the password-entry phase.

  I remember the conversation, and the rationale for the multiple
 role scripts.  But now that I've thought about it there are
 several issues with the stdio redirection that I think could
 be annoying.

  My initial inclination would be to have a role script to add
 the accounts, but not in the way that you're currently doing
 (with 'passwd').  Instead have a script which takes an
 input file of:

 username:password

  (Ideally a salted + crypted password which the role script
 could update directly via 'pwconv' / 'usermod'?)

> 2. IP address (re)allocation: unless I'm missing something, there is
> currently an auto-allocation mechanism for increasing subsequent IP
> addresses from a starting number. 

  Agreed, the current handling is not ideal.  Having xen-delete-image
 manage the de-allocation of IPs would be useful.  I guess a new
 format such as:

 192.168.1.1
 192.168.1.2:used
 192.168.1.3:used

  Or similar would suffice there?  Then on creation we'd scan for
 an IP which wasn't marked as used?  (And similarly remove the
 :used upon deletion.)

  That should be a simple change, the downside is that you would
 have to enumarate a range rather than just the starting number.

  (Altnertively I'd be happy with IP[ :]xen name. But that feels
 a little like duplication /etc/hosts ;)

> 3. Extended .deb caching


  I believe this should actually be handled already.   Certainly
 the intention is there.

   1.  We copy /var/cache/apt/archive/*.deb -> the guest.

   2.  We use debootstrap.

   3.  We use a role script (which will donwload mising files into the
      /cache/ directory on teh guest.)

   4.  We're all done

   5.  We copy guest:/var/cache/apt/archive/*.deb -> the host.

  That should mean that subsequent 'apt-get install' processes will
 find the existing packages.

  If you can demonstrate that failing it is a bug and I'll fix it.

> 4. Fine-grained 'skel' behavior: Kind of an out-there thing, but I was
> curious if there are any decent solutions for wanting to tweak just
> one or two specific options in config files instead of wholesale
> replacements as is currently done with the /etc/xen-tools/skel/ stuff.

   I can't think of a neat solution should have having per-host
  skel stuff, or per-role skel.  eg /etc/xen-tools/skel.$role.d/
  and a role to copy over the contents.  But I think that'd get
  messy fast.

> I originally started out writing additional role scripts that ran some
> sed replacements on the domU stock config files, but ended up just
> using the skel framework as it was quicker. Being an idealist I was
> curious if there's a better way to approach this. Or I could just be
> thinking about this too much :)

  I have an 'install cfengine' role which allows me to do this
 post-install .. ;)

Steve
--