SBR600 Potential Projects

This is a draft only!
It is still under construction and content may change. Do not rely on this information.

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
• 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

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

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.

• Maximum number of students: 2
• Initial contacts: Oxf13

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.

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.

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

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 this conversation from IRC you can see the benefits of this and a patch that has the initial work. Initial contacts: Armenzg

ScriptFactory

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. If you look in the 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 ScriptFactory and it is very simple.

Initial contacts: Armenzg

End-to-end project

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 tracking bug to optimize our infrastructure.

Initial contacts: Armenzg

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 tracking bug to reduce our load on our pools and therefore reduce our waiting times.

Initial contacts: Armenzg