Difference between revisions of "SBR600 Potential Projects"

From CDOT Wiki
Jump to: navigation, search
(Fedora Projects)
Line 36: Line 36:
 
* Maximum number of students: 1
 
* Maximum number of students: 1
 
* Skills required: Linux system administration, problem solving, documentation writing
 
* Skills required: Linux system administration, problem solving, documentation writing
* Resources: wiki notes from previous 2 semesters
+
* Resources: wiki notes from previous 2 semesters, access to the OpenRD and a GuruPlug or BeagleBoard
 
* Expected result: koji-hub running on the OpenRD; a recommendation on whether the OpenRD is suitable for use as a hub for the Fedora-ARM project
 
* Expected result: koji-hub running on the OpenRD; a recommendation on whether the OpenRD is suitable for use as a hub for the Fedora-ARM project
 
* Initial contacts: [[User:Chris Tyler|ctyler]], [[User:Paul.W|PaulW]]
 
* Initial contacts: [[User:Chris Tyler|ctyler]], [[User:Paul.W|PaulW]]
Line 49: Line 49:
 
* Expected result: a kernel (or kernels) for use with the PanadaBoard and the Fedora 12 or Fedora 13 root filesystems; user documentation on how to set up the PandaBoard with Fedora
 
* Expected result: a kernel (or kernels) for use with the PanadaBoard and the Fedora 12 or Fedora 13 root filesystems; user documentation on how to set up the PandaBoard with Fedora
 
* Initial contacts: [[User:Chris Tyler|ctyler]], [[User:Paul.W|PaulW]]
 
* Initial contacts: [[User:Chris Tyler|ctyler]], [[User:Paul.W|PaulW]]
 +
 +
== Add PandaBoards to the Fedora-ARM Build System ==
 +
 +
We have 15 PandaBoards on order for the Fedora-ARM build farm. These machines need to be configured and added into the farm, and then optimized to build packages as quickly as possible.
 +
 +
* Maximum number of students: 2
 +
* Skills required: system administration, network administration, troubleshooting, benchmarking
 +
* Resources: PandaBoard systems
 +
* Expected result: a filesystem image and documented standard operating procedure for adding PanadaBoards to the build farm; new PandaBoards actively building
 +
* Initial contacts:  [[User:Chris Tyler|ctyler]], [[User:Paul.W|PaulW]]
  
 
== iSCSI/AoE Support ==
 
== iSCSI/AoE Support ==
Line 82: Line 92:
 
= Fedora Projects =
 
= Fedora Projects =
  
== Package the ==
+
== Package the Weave Server ==
  
== Get the Mozilla Weave Server into Fedora ==
+
Mozilla Sync is a technology for synchronizing personal data (bookmarks, passwords, form values, and cookies) across multiple machines. It uses a server known as [[:mozilla:Labs/Weave/Sync/1.0/Setup Weave]].
 +
 
 +
This project involves packaging Weave for Fedora and getting it through the package-approval process. (Why package the Weave server? So that people can run a private version, either for enhanced security or for testing).
 +
 
 +
* Maximum number of students: 1
 +
* Skills required: Apache administration, packaging
 +
* Resources: CDOT systems
 +
* Expected result: the Weave server will be available in the main Fedora repositories (yum install weave)
 +
* Initial contacts: mhoye
  
Mozilla Sync is a technology for synchronizing personal data (bookmarks, passwords, form values, and cookies) across multiple machines. It uses a server known as Weave.
+
== Package the WIX Toolchain ==
  
This project involves packaging Weave for Fedora and getting it through the package-approval process.
+
WIX is an open-source packaging system for Microsoft Windows software. It is used to prepare software packages that can be installed on a Windows machine. However, the WIX tools themselves can run on Linux.
  
 +
This project involves packaging WIX for Fedora and getting it through the package-approval process.
  
 +
* Maximum number of students: 1
 +
* Skills required: packaging
 +
* Resources: CDOT systems
 +
