From Fedora Project Wiki
(Created page with "=On-Demand Fedora Build Service= {{:GSOC_2012/Student_Application_nehaljwani}} === Proposal Description === This page shall describe the proposed project. == Overview and The ...")
 
No edit summary
 
(24 intermediate revisions by the same user not shown)
Line 6: Line 6:
This page shall describe the proposed project.
This page shall describe the proposed project.


== Overview and The Need ==
====An overview of your proposal====


On Demand Build Service: This project is intended to help the developers, testers, etc who need to custom-install Fedora for specific purposes by creating a web interface capable of:


''On-Demand build service'' seeks to build Fedora LiveCDs and installation CDs for developers, testers and Fedora consumers.
*  Building and hosting live-images of Fedora [Desktop/KDESpin/LXDESpin/XfceSpin]
* Retrieving packages from the following repos : release,updates,update-testing,koji
** User will be able to specify the version of the package required *  Pull these newer builds (that wouldn't otherwise be pulled in to the .iso) in to the image build.
*  Estabilishing a Client-Login system via open-id.


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.  
and also provide an API as well as CLI for easy-to select, grab and push.


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.
====The need you believe it fulfills====


== Any relevant experience you have ==
This will help clients in the following manner:


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.
* First, testers will easily be able to judge the performance of unstable programs on the TC/RC builds.
* The project will resolve the problem of 'yum install' this , 'yum install' that for each program that a client of a specific organisation/institution requires for his work. Admins/Server People will find this tool very helpful as they can build an image in custom mode and use it on several workstations. Also, people running slow internet connections will find this beneficial.
* Having version of the packet specified by the user will enable the him to work with the version in which he/she feels comfortable and also the developer will be able to check compatibility issues.


====Any relevant experience you have====


== How do you intend to implement your proposal ==
Well, I have experience in automation using scripts and I have the knowledge of creating LiveCDs. Currently, I am exploring the packaging services of Fedora which include building rpms and pushing them into repositories.


*'''Creation of side-repositories'''
====How do you intend to implement your proposal====


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.
* Capturing packages :


*'''Web-based Interface and Job delegation'''
-Creation of a pseudo-repo using metadata which will just contain the list of packages that are available and can be pulled from repos: updates, update-testing, koji and release. This pseudo-repo will be updated regularly so that development versions of various packages are easily available. This repo will not have physical copies of the packages, instead it will just have links to the packages kept in the original repositories.


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'''.
-Upon the selection of client, a temporary side-repository will be built and the required packages for the LiveCD will be kept there till the finish of the build.


*'''Image Hosting '''
* Development of web-based UI:


Once the image is built successfully, the image is pushed by the slave to an image hosting provider along with the logs.
1. The client will be able to create an account which will store all of his previous requests. So that if he wants to make minor changes to previous ones, it will be easy.


*'''Notification'''
2. Since the requests will be pushed into a job queue and will be taken care of by the master node, status of the ongoing process will be available to the client. [In case of multiple requests, or request in queue, the build process might take some time]


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.
3. Once the image is made, it will be available for download from the image-hosting service for a short span of time, say 5 days. Client will be notified and the script used for generating will be stored in for future use.


== Final deliverable of the proposal at the end of the period ==
Key Points:
* Implementation of kickstart file
* Implementation of job queue management system
* Handling the master node
* Implementation of the web-interface


* A build service running as Python web application on the '''master node'''
A Concise Walkthrough Of The Entire Process:


* Client build services running on designated '''build nodes'''
* Client selects the required pacakages from the pseudo-repo.
*  A temporary side-repo is generated, which holds all the required packages.
*  The KickStart file is generated as per the request.
*  The Job Queue system handles the remaining process of builing the live image.
*  After lifecycle of 5 days, the image is deleted and requests are logged.


* A REST API to the build service
=*= Further, I would like to add that since the build tools are going to change after F18, we'll be maintaining a parallel code and keep inculcating changes by following the process going on at the development level of the buid tools. Needless to say, this will help in easily shifting from old to new base as soon as newer versions of the build tools are released.


== A rough timeline for your progress ==
====Final deliverable of the proposal at the end of the period====


* '''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.
* Build Services being processed through web2py on the master node
* Client build services running on designated build nodes
* A REST API to the build service
* Sqlite/MySql storing old requests along with the scripts generated


* '''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.
====A rough timeline for your progress====


* '''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.
*'''Till May 15:''' Developing an automated script like this [Made By Mentor] for retrieving data from repos and creating pseudo-repos. Note: This is just a basic model. The script needs to be modified to suite the needs of the project and make it error-free.


*''' July 20 - August 10:''' REST API implementation to the build service (running off master node), final testing and documentation.
*'''May 16 - June 15:''' Testing Scripts and implementing the build services, implementation of client services
 
*'''June 16 - July 15:''' Testing of http/ftp interface where the image will be hosted, development of RESTful API and job queueing system
 
*'''Mid-Term Evaluation:''' Web-UI will be running and image building services will be available with primitive features. Parallel hosting will have to wait.
 
*'''July 16 - August 5:''' Testing of API and queueing system, improving the user interface for normal users, adding xtra features [if time permits]
 
*'''August 5 - August 10:''' Final testing and documentation
 
====Any other details you feel we should consider====
 
1. Since this is my first project, I'll be happy to handle the part concerning scripting and development of web-ui. I'll explore the implementation of RESTful API and build servcies on the go.
 
2. I would like to add-in sone extra features to the main idea which can be implemented after the base of the project has finished, for eg:
* Adding/Removing packages from official releases.
* Specifying Image Size priorities [optional feature for those who have slow connections], so that if a new version of a particular package has more dependencies, then older one will be taken and size will be controlled under specified limits.  


==Any other details you feel we should consider==


=== Have you communicated with a potential mentor?  If so, who? ===
=== Have you communicated with a potential mentor?  If so, who? ===


[https://fedoraproject.org/wiki/User:Tflink Tim Flink]
* I have communicated with [https://fedoraproject.org/wiki/User:Tflink Tim Flink], who provided me the main idea behind this project and helped me make this proposal.
 
==Other Contact:==
 
* Potential Student Partner :[https://fedoraproject.org/wiki/User:Amitksaha Amit K Saha]


[[Category:Summer_coding_2012]]
[[Category:Summer_coding_2012]]

Latest revision as of 20:41, 5 April 2012

On-Demand Fedora Build Service

Contact Information

  • Email Address: nehaljw.kkd1@gmail.com
  • Telephone: +919052480529
  • Blog URL: commandlinewani.blogspot.com
  • Freenode IRC Nick: nehaljwani

NOTE: We require all students to blog about the progress of their project time to time.

You are strongly encouraged to register on the Freenode network and participate in our IRC channels. For more information and other instructions, see:

https://fedoraproject.org/wiki/GSOC_2012

Please answer following questions.

Why do you want to work with the Fedora Project?

I was introduced to linux last year. Out of all the available distros out there, because of it's simple UI and ease of administrative tasks, I liked Fedora the most. Working with fedora project will enhance my skills and I will be able to acquire more knowledge of open source programs. My interest lies in contributing to open source software programs and Fedora Project is a very nice platform for it. I have been, in the past year exploring the operating system and the way in which it is managed by developers. While using the OS, I found that having desired packages at one place is very difficult. The proposed project will help in creating ready-made image(s) with the required packages and pose a solution for the problem. Hence, I would like to contribute to the proposed project. Also, I will continue to contribute to the project, regardless of the status of my proposal.

Do you have any past involvement with the Fedora project or with any another open source project as a contributor (if possible please add some references as well)?

1. No, this is my first time.

Did you participate with the past GSoC programs, if so which years, which organizations?

1. No, this is my first time.

Will you continue contributing/ supporting the Fedora project after the GSoC 2012 program, if yes, which team(s)/area(s), you are interested with?

1. Yes, Definitely I would like to contribute to:

Fedora Packaging

Why should we choose you over the other applicants?

  • I have 3 months free during this summer, so I'll be able to donate as much time as possible on the project that I choose.
  • I have hands on experience in C, HTML, python, bash.
  • I have played quite a lot with source codes of programs, because in my institution, root access is not provided to undergrads. So, I have tweaked a lot of programs to suite our needs and compiled them for use on our workspace machines.
  • I posses knowledge of subversion systems[SVN,git] and building Fedora live CDs.
  • I am dedicated to the work I do and believe in "Do what you love, love what you do!". I am quite confident that I'll be able to contribute to this project with my efforts at their best!

Proposal Description

This page shall describe the proposed project.

An overview of your proposal

On Demand Build Service: This project is intended to help the developers, testers, etc who need to custom-install Fedora for specific purposes by creating a web interface capable of:

  • Building and hosting live-images of Fedora [Desktop/KDESpin/LXDESpin/XfceSpin]
  • Retrieving packages from the following repos : release,updates,update-testing,koji
    • User will be able to specify the version of the package required * Pull these newer builds (that wouldn't otherwise be pulled in to the .iso) in to the image build.
  • Estabilishing a Client-Login system via open-id.

and also provide an API as well as CLI for easy-to select, grab and push.

The need you believe it fulfills

This will help clients in the following manner:

  • First, testers will easily be able to judge the performance of unstable programs on the TC/RC builds.
  • The project will resolve the problem of 'yum install' this , 'yum install' that for each program that a client of a specific organisation/institution requires for his work. Admins/Server People will find this tool very helpful as they can build an image in custom mode and use it on several workstations. Also, people running slow internet connections will find this beneficial.
  • Having version of the packet specified by the user will enable the him to work with the version in which he/she feels comfortable and also the developer will be able to check compatibility issues.

Any relevant experience you have

Well, I have experience in automation using scripts and I have the knowledge of creating LiveCDs. Currently, I am exploring the packaging services of Fedora which include building rpms and pushing them into repositories.

How do you intend to implement your proposal

  • Capturing packages :

-Creation of a pseudo-repo using metadata which will just contain the list of packages that are available and can be pulled from repos: updates, update-testing, koji and release. This pseudo-repo will be updated regularly so that development versions of various packages are easily available. This repo will not have physical copies of the packages, instead it will just have links to the packages kept in the original repositories.

-Upon the selection of client, a temporary side-repository will be built and the required packages for the LiveCD will be kept there till the finish of the build.

  • Development of web-based UI:

1. The client will be able to create an account which will store all of his previous requests. So that if he wants to make minor changes to previous ones, it will be easy.

2. Since the requests will be pushed into a job queue and will be taken care of by the master node, status of the ongoing process will be available to the client. [In case of multiple requests, or request in queue, the build process might take some time]

3. Once the image is made, it will be available for download from the image-hosting service for a short span of time, say 5 days. Client will be notified and the script used for generating will be stored in for future use.

Key Points:

  • Implementation of kickstart file
  • Implementation of job queue management system
  • Handling the master node
  • Implementation of the web-interface

A Concise Walkthrough Of The Entire Process:

  • Client selects the required pacakages from the pseudo-repo.
  • A temporary side-repo is generated, which holds all the required packages.
  • The KickStart file is generated as per the request.
  • The Job Queue system handles the remaining process of builing the live image.
  • After lifecycle of 5 days, the image is deleted and requests are logged.

=*= Further, I would like to add that since the build tools are going to change after F18, we'll be maintaining a parallel code and keep inculcating changes by following the process going on at the development level of the buid tools. Needless to say, this will help in easily shifting from old to new base as soon as newer versions of the build tools are released.

Final deliverable of the proposal at the end of the period

  • Build Services being processed through web2py on the master node
  • Client build services running on designated build nodes
  • A REST API to the build service
  • Sqlite/MySql storing old requests along with the scripts generated

A rough timeline for your progress

  • Till May 15: Developing an automated script like this [Made By Mentor] for retrieving data from repos and creating pseudo-repos. Note: This is just a basic model. The script needs to be modified to suite the needs of the project and make it error-free.
  • May 16 - June 15: Testing Scripts and implementing the build services, implementation of client services
  • June 16 - July 15: Testing of http/ftp interface where the image will be hosted, development of RESTful API and job queueing system
  • Mid-Term Evaluation: Web-UI will be running and image building services will be available with primitive features. Parallel hosting will have to wait.
  • July 16 - August 5: Testing of API and queueing system, improving the user interface for normal users, adding xtra features [if time permits]
  • August 5 - August 10: Final testing and documentation

Any other details you feel we should consider

1. Since this is my first project, I'll be happy to handle the part concerning scripting and development of web-ui. I'll explore the implementation of RESTful API and build servcies on the go.

2. I would like to add-in sone extra features to the main idea which can be implemented after the base of the project has finished, for eg:

  • Adding/Removing packages from official releases.
  • Specifying Image Size priorities [optional feature for those who have slow connections], so that if a new version of a particular package has more dependencies, then older one will be taken and size will be controlled under specified limits.


Have you communicated with a potential mentor? If so, who?

  • I have communicated with Tim Flink, who provided me the main idea behind this project and helped me make this proposal.

Other Contact: