Jump to: navigation, search

Difference between revisions of "Internship ideas"

m (Coding)
m (Coding)
 
(241 intermediate revisions by 49 users not shown)
Line 1: Line 1:
 
 
<!-- ## page was renamed from [[GnomeOutreachWomen]]/Ideas -->
 
<!-- ## page was renamed from [[GnomeOutreachWomen]]/Ideas -->
== Outreach Program for Women Ideas List ==
 
 
The GNOME Foundation provides an outreach program for women. You can learn more here:  https://live.gnome.org/OutreachProgramForWomen.
 
 
OpenStack would like to participate as a project for the Dec. 2013 to March 2014 session. We have identified some mentors and have sponsorship from the OpenStack Foundation, Rackspace and HP to participate in this program. This page should collect the ideas for applicants to work on.
 
 
GNOME OPW emphasizes that applicants may not have ever worked on FLOSS before. There are several stages to the program, but the first stage is to mentor during the application process itself. Joining mailing lists, IRC, understanding the channels of communication are good first steps. Logging bugs and fixing bugs are also good ideas.
 
 
Interns are expected to spend 40 hours a week on the project.
 
 
So, feel free to list ideas here:
 
 
== Documentation ==
 
 
OpenStack documentation is highly technical and processed like the code itself. See below for ideas on how to participate as a doc contributor.
 
 
=== API All-in-one Guide ===
 
 
Description: Define new API Guide, and refactor of the API Reference/s and the API Complete Reference page.
 
  
Blueprint: https://wiki.openstack.org/w/index.php?title=Blueprint-os-api-docs
+
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]].
  
Expected results: New Guide on the api.openstack.org/ site to offer uniform, consistent instructions across multiple OpenStack APIs.
 
  
Knowledge Prerequisites: Understanding of XML, HTML, build automation, APIs, javascript
+
=  List of Ideas for Internships =
Nice-to-have knowledge: WADL, REST API, JSON, programming, Git
 
  
Mentor: Diane Fleming
+
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.
  
== 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).
* Build a supply-chain management system to distribute merchandising to OpenStack User Groups around the world [reed on IRC / stefano at openstack org] [[Community/CollateralMgmt|Details]]
 
* Write a mobile app for tablets to create a paperless kiosk for marketing collateral at events [reed on IRC / stefano at openstack org]
 
* Add audio (video?) real time collaboration capabilities to OpenStack User Groups portal [reed on IRC / stefano at openstack org]
 
  
 
== Coding ==
 
== Coding ==
  
=== Reporting Framework for Ceilometer based on Oslo Reporting ===
+
{{InternshipIdea|
 
+
TITLE=OpenStack as a virtual Kubernetes node|
Description: we need a way to store summary reports generated by Ceilometer. These would be stored as special Events in the CM database and accessable via the CM API. It would be nice to leverage the report work underway in Oslo, if possible.
+
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|
Existing Reporting BP: https://wiki.openstack.org/wiki/GuruMeditationReport
+
TOPICS=OpenStack Zun, Kubernetes|
 
+
SKILLS=Python Go|
Discussion: http://lists.openstack.org/pipermail/openstack-dev/2013-October/016122.html
+
EXTRA_SKILLS=|
 
+
MENTORS=hongbin on IRC channel #openstack-zun @ freenode |
Related work: https://github.com/openstack/oslo-incubator/tree/master/openstack/common/report
+
STATUS=Looking for candidates.|
 
+
PROGRAM=
Expected results: patches to Ceilometer to support the creation of Report Events.
+
}}
 
 
Knowledge prerequisites: programming knowledge
 
 
 
Nice-to-have knowledge: Python
 
 
 
Mentor: [[User:SandyWalsh|Sandy Walsh]]
 
 
 
=== Surface the "Instance Actions" Information ===
 
 
 
Description: In the web dashboard (Horizon), it is possible to see information about the instances currently running. It would be nice to be able to see the instance history when clicking on the details, e.g. to figure out when an instance was shut down and by whom, etc. This information is already provided by an API in the compute service (Nova), and needs to be surfaced both for the user (who can see the history for their own instances) and the admin (who can see the history for everyone). This will probably require using Horizon Tabs and TabGroups, adding it to the instance details and finding a nice way to display the data.
 
 
 
Related blueprint: https://blueprints.launchpad.net/horizon/+spec/instance-actions-dashboard
 
 
 
Expected results: Patchsets submitted for review, reviewed by community members.
 
 
 
Knowledge prerequisites: programming knowledge
 
 
 
Nice-to-have knowledge: Python, Django
 
 
 
Mentor: [[User:Jpichon|Julie Pichon]]
 
=== Marconi WebSocket Transport ===
 
 
 
Description: Marconi, a queuing service for OpenStack, is in its early ages and some of its areas are still being designed and developed from scratch. It is a great opportunity for interns to learn about queuing systems, OpenStack architecture and development methodologies. The proposed project is to help developing a WebSocket based transport for Marconi.
 
 
 
