=== How to Get Involved ===
As the involvement process is pretty consistent, we've moved that information to the [http://docs.openstack.org/developer/nova/how_to_get_involved.html Developer Reference Guide]. This page covers more in-flux items like who to contact and a rotating list of tasks that are good for new contributors.

Nova is a huge project with a lot going on, so don't expect to grok everything. You should pick a few areas to focus on while you're learning the lay of the land, or you'll get overwhelmed pretty quickly.

==== Team Priorities ====
Current Priorities for Newton: https://etherpad.openstack.org/p/newton-nova-priorities-tracking

==== Attend the Nova Team Meeting ====
The Nova team has weekly meetings at alternating times to accomodate different time zones. Attend this meeting, or read the logs to stay up to date. Work items often come up that you can volunteer to take on, or at least offer to help the person who has volunteered for it.

==== Join a Subteam ====
Nova is a big project and we have several subteams that are focused on specific efforts. Each of these subteams has a weekly meeting. If you are interested in getting involved with a subteam you can either attend the weekly meeting or keep up with the meeting logs if the time is inconvenient for you. During these meetings, subteams might mention tasks they need done and if the task isn't ideal for a new contributor, you may be able to pair with a current contributor who can delegate work to you. You can also offer to help someone out with documentation or test coverage, for instance.

Each subteam has a primary organizer. If you can't attend a subteam's meeting to introduce yourself, reach out to the subteam's organizer or a member of the subteam working on the thing you are interested in, and introduce yourself to them.

==== Attend the Design Summit or Midcycle Meeting ====
Meeting the other contributors face to face is really helpful. Even if you are just starting out, being present during the discussions can provide a lot of context. Try to review items that are published in the agenda for these meetings beforehand so you have some context prior to going in. During the meetings, take really good notes and ask clarifying questions outside of the main discussion. After the meeting, summarize the keys issues in your notes so you can follow subsequent discussions. Pick some areas to follow reviews on and even if you don't feel comfortable contributing a +1, make sure you at least understand the proposal or the code change itself.

=== Who to Contact ===

The current Mentoring Czar is:
* Augustina Ragwitz
** irc: auggy
** email: auggy@cpan.org

=== Work Items for New Contributors ===

The following is a list of areas with projects ideal for new contributors to participate in.

==== Fixing Bugs ====

While working on bugs is a normally a good way to get to know a new code base, that can be really tricky in Nova. Randomly submitting patches for bugs without talking to anyone is probably the least effective way to contribute to Nova. Always introduce yourself to the Nova team on IRC in #openstack-nova and ask about a bug before working on it.

===== Picking up a Bug =====
If you find a bug you want to work on, first ask in the #openstack-nova channel before assigning it to yourself. This serves a few purposes:
* Introduces you to the team
* Announces your intent to work on a bug, so others won't work on it
* Allows you to get context so your change is more likely to get approved

You can assign yourself the bug in 2 ways: 1) manually assign it in Launchpad or 2) submit a change referencing the bug ("Closes-Bug: 1234")

When you assign a bug to yourself in Launchpad, you have 2 weeks to submit a patch before you will be unassigned.

===== Recommended Tags =====
We use Launchpad as our bug tracker and bugs that have been verified are tagged to categorize them.

Here is a list of tags with bugs that might be good for new contributors:
* needs-functional-test: https://bugs.launchpad.net/nova/+bugs?field.tag=needs-functional-test
* api-ref: https://bugs.launchpad.net/nova/+bugs?field.tag=api-ref
* doc: https://bugs.launchpad.net/nova/+bugs?field.tag=doc
* testing: https://bugs.launchpad.net/nova/+bugs?field.tag=testing
* api: https://bugs.launchpad.net/nova/+bugs?field.tag=api

===== Low-Hanging-Fruit =====
Bugs tagged with "Low Hanging Fruit" are not usually good for new contributors. Try to use one of the tags above instead.
A list of low hanging fruit bugs is available here: https://bugs.launchpad.net/nova/+bugs?field.tag=low-hanging-fruit

==== Bug Queue Maintenance ====
* Contacts: markus_z, auggy
* Team Wiki Page: https://wiki.openstack.org/wiki/Nova/BugsTeam
* Meetings: https://wiki.openstack.org/wiki/Meetings/Nova/BugsTeam

