[xen-tools] Re: Outstanding bugs/requests for 3.0?

[Steve Kemp]

On Tue, Nov 28, 2006 at 01:00:16AM +0100, Henning Sprang wrote:

> I think it's not simple, but maybe you have an idea to make it simple:
> 
> Since a while am thinking that I need something like "simple presets"
> to recreate a vm for some host again in an easy and fast manner, by
> only entering the hostname.

  Right that sounds like an interesting idea.

> Maybe I can just create an extra config for each domain and use it with -c?
> But then I have a lot redundancy in all my config files, so what would
> be needed would be a possibility to include a generic config file and
> kind of "overload" it with the diffs that are needed for a specific
> vm.

  That should be doable.  So far what happens is:

    1.  Read /etc/xen-tools/xen-tools.conf (if it exists only).

    2.  Parse command line arguments.

  It has to be that way round so that command line arguments override
 the defaults in the configuration file.

  However it seems to me that I could have:

    3.  If --config=foo.conf then read /etc/xen-tools/foo.conf
       (Or the file if qualified).

  That would easily allow you to complete "hostname=xxx \n size= 999\n"
 from that file with only one parameter.

  Does that sound like a reasonable approach?

  It doesn't help much with scripting the xen.cfg file which is
 generated however you could use templates for that and specify
 "template=xxx" in each configuration file.

> Sorry for not putting this into the BTS already - iut's probably too late...

  If you're happy with the idea as presented it would be trivial to add.

> I've not had enough time to check it all intensively. Most issues I
> posted seem to be fixed.

  A good start.

> Hmm, you are right, the correct error handling that I thought was done
> seems to have some bugs, sometime this week I had a failed vm creation
> transaction that ended up with an lvm volume created but no vm config
> file, so the volume had to be deleted manually.
> (maybe in my fedory test, so not that important for now - i'll get
> back at this later).

   OK will look forward to hearing about that.

> And one usability thing that's probably really easy: on one hand, it's
> nice to have less typing when deleting domains with xen-delete-imags
> HOSTNAME, on the other hand, it's not consistent with the creation
> syntax. I'd kind of expect the delete program take the same argument
> to destroy the image as the creation program.

  It seems redundant to me to specify --hostname=xxx rather than
 just "xxx".  Since we're only ever talking about hostnames/image names.
  I could overload the script to accept both if you liked. I have no
 preference either way.

> And one interesting thing might be to have the correct kernel version
> in the default config file when installing. Unfortunately, the Debian
> Xen kernels don't come with the simplyfied Kernel Symlinks as the
> XenSource version does (vmlinuz-2.6) - maybe it's worth a wishlist bug
> against the xen kernel package?

  Wishlist bug wouldn't go amiss, but I dont think I'm the right person
 to add this.  I think it belongs in the debian/postinst file.

  Funnily enough I wrote code to do this once before but lost it
 when I did a hasty rm.  What I did was:

   kernel=` ls -1 /boot | grep ^vm  | grep xen | head -n 1`
   ramdisk=` ls -1 /boot | grep ^init | grep xen | head -n 1`

  Then used sed + awk to update /etc/xen-tools/xen-tools.conf if
 they were non-empty.  It might not be always correct, but I
 do recall it worked on all the machines I tried.  (Since I only
 ever had one "xen"-suffixed kernel and initrd in place.)

  Worst case is it guesses wrong and you have to fix it.  Best
 case you have no need to fix things.  One for the maintainers I guess.

Steve
--