[FrontPage] [TitleIndex] [WordIndex] 

This is a read-only archived version of wiki.centos.org

Ideas for GSoC 2014

Ideas for GSoC can be of direct benefit to the CentOS Project, such as tools to help contributors. They can be of benefit to the wider world, such as 'yum' plugins or packaging to help SIG variants. They can be of use to an upstream that is in CentOS Linux and a benefit to all free/open source software and Linux users (as long as a mentor can be found.)

Students: Use this page to give you a specific idea or generate an idea for your proposal.

Mentors: Write up your ideas here, and let us know who is interested in being a mentor; one main mentor is preferred but it's fine to have extra/back-up mentors. It is also good when an idea is associated with a full team.

Contents

  1. Idea: Template
  2. Yum plugin to handle multiple repositories
  3. Idea: ARM port of CentOS
  4. Idea: mechanism to build container images on demand, rapidly
  5. Idea: yum plugin to handle docker /container images
  6. Idea: Build a storage appliance OS
  7. Idea: Xen based Hypervisor in a Box
  8. Idea: Your idea here

1. Idea: Template

Summary of Idea e.g. Cool extension to contributor account system

Short description of idea. This paragraph is short, usually two to four sentences that explain the core of the idea.

Details

Long description of the idea. This section can be as long as is needed to describe the problem and solution. Implementation ideas can be included, but are not necessarily required. For more details, ask the project mentor.

Mentor:

2. Yum plugin to handle multiple repositories

Yum plugin to assist users in consuming SIG variants and dependent repositories

As users are consuming the work of special interest groups (SIGs) that maintain CentOS variants, this plugin will help keep track of packages that may be similar across repositories. This will be especially useful where priorities or projectbase are too confusing or don't work as expected.

Details

Some kind of framework to easily manage yum repositories -- based on the -devel mailing list threads, this looks like it's going to be essential for the SIGs, and the existing methods of priorities or protectbase are not going to work.

Doing things with include/exclude lines on repos may work, and that'll be fine for experienced admins, but that's not going to work out well for the vast majority of the people the SIGs are targeting.

A command line tool to somehow manage this would, IMO, be a good time investment, and something that could easily fit within a GSoC project. A stretch goal would be a TUI and/or GUI wrapper.

Mentor:

3. Idea: ARM port of CentOS

Work on porting CentOS to ARM hardware

Work with other CentOS contributors on a portion of the project to port CentOS to ARM hardware.

Details

To be decided with the student, based on experience and skill level. The goal is to make a project that is doable in the Summer and adds to or completes the ARM port effort

Mentor:

4. Idea: mechanism to build container images on demand, rapidly

build a git driven app that runs as a service, centrally, to deliver container images

Given a manifest file, that describes how a container should be setup, we should be able to create an image and writeout some metadata that can then be consumed by a yum plugin to download, install and manage the container on the user machine. This project aims to build and run the services needed on the build system side of the repository.

Details We want to make it easy for people to define what a container should look like, the app its going to host, and the interfaces it needs to run with. Then be able to take that information and convert it into container, inject it into a repository of containers, that can then be used very easily on the user machine ( via a yum plugin ). The scope of this effort will be limited to delivering the code required to build the containers and the server side infra needed to run a repository of container images. Visualise this as an app market, but of containers.

The largest challenge in this problem space is going to be working out and implemention a mechanism to establish relationships between container images.

Mentor:

5. Idea: yum plugin to handle docker /container images

a single yum command that can download and install container images

Containers are going to be big moving into the future as a way to download and run silo'd instances of applications and services. In this effort, we would setup a serer side repository of pre-built, and pre-configured images that are consumeable directly under lxc/docker; we would then write the yum code needed to expose that repository to the users and a few simple commands to download and install the images users want.

Details The problem space we are trying to address here is that at the moment, there is no way to easily mass build and promote container images ( a problem easily solved in the rpm world with yum and the server metadata for rpm/yum repositories ). Given that the mechanism to facilitate this already exists in yum, it makes most sense to just consume that interface along with the backend support, and run it for container images. We need to be able to implement 'yum list container', 'yum install container', 'yum erase container'. Due to the nature of how containers work, we will not need to implement a 'yum upgrade container' command since the instance would update using its own yum mechanism inside the container.

Mentor:

6. Idea: Build a storage appliance OS

Build a self hosting GlusterFS based Storage appliance ISO that can be used to deploy distributed storage clusters, based on CentOS

A single ISO that can be used to install CentOS + GlusterFS controller node, and using the CentOS Installer to setup the controller machine; The same iso should then be usable to provision further gluster storage nodes that auto-connect to the controller node.

Details

The aim is to make it trivial to deploy a distributed storage as software networks, across commodity hardware, using the CentOS Linux installer to make the primary decision. The installer will need to be modified to ask the right questions, and then to build the configs suitable to implement the policy and configs decided by the user. Being able to achieve this also means that the default install options supported by the CentOS Linux installer are directly consumable without any other overhead ( eg. install via http, ftp, nfs, pxe or dvd-iso / usb-iso ) and we can rely on the CentOS Linux upstream for security patches to the installed system.

Using a self hosted config management stack, we would then be able to interface with that ( multicast on a trusted network ? ) to deploy additional storage nodes, with the install and provision either hosted from the installed controller, or just using the isos that we deliver as a part of the development effort on this task. We would rely on some of the work already being done in the glusterfs communities as well as the CentOS SIG efforts; the aim would be to deliver something that is functionally compete and can be maintained into the future with as little effort as possible. Ideally, being able to setup a plugin mechanism that allows glusterfs to be replaced with ceph should the user desire that.

Mentor:

7. Idea: Xen based Hypervisor in a Box

A Single installer ISO that delivers a functional Xen4 stack on CentOS

The Xen4CentOS effort already builds packages for using Xen dom0 on CentOS-6, this effort would be to extend that into delivering a consumeable ISO that does not need CentOS to be preinstalled on the machine. The ISO would also contain CentOS-5 and CentOS-6 vm images that can be instantiated easily.

Details Consuming Xen as a hypervisor on CentOS-6 requires a few cycles, including needing an existing CentOS-6 installed base and requires a running kernel upgrade which can cause corner case issues hard to deal with. eg: firmware versions for drivers changing and device naming changing in a way that the system is hard to recover post install. The aim of this task would be to build an installer instance that uses the same kernel as the xen4centos repositories, and sets up networking as well as storage on a machine making it possible to consume Xen out of the box. The storage should be setup to consume either filebacked or lvm backed storage for the VM's, and the network should be setup to be either self hosted or completely bridged.

For self hosted network we would create a local bridge, managed via dnsmasq and setup to NAT all VM traffic, much like how the default libvirt install is. For fully bridged, the installer should bridge the selected physical network device and ensure that xen creates all virtual network interfaces for that bridge. In this scenario we would not do dhcp, NAT or any other network management.

A key followup goal from this task should be to facilitate upstream additions and downstream extensions on user scenarios. eg: it should be possible for OpenStack or OpenNebula efforts to consume this hypervisor. We don't need to deliver the mechanics for these extensions, just ensure that the work we do is open and extensible easily.

Mentor:

8. Idea: Your idea here

Please use the template above and create your own new stand-alone section.

CategoryGSoC2014

2023-09-11 07:22