Bug queue maintenance is managed by the Nova Bugs Team. This team is a great place to start getting involved with Nova! Bug Skimming and Triaging can teach you a lot about how Nova works and it gets you more engaged with the team. Before jumping on any of these tasks, please attend a Nova Bugs Team meeting and introduce yourself.

===== Bug Skimming =====
Bug skimming is a weekly commitment that involves monitoring new incoming bugs, tagging them appropriately, and attempting to reproduce them in order to verify them. Once a bug has been skimmed, it is marked as "Confirmed" and it can be triaged. Triaging means a priority is assigned and debug steps are taken to determine the root cause and to propose a possible fix.

See https://wiki.openstack.org/wiki/Nova/BugTriage

===== Bug Maintenance =====
Besides managing new bugs, we also update potentially stale bugs and clean up INCOMPLETE bugs.

See https://wiki.openstack.org/wiki/Meetings/Nova/BugsTeam#Queries

==== Centralize Config Options ====
Contacts: markus_z

Move configuration options from modules scattered throughout the Nova codebase into a few modules. Also improve documentation of these configuration options.

Resources:
* Background: http://lists.openstack.org/pipermail/openstack-dev/2015-November/079531.html
* Spec: https://blueprints.launchpad.net/nova/+spec/centralize-config-options-newton
* Project etherpad: https://etherpad.openstack.org/p/config-options

==== Improve Python 3 Compatibility ====
* Contacts: claudiub

Current Work Items:
* Get unit tests running under the python34 environment: https://blueprints.launchpad.net/nova/+spec/nova-python3-newton
* Need help with removing mox3 tests that are racing with py34: https://blueprints.launchpad.net/nova/+spec/remove-mox
* You can see the tests that need converting here: https://github.com/openstack/nova/blob/master/tests-py3.txt

''TODO(auggy): Update description and provide instructions on how to pick up a work item''

==== Objects ====
* Contacts: rlrossit, dansmith
* Wiki: https://wiki.openstack.org/wiki/ObjectProposal
* Current blueprint: https://blueprints.launchpad.net/nova/+spec/rm-object-dict-compat-newton

Removing nova.objects.base.NovaObjectDictCompat subclassing

The idea is to get the code base to the point where we are not accessing data model attributes via dict-key access. There is a mixin called NovaObjectDictCompat that is used for all "older" nova.objects models. It's a relatively easy exercise, if tedious, to free an older object from this mixin:

You can find these objects here: https://github.com/openstack/nova/search?utf8=%E2%9C%93&q=Remove+NovaObjectDictCompat&type=Code

# Remove an object's base.NovaObjectDictCompat mixin
# Run unit tests and note all failures with errors like "no __getitem__ method"
# Go into the source code and unit tests and change all obj[key] accesses to be obj.key accesses
# Re-run unit tests until everything passes
# Rinse and repeat with a new object.

The work is being tracked by a blueprint and patches converting to using objects should include in the commit message: "Partially-Implements: blueprint rm-object-dict-compat-newton"
Note: use topic branch 'bp/rm-object-dict-compat-newton' when pushing changes to Gerrit so all open changes for the blueprint can be seen together. To set a topic, do "git review -t bp/rm-object-dict-compat-newton" when you push a review.
The already merged patches in the blueprint can be used as guides for those new to objects.

How to find areas that need to be converted
* Look for direct DB access, for example, code containing "db.*" that isn't under nova/objects or nova/quota. Code calling "db.*" is returned dict-like SQLAlchemy model objects from the DB layer, which don't have versions.
* Look for dict-like access of objects. If they are versioned objects, the dict-like access needs to be changed to use dot notation. For example, "instance['uuid']" becomes "instance.uuid"
* Look for jsonutils.to_primitive() that is turning objects into dicts over RPC interfaces (or other persistence)
* A lot of tests still need to be converted. Almost anywhere you see a mock or stub for a db.instance_* method, that thing should be mocking out the object layer instead. Exceptions would be tests of the objects themselves, tests of the DB API layer, and probably some legacy EC2 tests that are hardly worth converting.
* There is a lot of db.* mocking out that happens in the API extension unit tests, i.e. http://git.openstack.org/cgit/openstack/nova/tree/nova/tests/unit/api/openstack/compute - they mock out things that the objects call in the DB API, and the objects are used in nova.compute.api which is the compute_api in the API extension code, so those unit tests dig very deep to do the DB mocking. (mriedem)

