Difference between revisions of "Internship ideas"
(→Coding) |
m (→Coding) |
||
Line 20: | Line 20: | ||
SKILLS=Python, Bash| | SKILLS=Python, Bash| | ||
EXTRA_SKILLS=Tests on CI, but we'll teach you| | EXTRA_SKILLS=Tests on CI, but we'll teach you| | ||
− | MENTORS=raildo, | + | MENTORS=raildo, rodrigods| |
STATUS=Open| | STATUS=Open| | ||
PROGRAM=December 2016 - March 2017 | PROGRAM=December 2016 - March 2017 |
Revision as of 18:29, 27 December 2016
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.
Difficulty | Medium |
Topics | Keystone, Infra, CI |
Required skills | Python, Bash |
Extra skills | Tests on CI, but we'll teach you |
Mentor | raildo, rodrigods |
Status | Open |
Program | December 2016 - March 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 | Open |
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 |
Zun
Nova integration for Zun, General improvements
Difficulty | Medium |
Topics | OpenStack Zun, OpenStack Nova, Oslo etc |
Required skills | Python |
Extra skills | |
Mentor | dims on IRC channel #openstack-zun @ freenode |
Status | Looking for candidates. |
Program | December 2016 - March 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:
(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:
|
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 |