Difference between revisions of "Ironic/Developer guidelines"
(→Tempest tests) |
(→Guidelines for Developers) |
||
| Line 2: | Line 2: | ||
The [http://docs.openstack.org/developer/ironic/dev/dev-quickstart.html developer documentation] provides a good starting point. This provides miscellaneous guidelines for doing development. | The [http://docs.openstack.org/developer/ironic/dev/dev-quickstart.html developer documentation] provides a good starting point. This provides miscellaneous guidelines for doing development. | ||
| + | |||
| + | === Backwards compatibility === | ||
| + | We need to make sure we don't unintentionally break backwards compatibility. Things to watch out for: | ||
| + | * exception names. If you want to change the name of an exception class, please add an alias for the original name. | ||
=== Tempest tests === | === Tempest tests === | ||
Revision as of 15:41, 7 October 2014
Guidelines for Developers
The developer documentation provides a good starting point. This provides miscellaneous guidelines for doing development.
Backwards compatibility
We need to make sure we don't unintentionally break backwards compatibility. Things to watch out for:
- exception names. If you want to change the name of an exception class, please add an alias for the original name.
Tempest tests
[Tempest] tests are black-box functionality tests. [Ironic uses tempest] for API and functional testing.
If your change includes significant API visible functionality, there should be corresponding tempest test coverage. Eg anything that the nova.virt.ironic driver does. The developer responsible for the code changes is also responsible for ensuring that there is tempest test coverage. (The developer doesn't have to make the tempest test changes; they could work with another developer to help write the tempest tests.)
Tempest is run via devstack, where the latest master branch of Ironic is cloned and then tests are run against it. So changes have to be in Ironic before the tempest test can pass. The suggested process is:
- code changes ready for review
- corresponding tempest changes ready for review
- the code changes may be blocked from being approved if there are no corresponding tempest changes
- after the code changes have been merged, the tempest changes will be merged. If the tempest tests fail, we'll all scream.
