Difference between revisions of "Internship ideas"
m (→Coding) |
m (→Coding) |
||
| (43 intermediate revisions by 16 users not shown) | |||
| Line 9: | Line 9: | ||
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). | 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 == | == Coding == | ||
{{InternshipIdea| | {{InternshipIdea| | ||
| − | TITLE= | + | TITLE=OpenStack as a virtual Kubernetes node| |
| − | DESCRIPTION= We want to make | + | 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=OpenStack Zun, Kubernetes| | ||
| + | SKILLS=Python Go| | ||
| + | EXTRA_SKILLS=| | ||
| + | MENTORS=hongbin on IRC channel #openstack-zun @ freenode | | ||
| + | STATUS=Looking for candidates.| | ||
| + | PROGRAM= | ||
| + | }} | ||
| + | |||
| + | {{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| | DIFFICULTY=Medium| | ||
| − | TOPICS= | + | TOPICS=OpenStack Zun, OpenStack Cinder, Docker| |
SKILLS=Python| | SKILLS=Python| | ||
| − | EXTRA_SKILLS= | + | EXTRA_SKILLS=| |
| − | MENTORS= | + | MENTORS=hongbin on IRC channel #openstack-zun @ freenode | |
| − | STATUS= | + | STATUS=Looking for candidates.| |
| − | PROGRAM= | + | PROGRAM= |
}} | }} | ||
| − | + | {{InternshipIdea| | |
| − | TITLE= | + | TITLE=Help Implement Support for a Generic Backup Driver in Cinder| |
| − | DESCRIPTION= | + | 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| | DIFFICULTY=Medium| | ||
| − | TOPICS= | + | TOPICS=OpenStack Cinder, Storage| |
SKILLS=Python| | SKILLS=Python| | ||
| − | EXTRA_SKILLS= | + | EXTRA_SKILLS=| |
| − | MENTORS= | + | MENTORS=jungleboyj and e0ne on IRC channel #openstack-cinder @ freenode | |
| − | STATUS= | + | STATUS=Looking for candidates.| |
| − | PROGRAM= | + | PROGRAM= |
}} | }} | ||
{{InternshipIdea| | {{InternshipIdea| | ||
| − | TITLE= | + | TITLE=Eliminate Redundant Downloads of Uncached Images| |
| − | DESCRIPTION= | + | 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= | + | 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| | SKILLS=Python| | ||
| − | EXTRA_SKILLS= | + | EXTRA_SKILLS=General distributed systems knowledge| |
| − | MENTORS= | + | MENTORS=jokke_ on IRC channel #openstack-glance @ freenode | |
STATUS=Looking for candidates.| | STATUS=Looking for candidates.| | ||
| − | PROGRAM= | + | PROGRAM= |
}} | }} | ||
| − | + | ||
| − | TITLE= | + | {{InternshipIdea| |
| − | DESCRIPTION= Nova | + | TITLE=Transform legacy notifications to the new versioned framework in Nova| |
| − | DIFFICULTY= Medium| | + | 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| |
| − | TOPICS= | + | DIFFICULTY=Medium| |
| − | SKILLS=Python| | + | TOPICS=OpenStack Nova| |
| + | SKILLS=Python | | ||
EXTRA_SKILLS=| | EXTRA_SKILLS=| | ||
| − | MENTORS= | + | MENTORS=gibi on IRC channel #openstack-nova @ freenode | |
STATUS=Looking for candidates.| | STATUS=Looking for candidates.| | ||
| − | PROGRAM= | + | PROGRAM= |
}} | }} | ||
{{InternshipIdea| | {{InternshipIdea| | ||
| − | TITLE= | + | TITLE=Policy Testing| |
| − | DESCRIPTION= | + | 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= | + | *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 | | |
| − | SKILLS=Python| | + | EXTRA_SKILLS=| |
| − | EXTRA_SKILLS= | + | MENTORS=hrybacki and lbragstad on IRC channel #openstack-keystone @ freenode | |
| − | MENTORS= | + | STATUS=Looking for candidates.| |
| − | STATUS= | + | PROGRAM= |
| − | PROGRAM= | ||
}} | }} | ||
{{InternshipIdea| | {{InternshipIdea| | ||
| − | TITLE= | + | TITLE=Flask support| |
| − | DESCRIPTION= | + | DESCRIPTION= |
| − | DIFFICULTY= Medium| | + | 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.| |
| − | TOPICS= | + | DIFFICULTY=Medium| |
| − | + | TOPICS=OpenStack Keystone| | |
| − | + | SKILLS=Python | | |
| − | + | EXTRA_SKILLS=| | |
| − | | | + | MENTORS=TBA | |
| − | SKILLS=Python| | + | STATUS=Looking for candidates.| |
| − | EXTRA_SKILLS= | + | PROGRAM= |
| − | MENTORS= | ||
| − | STATUS= | ||
| − | PROGRAM= | ||
}} | }} | ||
| − | + | {{InternshipIdea| | |
| − | TITLE= | + | TITLE=Native SAML| |
| − | DESCRIPTION= | + | 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= | ||
| + | }} | ||
| − | + | {{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= | ||
| + | }} | ||
| − | + | {{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| | |
| − | This | + | STATUS=Looking for candidates.| |
| − | DIFFICULTY= | + | PROGRAM=Outreachy May-Aug 2019 candidates. |
| − | TOPICS= | ||
| − | |||
| − | |||
| − | MENTORS= | ||
| − | STATUS=Looking for | ||
| − | PROGRAM= | ||
}} | }} | ||
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. |
