Ideas for GSoC 2015

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. You will need to ask on the centos-gsoc list to get in touch with mentors and start conversations around the areas that interest you most.

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.

Idea: Develop a kpatch delivery mechanism

(Anchor link)

Make it possible to a user audience to easily consume live patching in the Linux Kernel.

The CentOS Linux 7 kernel has kpatch support enabled and functional, however there is no easy way for users to consume a central set of kpatch diffs; the aim of this effort is to try to deliver a system like rpm/yum that can be used on the client machines to consume a set of kpatch diffs from a central resource (not unlike a yum repository).

Details

The challenge involves working out a metadata format that encapsulates the kpatch content, and map it to the user architecture as well as kernels installed. Then build a control repository structure to be hosted by the project. Finally the user interface needs to be developed that allows the users to consume these kpatch payloads. At the very least the features that CLI must implement:

Mentor:

Idea: Extend package management to consume content at a definable confidence level

(Anchor link)

Facilitate layered components on the baseline platform to define and then deliver their own confidence level in the platform.

Some applications, specially in the infrastructure space, e.g. OpenAFS and the SCST project, deliver kernel enhancing code. The goal of this project idea is to extend the package management layers and build the support mechanisms needed on the buildsystem side to allow the projects/applications to deliver a tested user experience.

Details

Typically, only the base OS is tested to make sure that updates can be applied and that the base OS itself is functional. In many cases, various open source projects layer on top of the base OS with their own components, some of which might replace some functionality in the base OS. An example might be a library or a kernel module. For these projects, offering a yum repo isn't enough, since in many cases they are unable to test the base OS components and their own integration with these components before the components are released.

The goal of this effort would be to extend the package management components in CentOS Linux, to facilitate this level of control. This would involve users getting and consuming content downstream from the external project (or a CentOS Special Interest Group) only after it's been tested, approved, and the external project has validated their code is functional on the new updates. An example workflow here would be:

Mentor:

Idea: CentOS Cloud Storage components

(Anchor link)

Deliver a set of cloud specific images that auto build a software defined storage network.

Make it trivial to deploy cloud hosted distributed storage arrays for either on-premise or public hosted clouds.

Details

The deliverable is a set of images, pre-setup and pre-configured, for various cloud vendors and ecosystems that can be deployed trivially, that use auto-discovery, and have pre-included monitoring and availability options. It should then be possible to deliver these from either inside the cloud itself, or from a user machine off-cloud. A typical setup, built around Gluster should be able to:

As an extended goal, the effort could use a non-storage technology specific configuration management interface to deliver the abstraction.

Mentor:

Idea: Build on premise Vagrant Hosted Index

(Anchor link)

Facilitate groups of people to self host vagrant boxes for their own groups' consumption.

Vagrant is a popular tool used in the developer communities. We would like to develop an application that allows for Vagrant images to be hosted in small registry-like apps, accessible over the web, and develop the tooling needed around it to allow anyone to implement it on site.

Details

Vagrant uses the idea of prebuilt VM images called boxes, and allows developers to get started with developing and testing in those boxes rapidly. The key value being that these boxes can be shared, and are often shared between various teams (sysadmins will often create them, maintain them, then send them out to the developers in the same company, who when done with a feature want to test the instances and then deploy them). However, there is no easy way to do this sharing of VM's other than copying them around from user to user via shared media (USB keys are often used, NFS sometimes, or just scp to copy between machines).

A single app that could be hosted behind a website that allows users to upload boxes, and other uses to search and download these boxs would make the entire process much easier and help improve the overall experience. We would also like to host an instance of this app to allow SIGs and other layered projects in CentOS to publish their own development and testing images for use within their groups.

The basic functionality needed would be:

As an additional goal: The ability to host Vagrant files in a similar manner could be developed.

Mentor:

Idea: Extend buildsystem to host triggers

(Anchor link)

Build the ability for Koji and related tooling to execute on conditionals and triggers.