Known areas that need to be converted:
* cells
* HostAPI
* SecurityGroupAPI
* nova-manage
* console API

Examples
* Support Network objects in set_network_host: https://review.openstack.org/#/c/192396/
* Make resize api of compute manager to send flavor object: https://review.openstack.org/#/c/161860/

Series available for review: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/rm-object-dict-compat-newton,n,z

''TODO(auggy): restructure this so it's more clear how to pick up a work item, also make sure this information is still current''

==== Logging ====
''TODO(auggy): This section needs to be updated''

Fix logs that violate these guidelines: http://specs.openstack.org/openstack/openstack-specs/specs/log-guidelines.html

==== Unit Test Cleanup ====
''TODO(auggy): This section needs to be updated''

* Conversion from mox to mock
** can be done in small, iterative patches.
* Switch the test.TestCase-derived unit tests to be test.NoDBTestCase-derived
** The latter tests do not need to have full service endpoints and database created for each test construction, making them significantly faster to run.

==== Standardize Error Messages ====
TODO(auggy): Update this

==== Subteam Specific Work Items ====
The following is a list of work items grouped by specific subteam.

==== API ====
Contacts: alex_xu, oomichi, sdague, auggy
Meetings: https://wiki.openstack.org/wiki/Meetings/NovaAPI
Team Information:

===== Fix API Documentation =====
Recently, Nova moved our API documentation from WADL XML format to RST, a human readable text markup common in the Python community. We also moved these documents into our Nova source tree and out of the central documentation repository. As part of this effort, we are verifying the correctness of this API documentation.

Resources:
Mailing List details - http://lists.openstack.org/pipermail/openstack-dev/2016-April/092936.html
Steps for how to do verification: https://wiki.openstack.org/wiki/NovaAPIRef
Burndown Chart, shows what files need verifying: http://burndown.dague.org/

==== Cells v2 ====
Contacts:
Meetings:
Team Information:

==== Live Migration ====
Contacts:
Meetings:
Team Information:

==== Notifications ====
Contacts: gibi
Meetings: https://wiki.openstack.org/wiki/Meetings/NovaNotification
Team Information: https://etherpad.openstack.org/p/nova-versioned-notifications

==== Scheduler ====
Contacts:
Meetings: https://wiki.openstack.org/wiki/Meetings/NovaScheduler
Team Information:

==== SR-IOV and NFV subteam ====
Contacts:
Meetings:
Team Information:

Nova/Mentoring

2016-05-21T00:18:12Z

Mmmpork: /* Logging */

=== How to Get Involved ===
As the involvement process is pretty consistent, we've moved that information to the [http://docs.openstack.org/developer/nova/how_to_get_involved.html Developer Reference Guide]. This page covers more in-flux items like who to contact and a rotating list of tasks that are good for new contributors.

Nova is a huge project with a lot going on, so don't expect to grok everything. You should pick a few areas to focus on while you're learning the lay of the land, or you'll get overwhelmed pretty quickly.

==== Team Priorities ====
Current Priorities for Newton: https://etherpad.openstack.org/p/newton-nova-priorities-tracking

==== Attend the Nova Team Meeting ====
The Nova team has weekly meetings at alternating times to accomodate different time zones. Attend this meeting, or read the logs to stay up to date. Work items often come up that you can volunteer to take on, or at least offer to help the person who has volunteered for it.

==== Join a Subteam ====
Nova is a big project and we have several subteams that are focused on specific efforts. Each of these subteams has a weekly meeting. If you are interested in getting involved with a subteam you can either attend the weekly meeting or keep up with the meeting logs if the time is inconvenient for you. During these meetings, subteams might mention tasks they need done and if the task isn't ideal for a new contributor, you may be able to pair with a current contributor who can delegate work to you. You can also offer to help someone out with documentation or test coverage, for instance.

