Jump to: navigation, search

Difference between revisions of "Past internship ideas"

(→‎Swift - Improving the security of Swift's internal network)
(→‎Coding)
Line 26: Line 26:
  
 
See also [[:Category:Internship_idea|Ideas pages]].
 
See also [[:Category:Internship_idea|Ideas pages]].
 +
 +
=== Murano - Murano package validation tool ===
 +
 +
Description:
 +
 +
Murano cloud-ready applications are written in MuranoPL language and are packaged into zip packages, with certain prerequisites obligatory (manifest file, package structure, etc.). Having a murano package verification tool would speed up development and debugging of such apps greatly. Package verification tool should include tools for verifying that package structure is correct, all the class files mentioned in manifest file are present. It should also include MuranoPL linting code, to speed up MuranoPL-app development. Finally after the tool is ready — we should implement checks at import level (when importing a package to murano-api) and jobs at commit-time for murano-apps
 +
 +
{| class="wikitable"
 +
|-
 +
| Difficulty || Medium
 +
|-
 +
| Topics || Murano
 +
|-
 +
| Required skills || Python
 +
|-
 +
| Extra skills || YAML
 +
|-
 +
| Mentor || kzaitcev
 +
|}
 +
 +
=== Neutron - ovsdb client monitor for Windows ===
 +
 +
Description:
 +
 +
The OVS agent monitors the ports that are added in the compute host to be able to wire them correctly. In Linux it uses the class InterfacePollingMinimizer that notifies the agent when a new port is plugged or unplugged and passes the related events (port added or deleted). For Windows it uses the class AlwaysPoll that doesn't notify any specific event, it returns always true. The OVS agent in Windows is forced to rescan the devices currently in the machine to infer which were added. This is because the current Windows implementation of the interface polling manager doesn't use ovsdb client monitor. The aim of this project is to use ovsdb client monitor also for Windows and make sure that the events are passed correctly to the OVS agent. This will improve the performance and will enable some clean up in the OVS agent code. The first step is getting familiar with the OVS agent and with Neutron in general. Then you will approach openvswitch tools and investigate how to use ovsdb monitor client in Windows. 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.
 +
 +
{| class="wikitable"
 +
|-
 +
| Difficulty || Medium
 +
|-
 +
| Topics || Neutron
 +
|-
 +
| Required skills || Python
 +
|-
 +
| Extra skills || Networking, OVS
 +
|-
 +
| Mentor || rossella_s
 +
|}
 +
 +
=== Glance - Extended support for requests library ===
 +
 +
Description:
 +
 +
You would be learning about glance-replicator, glance_store drivers and if time permits other modules. You are then expected to add support for requests library ( https://pypi.python.org/pypi/requests ) starting with glance-replicator. Although, supporting more than glance-replicator is not expected, more support you add the better your internship will be. You will also help with bug triage and optimizations around that code base as you add more support.
 +
 +
{| class="wikitable"
 +
|-
 +
| Difficulty || Medium
 +
|-
 +
| Topics || Glance
 +
|-
 +
| Required skills || Python
 +
|-
 +
| Extra skills || Good communication skills
 +
|-
 +
| Mentor || nikhil
 +
|}
 +
 +
=== Glance - Develop a python based GLARE (GLance Artifacts REpository) client library and shell API ===
 +
 +
Description:
 +
 +
You will learn how python based clients are developed in the Openstack realm. You will be responsible for closely working with the Glare drivers to understand the requirements, API evolution and contribute ideas to the development of the Glare API. You should be able to set up the basic build structure, common interfaces, setup configs and infra jobs for the glareclient. Co-ordinate with the Glare drivers and infra team to setup repositories, documentation and test jobs for releases of this client. Also, based on the outcome and feedback from the Glare API discussions you will be responsible for keep evolving the client library.
 +
 +
{| class="wikitable"
 +
|-
 +
| Difficulty || Medium-Advanced
 +
|-
 +
| Topics || Glance
 +
|-
 +
| Required skills || Python
 +
|-
 +
| Extra skills || Shell scripting & packaging, good communication skills
 +
|-
 +
| Mentor || nikhil
 +
|}
 +
 +
=== Searchlight - Extend automated functional testing for Searchlight plugins  / Improve existing plugins ===
 +
 +
Description:
 +
 +
Searchlight is intended to dramatically improving the search capabilities and performance of various OpenStack cloud services by indexing their data into ElasticSearch using plugins. You will be learning the Searchlight fundamentals including indexing, searching, faceting, security, etc. You will also learn the APIs and data models of various other OpenStack services that are indexed into Searchlight. You will understand plugin design then explore all of the functional testing aspects mentioned above. You will be responsible for implementing complete coverage of functional testing for one big or two medium sized plugins. You will improve the existing plugins for any bugs or improvements you discover.
 +
 +
{| class="wikitable"
 +
|-
 +
| Difficulty || Medium-Advanced
 +
|-
 +
| Topics || Searchlight
 +
|-
 +
| Required skills || Python
 +
|-
 +
| Extra skills || Basic understanding of ElasticSearch, good communication skills
 +
|-
 +
| Mentor || nikhil
 +
|}
 +
 +
=== OSprofiler - Implement new storage drivers for OSprofiler / add OSprofiler support to other OpenStack projects ===
 +
 +
Description:
 +
 +
OSprofiler is an Oslo library allowing to trace cross-project requests and identify the OpenStack performance bottlenecks via understanding what time was spent on each request stage, how many requests were used, etc. Lots of developing efforts might be found here, including writing new storage drivers for OSprofiler and adding its integration to other OpenStack projects.
 +
 +
{| class="wikitable"
 +
|-
 +
| Difficulty || Medium-Advanced
 +
|-
 +
| Topics || OSprofiler
 +
|-
 +
| Required skills || Python
 +
|-
 +
| Extra skills ||
 +
|-
 +
| Mentor || DinaBelova
 +
|}
 +
 +
=== Magnum - Container Service for Magnum's Kubernetes Orchestration Engine ===
 +
 +
Description:
 +
 +
Magnum's client has several actions (create/delete/exec/logs/pause/reboot/start/stop/unpause) for containers, currently these commands work only for Docker Swarm COE. When a operator deploys a bay with either Kubernetes COE or the Mesos COE, these command line functionality is not available for the operator as there is not backend support for these operations. In this project, we will first add a concrete implementation for the Container Service that calls Kubernetes API appropriately, then we make sure that the magnum's client command lines work properly against this, just like this works when the operator deploys a bay using swarm COE.
 +
 +
{| class="wikitable"
 +
|-
 +
| Difficulty || Medium
 +
|-
 +
| Topics || Magnum
 +
|-
 +
| Required skills || Python
 +
|-
 +
| Extra skills ||
 +
|-
 +
| Mentor || Dims
 +
|}
 +
 +
=== Horizon- Context-sensitive help in openstack-dashboard ===
 +
 +
Description:
 +
 +
Context-sensitive Help allows the openstack-dashboard to dynamically provide users with links to relevant content, depending on the user's location in the dashboard (ie. their 'user context). This implementation should also allow developers to easily define links to serve for each specific context. For more details please check [https://blueprints.launchpad.net/horizon/+spec/context-sensitive-help this blueprint]
 +
 +
{| class="wikitable"
 +
|-
 +
| Difficulty || Medium
 +
|-
 +
| Topics || Horizon
 +
|-
 +
| Required skills || Python
 +
|-
 +
| Extra skills || Good communication skills
 +
|-
 +
| Mentor || sayalilunkad
 +
|}
 +
 +
===  Keystone- Long Term Tokens ===
 +
 +
Description:
 +
 +
We want to make a form of validation that will ignore expiration of tokens in order to support long running tasks
 +
 +
{| class="wikitable"
 +
|-
 +
| Difficulty || Easy
 +
|-
 +
| Topics || keystone
 +
|-
 +
| Required skills || Python
 +
|-
 +
| Extra skills || Keystone is its own thing, but we'll teach you
 +
|-
 +
| Mentor || ayoung
 +
|}
 +
 +
=== Keystone/Infra - Improving Keystone jobs for new scenarios  ===
 +
 +
Description:
 +
 +
We want to make sure the currently jobs on Jenkins cover the new features on Keystone, such as fernet tokens, v3 API  and functional tests
 +
 +
{| class="wikitable"
 +
|-
 +
| Difficulty || Medium
 +
|-
 +
| Topics || Keystone, Infra, CI
 +
|-
 +
| Required skills || Python
 +
|-
 +
| Extra skills || Tests on CI, but we'll teach you
 +
|-
 +
| Mentor || sayalilunkad
 +
|}
  
 
=== Neutron - metering agent add port statistics  ===
 
=== Neutron - metering agent add port statistics  ===

Revision as of 16:21, 13 September 2016

Contents

Documentation

Mentors:

    • loquacities on IRC / openstack at lanabrindley 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.

Community

To be announced

Mentors:

    • hodepodge on IRC / chris at openstack org
    • EmilienM on IRC / emilien at redhat com
    • reed in IRC / stefano at openstack org


Coding

See also Ideas pages.

Murano - Murano package validation tool

Description:

Murano cloud-ready applications are written in MuranoPL language and are packaged into zip packages, with certain prerequisites obligatory (manifest file, package structure, etc.). Having a murano package verification tool would speed up development and debugging of such apps greatly. Package verification tool should include tools for verifying that package structure is correct, all the class files mentioned in manifest file are present. It should also include MuranoPL linting code, to speed up MuranoPL-app development. Finally after the tool is ready — we should implement checks at import level (when importing a package to murano-api) and jobs at commit-time for murano-apps

Difficulty Medium
Topics Murano
Required skills Python
Extra skills YAML
Mentor kzaitcev

Neutron - ovsdb client monitor for Windows

Description:

The OVS agent monitors the ports that are added in the compute host to be able to wire them correctly. In Linux it uses the class InterfacePollingMinimizer that notifies the agent when a new port is plugged or unplugged and passes the related events (port added or deleted). For Windows it uses the class AlwaysPoll that doesn't notify any specific event, it returns always true. The OVS agent in Windows is forced to rescan the devices currently in the machine to infer which were added. This is because the current Windows implementation of the interface polling manager doesn't use ovsdb client monitor. The aim of this project is to use ovsdb client monitor also for Windows and make sure that the events are passed correctly to the OVS agent. This will improve the performance and will enable some clean up in the OVS agent code. The first step is getting familiar with the OVS agent and with Neutron in general. Then you will approach openvswitch tools and investigate how to use ovsdb monitor client in Windows. 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.

Difficulty Medium
Topics Neutron
Required skills Python
Extra skills Networking, OVS
Mentor rossella_s

Glance - Extended support for requests library

Description:

You would be learning about glance-replicator, glance_store drivers and if time permits other modules. You are then expected to add support for requests library ( https://pypi.python.org/pypi/requests ) starting with glance-replicator. Although, supporting more than glance-replicator is not expected, more support you add the better your internship will be. You will also help with bug triage and optimizations around that code base as you add more support.

Difficulty Medium
Topics Glance
Required skills Python
Extra skills Good communication skills
Mentor nikhil

Glance - Develop a python based GLARE (GLance Artifacts REpository) client library and shell API

Description:

You will learn how python based clients are developed in the Openstack realm. You will be responsible for closely working with the Glare drivers to understand the requirements, API evolution and contribute ideas to the development of the Glare API. You should be able to set up the basic build structure, common interfaces, setup configs and infra jobs for the glareclient. Co-ordinate with the Glare drivers and infra team to setup repositories, documentation and test jobs for releases of this client. Also, based on the outcome and feedback from the Glare API discussions you will be responsible for keep evolving the client library.

Difficulty Medium-Advanced
Topics Glance
Required skills Python
Extra skills Shell scripting & packaging, good communication skills
Mentor nikhil

Searchlight - Extend automated functional testing for Searchlight plugins / Improve existing plugins

Description:

Searchlight is intended to dramatically improving the search capabilities and performance of various OpenStack cloud services by indexing their data into ElasticSearch using plugins. You will be learning the Searchlight fundamentals including indexing, searching, faceting, security, etc. You will also learn the APIs and data models of various other OpenStack services that are indexed into Searchlight. You will understand plugin design then explore all of the functional testing aspects mentioned above. You will be responsible for implementing complete coverage of functional testing for one big or two medium sized plugins. You will improve the existing plugins for any bugs or improvements you discover.

Difficulty Medium-Advanced
Topics Searchlight
Required skills Python
Extra skills Basic understanding of ElasticSearch, good communication skills
Mentor nikhil

OSprofiler - Implement new storage drivers for OSprofiler / add OSprofiler support to other OpenStack projects

Description:

OSprofiler is an Oslo library allowing to trace cross-project requests and identify the OpenStack performance bottlenecks via understanding what time was spent on each request stage, how many requests were used, etc. Lots of developing efforts might be found here, including writing new storage drivers for OSprofiler and adding its integration to other OpenStack projects.

Difficulty Medium-Advanced
Topics OSprofiler
Required skills Python
Extra skills
Mentor DinaBelova

Magnum - Container Service for Magnum's Kubernetes Orchestration Engine

Description:

Magnum's client has several actions (create/delete/exec/logs/pause/reboot/start/stop/unpause) for containers, currently these commands work only for Docker Swarm COE. When a operator deploys a bay with either Kubernetes COE or the Mesos COE, these command line functionality is not available for the operator as there is not backend support for these operations. In this project, we will first add a concrete implementation for the Container Service that calls Kubernetes API appropriately, then we make sure that the magnum's client command lines work properly against this, just like this works when the operator deploys a bay using swarm COE.

Difficulty Medium
Topics Magnum
Required skills Python
Extra skills
Mentor Dims

Horizon- Context-sensitive help in openstack-dashboard

Description:

Context-sensitive Help allows the openstack-dashboard to dynamically provide users with links to relevant content, depending on the user's location in the dashboard (ie. their 'user context). This implementation should also allow developers to easily define links to serve for each specific context. For more details please check this blueprint

Difficulty Medium
Topics Horizon
Required skills Python
Extra skills Good communication skills
Mentor sayalilunkad

Keystone- Long Term Tokens

Description:

We want to make a form of validation that will ignore expiration of tokens in order to support long running tasks

Difficulty Easy
Topics keystone
Required skills Python
Extra skills Keystone is its own thing, but we'll teach you
Mentor ayoung

Keystone/Infra - Improving Keystone jobs for new scenarios

Description:

We want to make sure the currently jobs on Jenkins cover the new features on Keystone, such as fernet tokens, v3 API and functional tests

Difficulty Medium
Topics Keystone, Infra, CI
Required skills Python
Extra skills Tests on CI, but we'll teach you
Mentor sayalilunkad

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

Redis jobboards

The spec @ https://review.openstack.org/#/c/105298/ basically explains all of this (the why, what and where).

Difficulty
Topics TaskFlow, Distributed Systems
Required skills Python
Extra skills Distributed Systems
Mentor Joshua Harlow (harlowja)

Policy | Policy enforcement in OpenStack: Nova Scheduling and Policy integration

Difficulty
Topics Policy, Nova
Required skills
Extra skills
Mentor


Test results dashboard

Tasks: 

    * Create an infra hosted dashboard view of testing results (both check/gate and periodic)
Difficulty
Topics
Required skills
Extra skills
Mentor


Policy | Policy-based intent-driven OpenStack Cloud Infrastructure

See an example case study here: Meta-data Driven Cloud - Running OpenStack @ Scale Using a Policy Framework

Tasks: 

    * Extension of intent-based policy framework to Compute and Storage
    * Policy-based service composition integration with OpenDaylight
Difficulty Moderate to Advanced
Topics Functional and scenario testing framework
Required skills OpenStack, Python
Extra skills
Mentor Sumit Naiksatam, Magesh GV

Rich Network Services in a Federated OpenStack Public Cloud

L4-7 Services' integration, NFV, service function chaining, OpenDaylight

Difficulty Moderate to Advanced
Topics Functional and scenario testing framework
Required skills OpenStack, Python
Extra skills
Mentor Sumit Naiksatam, Magesh GV

Understand OpenStack Operations via Insights from Logs and Metrics: A Data Science Perspective

Tasks: 

    *  How do we make sense out of logs?
    *  How do we set up alarms based on specific events (identify events)
    *  Anomaly detection from Logs
Difficulty
Topics
Required skills Experience/interest in algorithms
Extra skills
Mentor


Keystone | Dynamic Policy

The general idea is described at the blog post Dynamic Policy in Keystone, by Adam Young.

Difficulty Medium
Topics Keystone
Required skills Python
Extra skills
Mentor David Stanek (dstanek), Samuel de Medeiros Queiroz (samueldmq)

Keystone | Tokenless Operations

The general idea is described at the blog post Who can sign for what?, by Adam Young. In few words, the fact of the signature on a document be valid does not mean that the signer was authorized to sign it.

The proposed challenge is to create, based on existing mechanisms, an extension to Keystone client able to check if the the signer of a token was effectively authorized to sign tokens.

Tasks: 

    *  Extract signer data out of the certificates;
    *  Fetch the complete list of certificate from Keystone using the OS-SIMPLE-CERT extension;
    *  Match the signer to the cert to validate the signature and extract the domain data for the token;
    *  Fetch the mapping info from the Federation extension;
    *  Use the mapping info to convert from the signing cert to a keystone user and groups;
    *  Fetch the effective roles from Keystone for the user/groups for that domain;
    *  Fetch policy from Keystone;
    *  Execute the policy check to validate that the signer could sign for the data.
Difficulty Medium
Topics Keystone
Required skills Python
Extra skills
Mentor David Stanek (dstanek), Samuel de Medeiros Queiroz (samueldmq)

Ceilometer

Mentor: Dina Belova

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 Gnocchi, possibly via the rados gateway REST API (as opposed to ceph-sitting-behind-swift-proxy as an alternative storage driver for Swift itself).

Trove

Mentor: Iccha Sethi

Description: MySQL replication enhancements

Work on trove enhancements for mysql replication.

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

WIP Schedule: https://etherpad.openstack.org/p/iaR4TQZ7NP


Swift/Swift3 - Improve S3 compatibility layer

Improve the Swift3 middleware to get better S3 API coverage

https://github.com/stackforge/swift3

Mentors: 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:

Openstack Access Control According to Identity API V3

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: 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

Mentor: 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/baseline-horizon-usability-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

Retrieved from "https://wiki.openstack.org/w/index.php?title=Past_internship_ideas&oldid=132907"