Revision as of 21:13, 5 February 2019

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

OpenStack as a virtual Kubernetes node

Implement a virtual Kubernetes node that allows running containers/pods on OpenStack. Students applying to work on this will learn about Zun and Kubernetes, and will work on implemeting a whole new feature for Zun, which will include not only coding but also testing and documentation efforts. See https://github.com/virtual-kubelet/virtual-kubelet/issues/22 for more info on the requirement

Difficulty	Medium
Topics	OpenStack Zun, Kubernetes
Required skills	Python Go
Extra skills
Mentor	hongbin on IRC channel #openstack-zun @ freenode
Status	Looking for candidates.
Program

Improve Cinder integration for Docker containers

Add support for Cinder volume multi-attach for Docker containers. Students willing to take this task will learn about Zun and Cinder. During the Ocata cycle a new flow for volume attaching has been implemented in Cinder. We want to make Zun leverage this new flow. Implementing this will require the student not only contribute with code, but also with testing and documentation for the feature. Check https://blueprints.launchpad.net/zun/+spec/cinder-volume-multi-attach for more details.

Difficulty	Medium
Topics	OpenStack Zun, OpenStack Cinder, Docker
Required skills	Python
Extra skills
Mentor	hongbin on IRC channel #openstack-zun @ freenode
Status	Looking for candidates.
Program

Help Implement Support for a Generic Backup Driver in Cinder

The goal is to create a generic backup driver that be used to turn any Cinder volume backend into a target for backups. This way, we won't need to implement specific backup driver for supported backends. Students picking this internship task will learn about Cinder and will be asked to contribute with testing and documentation of this feature. Refer to https://review.openstack.org/#/c/504099/1/specs/queens/generic-backup-implementation.rst for more detials

Difficulty	Medium
Topics	OpenStack Cinder, Storage
Required skills	Python
Extra skills
Mentor	jungleboyj and e0ne on IRC channel #openstack-cinder @ freenode
Status	Looking for candidates.
Program

Eliminate Redundant Downloads of Uncached Images

An important component in the amount of time it takes to boot a new virtual machine is how long it takes to get the image being used from backend storage down to the host. To speed this up, Glance has optional caching middleware that for some back ends (specifically, OpenStack Swift), significantly improves performance. The problem is that the cache is kind of stupid, and in the scenario where someone wants to boot 1000 VMs from the same image, each request will discover that the image isn't cached, and will initiate a download from the storage backend, resulting in severely degraded performance.

There are some complexities to improving the caching middleware that are discussed in a Glance specification document: http://specs.openstack.org/openstack/glance-specs/specs/untargeted/glance/duplicate-downloads.html . In addition to coding, you will get exposure to working in an open-source community from the design phase through implementation, because your first task will be to re-propose the spec to the Glance community so that it can be reviewed and re-approved. (Don't worry, this won't drag on because it was already approved once; it is untargeted because the original developer was reassigned to a different project.) This is an interesting project that will touch several Glance components: the API server, the caching middleware, and the glance_store library. And, of course, you'll be adding good tests.

