Jump to: navigation, search

Difference between revisions of "Internship ideas"

(Outreachy Ideas List: making this more generic and valid for all sorts of internships, not just Outreachy)
(Added notice about this page being out of date)
 
(115 intermediate revisions by 33 users not shown)
Line 1: Line 1:
 
<!-- ## page was renamed from [[GnomeOutreachWomen]]/Ideas -->
 
<!-- ## page was renamed from [[GnomeOutreachWomen]]/Ideas -->
=  List of Ideas for Internships =
 
  
The OpenStack Foundation has multiple sources for internships, from [[Outreachy]] to [[GSoC|Google Summer of Code]] and other opportunities. This page collects the ideas for candidate interns to work on.  
+
<div style="font-size: 150%; background-color: yellow; padding: 1em">
 +
<span style="font-size: 150%">This page is not actively maintained.</span>
 +
<br/><br/>
 +
Before working on any of the internship ideas on this page, contact the listed Mentor to find out whether the idea is still relevant.
 +
<br/><br/>
 +
You can also take a look at the current Outreachy proposals, which are up-to-date:
 +
https://www.outreachy.org/apply/project-selection/#openstack
 +
<br/><br/>
 +
Finally, you can take a look at the current "Upstream Investment Opportunities", which lists projects of interest to the community that don't have owners:
 +
https://governance.openstack.org/tc/reference/upstream-investment-opportunities/
 +
</div>
  
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).
+
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 [[Test idea|sample idea page]] would look like. The pages created with such template are listed on [[:Category:Internship_idea]].
  
== Coding ==
 
  
=== Zaqar: zaqar-pythonclient support for Zaqar API v1.1 ===
+
= List of Ideas for Internships =
  
Mentor: [[User:Vkmc|Victoria Martinez de la Cruz]]
+
The OpenStack Foundation has multiple sources for internships, from [[Outreachy]] to [[:Category:GSoC|Google Summer of Code]] and other opportunities. This page collects the ideas for candidate interns to work on.
  
Currently there are three versions of Zaqar API: v1, v1.1 and v2.0 (under heavy development). zaqar-pythonclient has full support for all the features in API v1, but its missing support for some features in API v1.1. This task would require to learn and understand the new features provided in API v1.1 and add support for them client side.
+
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).
 
 
Difficulty: Normal
 
Required skills: Python
 
 
 
=== Zaqar: Creation of a Zaqar panel for Horizon ===
 
 
 
Mentor: [[User:Vkmc|Victoria Martinez de la Cruz]]
 
 
 
Right now the only way to use Zaqar is through the API. The creation of a panel for Horizon would make Zaqar more user friendly. This task would require to learn and understand how panels are created in Horizon, to select Zaqar features to expose, to create a UI for it and do the implementation afterwards.
 
 
 
Difficulty: Hard
 
Required skills: Python, Django, Javascript
 
 
 
=== Neutron - metering agent add port statistics  ===
 
 
 
Description:
 
 
 