Each subteam has a primary organizer. If you can't attend a subteam's meeting to introduce yourself, reach out to the subteam's organizer or a member of the subteam working on the thing you are interested in, and introduce yourself to them.

==== Attend the Design Summit or Midcycle Meeting ====
Meeting the other contributors face to face is really helpful. Even if you are just starting out, being present during the discussions can provide a lot of context. Try to review items that are published in the agenda for these meetings beforehand so you have some context prior to going in. During the meetings, take really good notes and ask clarifying questions outside of the main discussion. After the meeting, summarize the keys issues in your notes so you can follow subsequent discussions. Pick some areas to follow reviews on and even if you don't feel comfortable contributing a +1, make sure you at least understand the proposal or the code change itself.

=== Who to Contact ===

The current Mentoring Czar is:
* Augustina Ragwitz
** irc: auggy
** email: auggy@cpan.org

=== Work Items for New Contributors ===

The following is a list of areas with projects ideal for new contributors to participate in.

==== Fixing Bugs ====

While working on bugs is a normally a good way to get to know a new code base, that can be really tricky in Nova. Randomly submitting patches for bugs without talking to anyone is probably the least effective way to contribute to Nova. Always introduce yourself to the Nova team on IRC in #openstack-nova and ask about a bug before working on it.

===== Picking up a Bug =====
If you find a bug you want to work on, first ask in the #openstack-nova channel before assigning it to yourself. This serves a few purposes:
* Introduces you to the team
* Announces your intent to work on a bug, so others won't work on it
* Allows you to get context so your change is more likely to get approved

You can assign yourself the bug in 2 ways: 1) manually assign it in Launchpad or 2) submit a change referencing the bug ("Closes-Bug: 1234")

When you assign a bug to yourself in Launchpad, you have 2 weeks to submit a patch before you will be unassigned.

===== Recommended Tags =====
We use Launchpad as our bug tracker and bugs that have been verified are tagged to categorize them.

Here is a list of tags with bugs that might be good for new contributors:
* needs-functional-test: https://bugs.launchpad.net/nova/+bugs?field.tag=needs-functional-test
* api-ref: https://bugs.launchpad.net/nova/+bugs?field.tag=api-ref
* doc: https://bugs.launchpad.net/nova/+bugs?field.tag=doc
* testing: https://bugs.launchpad.net/nova/+bugs?field.tag=testing
* api: https://bugs.launchpad.net/nova/+bugs?field.tag=api

===== Low-Hanging-Fruit =====
Bugs tagged with "Low Hanging Fruit" are not usually good for new contributors. Try to use one of the tags above instead.
A list of low hanging fruit bugs is available here: https://bugs.launchpad.net/nova/+bugs?field.tag=low-hanging-fruit

==== Bug Queue Maintenance ====
* Contacts: markus_z, auggy
* Team Wiki Page: https://wiki.openstack.org/wiki/Nova/BugsTeam
* Meetings: https://wiki.openstack.org/wiki/Meetings/Nova/BugsTeam

Bug queue maintenance is managed by the Nova Bugs Team. This team is a great place to start getting involved with Nova! Bug Skimming and Triaging can teach you a lot about how Nova works and it gets you more engaged with the team. Before jumping on any of these tasks, please attend a Nova Bugs Team meeting and introduce yourself.

===== Bug Skimming =====
Bug skimming is a weekly commitment that involves monitoring new incoming bugs, tagging them appropriately, and attempting to reproduce them in order to verify them. Once a bug has been skimmed, it is marked as "Confirmed" and it can be triaged. Triaging means a priority is assigned and debug steps are taken to determine the root cause and to propose a possible fix.

See https://wiki.openstack.org/wiki/Nova/BugTriage

===== Bug Maintenance =====
Besides managing new bugs, we also update potentially stale bugs and clean up INCOMPLETE bugs.

See https://wiki.openstack.org/wiki/Meetings/Nova/BugsTeam#Queries

==== Centralize Config Options ====
Contacts: markus_z

Move configuration options from modules scattered throughout the Nova codebase into a few modules. Also improve documentation of these configuration options.

Resources:
* Background: http://lists.openstack.org/pipermail/openstack-dev/2015-November/079531.html
* Spec: https://blueprints.launchpad.net/nova/+spec/centralize-config-options-newton
* Project etherpad: https://etherpad.openstack.org/p/config-options

