The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

GSOC13

Overview

One of the differences between the projects listed below and previous years' projects is that all of these should be implemented as stand-alone modules to be distributed on the Forge. This will permit greater longevity and easier maintenance of the code once GSOC ends and keeps focus reasonably tightly scoped.

In addition to the ideas below, we’d accept proposals against any of the “top 25” bugs by community votes, provided they fit the above constraint (can be implemented as an external module without changes to core). That list is here: Tickets – Top By Votes

Idea List

Build a new yum provider

Project Title: Build a Better Yum Provider

Description/benefits: The yum provider (the portion of puppet that installs/removes/upgrade/downgrades rpms), is one of the most commonly used portions of the Puppet code-base by system administrators. However, it has several shortcomings. This project would aim to fix those short-comings and improve the experience of everyone using the yum in their puppet modules. To provide clean encapsulation and backwards compatibility, this should probably be implemented as a separate provider (and maybe even its own Type to avoid further pollution of the Package type) and distributed as a module.

Things that need to be fixed:

  • have the ability to install groups (the command yum groupinstall) via the package resource
  • separate out the architecture of the package as a property (e.g. x86_64 vs i386)
  • allow for multiple versions of the same package (e.g. kernel)
  • refactor for speed in any ways posssible
  • expand the options/parameters that a package resource can take when using a yum provider to closely map to the yum command line interface
  • allow to specifically enable/disable a repo per package resource utilizing the yum provider
  • remove python yum helper and utilize ruby for consistancy (the yum helper is the only bit of python code in the puppet code base)
  • allow upgrade/verification of package that has been renamed or obsoleted
  • group package installs for speed (rather than a single transaction per package)
  • Place inline yard documentation in the codebase to be auto-generated on our github pages for code docs
  • Work with documentation team to improve coverage of the yum package provider

Existing discussion:

Knowledge/Skills Required: Yum, rpm, Puppet, ruby

Skill level (1-5): 4 (Medium)

Mentor:TBD

Backup: TBD

GitlabHQ deployment end-to-end

Project TItle: Setup and deploy GitlabHQ http://gitlabhq.com/

This is also real-world problem around installing/setup of a new popular application. This would be a series of de-coupled module to setup the entire stack for gitlab in a robust way. Some of the needed modules exist on http://forge.puppetlabs.com and could be improved upon; others would need a fresh start.

This is likely a bit more difficult than Mediawiki because it requires Ruby 1.9, (which means running master of Puppet), and involves rails 3 deployments.

The target operating system for this would be Enterprise Linux 6 and Ubuntu Precise. Debian Wheezy would be optional.

This would include de-coupled modules for:

  • Redis
  • Package prerequisites
  • Rails deployment
  • Management of Bundler
  • gitolite setup
  • mysql or sqlite

Skill level: (1-5) 3 (Medium)

Existing discussion, comments, etc:

Mentor: stahnma@puppetlabs.com

Backup Mentor: james@puppetlabs.com

http/https file transport, package source via http

Project Title: write a http/https file transport, package source via http

Description/Benefits: This would allow a source URI to include HTTP for file and packages. Some providers already implement this for package, but all should be able to do so. Also, Files should be able to be http served in the same way.

Knowledge/Skills Required: Ruby, Puppet, HTTP

Skill level (1-5): 2 (Medium)

Existing discussion, comments, etc:

Mentor: stahnma@puppetlabs.com

Backup Mentor: jeff@puppetlabs.com

Student Application Template

GSOC_Student_App_Template