Jump to: navigation, search

Difference between revisions of "NeutronStarterBugs"

Line 23: Line 23:
 
* '''API "metadata" tag'''s:  a standard part of a tenant-facing cloud API is to be able to tag objects (e.g., networks, ports in the case of quantum) with key value pairs that can be used to filter the set of objects when querying.   
 
* '''API "metadata" tag'''s:  a standard part of a tenant-facing cloud API is to be able to tag objects (e.g., networks, ports in the case of quantum) with key value pairs that can be used to filter the set of objects when querying.   
 
* '''Audit existing code coverage''' report and identify additional unit tests that should be written to improve those numbers.   
 
* '''Audit existing code coverage''' report and identify additional unit tests that should be written to improve those numbers.   
* '''Improve pylint score'''
+
* '''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

Revision as of 07:00, 26 March 2012

Starter Bugs

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

https://bugs.launchpad.net/quantum/+bugs?field.tag=low-hanging-fruit

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.

Starter/Community Projects

Note: if you're interested in taking on one of these starter 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.

  • Keystone support for Quantum Client: the python-quantumclient code does not support the keystone middleware that has been created for Quantum. Ideally, we would match the python-novaclient as closely as possible here, so that users can provide credentials in a similar way (either via CLI arguments or via environment).
  • Split quantum.common: the quantum.common namespace currently exists in the python-quantumclient repository, even though most of the code is not shared by both the client and the server. We'd like to split this package, so that code specific to the server is in the server repository.
  • multi-node devstack support: currently, the quantum support in devstack only supports single node deployments. We should extend it to support multiple nodes. (interested parties: davelaps)
  • API to query extensions supported by currently running plugin: current approach only tells what extensions are loaded, but some loaded extensions may not be supported by the plugin, and thus, should not be used.
  • keystone authz (authn framework exists + is documented, but isn't widely used because we have no authz). Some thoughts on this functionality were included in a write-up here: http://wiki.openstack.org/QuantumAuthZ (interested parties: deepak)
  • quantum client improvements, particularly making it act more like other openstack clients. Quantum client currently doesn't using standard arg parsing, so all args are positional, and there isn't good support for optional arguments. It also isn't possible to put things like your credentials and tenant-id into environment variables (as is the case with other openstack clients). The output also is not in a standard table format like other clients, which can be confusing, and makes the output harder to parse with scripts. The commands should also use dashes, not underscores. Finally, figuring out how people should be able to extend the CLI to take advantage of extensions is another major area for improvement. (interested parties: maru)
  • 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, davelaps)
  • 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.
  • Quantum + Horizon Integration: letting tenants drive Quantum configuration via the Horizon web gui will be important for widespread adoption + use of Quantum. An early version of the Quantum + Horizon integration no longer works with the current Nova + Quantum integration, so we need to redo it (it is currently disabled). We have folks from the Horizon team willing to help, but we need people familiar with Quantum to help them out.
  • API "metadata" tags: a standard part of a tenant-facing cloud API is to be able to tag objects (e.g., networks, ports in the case of quantum) with key value pairs that can be used to filter the set of objects when querying.
  • 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