==== Improve Python 3 Compatibility ====
* Contacts: claudiub

Current Work Items:
* Get unit tests running under the python34 environment: https://blueprints.launchpad.net/nova/+spec/nova-python3-newton
* Need help with removing mox3 tests that are racing with py34: https://blueprints.launchpad.net/nova/+spec/remove-mox
* You can see the tests that need converting here: https://github.com/openstack/nova/blob/master/tests-py3.txt

''TODO(auggy): Update description and provide instructions on how to pick up a work item''

==== Objects ====
* Contacts: rlrossit, dansmith
* Wiki: https://wiki.openstack.org/wiki/ObjectProposal
* Current blueprint: https://blueprints.launchpad.net/nova/+spec/rm-object-dict-compat-newton

Removing nova.objects.base.NovaObjectDictCompat subclassing

The idea is to get the code base to the point where we are not accessing data model attributes via dict-key access. There is a mixin called NovaObjectDictCompat that is used for all "older" nova.objects models. It's a relatively easy exercise, if tedious, to free an older object from this mixin:

You can find these objects here: https://github.com/openstack/nova/search?utf8=%E2%9C%93&q=Remove+NovaObjectDictCompat&type=Code

# Remove an object's base.NovaObjectDictCompat mixin
# Run unit tests and note all failures with errors like "no __getitem__ method"
# Go into the source code and unit tests and change all obj[key] accesses to be obj.key accesses
# Re-run unit tests until everything passes
# Rinse and repeat with a new object.

The work is being tracked by a blueprint and patches converting to using objects should include in the commit message: "Partially-Implements: blueprint rm-object-dict-compat-newton"
Note: use topic branch 'bp/rm-object-dict-compat-newton' when pushing changes to Gerrit so all open changes for the blueprint can be seen together. To set a topic, do "git review -t bp/rm-object-dict-compat-newton" when you push a review.
The already merged patches in the blueprint can be used as guides for those new to objects.

How to find areas that need to be converted
* Look for direct DB access, for example, code containing "db.*" that isn't under nova/objects or nova/quota. Code calling "db.*" is returned dict-like SQLAlchemy model objects from the DB layer, which don't have versions.
* Look for dict-like access of objects. If they are versioned objects, the dict-like access needs to be changed to use dot notation. For example, "instance['uuid']" becomes "instance.uuid"
* Look for jsonutils.to_primitive() that is turning objects into dicts over RPC interfaces (or other persistence)
* A lot of tests still need to be converted. Almost anywhere you see a mock or stub for a db.instance_* method, that thing should be mocking out the object layer instead. Exceptions would be tests of the objects themselves, tests of the DB API layer, and probably some legacy EC2 tests that are hardly worth converting.
* There is a lot of db.* mocking out that happens in the API extension unit tests, i.e. http://git.openstack.org/cgit/openstack/nova/tree/nova/tests/unit/api/openstack/compute - they mock out things that the objects call in the DB API, and the objects are used in nova.compute.api which is the compute_api in the API extension code, so those unit tests dig very deep to do the DB mocking. (mriedem)

Known areas that need to be converted:
* cells
* HostAPI
* SecurityGroupAPI
* nova-manage
* console API

Examples
* Support Network objects in set_network_host: https://review.openstack.org/#/c/192396/
* Make resize api of compute manager to send flavor object: https://review.openstack.org/#/c/161860/

Series available for review: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/rm-object-dict-compat-newton,n,z

''TODO(auggy): restructure this so it's more clear how to pick up a work item, also make sure this information is still current''

==== Logging ====
''TODO(auggy): This section needs to be updated''

Fix logs that violate these guidelines: http://specs.openstack.org/openstack/openstack-specs/specs/log-guidelines.html

==== Unit Test Cleanup ====
TODO(auggy): Update this

* Conversion from mox to mock

Can be done in small, iterative patches.

* Switch the test.TestCase-derived unit tests to be test.NoDBTestCase-derived

The latter tests do not need to have full service endpoints and database created for each test construction, making them significantly faster to run.

==== Standardize Error Messages ====
TODO(auggy): Update this