Difficulty	Low to Medium (you don't need previous OpenStack experience, but you need to be self-motivated enough to learn the components of Glance and how they interact)
Topics	Glance
Required skills	Python
Extra skills	General distributed systems knowledge
Mentor	jokke_ on IRC channel #openstack-glance @ freenode
Status	Looking for candidates.
Program

Transform legacy notifications to the new versioned framework in Nova

Help transforming legacy Nova notifications to a new versioned framework. Students applying for this task will learn about Nova and the oslo.messaging library, and will help transforming the legacy notifications of Nova to a proper versioned API using an already established framework. Check for more details on this page https://wiki.openstack.org/wiki/Nova/VersionedNotificationTransformation

Difficulty	Medium
Topics	OpenStack Nova
Required skills	Python
Extra skills
Mentor	gibi on IRC channel #openstack-nova @ freenode
Status	Looking for candidates.
Program

Policy Testing

WIth all the system-scope work coming down the pipe and landing in Queens, we need to be prepared to rethink out test_v3_protection.py test module. This is the module responsible for making it so policies are doing what they should. Since we're adding a few new combinations with system scope, this should result in a test explosion that could be difficult to maintain and understand.

Can we come up with a way to flexibly test different policy cases
Refactor current coverage
Integration with Patrole

Difficulty	Medium
Topics	OpenStack Keystone
Required skills	Python
Extra skills
Mentor	hrybacki and lbragstad on IRC channel #openstack-keystone @ freenode
Status	Looking for candidates.
Program

Flask support

We have a home-grown WSGI implementation when there are suitable frameworks to do that lifting for us. We can get rid of a wheel to maintain by moving to a framework and ditching the home-grown implementation. We've talked about moving to Flask for a while. The benefits would be less maintenance of a home-grown implementation.

Difficulty	Medium
Topics	OpenStack Keystone
Required skills	Python
Extra skills
Mentor	TBA
Status	Looking for candidates.
Program

Native SAML

Currently, federation requires the use of Apache plugins to do the SAML processing. We want to experiment with a piece of middleware that can go into keystone paste pipeline to process SAML according to specification. This will make federation easier to configure for deployers and it has the ability to reduce a mapping currently used in federation (assertions -> env var, env vars -> keystone mappings).

Difficulty	Medium
Topics	OpenStack Keystone
Required skills	Python
Extra skills
Mentor	cmurphy and rodrigods on IRC channel #openstack-keystone @ freenode
Status	Looking for candidates.
Program

Make keystone a fully-fledged IdP

Currently, keystone can act as an IdP but only in a non-standard in-house-designed auth flow, not with WebSSO. We could implement the rest of the WebSSO standard in keystone. https://bugs.launchpad.net/keystone/+bug/1470205 This could be a good warm-up bug for either this or the Native SAML project: https://bugs.launchpad.net/keystone/+bug/1641625

Difficulty	Medium
Topics	OpenStack Keystone
Required skills	Python
Extra skills
Mentor	TBA
Status	Looking for candidates.
Program

OpenStack Manila Integration with OpenStack CLI (OSC)

OpenStackClient (aka OSC) is a command-line client for OpenStack that brings the command set for Compute, Identity, Image, Object Store and Volume APIs together in a single shell with a uniform command structure. OSC primary goal is to provide a unified shell command structure and a common language to describe operations in OpenStack. Manila basic commands should be added to OSC client. This will be helpful for user to provide a unified shell command structure to describe operations in OpenStack.

Difficulty	Low
Topics	OpenStack Manila
Required skills	Ruby
Extra skills	Python
Mentor	enriquetaso and vkmc on IRC channel #openstack-manila @ freenode
Status	Looking for candidates.
Program	Outreachy May-Aug 2019 candidates.

@@ Line 10: / Line 10: @@
 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).