Related blueprint: https://blueprints.launchpad.net/marconi/+spec/websocket-endpoint
 
 
Expected results: Patchsets submitted for review, reviewed by community members.
 
 
 
Knowledge prerequisites: programming knowledge
 
 
 
Nice-to-have knowledge: RESTFul APIs, HTTP, MongoDB
 
 
 
Mentor: [[User:flaper87|Flavio Percoco]]
 
 
 
=== Marconi API Spec ===
 
 
 
Description: Marconi is a queuing service for OpenStack. it's grown very fast, since it was kicked off in late Grizzly. This growth has allowed it to be incubated and to support multiple technologies under the same API and goal. However, there are still some areas that could be more generic and improved. One of those areas is the API specification. As for now, an API is specified within the transport itself. A transport is a frontend plugin that adds support for a specific protocol to Marconi - wsgi, zmq, tcp.
 
 
 
This project is about creating a generic enough API spec that can be interpreted by every transport and that will also allow to have extensions and versioning without sacrificing Marconi's API stability.
 
 
 
Related blueprint: https://blueprints.launchpad.net/marconi/+spec/cross-transport-api-spec
 
 
 
Expected results: Patchsets submitted for review, reviewed by community members. Blueprint draft completion and good development progress.
 
Nice-to-have Knowledge: RESTFul APIs, HTTP.
 
 
 
Mentor: [[User:flaper87|Flavio Percoco]]
 
 
 
=== Sparklines in Horizon ===
 
 
 
Description: A lot of work is currently being done to integrate metering (Ceilometer) better with the web dashboard (Horizon). One nice addition would be to add "sparklines" (for an example of what a sparkline is, [http://www.bissantz.de/site_images/tufte/sparklines.jpg see this]) to some of the tables in Horizon, so that they poll the data from Ceilometer. The Line Charts library should already provide asynchronous polling.
 
 
 
Related blueprint: https://blueprints.launchpad.net/horizon/+spec/sparklines
 
 
 
Expected results: Patchsets submitted for review, reviewed by community members.
 
 
 
Knowledge prerequisites: programming knowledge
 
 
 
Nice-to-have knowledge: Python, Django
 
 
 
Mentors: [[User:Jpichon|Julie Pichon]], [[User:Lsmola|Ladislav Smola]]
 
 
 
=== Selenium integration ===
 
 
 
Description: The web dashboard (Horizon) unit tests heavily rely on mocking in order to run fast and avoid requiring a fully set up OpenStack environment to run. It would be good to expand the Selenium test suite and use it for integration tests that would test Horizon in more depth, including the APIs it relies on.
 
 
 
Members of the community already have ideas on how one might want to implement this, therefore the first step will be to reach out to the community to collect and discuss ideas. Investigating if Selenium is the best tool for the job or if another may suit better (PhantomJS, ...?) would also be part of the task.
 
 
 
Related blueprint: https://blueprints.launchpad.net/horizon/+spec/selenium-integration-testing
 
 
 
Expected results: Patchsets submitted for review, reviewed by community members.
 
 
 
Knowledge prerequisites: programming knowledge
 
 
 
Nice-to-have knowledge: Python, Django, Selenium/UI Testing
 
 
 
Mentors: [[User:Jpichon|Julie Pichon]]
 
 
 
=== Glance - adding MongoDB support ===
 
 
 
Description: Glance is used as metadata repository management tool within OpenStack for server Images. NoSQL can be really useful for DB backend for Glance.
 
 
 
Members of the community already have ideas on how one might want to implement this, therefore the first step will be to reach out to the community to collect and discuss ideas. 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.
 
 
 
Related blueprint: https://blueprints.launchpad.net/glance/+spec/enable-mongo-db
 
  
Expected results: Patchsets submitted for review, reviewed by community members.
+
{{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=
 +
}}
  
Knowledge prerequisites: programming knowledge
+
{{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=
 +
}}
  
Nice-to-have knowledge: Python, MongoDB
+
{{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.
  
Mentors: [[User:IcchaSethi|Iccha Sethi]], [[User:nikhil|Nikhil Komawar]]
+
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=
 +
}}
  
=== Glance - add memcache support for backend upload/download ===
 
  
Description:  
+
{{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=
 +
}}
  
Members of the community already have ideas on how one might want to implement this, therefore the first step will be to reach out to the community to collect and discuss ideas. 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.
+
{{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/glance/+spec/glance-upload-memcache , https://blueprints.launchpad.net/glance/+spec/glance-download-memcache
+
*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: Patchsets submitted for review, reviewed by community members.
+
{{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: programming knowledge
+
{{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: Python
+
{{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:IcchaSethi|Iccha Sethi]], [[User:nikhil|Nikhil Komawar]]
+
{{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 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.