Jump to: navigation, search

Internship ideas

Revision as of 20:05, 17 March 2017 by Vkmc (talk | contribs) (Cleaned up internship tasks for Outreachy May-Aug 2017)

To submit new ideas please consider creating a new page and use the Template:InternshipIdea (instructions are provided on that page) and you can see how a sample idea page would look like. The pages created with such template are listed on Category:Internship_idea.

List of Ideas for Internships

The OpenStack Foundation has multiple sources for internships, from Outreachy to Google Summer of Code and other opportunities. This page collects the ideas for candidate interns to work on.

Applicants may not have ever worked on FLOSS before and have different levels of competence. Since we have different programs, add here ideas that can be completed by inexperienced contributors, developers or other fields (marketing, communication, graphic design, and anything that may be useful for OpenStack and to include new people in this community).


Keystone - Documentation Auditing

Study keystone documentation in order to improve accuracy and completeness. Keystone documentation is split into dev, user and operator docs. The goal is to analyze as much documentation as possible. Notice that analyzing a) developer docs will require setting up a development environment; b) user docs will require using the REST API and the clients; and c) operator docs will require deploying the service in different ways. The goal is to identify gaps and propose patches for community review.

Difficulty Medium
Topics Docs, Keystone
Required skills Documentation Reading and Writing
Extra skills Developing with Python
Mentor samueldmq and nishaYadav
Status Juciane Chianca is a candidate
Program May 2017 - August 2017


Keystone/Infra - LDAP testing job

Although the OpenStack Identity Service (keystone) supports LDAP as identity backend, we currently don’t have any functional tests running in such scenario. We would like to add a new job to OpenStack’s CI where keystone would be deployed with LDAP as the identity backend. This project involves several pieces of the OpenStack upstream infra/CI.

Difficulty Medium
Topics Keystone, Infra, CI
Required skills Python, Bash
Extra skills Tests on CI, but we'll teach you
Mentor rodrigods
Status Looking for candidates
Program May 2017 - August 2017

Go and Container related projects in OpenStack

Go Common/Client Library, others. See https://etherpad.openstack.org/p/go-and-containers for ideas

Difficulty Medium
Required skills Python Go
Extra skills
Mentor dims on #openstack-dev channel @ freenode
Status Looking for candidates.
Program May 2017 - August 2017


Add introspection HTTP REST points to the Kubernetes API watchers

Difficulty Medium
Topics OpenStack Kuryr, Kubernetes, Flask, HTTP
Required skills Python
Extra skills API design
Mentor apuimedo on IRC channel #openstack-kuryr @ freenode
Status Looking for candidates.
Program May 2017 - August 2017

Keystone/Infra - Improving Keystone jobs for new scenarios

We want to make sure the currently jobs on Jenkins cover the new features on Keystone, such as fernet tokens, v3 API and functional tests

Difficulty Medium
Topics Keystone, Infra, CI
Required skills Python
Extra skills Tests on CI, but we'll teach you
Mentor raildo
Status No longer taking applicants
Program May 2017 - August 2017

Portable templates

OpenStack Sahara allows users to create data processing clusters using different processing tools such as Hadoop (upstream or "Vanilla", Cloudera, Ambari, MapR), Spark and Storm. To do so, Sahara relies on templates to define node groups (what process runs on each type of node) and clusters (how many of each node group should be present in the cluster). Templates can be created as a JSON file and imported to the CLI. But to the end user, that uses Sahara through horizon, there is no way to export or import an pre-defined template. We are proposing the introduction of this two functionalities, export and import of templates (Node Group and Cluster). This will allow users to easily move templates from one deploy to another and store definitions of a cluster for a future time, also will allow for quick testing set up. We plan to do this in two steps, first would be a simple import export of the same template we have now, which relies on UUIDs and for a second step we would refactor the way sahara handles the templates to allow the template to be portable for different environments.

Difficulty Medium
Topics Major topics include:
  • Templates (you'll learn how Sahara works on the background for creating clusters)
  • Refactoring (Sahara will need to be worked on to allow a more portable template)
  • Abstraction (Sahara may need more templates in the future, learning how to prepare the environment for future change is always a great skill)
Required skills Python
Extra skills Unit Testing, html, js
Mentor tellesnobrega/tenobreg (Telles Nobrega) on IRC channel #openstack-sahara @ freenode
Status looking for applicants
Program May 2017 - August 2017

Ceph's RBD incremental backups for Cinder

Cinder is the OpenStack Block Storage service in charge of providing on demand, self-service access to Block Storage resources. Besides providing block storage (volumes) for instances it also has a specific service to manage all backup operations related to those volumes, like creating, restoring, and deleting backups.

Ceph is a distributed object, block, and file system storage in a single unified storage cluster designed to provide excellent performance, reliability and scalability. And RBD is the Block Storage part.

Within the Backup Cinder Service there are multiple backup drivers, one of these drivers is the RBD backup driver, which was the first one that implemented the possibility of doing incremental backups. But users could not chose whether they wanted to do full or incremental backups, as these were automatic -not user driven- and were only possible for volumes that were also stored in a Ceph cluster.

After a couple of releases a generic incremental mechanism was introduced that allowed users to create incremental backups on demand regardless of the backend where the source volume was stored, but the RBD driver was not updated to support this new mechanism.

Later on the Backup service was decoupled from the Cinder Volume service inadvertently causing the RBD driver to lose the Ceph to Ceph incremental backup feature.

Your mission, should you choose to accept it, would be to implement the incremental backup feature in the RBD backup driver.

This feature allows multiple levels of perfection, being the primary objective to provide the generic mechanism that allows on-demand incremental backups from any source volume backup while preserving backward compatibility with old deployments. As a secondary optional objective the existing optimized mechanism could be fixed to allow better performance for Ceph to Ceph backups.

Difficulty Medium
Topics Storage, Cinder, Ceph, RBD, Backup
Required skills Python
Extra skills None
Mentor geguileo on IRC channel #openstack-cinder @ freenode. I'm a native Spanish speaker, so if the thought of having all your communications in English seems a little daunting don't worry, we may resort to Spanish if we find ourselves in a pinch.  ;-)
Status Looking for Candidates.
Program May 2017 - August 2017