On 01/26/2014 06:02 AM, Saket Sinha wrote:
Hi Marcus,
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 the developers.
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 other packages 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 cloud. 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 project?
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 would change. HTH, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead Public Cloud Architect rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org