David Huff wrote:
Jeremy Katz wrote:
| Jeremy Katz wrote:
|> This I'm still not sure that I really want to be carrying in
|> imgcreate. There's already a lot of overlap functionality-wise with
|> anaconda and I know that as soon as we start down this path, we'll end
|> up having to add all the other crud for various more "advanced"
|> partitioning things (especially LVM and dm-crypt). Maintaining one
|> copy of that kind of code is enough for me ;-)
|>
|> I'd be okay with adding the kickstart hunk, though. And then there's
|> really not any big reason that I can see why you couldn't just have
|> the PartitionedDisk bits just in your caller rather than having them a
|> part of the main imgcreate API
|
| ... although I would still strongly ask the question of looking at what
| you're doing and seeing if it makes sense to build your images by
| actually going through an install (in a VM of some sort) rather than
| using imgcreate once you get to the point of needing partitions, etc
Partitions are needed for mainly two reasons. The most important reason
is that it allows the use of grub. This makes any image created with
this tool bootable and it looks and feels like any bare metal system.
It also allows for the ability of creating multiple partitions so an
appliance can have a septate data partition(s). This allows for
flexibility in your update/data model, where if you want to, you can
switch out your "appliance engine" and keep the data intact.
Oh, I can fully see why partitions are useful for a variety of cases...
The ability for a tool to create these partitioned disk images via
the
command like, livecd-creator, is very helpful in reproducing known state
appliances, epically with the rising use of visualization. Going
through a actual install in a vm limits you to VM container, xen, kvm,
vmware and adds extra overhead of building on a machine with extra virt
resources.
Reproducing known state should work just as well with a kickstart config
and doing an install via, eg, virt-install. Yes, it adds overhead, but
there are also advantages in functionality and it also means *not*
maintaining this sort of code in multiple places. And that's a pretty
big win as partitioning code is not in the least bit trivial.
Especially as you start trying to handle more and more of the cases.
We have also noticed that an image that was installed via
anaconda is larger that an image created with the appliance creator
tools.
There shouldn't be any difference to speak of here. Take a look at the
package sets and see if there's anything, but I wouldn't expect this at
all. And if so, it's likely more due to bugs in imgcreate than anything
else
Jeremy