Allow projects that consume CentOS Linux and various components to setup and rely on conditional triggers to execute builds, tests, CI runs, and delivery scripts.

Details

The CentOS Community Build Service (cbs.centos.org) facilitates various build options, but does not integrate with the CI facilities available to the community (and hosted from ci.centos.org). The aim of this effort is to extend Koji (the software used to run CBS) to deliver the following features:

Mentor:

Idea: Lightweight Cloud instance contextualisation tool

(Anchor link)

Develop a lightweight, zero dependancy cloud instance contextualisation tool.

Virtual Machines running in the cloud (or virtualised environments) need some way to have their instance contextualised to run within that environment. This allows providers to build a single instance image that can be used in different places.

Details

All existing cloud instance contextualisation tools are heavyweight, have long dependancy chains, are hard to customise and extend, and are slow to execute. The aim here is to deliver something written in 'C' or 'Go' so it has no dependancy and delivers on the key basic functionality that is needed by a majority of situations. The functions include:

The basic formats this tool needs to be able to consume:

The main focal points are to deliver the basic functionality with the fastest and the most lightweight solution possible.

Mentor:

Idea: yum plugin to handle docker /container images

(Anchor link)

A single yum command that can download and install container images.

In this effort, we would setup a server side repository of pre-built and pre-configured images that are consumable directly under 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', and '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.

This extends just delivering dockerfiles in an RPM, it enables existing system management tooling to work with an evolving container set, by being treated much like an RPM repository would be.

Mentor:

Idea: Xen based Hypervisor in a Box

(Anchor link)

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 that can cause corner case issues hard to deal with. For example, 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 is 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. E.g. 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:

Idea: Extendable system hardening tool

(Anchor link)

A single tool to audit and implement system hardening recipes.

Create an application that can be easily deployed on CentOS machines, which can consume central hosted metadata and recipes on hardening and securing the CentOS Linux install.

Details

This project is to build an easily extendable tool that can implement policy and recipes to secure a machine, and if needed audit the machine against a given set of recipes. This makes it easier for a user-contributed, community-driven, security-focused Special Interest Group to come together and help the larger, newer userbase implement best practises for various roles. The tool should be able to communicate with a central server, and access information from the RPM metadata repositories, as well as custom recipes. This might be a wrapper around a config management tool.

The aim would be to deliver the tooling needed, the client side application, and a reference set of recipes. Examples of some recipes might be:

Mentor:

Idea: App to trim containers

(Anchor link)

Trim content inside a container to just be enough to run the app it is meant to host.

Containers are typically used to run applications, but the container images delivered are still done as complete machine instances, in many cases carrying redundant libraries, docs, and other content that is never used from the container itself and has no impact on the application being run from the container. We want to lose all that excess content.

Details

Linux applications have a predictable dependancy tree, and it's possible to trim everything else away from the container images that are going to used to host and run these apps. Typically, this could mean 80 - 85% savings on disk sizes of these container images, and also dramatically reduce the resources need to ship them around over the Internet.

We would need to define scope, define the goals, and also identify automation opportunities in order to deliver on this.

Mentor:

Idea: Cloud in a box

(Anchor link)

Preconfigured, assumption driven, easily installed single node cloud controller for development and Proof of Concept testing.

Cloud infrastructure is typically hard to install and requires quite a lot of early study. Depending on how well a user is able to prepare the result of a cloud evaluation can vary. The goal would be to accumulate best practises into a single location, and then deliver a live image (either as an ISO or a qcow2 file), that implements these ideas, ready to be instantiated or installed as a single machine cloud in a box.

Details

Installing a cloud controller requires a fair bit of prep, which a lot of users prefer to skip when evaluating a cloud infrastructure. Having a single ISO or a Live Image that pre-implements best practices and sets up a usable single node would make it simpler and faster to productivity for people looking at evaluating or running simple workloads on a single node cloud.

As an additional goal, the same setup could be extended to be hosted on an installer image, allowing people to expand their cloud easily onto multiple nodes.

Mentor:

