7:01 p.m.
On Tue, 2008-02-19 at 19:16 +0000, Daniel P. Berrange wrote:
On Tue, Feb 19, 2008 at 01:58:46PM -0500, Jeremy Katz wrote:
> On Sun, 2008-02-17 at 02:14 +0000, Daniel P. Berrange wrote:
> > This patch adds support for another installation variant. The livecd-creator
> > produces ISO images which boot using syslinux. The image-creator creates a
> > single file containing a filesystem in which the OS is installated. This patch
> > adds a new disk-creator, which creates a single file containing a partitioned
> > disk with potentially many filesystems in which the OS is installed.
Furthermore
> > it installs grub in the boot sector, so this image is immediately bootable in
> > a virtual machine.
>
> Seems reasonable enough and it's something I had started looking at. My
> biggest concerns end up being scope... the next thing someone will want
> to add is RAID. Or LVM. Or dm-crypt. And I sort of wonder where it
> ends. I already gets bugs on one copy of code like that and it's called
> anaconda ;-)
Where to draw the line is an interesting question. If you consider the created
appliance as primary serving for deployment in virtual machines, then I'd
argue that RAID / crypt is out of scope. They would be a site-specific deployment
question. If an admin wants encryption they can set it up in the host directly.
Likewise RAID can be done in the host already so its redundant for guests.
The admin of the virtual machine isn't necessarily the admin of the
host, though. At which point encryption, at least, becomes relevant.
LVM would be useful if only to make adding storage to the appliance
easier.
So I'd declare that scope is limited to plain partitions + LVM.
Others could well argue differently, though, is my point. And
especially when you're already saying that LVM is desirable, I start to
lean towards really think that this is the wrong approach.
> > I've used this tool to create an instance of the oVirt
web management appliance
> > from its kickstart recipe. Currently developers building the appliance have
to
> > boot a VM using the F8 boot.iso and run the kickstart script in the VM and so
> > on. While this works, involves many steps with potential for failure. This new
> > tool reduces the problem to simply
>
> As opposed to virt-install --name ... ? I'm not convinced there's a
> huge gain in terms of number of places for failure :-/
You have to have a working virtualization stack & it takes more resource
overhead than just doing the chroot'd build. Emprically the part of our
build process doing the guest based installs has been less reliable than
the livecd-creator part. Havinga disk-creator will address that problem
You have to have a working virt stack to *use* virtualization or test
things. I'm not sure that't eh argument to use. And as far as
reliability, what bugs are you talking about? livecd-creator has
managed to have lower numbers of bugs largely due to a) less
functionality and b) less users.
> > With the background information out of the way, here's
some info about the
> > changes in this patch...
>
> Ob-side-note: your patch doesn't seem to be against master or at least,
> is missing some bits as it doesn't want to apply.
I used a fresh git checkout from saturday for doing all the work against
and don't see any changes since then.
Are you sure it's diff'd against master and not something earlier of
yours? As it doesn't include all of imgcreate/disk.py and you created
it.
> Sounds okay... the API change involved is a little unfortunate,
but
I
> did caveat that the API in -14 isn't guaranteed, so it should be
fine.
If its really a problem, we've got the option of just leaving the
existing
classes unchanged & deprecating their use in favour of the new ones,
but
if no one is using the API seriously yet it might not be worth the
hassle.
Probably not worth the hassle, I was just calling it out to see if
anyone else noticed and thought so.
> > Aside from partitioning, DiskImageCreator will setup an
fstab file containing
> > entries for all the filesystems and swap space. It will add the grub device
> > map file, and create a grub.cfg based off the installed kernel. It is able
> > to cope with a layout where grub config is on /, or a separate /boot
partition.
> > We can't use grub-install since it doesn't understand loopdevices, so
to do
> > the MBR install we invoke grub manually.
>
> Yeah, and this can be tricky. At least historically, there have been
> cases which setup wasn't sufficient for and we had to do the full
> install invocation. Which is why that's what anaconda does.
On the flip side anaconda has a much broader use case than we have to worry
about for creating appliances. Looking at the final grub commands that
grub-install actually runs, there's nothing magic we can't do directly. The
problem with grub-install is all the 'sanity' checking & probing it does
before actually running grub, which simply doesn't apply to loop devices.
By install, I didn't mean grub-install, I meant running the
(lower-level) install command from the grub shell. We really should be
sure to have as much consistency as we can here
Jeremy