-== Docs ==
- {{InternshipIdea|
- TITLE=Keystone - Documentation Auditing  |
- DESCRIPTION=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|
- SKILLS=Documentation Reading and Writing|
- EXTRA_SKILLS=Developing with Python|
- MENTORS=samueldmq and nishaYadav |
- STATUS=Juciane Chianca is a candidate|
- PROGRAM=May 2017 - August 2017
-}}
 == Coding ==
   {{InternshipIdea|
-  TITLE= Keystone/Infra - LDAP testing job  |
+  TITLE=OpenStack as a virtual Kubernetes node|
-  DESCRIPTION= 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.|
+  DESCRIPTION=Implement a virtual Kubernetes node that allows running containers/pods on OpenStack. Students applying to work on this will learn about Zun and Kubernetes, and will work on implemeting a whole new feature for Zun, which will include not only coding but also testing and documentation efforts. See https://github.com/virtual-kubelet/virtual-kubelet/issues/22 for more info on the requirement|
   DIFFICULTY=Medium|
-  TOPICS=Keystone, Infra, CI|
+  TOPICS=OpenStack Zun, Kubernetes|
- SKILLS=Python, Bash|
- EXTRA_SKILLS=Tests on CI, but we'll teach you|
- MENTORS=rodrigods|
- STATUS=Looking for candidates|
- PROGRAM=May 2017 - August 2017
-}}
- {{InternshipIdea|
- TITLE=Go and Container related projects in OpenStack|
- DESCRIPTION= Go Common/Client Library, others. See https://etherpad.openstack.org/p/go-and-containers for ideas|
- DIFFICULTY= Medium|
- TOPICS=|
   SKILLS=Python Go|
   EXTRA_SKILLS=|
-  MENTORS=dims on #openstack-dev channel @ freenode |
+  MENTORS=hongbin on IRC channel #openstack-zun @ freenode |
   STATUS=Looking for candidates.|
-  PROGRAM=May 2017 - August 2017
+  PROGRAM=
 }}
 {{InternshipIdea|
-  TITLE=Kuryr-Kubernetes|
+  TITLE=Improve Cinder integration for Docker containers|
-  DESCRIPTION=Add introspection HTTP REST points to the Kubernetes API watchers |
+  DESCRIPTION=Add support for Cinder volume multi-attach for Docker containers. Students willing to take this task will learn about Zun and Cinder. During the Ocata cycle a new flow for volume attaching has been implemented in Cinder. We want to make Zun leverage this new flow. Implementing this will require the student not only contribute with code, but also with testing and documentation for the feature. Check https://blueprints.launchpad.net/zun/+spec/cinder-volume-multi-attach for more details.|
-  DIFFICULTY= Medium|
+  DIFFICULTY=Medium|
-  TOPICS=OpenStack Kuryr, Kubernetes, Flask, HTTP|
+  TOPICS=OpenStack Zun, OpenStack Cinder, Docker|
   SKILLS=Python|
-  EXTRA_SKILLS=API design|
+  EXTRA_SKILLS=|
-  MENTORS=apuimedo on IRC channel #openstack-kuryr @ freenode |
+  MENTORS=hongbin on IRC channel #openstack-zun @ freenode |
   STATUS=Looking for candidates.|
-  PROGRAM=May 2017 - August 2017
+  PROGRAM=
 }}