Idea: Source validation and mirroring app

(Anchor link)

Mirror, audit, and trigger tasks based around source changes in arbitary locations upstream.

Developers prefer to write code in areas they are most confortable in, using tools they are most comfortable with. We need the ability to manage code hosted in git.centos.org, build a relationship with the upstream content it feeds from (either github.com or bitbucket.org or any arbitary place), and mirror content as needed. Sometimes this might be a two-way process where content from git.centos.org is made available on various other places, making it easier for contributors to interact and develop. The goal would be to develop the applications needed to make this happen, but also to validate content and ensure that no changes take place in past history.

This project also needs to build functionality that allows further actions to take place depending on the code that is changing and what the intended results would. For RPM payloads, we need to track the tarballs, the spec files, and the patches - with every change triggering a build and CI run. For kickstart and metadata around images, we need to ensure that content validates for syntax etc., triggers relevant builds, and collect a diff of content changes included in the resulting artifacts.

Mentor:

Idea: Rootfs build factory

(Anchor link)

ARMv7 and other platforms require rootfs images, but there is no easy way to build them.

Deliver a set of scripts and tools needed to unpack stock CentOS Linux Arm 32bit images and rebuild / rebundle them based on the target machine the image needs to be dropped into.

Details

Every ARM32 board manufacturer has their own device tree, bootloader, firmware, and kernel expectations. It's increasingly difficult for the CentOS Project, or the community around it, to deliver a rootfs image that targets every possible board. However, having a tool that is able to consume some baseline metadata and rebuild a generic rootfs image to suit the boards needed would reduce the user barrier to entry and also make it much easier for people to rebase their images after critical updates in the kernel and the bootloader stack.

Mentor:

Idea: Clean-up of rpkg

(Anchor link)

Clean-up and refactoring of rpkg for easier customization.

The rpkg application is used by CentOS Project to build community-supported software packages. This project focuses on cleaning-up and refactoring the code to organize by components for easier customization and sub-classing.

Details

CentOS Project uses a tool derived from the upstream rpkg called centpkg. This project would refactor methods to be organized by components, such as the buildsystem, SCM layout on the filesystem, and local build tools. The purpose of making these components is to make it easier to customize and sub-class from the main rpkg methods.

Part of this project will be to work with the rpkg upstream project to work out a good plan so that the changes can be carried in the upstream project for all to use.

Mentor:

Idea: Replace sub-shells with library calls in rpkg

(Anchor link)

Clean-up and refactoring of rpkg for easier customization.

The rpkg application is used by CentOS Project to build community-supported software packages. This project focuses on replacing sub-shells with proper library calls, especially for git.

Details

CentOS Project uses a tool derived from the upstream rpkg called centpkg. This project focuses on general cleanup and replacing a lot of the subshells with proper library calls, especially the git operations.

Part of this project will be to work with the rpkg upstream project to work out a good plan so that the changes can be carried in the upstream project for all to use.

Mentor:

Idea: API on top of reposync for repo sync management

(Anchor link)

Build an API on top of reposync to manage and delegate repo synchronization.

Have an API on top of reposync to manage and delegate repository synchronization to the special interest group (SIG) users.

Details

CentOS SIGs need to be able to run reposync for their packages in the CentOS package repository without having to request administrative access or others to do the re-synchronization manually.

The API should support:

Mentor:

Idea: Implement and create new documentation toolchain

(Anchor link)

Implement and partially create a toolchain that lowers the barriers to contributing.

The CentOS Project needs more short-form contributions of content that focuses on how-to do things on top of a CentOS Linux installation, with a method to push changes in to appropriate and related upstream open source projects.

Details

There is a lot of content scattered across the Internet on how to do things with CentOS Linux. The goal of this toolchain is to make it easy for people to contribute new, short-form content articles to the Project with an ability to push them outward to relevant upstream projects.

The toolchain should:

Mentor:


Category:GSoC2015

GSoC/2015/Ideas (last edited 2015-03-23 22:21:24 by KarstenWade)