Line 30: | Line 30: | ||
*'''Web-based Interface and Job delegation''' | *'''Web-based Interface and Job delegation''' | ||
The next step would be to implement an interface (web-based) whereby the user can select the packages he/she wants to be in the installer/live CD. If these packages are available in the main, they are taken from there, else a side repository is built using the packages from updates/updates-testing or Koji. Once the packages are all available, a kickstart file will be generated at the '''master''' node. The master node then delegates this job to a job queue. The job queue management system will be responsible for handing over the jobs to a '''free build node'''. | The next step would be to implement an interface (web-based) whereby the user can select the packages he/she wants to be in the installer/live CD. If these packages are available in the main, they are taken from there, else a side repository is built using the packages from updates/updates-testing or Koji. Once the packages are all available, a kickstart file (for Live images) and other necessary information will be generated at the '''master''' node. The master node then delegates this job to a job queue. The job queue management system will be responsible for handing over the jobs to a '''free build node'''. | ||
*'''Image Hosting ''' | *'''Image Hosting ''' | ||
Once the image is built successfully, the image is pushed by the slave to an image hosting provider along with the logs. | Once the image is built successfully, the image is pushed by the slave to an image hosting provider along with the logs. | ||
*'''Notification''' | *'''Notification''' | ||
On successful/unsuccessful build, an email is sent to the user with appropriate information. If the build was successful, a link is sent to the user to download the image and logs. | On successful/unsuccessful build, an email is sent to the user with appropriate information. If the build was successful, a link is sent to the user to download the image and logs. In case of a build failure, the build logs are sent to the user so that the cause of the error is known. | ||
== Final deliverable of the proposal at the end of the period == | == Final deliverable of the proposal at the end of the period == |
Revision as of 23:05, 3 April 2012
On-Demand Fedora Build Service
Contact Information
- Name: Amit Saha
- Email Address: amitksaha@fedoraproject.org
- Blog URL: http://echorand.me/category/fedora/
- Freenode IRC Nick: amitksaha
Why do you want to work with the Fedora Project?
My second stint as a Fedora user started about an year back, and liked it much more than I had about 10 years ago when I first started using Linux. I was nursing the idea of a custom Linux distribution for scientific and numerical computing for quite some time. I started exploring the options of creating this spin based on Fedora, and the Fedora project's easy and transparent way to propose a custom spin attracted me. In no time I had the Scientific Spin's process rolling. The Scientific Spin was released along with Fedora 16, thanks to the welcoming and co-operative nature of the Spins SIG, release engineering and the Fedora design and websites team.
This first involvement and my growing understanding of the Fedora community makes it a first choice for me for GSoC 2012. Needless to say, my involvement won't start or cease with GSoC.
Past involvement with Fedora Project:
- Creator and Maintainer of the Fedora Scientific Spin
- Mailing list moderator of the SciTech SIG
- Packager (Review awaited)
Past involvement with other Open Source projects:
Did you participate with the past GSoC programs, if so which years, which organizations?
Not yet
Why should we choose you over the other applicants?
There are a few things which should definitely give me a head-start over other applicants
- My experience of creating and maintaining the Fedora Scientific Spin
- My experience packaging for Fedora
- Existing experience with the toolchain (creating/building Fedora live CDs, kickstart files, installers) desired for the proposed GSoC 2012 project
- Possession of Generic toolset knowledge - community and mailing list interaction, version control system and programming knowhow - Shell scripting, Python scrpting and working with the Fedora tools such as Koji, Pungi, Lorax, etc.
- Documentation is important. My articles have appered in Linux Journal, Linux For You, Linux Gazette and elsewhere. So, I actually like documentation.
Proposal Description
This page shall describe the proposed project.
Overview and The Need
On-Demand build service seeks to build Fedora LiveCDs and installation CDs for developers, testers and Fedora consumers.
During the testing of Fedora releases, test images are often useful as smoke tests before full TC/RC composes, as baselines for specific test days or for automated installation testing in AutoQA. The idea is to make an on-demand Web-based build service which users/developers can use to make custom Fedora based distributions.
The service would be capable of building and hosting images (boot iso, installation DVDs and live images) made up of builds from stable repositories in addition to side repos containing specific builds from both updates-testing and koji builds that have yet to be pushed to any repos. The service will also also have a RESTful API which will make it accessible from command-line clients as well.
Any relevant experience you have
As the creator and maintainer of the Fedora Scientific Spin, I am well aware of the LiveCD creation tool chain. I am also knowledgeable about creating local repositories (side repositories) and pulling in packages from there into the installer/Live CD. I am currently exploring building installers.
How do you intend to implement your proposal
- Creation of side-repositories
As a first step, I am experimenting with creating a local repository (side repo) with builds of packages, which are not yet available in the main (either updates/updates-testing or Koji). So far, I have experimented with creating a Live CD having packages from this repository. The next step is to attempt to create installer images.
- Web-based Interface and Job delegation
The next step would be to implement an interface (web-based) whereby the user can select the packages he/she wants to be in the installer/live CD. If these packages are available in the main, they are taken from there, else a side repository is built using the packages from updates/updates-testing or Koji. Once the packages are all available, a kickstart file (for Live images) and other necessary information will be generated at the master node. The master node then delegates this job to a job queue. The job queue management system will be responsible for handing over the jobs to a free build node.
- Image Hosting
Once the image is built successfully, the image is pushed by the slave to an image hosting provider along with the logs.
- Notification
On successful/unsuccessful build, an email is sent to the user with appropriate information. If the build was successful, a link is sent to the user to download the image and logs. In case of a build failure, the build logs are sent to the user so that the cause of the error is known.
Final deliverable of the proposal at the end of the period
- A build service running as Python web application on the master node
- Client build services running on designated build nodes
- A REST API to the build service
A rough timeline for your progress
- Current - May 21: Implementing an automated script which if given a list of packages, retrieves the ones not available in the main and creates a side-repository, and building the web interface.
- May 21 - June 10: Finalize the image creation scripts and have a system containing a master node and a single build node in place. Work on implementing the client service which will run on the build node.
- June 28 - Mid-term evaluation: Evaluate and implement a job queueing system and formalize a way to distribute build jobs. Formalize the Image hosting node specifications - FTP/HTTP interface.
- July 20 - August 10: REST API implementation to the build service (running off master node), final testing and documentation.