Difference between revisions of "Internship ideas"
(→Zaqar: Split data/control planes) |
(→Zaqar: Split data/control planes) |
||
Line 33: | Line 33: | ||
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. | 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 | + | * Expected Results: Both planes should be completely separate |
− | Required Knowedge: Python | + | * Required Knowedge: Python |
=== Trove === | === Trove === |
Revision as of 13:15, 1 October 2014
Contents
- 1 Outreach Program for Women Ideas List
- 2 Documentation
- 3 Community
- 4 Coding
- 5 Design
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. 2014 to March 2015 session. We are still identifying mentors and have sponsorship from the OpenStack Foundation. 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
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
Zaqar: Split data/control planes
Mentor: Flavio Percoco
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: 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: 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: 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: John Dickinson
Neutron - metering agent add port statistics
Description:
In Neutron the metering agent [1] 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: Rossella Sblendido
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:
Using a property graph database (where both nodes and edges have attributes) as a backend for identity, we can express contextual association between any two entities of OpenStack. 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 project is associated with a domain and this association is temporal, if we can say that the association is only active from 8am to 5pm this is something to say about the project-domain association. We can express this as an attribute of the project-domain association edge and use this for access control perspective. Incorporating a property graph database like Neo4j [1] to the OpenStack Identity backend can give us the flexibility to express contextual association of different entities in OpenStack.
Steps to Implement AGBAC in Openstack
1. Add support for an open source graph database Neo4j [1] in the OpenStack Identity backend. 2. In policy specification use path expression based policy. 3. Make a policy analyzer that translates the path expression based policy to “Cypher” query for Neo4j.
[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
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: 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)
Expected results: Redesign of "Containers" section in Object Storage panel proposed and approved by Horizon community.
Knowledge prerequisites: basic sketching or wireframing skills
Nice-to-have knowledge: User Experience Design basics
Mentors: Ju Lim
Horizon Concept Review and Usability Testing
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.
Related blueprint: https://blueprints.launchpad.net/openstack-ux/+spec/ux-users-community-testing
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.
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.
Nice-to-have knowledge: User Experience Design and/or User Research basics
Mentors: Ju Lim