In Neutron the metering agent [https://wiki.openstack.org/wiki/Neutron/Metering/Bandwidth] collects statistics regarding bandwidth usage. Right now it only measure the bandwidth used by routers. The idea is to extend it and provide statistics also for ports. In the first implementation only openvswitch will be supported, since we will use openvswitch tools to get the port statistics.
 
The first step will be getting familiar with the metering agent and with Neutron in general. Then you will approach openvswitch tools and think about how to use them for this project. After that you can reach out to the community to collect and discuss ideas. Neutron folks are pretty active on #openstack-neutron channel most of the time and would be willing to share their opinions on this or any other project. You'll submit your code upstream and address the comments you get till your patch gets merged.
 
 
 
Related blueprint: https://blueprints.launchpad.net/neutron/+spec/port-statistics
 
 
 
Expected results: Patchsets submitted for review, reviewed by community members.
 
 
 
Knowledge prerequisites: programming knowledge
 
 
 
Nice-to-have knowledge: Python, Openvswitch
 
 
 
Mentors: [[User:Rossella|Rossella Sblendido]]
 
 
 
== Documentation ==
 
 
 
Mentors:
 
** loquacities on IRC / lana dot brindley at rackspace dot com
 
** asettle on IRC/ alexandra dot settle at rackspace dot com
 
 
 
* Assist with the RST conversion of the Admin User Guide
 
 
 
* Help with the Networking Guide: either with content, copyediting, or the RST conversion.
 
 
 
* General bug work (find something interesting and work on it). This would look great on her resume as it's a solid visible contribution, but would also hopefully pay down some of our technical debt.
 
 
 
* Choose a book/section of interest, and research and update that section. A good candidate here would be the API guides.
 
 
 
<big>'''Ideas below this point correspond to the last Outreachy round (December 2014 - March 2015). This means that they may not be available anymore. Please ask the mentor listed about it'''</big>
 
 
 
 
 
== Community ==
 
 
 
* Write puppet scripts to automatically deploy/manage Ask OpenStack
 
 
 
Mentors:
 
** hodepodge on IRC / chris at openstack org
 
** EmilienM on IRC / emilien at redhat com
 
  
 
== Coding ==
 
== Coding ==
  
=== Ceilometer ===
+
{{InternshipIdea|
 
+
TITLE=OpenStack as a virtual Kubernetes node|
Mentor: [[DinaBelova|Dina Belova]]
+
  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|
Ceilometer team is currently working on new Time-Series storage concept for metrics. For now Gnocchi (Telemetry Stackforge project where we're trying to implement this kind of effort) lacks of the backend support (only Swift in place, InfluxDB and OpenTSDB still in progress). There is some interest to use Ceph directly instead of it. So we need direct-to-ceph usage from
+
TOPICS=OpenStack Zun, Kubernetes|
Gnocchi, possibly via the rados gateway REST API (as opposed to ceph-sitting-behind-swift-proxy as an alternative storage driver for Swift itself).
+
SKILLS=Python Go|
 
+
  EXTRA_SKILLS=|
=== Zaqar: Split data/control planes ===
+
  MENTORS=hongbin on IRC channel #openstack-zun @ freenode |
 
+
  STATUS=Looking for candidates.|
Mentor: [[User:flaper87|Flavio Percoco]]
+
PROGRAM=
 
+
}}
Zaqar has 2 different logical "data-planes". One is used to control the state of the system and other administrative operations - pools, flavors, etc - and the other is used for the actual data going through Zaqar - queues, messages, etc. These 2 data planes currently share lots of things like config options, modules and more. The team has been willing to split these 2 logically different planes into isolated modules and configs.
 
 
 
This task will give the mentee great insights on Zaqar's architecture, logic and also more general information on how some messaging patterns are implemented in the system. This task is a great intro to Zaqar, to OpenStack and to messaging technologies with enough complexity to help the mentee grow.
 
 
 
* Expected Results: Both planes should be completely separate
 
* Required Knowedge: Python
 
 
 
=== Trove ===
 
 
 
Mentor: [[User:iccha-sethi|Iccha Sethi]]
 
 
 
Description: MySQL replication enhancements
 
 
 
Work on trove enhancements for mysql replication.
 
 
 
=== Glance - Implement Tasks scrubber ===
 
 
 
Description: Glance Tasks are currently never deleted. This project would involve writing a scrubber logic for soft-deleting tasks as a part of Glance codebase.
 
 
 
Glance folks are pretty active on #openstack-glance channel most of the time and would be willing to share their opinions on this or any other project.
 
Please reach out on IRC to get a detailed information on this.
 
 
 
Initial blueprint: https://blueprints.launchpad.net/glance/+spec/async-glance-workers . A new BP would be needed to get this implemented. It would also be a responsibility of the candidate.
 
 
 
Expected results: Patchsets submitted for review, reviewed by community members.
 
 
 
Knowledge prerequisites: programming knowledge
 
 
 
Nice-to-have knowledge: Python
 
 
 
Mentors: [[User:nikhil|Nikhil Komawar]]
 
 
 
=== Glance - Swift ranged uploads ===
 
 
 
Note(nikhil_k): This is a really challenging project. It would need a lot of research and motivation from candidate to perform the tasks. The tasks would also need to be defined by the candidate themselves to have a good "concurrent" distributed system as a end-result.
 
 
 
Description: We currently retry the entire upload process if it fails. Need to add the ranged uploads logic from swift store to improve performance. Target repo - openstack/glance_store
 
 
 
Glance folks are pretty active on #openstack-glance channel most of the time and would be willing to share their opinions on this or any other project.
 
Please reach out on IRC to get a detailed information on this.
 
 
 
Related blueprint: TBA
 
 
 
Expected results: Patchsets submitted for review, reviewed by community members.
 
 
 
Knowledge prerequisites: programming knowledge
 
 
 
Nice-to-have knowledge: Python
 
 
 
Mentors:  [[User:nikhil|Nikhil Komawar]]
 
 
 
=== Swift - storage server OPTIONS support and checker tool ===
 
 
 
Many times new deployers get mysterious errors after first setting up their Swift clusters. Most of the time, the errors are because the values in the ring are incorrect (e.g. a bad port number). We need a way to validate that the rings actually match the deployment.
 
 
 
http://tools.ietf.org/html/rfc7231#section-4.3.7 talks about the OPTIONS verb. Swift's proxy server already supports OPTIONS, but the storage nodes do not. The first task is to implement OPTIONS on the account, container, and object servers.
 
 
 
Once the "OPTIONS *" functionality is implemented, swift-recon can be updated to include a ring checker. This checker would look at the ring and validate that there is something running on the server endpoints listed in the ring. Furthermore it would be able to actually check that the endpoint, if it's a real endpoint, is the right kind of endpoint (e.g. actually check that it's an object server). swift-recon would then generate a report of any found issues in the cluster.
 
 
 
Expected results: patches written, submitted for review, and reviewed by the community
 
 
 
Knowledge prerequisites: Python programming knowledge
 
 
 
Nice-to-have knowledge: familiarity with HTTP protocols
 
 
 
Mentors: [[User:notmyname|John Dickinson]]
 
 
 
WIP Schedule: https://etherpad.openstack.org/p/iaR4TQZ7NP
 
 
 
 
 
=== Swift - Improving the security of Swift's internal network ===
 
 
 
Today all internal messages within a Swift cluster are unencrypted and unsigned. This means that all Swift deployments must be configured with a private, secure network for internal requests. This project is to add a cryptographic signature to all messages sent between Swift processes.
 
 
 
Blueprint: https://blueprints.launchpad.net/swift/+spec/secure-internal-network-requests
 
 
 
Expected results: patches written, submitted for review, and reviewed by the community
 
 
 
Knowledge prerequisites: good Python programming knowledge, Swift's architecture, familiarity with HTTP
 
 
 
Nice-to-have knowledge: familiarity with PKI
 
 
 
Mentors: [[User:notmyname|John Dickinson]]
 
 
 
WIP Schedule: https://etherpad.openstack.org/p/Wp3Hn7YY8p
 
 
 
 
 
=== Swift/Swift3 - Improve S3 compatibility layer ===
 
 
 
Improve the Swift3 middleware to get better S3 API coverage
 
 
 
https://github.com/stackforge/swift3
 
 
 
Mentors: [[User:notmyname|John Dickinson]]
 
 
 
=== Proposed by applicants ===
 
 
 
==== Keystone - Implementation of Attribute and Graph Based Access Control Model (AGBAC) for Openstack ====
 
 
 
Proposed by: Tahmina Ahmed - Tahmina
 
 
 
Description: The Core Openstack Access Control Module according to identity API V3 (user, token,project, domain, group, role association) [0] can be abstracted  as a graph:
 
<br />
 
 
 
[[File:OSACFinal.jpg|Openstack Access Control According to Identity API V3 ]]
 
<br />
 
 
 
Attribute of different entities and the relationship between them and attribute of the relationship can be expressed through property graph [2] where entities are nodes and relationships are edges and both nodes and edges has attribute. Using entities and their attributes and relationship between entities and attribute of relationship to specify authorization policy will allow a system to have more finer grained access control model. For this representation, OpenStack entities (user, group, role, project, domain) are represented as nodes in the graph and the attributes and association between any two of them can be depicted as attributed edges. Given that a role is associated with a user and a project where the association  is temporal, if we can say that the association is only active from 8am to 5pm this is something to say about the user- project- role association. We can express this as an attribute of the user- project and project - role association edge and use this for authorization to findout active roles.
 
 
 
This implementation plan is to make minimum impact on services outside keystone.So the plan is to like computing authorization path specification for a certain time when user requests for a token and and return a list of active roles. In that case  this extension to the authorization model is transparent to all other  openstack services like nova, glance, cynder etc.
 
 
 
Steps to Implement AGBAC in Openstack
 
 
 
1. Define API and Storage for Specifying Attributes of different entities 
 
2. Define  storage Assignment Attributes.
 
3. Define API to set the entity attributes
 
4. Define API to set the association attributes
 
5. A Policy specification storage that would  specify path based policy to compute roles.
 
6. A Compute function that would compute the roles using entites, their attributes relationship between entities attribute of relationships and policy.
 
   
 
[0] Bo Tang and Ravi Sandhu, Extending Openstack Access Control With Domain Trust. In Proceedings 8th International Conference on Network and System Security (NSS 2014), Xi'an, China, October 15-17, 2014, 15 pages
 
 
 
[1] http://neo4j.com/
 
 
 
[2] Rodriguez, Marko A., and Peter Neubauer. "Constructions from dots and lines." Bulletin of the American Society for Information Science and Technology 36.6 (2010): 35-41.
 
 
 
== Design ==
 
 
 
=== Persona research and design for Horizon UI ===
 
 
 
Description:
 
There has been some initial work done in a few different areas around generating Personas for the Horizon UI. This task/project would allow someone to lead the effort to pull the research together, perhaps perform further end-user interviews or surveys, analyze data, form groups of personas, and put together an initial set of target Horizon personas that we can use during requirements gathering, design phases, and general discussion.
 
 
 
Related blueprint: https://blueprints.launchpad.net/openstack-ux/+spec/horizon-personas
 
 
 
Expected results: Initial set of Personas for people to use during requirements gathering, design phases, and general discussion of our target Horizon users.
 
 
 
Knowledge prerequisites: basic interviewing skills, willingness to talk with a lot of new people, readiness to listen and report back findings
 
 
 
Nice-to-have knowledge: User Experience Design basics
 
 
 
Mentors: [[User:julim|Ju Lim]]
 
 
 
=== Redesign for the Object Storage -> Containers section in Horizon ===
 
 
 
Description:
 
 
 
Currently, there is a section under the Object Storage panel that allows users (e.g. Consumers and/or Project Administrators) to Create, Delete, and Edit Containers. It would be great to do a little bit of research into identifying the use cases around these features and then proposing a redesign of these features based on the findings. This will include learning some basic Usability best practices and applying them to a design. The design would be done in wireframe format, so it could be done in any tool that allows for this. The design would be reviewed on the UX AskBot site, a new blueprint would need to be created as well. This would take a new designer through the process that currently exists for proposing an updated design to a current feature in Horizon.
 
  
Related blueprint: N/A (To be created by intern as part of process)
+
{{InternshipIdea|
 +
TITLE=Improve Cinder integration for Docker containers|
 +
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|
 +
TOPICS=OpenStack Zun, OpenStack Cinder, Docker|
 +
SKILLS=Python|
 +
EXTRA_SKILLS=|
 +
MENTORS=hongbin on IRC channel #openstack-zun @ freenode |
 +
STATUS=Looking for candidates.|
 +
PROGRAM=
 +
}}
  
Expected results: Redesign of "Containers" section in Object Storage panel proposed and approved by Horizon community.
+
{{InternshipIdea|
 +
TITLE=Help Implement Support for a Generic Backup Driver in Cinder|
 +
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=OpenStack Cinder, Storage|
 +
SKILLS=Python|
 +
EXTRA_SKILLS=|
 +
MENTORS=jungleboyj and e0ne on IRC channel #openstack-cinder @ freenode |
 +
STATUS=Looking for candidates.|
 +
PROGRAM=
 +
}}
  
Knowledge prerequisites: basic sketching or wireframing skills
+
{{InternshipIdea|
 +
TITLE=Eliminate Redundant Downloads of Uncached Images|
 +
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.
  
Nice-to-have knowledge: User Experience Design basics
+
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=General distributed systems knowledge|
 +
MENTORS=jokke_ on IRC channel #openstack-glance @ freenode |
 +
STATUS=Looking for candidates.|
 +
PROGRAM=
 +
}}
  
Mentors: [[User:julim|Ju Lim]], [[User:lblanchard|Liz Blanchard]]
 
  
=== Horizon Concept Review and Usability Testing ===
+
{{InternshipIdea|
 +
TITLE=Transform legacy notifications to the new versioned framework in Nova|
 +
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|
 +
TOPICS=OpenStack Nova|
 +
SKILLS=Python |
 +
EXTRA_SKILLS=|
 +
MENTORS=gibi on IRC channel #openstack-nova @ freenode |
 +
STATUS=Looking for candidates.|
 +
PROGRAM=
 +
}}
  
Description: There has been very little work done around Horizon UI concept reviews and usability testing.  This task/project would allow someone to lead the effort to put together a test plan, identify customers as test participants, conduct (contextual) inquiry / interview, survey users, analyze data to share results / findings with the community findings regarding how current production OpenStack users are using the software, their use cases, and whether the Horizon UI meets their needs. Along the way, you may identify areas of improvement, concepts that need further refinement, and new use cases or opportunities that have not yet been addressed.
+
{{InternshipIdea|
 +
TITLE=Policy Testing|
 +
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.
  
Related blueprint: https://blueprints.launchpad.net/openstack-ux/+spec/ux-users-community-testing
+
*Can we come up with a way to flexibly test different policy cases
 +
*Refactor current coverage
 +
*Integration with Patrole|
 +
DIFFICULTY=Medium|
 +
TOPICS=OpenStack Keystone|
 +
SKILLS=Python |
 +
EXTRA_SKILLS=|
 +
MENTORS=hrybacki and lbragstad on IRC channel #openstack-keystone @ freenode |
 +
STATUS=Looking for candidates.|
 +
PROGRAM=
 +
}}
  
Expected results: (1) Identify a community of users willing to participate in Horizon UI usability testing and participate in various OpenStack concept reviews. (2) Share usability test findings with the community that will be used for design and general Horizon discussions.
+
{{InternshipIdea|
 +
TITLE=Flask support|
 +
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=
 +
}}
  
Knowledge prerequisites: usability testing skills, basic interviewing skills, willingness to talk with a lot of new people, readiness to listen and report back findings, ability to analyze data to find patterns.
+
{{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=
 +
}}
  
Nice-to-have knowledge: User Experience Design and/or User Research basics
+
{{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=
 +
}}
  
Mentors: [[User:julim|Ju Lim]], [[User:lblanchard|Liz Blanchard]]
+
{{InternshipIdea|
 +
TITLE=OpenStack Manila Integration with OpenStack CLI (OSC)|
 +
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|
 +
TOPICS=OpenStack Manila|
 +
SKILLS=Ruby|
 +
EXTRA_SKILLS=Python|
 +
MENTORS=enriquetaso and vkmc on IRC channel #openstack-manila @ freenode|
 +
STATUS=Looking for candidates.|
 +
PROGRAM=Outreachy May-Aug 2019 candidates.
 +
}}

Latest revision as of 16:03, 15 February 2023


This page is not actively maintained.

Before working on any of the internship ideas on this page, contact the listed Mentor to find out whether the idea is still relevant.

You can also take a look at the current Outreachy proposals, which are up-to-date: https://www.outreachy.org/apply/project-selection/#openstack

Finally, you can take a look at the current "Upstream Investment Opportunities", which lists projects of interest to the community that don't have owners: https://governance.openstack.org/tc/reference/upstream-investment-opportunities/

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.