==== Subteam Specific Work Items ====
The following is a list of work items grouped by specific subteam.

==== API ====
Contacts: alex_xu, oomichi, sdague, auggy
Meetings: https://wiki.openstack.org/wiki/Meetings/NovaAPI
Team Information:

===== Fix API Documentation =====
Recently, Nova moved our API documentation from WADL XML format to RST, a human readable text markup common in the Python community. We also moved these documents into our Nova source tree and out of the central documentation repository. As part of this effort, we are verifying the correctness of this API documentation.

Resources:
Mailing List details - http://lists.openstack.org/pipermail/openstack-dev/2016-April/092936.html
Steps for how to do verification: https://wiki.openstack.org/wiki/NovaAPIRef
Burndown Chart, shows what files need verifying: http://burndown.dague.org/

==== Cells v2 ====
Contacts:
Meetings:
Team Information:

==== Live Migration ====
Contacts:
Meetings:
Team Information:

==== Notifications ====
Contacts: gibi
Meetings: https://wiki.openstack.org/wiki/Meetings/NovaNotification
Team Information: https://etherpad.openstack.org/p/nova-versioned-notifications

==== Scheduler ====
Contacts:
Meetings: https://wiki.openstack.org/wiki/Meetings/NovaScheduler
Team Information:

==== SR-IOV and NFV subteam ====
Contacts:
Meetings:
Team Information:

Nova/Mentoring

2016-05-21T00:16:42Z

Mmmpork: /* Objects */

=== How to Get Involved ===
As the involvement process is pretty consistent, we've moved that information to the [http://docs.openstack.org/developer/nova/how_to_get_involved.html Developer Reference Guide]. This page covers more in-flux items like who to contact and a rotating list of tasks that are good for new contributors.

Nova is a huge project with a lot going on, so don't expect to grok everything. You should pick a few areas to focus on while you're learning the lay of the land, or you'll get overwhelmed pretty quickly.

==== Team Priorities ====
Current Priorities for Newton: https://etherpad.openstack.org/p/newton-nova-priorities-tracking

==== Attend the Nova Team Meeting ====
The Nova team has weekly meetings at alternating times to accomodate different time zones. Attend this meeting, or read the logs to stay up to date. Work items often come up that you can volunteer to take on, or at least offer to help the person who has volunteered for it.

==== Join a Subteam ====
Nova is a big project and we have several subteams that are focused on specific efforts. Each of these subteams has a weekly meeting. If you are interested in getting involved with a subteam you can either attend the weekly meeting or keep up with the meeting logs if the time is inconvenient for you. During these meetings, subteams might mention tasks they need done and if the task isn't ideal for a new contributor, you may be able to pair with a current contributor who can delegate work to you. You can also offer to help someone out with documentation or test coverage, for instance.

Each subteam has a primary organizer. If you can't attend a subteam's meeting to introduce yourself, reach out to the subteam's organizer or a member of the subteam working on the thing you are interested in, and introduce yourself to them.

==== Attend the Design Summit or Midcycle Meeting ====
Meeting the other contributors face to face is really helpful. Even if you are just starting out, being present during the discussions can provide a lot of context. Try to review items that are published in the agenda for these meetings beforehand so you have some context prior to going in. During the meetings, take really good notes and ask clarifying questions outside of the main discussion. After the meeting, summarize the keys issues in your notes so you can follow subsequent discussions. Pick some areas to follow reviews on and even if you don't feel comfortable contributing a +1, make sure you at least understand the proposal or the code change itself.

=== Who to Contact ===

The current Mentoring Czar is:
* Augustina Ragwitz
** irc: auggy
** email: auggy@cpan.org

=== Work Items for New Contributors ===

The following is a list of areas with projects ideal for new contributors to participate in.

==== Fixing Bugs ====

While working on bugs is a normally a good way to get to know a new code base, that can be really tricky in Nova. Randomly submitting patches for bugs without talking to anyone is probably the least effective way to contribute to Nova. Always introduce yourself to the Nova team on IRC in #openstack-nova and ask about a bug before working on it.

===== Picking up a Bug =====
If you find a bug you want to work on, first ask in the #openstack-nova channel before assigning it to yourself. This serves a few purposes:
* Introduces you to the team
* Announces your intent to work on a bug, so others won't work on it
* Allows you to get context so your change is more likely to get approved