- {{InternshipIdea|
+{{InternshipIdea|
-  TITLE= Keystone/Infra - Improving Keystone jobs for new scenarios  |
+  TITLE=Help Implement Support for a Generic Backup Driver in Cinder|
-  DESCRIPTION= 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 |
+  DESCRIPTION=The goal is to create a generic backup driver that be used to turn any Cinder volume backend into a target for backups.
+This way, we won't need to implement specific backup driver for supported backends. Students picking this internship task will learn about Cinder and will be asked to contribute with testing and documentation of this feature. Refer to https://review.openstack.org/#/c/504099/1/specs/queens/generic-backup-implementation.rst for more detials |
   DIFFICULTY=Medium|
-  TOPICS=Keystone, Infra, CI|
+  TOPICS=OpenStack Cinder, Storage|
   SKILLS=Python|
-  EXTRA_SKILLS=Tests on CI, but we'll teach you|
+  EXTRA_SKILLS=|
-  MENTORS=raildo|
+  MENTORS=jungleboyj and e0ne on IRC channel #openstack-cinder @ freenode |
-  STATUS=No longer taking applicants|
+  STATUS=Looking for candidates.|
-  PROGRAM=December 2016 - March 2017
+  PROGRAM=
 }}
   {{InternshipIdea|
-  TITLE= Swift/Swift3 - Improve S3 compatibility layer  |
+  TITLE=Eliminate Redundant Downloads of Uncached Images|
-  DESCRIPTION= Swift3 Middleware for OpenStack Swift, allows access to OpenStack swift via the Amazon S3 API |
+  DESCRIPTION=An important component in the amount of time it takes to boot a new virtual machine is how long it takes to get the image being used from backend storage down to the host.  To speed this up, Glance has optional caching middleware that for some back ends (specifically, OpenStack Swift), significantly improves performance.  The problem is that the cache is kind of stupid, and in the scenario where someone wants to boot 1000 VMs from the same image, each request will discover that the image isn't cached, and will initiate a download from the storage backend, resulting in severely degraded performance.
-  DIFFICULTY=Medium|
-  TOPICS=Swift|
+There are some complexities to improving the caching middleware that are discussed in a Glance specification document: http://specs.openstack.org/openstack/glance-specs/specs/untargeted/glance/duplicate-downloads.html .  In addition to coding, you will get exposure to working in an open-source community from the design phase through implementation, because your first task will be to re-propose the spec to the Glance community so that it can be reviewed and re-approved. (Don't worry, this won't drag on because it was already approved once; it is untargeted because the original developer was reassigned to a different project.)  This is an interesting project that will touch several Glance components: the API server, the caching middleware, and the glance_store library.  And, of course, you'll be adding good tests.|
+  DIFFICULTY=Low to Medium (you don't need previous OpenStack experience, but you need to be self-motivated enough to learn the components of Glance and how they interact)|
+  TOPICS=Glance|
   SKILLS=Python|
-  EXTRA_SKILLS=familiarity with HTTP protocols|
+  EXTRA_SKILLS=General distributed systems knowledge|
-  MENTORS=timburke|
+  MENTORS=jokke_ on IRC channel #openstack-glance @ freenode |
-  STATUS=Open|
+  STATUS=Looking for candidates.|
-  PROGRAM=December 2016 - March 2017
+  PROGRAM=
 }}
 {{InternshipIdea|
-  TITLE=Pluggable Data Sources for Sahara |
+  TITLE=Transform legacy notifications to the new versioned framework in Nova|
-  DESCRIPTION= 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. |
+  DESCRIPTION=Help transforming legacy Nova notifications to a new versioned framework. Students applying for this task will learn about Nova and the oslo.messaging library, and will help transforming the legacy notifications of Nova to a proper versioned API using an already established framework. Check for more details on this page https://wiki.openstack.org/wiki/Nova/VersionedNotificationTransformation|
-  DIFFICULTY= Medium|
+  DIFFICULTY=Medium|
-  TOPICS= Major topics include:
+  TOPICS=OpenStack Nova|
-* Big Data frameworks (you'll learn how Hadoop, Spark, and Storm run data processing jobs)
+  SKILLS=Python |
-* Refactoring (the art of changing the design of existing code to make it more understandable and extensible)
+  EXTRA_SKILLS=|
-* Encapsulation (the art of locating all the logic required for a certain task together to make code modification easier)
+  MENTORS=gibi on IRC channel #openstack-nova @ freenode |
-* Abstraction (the art of discovering what multiple use cases have in common and building a common interface for them)
+  STATUS=Looking for candidates.|
-(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.) |
+  PROGRAM=
-  SKILLS=Python|
-  EXTRA_SKILLS=Unit testing|
-  MENTORS=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
 }}
 {{InternshipIdea|
-  TITLE=Portable templates |
+  TITLE=Policy Testing|
-  DESCRIPTION= 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. |
+  DESCRIPTION=WIth all the system-scope work coming down the pipe and landing in Queens, we need to be prepared to rethink out test_v3_protection.py test module. This is the module responsible for making it so policies are doing what they should. Since we're adding a few new combinations with system scope, this should result in a test explosion that could be difficult to maintain and understand.
-  DIFFICULTY= Medium|
-  TOPICS= Major topics include:
+*Can we come up with a way to flexibly test different policy cases
-* Templates (you'll learn how Sahara works on the background for creating clusters)
+*Refactor current coverage
-* Refactoring (Sahara will need to be worked on to allow a more portable template)
+*Integration with Patrole|
-* Abstraction (Sahara may need more templates in the future, learning how to prepare the environment for future change is always a great skill)
+  DIFFICULTY=Medium|
-|
+  TOPICS=OpenStack Keystone|
-  SKILLS=Python|
+  SKILLS=Python |
-  EXTRA_SKILLS=Unit Testing, html, js|
+  EXTRA_SKILLS=|
-  MENTORS=tellesnobrega/tenobreg (Telles Nobrega) on IRC channel #openstack-sahara @ freenode |
+  MENTORS=hrybacki and lbragstad on IRC channel #openstack-keystone @ freenode |
-  STATUS= looking for applicants|
+  STATUS=Looking for candidates.|
-  PROGRAM=December 2016 - March 2017
+  PROGRAM=
 }}
- {{InternshipIdea|
+{{InternshipIdea|
-  TITLE=Ceph's RBD incremental backups for Cinder|
+  TITLE=Flask support|
-  DESCRIPTION=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.
+  DESCRIPTION=
+We have a home-grown WSGI implementation when there are suitable frameworks to do that lifting for us. We can get rid of a wheel to maintain by moving to a framework and ditching the home-grown implementation. We've talked about moving to Flask for a while. The benefits would be less maintenance of a home-grown implementation.|
+ DIFFICULTY=Medium|
+ TOPICS=OpenStack Keystone|
+ SKILLS=Python |
+ EXTRA_SKILLS=|
+ MENTORS=TBA |
+ STATUS=Looking for candidates.|
+ PROGRAM=
+}}
-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.
+{{InternshipIdea|
+ TITLE=Native SAML|
+ DESCRIPTION=Currently, federation requires the use of Apache plugins to do the SAML processing. We want to experiment with a piece of middleware that can go into keystone paste pipeline to process SAML according to specification. This will make federation easier to configure for deployers and it has the ability to reduce a mapping currently used in federation (assertions -> env var, env vars -> keystone mappings).|
+ DIFFICULTY=Medium|
+ TOPICS=OpenStack Keystone|
+ SKILLS=Python |
+ EXTRA_SKILLS=|
+ MENTORS=cmurphy and rodrigods on IRC channel #openstack-keystone @ freenode |
+ STATUS=Looking for candidates.|
+  PROGRAM=
+}}
-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.
+{{InternshipIdea|
+ TITLE=Make keystone a fully-fledged IdP|
+ DESCRIPTION=Currently, keystone can act as an IdP but only in a non-standard in-house-designed auth flow, not with WebSSO. We could implement the rest of the WebSSO standard in keystone.
+https://bugs.launchpad.net/keystone/+bug/1470205
+This could be a good warm-up bug for either this or the Native SAML project: https://bugs.launchpad.net/keystone/+bug/1641625|
+ DIFFICULTY=Medium|
+ TOPICS=OpenStack Keystone|
+ SKILLS=Python |
+ EXTRA_SKILLS=|
+ MENTORS=TBA |
+ STATUS=Looking for candidates.|
+ PROGRAM=
+}}
-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.
+ {{InternshipIdea|
+ TITLE=OpenStack Manila Integration with OpenStack CLI (OSC)|
-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.
+ DESCRIPTION=OpenStackClient (aka OSC) is a command-line client for OpenStack that brings the command set for Compute, Identity, Image, Object Store and Volume APIs together in a single shell with a uniform command structure. OSC primary goal is to provide a unified shell command structure and a common language to describe operations in OpenStack. Manila basic commands should be added to OSC client. This will be helpful for user to provide a unified shell command structure to describe operations in OpenStack. |
+  DIFFICULTY=Low|
-Your mission, should you choose to accept it, would be to implement the incremental backup feature in the RBD backup driver.
+  TOPICS=OpenStack Manila|
+  SKILLS=Ruby|
-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. |
+  EXTRA_SKILLS=Python|
-  DIFFICULTY=Medium|
+  MENTORS=enriquetaso and vkmc on IRC channel #openstack-manila @ freenode|
-  TOPICS=Storage, Cinder, Ceph, RBD, Backup|
+  STATUS=Looking for candidates.|
-  EXTRA_SKILLS=None|
+  PROGRAM=Outreachy May-Aug 2019 candidates.
-  SKILLS=Python|
-  MENTORS=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
 }}

Difference between revisions of "Internship ideas"

Revision as of 21:13, 5 February 2019

List of Ideas for Internships

Coding