On 01/26/2014 06:02 AM, Saket Sinha wrote:
I have some questions regarding Kiwi internal
working from a developer's point of view. I have gone through the Kiwi
System image cookbook but that mainly targets end-users rather than
1. kiwi takes the initrd, kernel details and the user defined
config.xml as input and creates the desired image. I would like to
know the details as to how it does that.
Here is the high level overview:
- create a directory (location provided by the user)
- use the build system package manager and install the packages that
are listed as "bootstrap"
- chroot into the directory
- now use the package manager inside the chroot and install all the
Repeat the above process for the initrd. The initrd is created based on
a description provided by kiwi, that can also be a user defined
description. There is also some clean up code that prunes the initrd
image we build.
Create a disk image file install the bootloader, put the initrd in place
and all the stuff from the first list I provided.
2. As you have said-
In kiwi we have experimented with many
union approaches using e.g clicfs, unionfs, deltafs, aufs but they
are all running as fuse userspace processes which lead to other
implementations like device-mapper-snapshot and btrfs+seed.
Why and where do you implement this in Kiwi
3. Now regarding the GSOC project.
Kiwi supports Amazon Elastic Compute Cloud (Amazon EC2) which, AFAIK,
is a web service that provides re-sizable compute capacity in the
According to Kiwi Cloud Cookbook-
We just completely changed the way we build the EC2 images and the doc
also changed with it.
For a Simple Storage Service backed Amazon Machine
Image, a bundle
with a manifest XML file is required and KIWI uses the Amazon tools to
create this bundle for you.
We decided to no longer let kiwi do this but shift the bundle and
manifest creation to the user, the doc has been updated accordingly. For
EC2 images we now create a disk image rather than a flat filesystem
image as we did before.
The steps involved are-
1. Register an Amazon EC2 account.
2. Modify the config.xml with the EC2 account information
3. kiwi --prepare
4. kiwi --create
Now the image gets created.
The generated image needs to be transfered over to Amazon which is
done by the ec2-upload-bundle tool.
Now my question is this, what does this GSOC project aim to change in
these above steps. What would be the final deliverable of this
EC2 is pretty much done now. But there are other cloud formats that need
attention. One thing that needs to go away is the initrd regeneration on
boot for cloud images. There is a fair amount of code restructuring to
do to make the kiwi work flow more structured and get the code base into
better shape for unit testing. From a user perspective almost nothing
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
Public Cloud Architect
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org