You can assign yourself the bug in 2 ways: 1) manually assign it in Launchpad or 2) submit a change referencing the bug ("Closes-Bug: 1234")

When you assign a bug to yourself in Launchpad, you have 2 weeks to submit a patch before you will be unassigned.

===== Recommended Tags =====
We use Launchpad as our bug tracker and bugs that have been verified are tagged to categorize them.

Here is a list of tags with bugs that might be good for new contributors:
* needs-functional-test: https://bugs.launchpad.net/nova/+bugs?field.tag=needs-functional-test
* api-ref: https://bugs.launchpad.net/nova/+bugs?field.tag=api-ref
* doc: https://bugs.launchpad.net/nova/+bugs?field.tag=doc
* testing: https://bugs.launchpad.net/nova/+bugs?field.tag=testing
* api: https://bugs.launchpad.net/nova/+bugs?field.tag=api

===== Low-Hanging-Fruit =====
Bugs tagged with "Low Hanging Fruit" are not usually good for new contributors. Try to use one of the tags above instead.
A list of low hanging fruit bugs is available here: https://bugs.launchpad.net/nova/+bugs?field.tag=low-hanging-fruit

==== Bug Queue Maintenance ====
* Contacts: markus_z, auggy
* Team Wiki Page: https://wiki.openstack.org/wiki/Nova/BugsTeam
* Meetings: https://wiki.openstack.org/wiki/Meetings/Nova/BugsTeam

Bug queue maintenance is managed by the Nova Bugs Team. This team is a great place to start getting involved with Nova! Bug Skimming and Triaging can teach you a lot about how Nova works and it gets you more engaged with the team. Before jumping on any of these tasks, please attend a Nova Bugs Team meeting and introduce yourself.

===== Bug Skimming =====
Bug skimming is a weekly commitment that involves monitoring new incoming bugs, tagging them appropriately, and attempting to reproduce them in order to verify them. Once a bug has been skimmed, it is marked as "Confirmed" and it can be triaged. Triaging means a priority is assigned and debug steps are taken to determine the root cause and to propose a possible fix.

See https://wiki.openstack.org/wiki/Nova/BugTriage

===== Bug Maintenance =====
Besides managing new bugs, we also update potentially stale bugs and clean up INCOMPLETE bugs.

See https://wiki.openstack.org/wiki/Meetings/Nova/BugsTeam#Queries

==== Centralize Config Options ====
Contacts: markus_z

Move configuration options from modules scattered throughout the Nova codebase into a few modules. Also improve documentation of these configuration options.

Resources:
* Background: http://lists.openstack.org/pipermail/openstack-dev/2015-November/079531.html
* Spec: https://blueprints.launchpad.net/nova/+spec/centralize-config-options-newton
* Project etherpad: https://etherpad.openstack.org/p/config-options

==== Improve Python 3 Compatibility ====
* Contacts: claudiub

Current Work Items:
* Get unit tests running under the python34 environment: https://blueprints.launchpad.net/nova/+spec/nova-python3-newton
* Need help with removing mox3 tests that are racing with py34: https://blueprints.launchpad.net/nova/+spec/remove-mox
* You can see the tests that need converting here: https://github.com/openstack/nova/blob/master/tests-py3.txt

''TODO(auggy): Update description and provide instructions on how to pick up a work item''

==== Objects ====
* Contacts: rlrossit, dansmith
* Wiki: https://wiki.openstack.org/wiki/ObjectProposal
* Current blueprint: https://blueprints.launchpad.net/nova/+spec/rm-object-dict-compat-newton

Removing nova.objects.base.NovaObjectDictCompat subclassing

The idea is to get the code base to the point where we are not accessing data model attributes via dict-key access. There is a mixin called NovaObjectDictCompat that is used for all "older" nova.objects models. It's a relatively easy exercise, if tedious, to free an older object from this mixin:

You can find these objects here: https://github.com/openstack/nova/search?utf8=%E2%9C%93&q=Remove+NovaObjectDictCompat&type=Code