* Expected result: the WIX software will be available in the main Fedora repositories (yum install wix)
 +
* Initial contacts: mhoye
  
== fedpkg Test Suite ==
+
<!-- == fedpkg Test Suite ==
  
 
''fedpkg'' is a new Fedora packager tool written by Jesse Keating; it's one of the main command-line tools that a packager will use. It needs a test suite, so that as new features are added, regressions can be detected.
 
''fedpkg'' is a new Fedora packager tool written by Jesse Keating; it's one of the main command-line tools that a packager will use. It needs a test suite, so that as new features are added, regressions can be detected.
Line 98: Line 122:
 
* Maximum number of students: 2
 
* Maximum number of students: 2
 
* Initial contacts: [http://jkeating.livejournal.com/ Oxf13]
 
* Initial contacts: [http://jkeating.livejournal.com/ Oxf13]
 
+
-->
 
== Koji Setup Documentation ==
 
== Koji Setup Documentation ==
  
 
Koji documentation is obsolete and needs a major overhaul. This project involves reading the current documentation, updating and editing it, and testing it by setting up a Koji system.
 
Koji documentation is obsolete and needs a major overhaul. This project involves reading the current documentation, updating and editing it, and testing it by setting up a Koji system.
  
Initial contacts: [[User:Chris Tyler|ctyler]], dgilmore
+
* Maximum number of students: 2
 +
* Skills required: writing, system administration
 +
* Resources: CDOT systems, Wiki
 +
* Expected result: a complete, well-written guide to setting up a Koji system (from A-Z)
 +
* Initial contacts: [[User:Chris Tyler|ctyler]], dgilmore
  
 
== AutoQA ==
 
== AutoQA ==
 
[[:fedora:AutoQA|AutoQA]] is an automated test system for Fedora. At present there are event watchers for koji builds, bodhi updates, repo changes, and nightly installed images; these events trigger a small number of tests, but more tests are needed.
 
[[:fedora:AutoQA|AutoQA]] is an automated test system for Fedora. At present there are event watchers for koji builds, bodhi updates, repo changes, and nightly installed images; these events trigger a small number of tests, but more tests are needed.
  
Initial contacts: [[:fedora:User:JLaska|JLaska]]
+
* Maximum number of students: 3
 +
* Skills requires: Python scripting, scripting, system administration, packaging
 +
* Resources: CDOT systems
 +
* Expected results: additional tests for AutoQA, accepted/committed into the main AutoQA codebase
 +
* Initial contacts: [[:fedora:User:JLaska|JLaska]]
  
 
= Fedora-Mozilla Projects =
 
= Fedora-Mozilla Projects =
Line 126: Line 158:
 
= Mozilla Projects =
 
= Mozilla Projects =
  
== hgtools ==
+
<!-- == hgtools ==
 
What if the Mozilla builders were better at managing all the different working directories (from Mercurial checkouts) that we need at any give time? If you look at [https://bugzilla.mozilla.org/show_bug.cgi?id=589885#c11 this conversation from IRC] you can see the benefits of this and [https://bug506404.bugzilla.mozilla.org/attachment.cgi?id=476270 a patch] that has the initial work.
 
What if the Mozilla builders were better at managing all the different working directories (from Mercurial checkouts) that we need at any give time? If you look at [https://bugzilla.mozilla.org/show_bug.cgi?id=589885#c11 this conversation from IRC] you can see the benefits of this and [https://bug506404.bugzilla.mozilla.org/attachment.cgi?id=476270 a patch] that has the initial work.
Initial contacts: [[User:Armenzg|Armenzg]]
+
Initial contacts: [[User:Armenzg|Armenzg]] -->
  
== ScriptFactory ==
+
<!-- == MozHarness ==
  
 
Imagine that we did not have to touch the Mozilla buildbot factories but instead we maintained a bunch of script for all the different jobs they run?
 
Imagine that we did not have to touch the Mozilla buildbot factories but instead we maintained a bunch of script for all the different jobs they run?
  
 
It would be good if we could create scripts that told a machine how to generate an optimized build, a debug build, unit tests, talos runs, locale repackages.
 
It would be good if we could create scripts that told a machine how to generate an optimized build, a debug build, unit tests, talos runs, locale repackages.
If you look in the [http://hg.mozilla.org/build/tools/file/tip/scripts tools/scripts] repo you can see that we have a simple shell file to do this for the fuzzing automation. The buildbot factory that calls it is called [http://hg.mozilla.org/build/buildbotcustom/file/a70b38b40088/process/factory.py#l7895 ScriptFactory] and it is very simple.
+
If you look in the [http://hg.mozilla.org/build/tools/file/tip/scripts tools/scripts] repo you can see that we have a simple shell file to do this for the fuzzing automation. The buildbot factory that calls it is called [http://hg.mozilla.org/build/buildbotcustom/file/a70b38b40088/process/factory.py#l7895 ScriptFactory] and it is very simple. -->
  
 
Initial contacts: [[User:Armenzg|Armenzg]]
 
Initial contacts: [[User:Armenzg|Armenzg]]
 
+
-->
== End-to-end project ==
+
<!-- == End-to-end project ==
 
How can we build faster and provide tests results faster to our developers?
 
How can we build faster and provide tests results faster to our developers?
 
That is what we are trying to figure out and we will be adding bugs to this [https://bugzilla.mozilla.org/show_bug.cgi?id=598175 tracking bug] to optimize
 
That is what we are trying to figure out and we will be adding bugs to this [https://bugzilla.mozilla.org/show_bug.cgi?id=598175 tracking bug] to optimize
Line 145: Line 177:
  
 
Initial contacts: [[User:Armenzg|Armenzg]]
 
Initial contacts: [[User:Armenzg|Armenzg]]
 
+
-->
== I don't like waiting - give me a CPU! ==
+
<!-- == I don't like waiting - give me a CPU! ==
 
We have a hundred jobs running per hour and we sometimes have jobs that have to wait for something before getting started. If we optimized the load we could use the build resources more effectively. I will be adding bugs to this [http://www.themoviemind.com/wp-content/uploads/2008/08/chuck-norris-2.jpg tracking bug] to reduce our load on our pools and therefore reduce our waiting times.
 
We have a hundred jobs running per hour and we sometimes have jobs that have to wait for something before getting started. If we optimized the load we could use the build resources more effectively. I will be adding bugs to this [http://www.themoviemind.com/wp-content/uploads/2008/08/chuck-norris-2.jpg tracking bug] to reduce our load on our pools and therefore reduce our waiting times.
  
 
Initial contacts: [[User:Armenzg|Armenzg]]
 
Initial contacts: [[User:Armenzg|Armenzg]]
 +
-->

Revision as of 13:34, 11 January 2011

Important.png
This is a draft only!
It is still under construction and content may change. Do not rely on this information.
Stop (medium size).png
Old Version
This list is being revised for the Winter 2011 semester.

Introduction

This is a list of potential projects related to the SBR600 course that need people.

Students: Please select a project that you're interested in and add an entry to the project table/participants page.

Open Source Community Members: We welcome your recommendations for potential projects. Please create an account on this Wiki and create a description for your proposed project below. Please list your contact info (just an IRC or FAS2 name is OK) as well as links to any related web pages as Resources for the proposed project. (Questions? Ask Chris Tyler).

Sample Project

This is a sample project stub. You can use the template for Sample Project in order to create a project page for one of the stubs below. This is how you 'sign-up' for a project.

NOTE: if someone has already created the project page, speak to this person and see if you can join them. If so, simply add your name to the Project Leader(s) section on the project page. Otherwise, you can become a contributor later.

Fedora-ARM Projects

System Administration Tools for the ARM Build Farm

As the ARM build farm grows with the addition of the PandaBoard systems, the need for efficient system management tools increases. The previous semesters' students started the work of setting up nagios (monitoring) and func (group control) tools. This project involves configuring these tools to work with all of the systems in the ARM build farm, as well as setting up and configuring the puppet (configuration file management) tool.

  • Maximum number of students: 2
  • Skills required: Linux system administration, problem solving, documentation writing
  • Resources: wiki notes from previous semesters
  • Expected result: nagios, func, and puppet working across the entire ARM build farm; documentation on how to use these tools on the farm and how to add additional devices
  • Initial contacts: ctyler, PaulW

Koji Hub on ARM

The Fedora-ARM koji system uses HongKong, an x86_64 system, as the Koji hub, along with a group of ARM builders.

Ideally, it would be nice to prove the ability of the Fedora-ARM project to be entirely self-hosting by using an ARM system as the Koji hub (this is sometimes called "Eating your own dogfood" in the industry). This project involves configuring the OpenRD-Client system as Koji hub and determining if this is a viable configuration.

  • Maximum number of students: 1
  • Skills required: Linux system administration, problem solving, documentation writing
  • Resources: wiki notes from previous 2 semesters, access to the OpenRD and a GuruPlug or BeagleBoard
  • Expected result: koji-hub running on the OpenRD; a recommendation on whether the OpenRD is suitable for use as a hub for the Fedora-ARM project
  • Initial contacts: ctyler, PaulW

Device Support and Testing: PandaBoard

Various ARM devices need different driver sets and/or kernels. This project will test the Fedora-ARM system on the PandaBoard, creating a kernel that works well with it, and figuring out how to use as many of the built-in peripherals as possible.

  • Maximum number of students: 1
  • Skills required: Linux system administration, kernel building, research, documentation writing
  • Resources: a PandaBoard, notes from other PanadaBoard support projects
  • Expected result: a kernel (or kernels) for use with the PanadaBoard and the Fedora 12 or Fedora 13 root filesystems; user documentation on how to set up the PandaBoard with Fedora
  • Initial contacts: ctyler, PaulW

Add PandaBoards to the Fedora-ARM Build System

We have 15 PandaBoards on order for the Fedora-ARM build farm. These machines need to be configured and added into the farm, and then optimized to build packages as quickly as possible.

  • Maximum number of students: 2
  • Skills required: system administration, network administration, troubleshooting, benchmarking
  • Resources: PandaBoard systems
  • Expected result: a filesystem image and documented standard operating procedure for adding PanadaBoards to the build farm; new PandaBoards actively building
  • Initial contacts: ctyler, PaulW

iSCSI/AoE Support

iSCSI (SCSI over TCP/IP) and AoE (ATA-over-ethernet) are different SAN protocols that can use a standard network. iSCSI did not work reliably in Fedora 12, but will be needed by future ARM server systems. AoE has not been well-tested on ARM systems. iSCSI and AoE need to be tested for stability and performance, and the best solution implemented on the ARM build farm.

  • Maximium number of students: 2
  • Skills required: Linux system administration, debugging and troubleshooting, benchmarking, documentation writing
  • Resources: an ARM system, CDOT PC systems
  • Expected result: iSCSI on ARM fixed and tested, and changes pushed upstream; AoE tested on ARM; report comparing iSCSI and AoE performance on ARM; ARM buildsystem configured to use a high-performing iSCSI or AoE storage solution in place of the existing NFS system
  • Initial contacts: ctyler, PaulW

RPM-based Kernels for Fedora ARM

On a PC, Fedora manages and updates kernels as RPM packages, which modify grub boot parameters and the initial ram disk (initrd, configured by dracut). On Fedora-ARM systems, the kernel is not managed via RPMs, grub is not used, and the initrd system is rarely used. This project involves understanding how the PC (i386/x86_64) kernel/boot/initrd system works, determining which pieces can be reused on Fedora-ARM and which pieces need to be adapted or replaced, and implementing RPM-based kernel management for ARM.

  • Maximum number of students: 3
  • Skills required: Linux system administration, script writing, RPM packaging, kernel building, initrd debugging
  • Resources: an ARM system
  • Expected result: RPM-based Kernels work on Fedora-ARM, with changes committed upstream; documentation about the differences between kernel management on ARM and on PCs
  • Initial contacts: ctyler, PaulW

Fedora-ARM Communication

We're not doing a great job of communicating how the Fedora-ARM project is doing. The status page is very bare-bones and doesn't convey a lot of information, the Fedora-ARM wiki pages need to be made more useful to prospective users, and we need an effective communication strategy with the rest of the Fedora community. This project involves writing some web scripts to create a easy-to-use, informative status page (showing, for example, the current state and progress of the ARM builds), creating user documentation on the Fedora wiki, and fostering effective communication within the Fedora-ARM project and the larger Fedora community.

  • Maximum number of students: 2
  • Skills required: Apache administration, script-writing, effective written communication skills
  • Resources: the web server on HongKong, various data sources within the Fedora-ARM build system, Fedora project communication tools, access to ARM systems
  • Expected result: a useful (easy-to-use, informative) and automatically-updated Fedora-ARM status page; improved user documentation on the Fedora wiki (e.g., how to set up Fedora-ARM on common devices); better communication on the arm@lists.fedoraproject.org mailing list and the #fedora-arm IRC channel
  • Initial contacts: ctyler, PaulW

Fedora Projects

Package the Weave Server

Mozilla Sync is a technology for synchronizing personal data (bookmarks, passwords, form values, and cookies) across multiple machines. It uses a server known as mozilla:Labs/Weave/Sync/1.0/Setup Weave.

This project involves packaging Weave for Fedora and getting it through the package-approval process. (Why package the Weave server? So that people can run a private version, either for enhanced security or for testing).

  • Maximum number of students: 1
  • Skills required: Apache administration, packaging
  • Resources: CDOT systems
  • Expected result: the Weave server will be available in the main Fedora repositories (yum install weave)
  • Initial contacts: mhoye

Package the WIX Toolchain

WIX is an open-source packaging system for Microsoft Windows software. It is used to prepare software packages that can be installed on a Windows machine. However, the WIX tools themselves can run on Linux.

This project involves packaging WIX for Fedora and getting it through the package-approval process.

  • Maximum number of students: 1
  • Skills required: packaging
  • Resources: CDOT systems
  • Expected result: the WIX software will be available in the main Fedora repositories (yum install wix)
  • Initial contacts: mhoye

Koji Setup Documentation

Koji documentation is obsolete and needs a major overhaul. This project involves reading the current documentation, updating and editing it, and testing it by setting up a Koji system.

  • Maximum number of students: 2
  • Skills required: writing, system administration
  • Resources: CDOT systems, Wiki
  • Expected result: a complete, well-written guide to setting up a Koji system (from A-Z)
  • Initial contacts: ctyler, dgilmore

AutoQA

AutoQA is an automated test system for Fedora. At present there are event watchers for koji builds, bodhi updates, repo changes, and nightly installed images; these events trigger a small number of tests, but more tests are needed.

  • Maximum number of students: 3
  • Skills requires: Python scripting, scripting, system administration, packaging
  • Resources: CDOT systems
  • Expected results: additional tests for AutoQA, accepted/committed into the main AutoQA codebase
  • Initial contacts: JLaska

Fedora-Mozilla Projects

Repository Setup for Mozilla Nightlies and Betas

Many web developers want access to the latest Firefox pre-releases, including the nightly builds and beta releases. Mozilla's build team wants to make these accessible as parallel-installable binaries, released through a Fedora-compatible repository. This project involves setting this up.

Subprojects:

  • Build configuration for the RPM files.
  • Repository configuration RPMs.
  • Getting SELinux to work with the nightlies.

-> Bug 600317
Initial contacts: ctyler, armenzg

Mozilla Projects

Initial contacts: Armenzg -->