Jump to: navigation, search

Difference between revisions of "Internship ideas"

(Coding)
(Coding)
Line 62: Line 62:
  
 
  {{InternshipIdea|
 
  {{InternshipIdea|
  TITLE=Zun|
+
  TITLE=Go and Container related projects in OpenStack|
  DESCRIPTION= Nova integration for Zun, General improvements |
+
  DESCRIPTION= Go Common/Client Library, others. See https://etherpad.openstack.org/p/go-and-containers |
 
  DIFFICULTY= Medium|
 
  DIFFICULTY= Medium|
  TOPICS=OpenStack Zun, OpenStack Nova, Oslo etc|
+
  TOPICS=|
  SKILLS=Python|
+
  SKILLS=Python Go|
 
  EXTRA_SKILLS=|
 
  EXTRA_SKILLS=|
  MENTORS=dims on IRC channel #openstack-zun @ freenode |
+
  MENTORS=dims on #openstack-dev channel @ freenode |
 
  STATUS=Looking for candidates.|
 
  STATUS=Looking for candidates.|
  PROGRAM=December 2016 - March 2017
+
  PROGRAM=April 2017 - Sept 2017
 
}}
 
}}
  

Revision as of 13:49, 8 March 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).


Coding

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


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 December 2016 - March 2017


Swift/Swift3 - Improve S3 compatibility layer

Swift3 Middleware for OpenStack Swift, allows access to OpenStack swift via the Amazon S3 API

Difficulty Medium
Topics Swift
Required skills Python
Extra skills familiarity with HTTP protocols
Mentor timburke
Status Open
Program December 2016 - March 2017


Kuryr-Kubernetes

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 December 2016 - March 2017


Go and Container related projects in OpenStack

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

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


Pluggable Data Sources for Sahara

OpenStack Sahara's data sources allow users to specify locations which elastic data processing jobs can use for input and output (such as HDFS, Swift, and Manila). At present, the set of allowable data sources is hardcoded into the application. Using the Stevedore plugin framework, you will redesign the way Sahara jobs interact with data sources to allow developers to easily "plug in" new data sources and have them work reasonably seamlessly. Note that if you are able to complete this task quickly, you can move on to make other EDP components pluggable as well, including job types (like Java, MapReduce, and Spark) and job engines (like Oozie, Spark, and Storm.) Completing this task would be a huge improvement for the ease with which developers can understand and extend Sahara's EDP framework.

Difficulty Medium
Topics Major topics include:
  • Big Data frameworks (you'll learn how Hadoop, Spark, and Storm run data processing jobs)
  • Refactoring (the art of changing the design of existing code to make it more understandable and extensible)
  • Encapsulation (the art of locating all the logic required for a certain task together to make code modification easier)
  • Abstraction (the art of discovering what multiple use cases have in common and building a common interface for them)

(Note that the last three here are foundational skills for any engineer; they take a lot of practice even if you understand the concepts, but any seasoned engineer understands that team members who excel at these skills are incredibly valuable.)

Required skills Python
Extra skills Unit testing
Mentor egafford (Elise Gafford) on IRC channel #openstack-sahara @ freenode (Note: Are you trans? Me too. Feel free to connect with me if you'd like, regardless of whether this internship is your cup of tea.)
Status No longer taking applicants
Program December 2016 - March 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 No longer looking for applicants
Program December 2016 - March 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 December 2016 - March 2017