# Remove an object's base.NovaObjectDictCompat mixin
# Run unit tests and note all failures with errors like "no __getitem__ method"
# Go into the source code and unit tests and change all obj[key] accesses to be obj.key accesses
# Re-run unit tests until everything passes
# Rinse and repeat with a new object.

The work is being tracked by a blueprint and patches converting to using objects should include in the commit message: "Partially-Implements: blueprint rm-object-dict-compat-newton"
Note: use topic branch 'bp/rm-object-dict-compat-newton' when pushing changes to Gerrit so all open changes for the blueprint can be seen together. To set a topic, do "git review -t bp/rm-object-dict-compat-newton" when you push a review.
The already merged patches in the blueprint can be used as guides for those new to objects.

How to find areas that need to be converted
* Look for direct DB access, for example, code containing "db.*" that isn't under nova/objects or nova/quota. Code calling "db.*" is returned dict-like SQLAlchemy model objects from the DB layer, which don't have versions.
* Look for dict-like access of objects. If they are versioned objects, the dict-like access needs to be changed to use dot notation. For example, "instance['uuid']" becomes "instance.uuid"
* Look for jsonutils.to_primitive() that is turning objects into dicts over RPC interfaces (or other persistence)
* A lot of tests still need to be converted. Almost anywhere you see a mock or stub for a db.instance_* method, that thing should be mocking out the object layer instead. Exceptions would be tests of the objects themselves, tests of the DB API layer, and probably some legacy EC2 tests that are hardly worth converting.
* There is a lot of db.* mocking out that happens in the API extension unit tests, i.e. http://git.openstack.org/cgit/openstack/nova/tree/nova/tests/unit/api/openstack/compute - they mock out things that the objects call in the DB API, and the objects are used in nova.compute.api which is the compute_api in the API extension code, so those unit tests dig very deep to do the DB mocking. (mriedem)

Known areas that need to be converted:
* cells
* HostAPI
* SecurityGroupAPI
* nova-manage
* console API

Examples
* Support Network objects in set_network_host: https://review.openstack.org/#/c/192396/
* Make resize api of compute manager to send flavor object: https://review.openstack.org/#/c/161860/

Series available for review: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/rm-object-dict-compat-newton,n,z

''TODO(auggy): restructure this so it's more clear how to pick up a work item, also make sure this information is still current''

==== Logging ====
TODO(auggy): Update this

We have agreed this approach for logging:
http://specs.openstack.org/openstack/openstack-specs/specs/log-guidelines.html

It would be good to fix up some of our logs that violate those guidelines.

==== Unit Test Cleanup ====
TODO(auggy): Update this

* Conversion from mox to mock

Can be done in small, iterative patches.

* Switch the test.TestCase-derived unit tests to be test.NoDBTestCase-derived

The latter tests do not need to have full service endpoints and database created for each test construction, making them significantly faster to run.

==== Standardize Error Messages ====
TODO(auggy): Update this

==== Subteam Specific Work Items ====
The following is a list of work items grouped by specific subteam.

==== API ====
Contacts: alex_xu, oomichi, sdague, auggy
Meetings: https://wiki.openstack.org/wiki/Meetings/NovaAPI
Team Information:

===== Fix API Documentation =====
Recently, Nova moved our API documentation from WADL XML format to RST, a human readable text markup common in the Python community. We also moved these documents into our Nova source tree and out of the central documentation repository. As part of this effort, we are verifying the correctness of this API documentation.

Resources:
Mailing List details - http://lists.openstack.org/pipermail/openstack-dev/2016-April/092936.html
Steps for how to do verification: https://wiki.openstack.org/wiki/NovaAPIRef
Burndown Chart, shows what files need verifying: http://burndown.dague.org/

==== Cells v2 ====
Contacts:
Meetings:
Team Information:

==== Live Migration ====
Contacts:
Meetings:
Team Information:

==== Notifications ====
Contacts: gibi
Meetings: https://wiki.openstack.org/wiki/Meetings/NovaNotification
Team Information: https://etherpad.openstack.org/p/nova-versioned-notifications

==== Scheduler ====
Contacts:
Meetings: https://wiki.openstack.org/wiki/Meetings/NovaScheduler
Team Information:

==== SR-IOV and NFV subteam ====
Contacts:
Meetings:
Team Information: