Jump to: navigation, search

Difference between revisions of "NeutronStarterBugs"

Line 20: Line 20:
  
 
* '''Quantum + Horizon Integration''':  letting tenants drive Quantum configuration via the Horizon web gui will be important for widespread adoption + use of Quantum.  Arvind is working on the base integration of Horizon and Quantum, but we will need a lot more help to get advanced Quantum features (e.g., security groups, L3, port-status, admin-state, port-statistics) expose.   
 
* '''Quantum + Horizon Integration''':  letting tenants drive Quantum configuration via the Horizon web gui will be important for widespread adoption + use of Quantum.  Arvind is working on the base integration of Horizon and Quantum, but we will need a lot more help to get advanced Quantum features (e.g., security groups, L3, port-status, admin-state, port-statistics) expose.   
* '''Notifications API'''.  Other openstack projects like Nova have a notifications API for external tools to listen to event (e.g., network created/destroyed, floating ip allocated/deallocated).  Quantum should leverage that code (ideally as code from openstack-common) for its own notifications infrastructure.  One example of an external system that would like to consume that information is Ceiliometer (https://launchpad.net/ceilometer)  
+
* '''String Localization''': Compared to Nova we haven't paid much attention to string localizationIf this is important to you, updating the codebase for this would be a great way to get up to speed on Quantum.
 +
* '''Ceiliometer Integration'''Use Quantum Notification mechanism (in development) to integrate with Ceiliometer (https://launchpad.net/ceilometer)  
 
* '''Integration with Orchestration/PaaS Layers'''.  While some people will interact with Quantum + Nova APIs directly or via Horizon, others will want to use a mechanism that define a complete topology of servers and network connectivity as a single template.  One possibility for this is the new [[OpenStack]] Heat project (http://wiki.openstack.org/Heat).  Heat is an open source implementation of the Amazon Cloudformation APIs (http://aws.amazon.com/cloudformation/).   
 
* '''Integration with Orchestration/PaaS Layers'''.  While some people will interact with Quantum + Nova APIs directly or via Horizon, others will want to use a mechanism that define a complete topology of servers and network connectivity as a single template.  One possibility for this is the new [[OpenStack]] Heat project (http://wiki.openstack.org/Heat).  Heat is an open source implementation of the Amazon Cloudformation APIs (http://aws.amazon.com/cloudformation/).   
 
* '''System/Integration testing'''.  We need system/integration testing that exercises much more functionality than the basic excercise.sh script.  We'd also like to explore integration with Tempest and working with the openstack CI team to make sure that both unit tests and system/integration testing is a gate to Quantum commits in Folsom.  (interested parties: debo, hua)
 
* '''System/Integration testing'''.  We need system/integration testing that exercises much more functionality than the basic excercise.sh script.  We'd also like to explore integration with Tempest and working with the openstack CI team to make sure that both unit tests and system/integration testing is a gate to Quantum commits in Folsom.  (interested parties: debo, hua)

Revision as of 18:11, 20 July 2012


Code Reviews

Before you even start fixing bugs, a good way to familiarize yourself with the Quantum codebase and development practices is to participate in code reviews.

Starter Bugs

These are bugs that folks new to Quantum might want to pick off as an introduction: low-hanging-fruit bugs

If you're new to Quantum, just assign the bug to yourself on launchpad, and feel free to use the bug (or the mailing list) to ask questions about how to fix it.

Community Projects

Note: if you're interested in taking on one of these community projects, create a blueprint and send email to the netstack list with thoughts and to get feedback from the team. Send email will also help you identify the right people on the Quantum team to help you complete this project.

  • Quantum + Horizon Integration: letting tenants drive Quantum configuration via the Horizon web gui will be important for widespread adoption + use of Quantum. Arvind is working on the base integration of Horizon and Quantum, but we will need a lot more help to get advanced Quantum features (e.g., security groups, L3, port-status, admin-state, port-statistics) expose.
  • String Localization: Compared to Nova we haven't paid much attention to string localization. If this is important to you, updating the codebase for this would be a great way to get up to speed on Quantum.
  • Ceiliometer Integration. Use Quantum Notification mechanism (in development) to integrate with Ceiliometer (https://launchpad.net/ceilometer)
  • Integration with Orchestration/PaaS Layers. While some people will interact with Quantum + Nova APIs directly or via Horizon, others will want to use a mechanism that define a complete topology of servers and network connectivity as a single template. One possibility for this is the new OpenStack Heat project (http://wiki.openstack.org/Heat). Heat is an open source implementation of the Amazon Cloudformation APIs (http://aws.amazon.com/cloudformation/).
  • System/Integration testing. We need system/integration testing that exercises much more functionality than the basic excercise.sh script. We'd also like to explore integration with Tempest and working with the openstack CI team to make sure that both unit tests and system/integration testing is a gate to Quantum commits in Folsom. (interested parties: debo, hua)
  • Developer documentation. Core openstack projects have develop documentation generated using sphinx and available at <project-name>.openstack.org (e.g., http://keystone.openstack.org/). Quantum currently only has a basic wiki page for developers: http://wiki.openstack.org/QuantumDevelopment . We'll need to improve this significantly in Folsom.
  • Audit existing code coverage report and identify additional unit tests that should be written to improve those numbers.
  • Improve pylint score
  • Openstack Common Make Quantum leverage the "openstack common" library whenever possible. See QuantumOpenstackCommon for a list of files that would be great candidates. If those files contain code that is not specific to Quantum, consider adding it to Openstack common. See: https://github.com/openstack/openstack-common
  • Scale Testing We need to be testing Quantum operations at large scale to identify any bottlenecks. There are three likely divisions for this work. 1) Nova Quantum Integration 2) Quantum API Layer and 3) Plugin Layer. Each plugin will have to be evaluated for scale independently, but it should be pretty easy to use the SamplePlugin just to test scale in the first two layers.