Nova/PortingAPIExtensionToV3
< Nova
Porting a V2 API extension to the V3 API
Note that it will be significantly easier for people to review porting changes if you split the patch into two changesets:
- In the first just copy the extension and test files unchanged to the v3 directories
- In the second make the modifications required for the V3 API framework and any other API fixes
This will allow people to see just the changes required rather than an entirely new file
Checklist
- Checks before starting porting work on an extensions
- Check the V3 API Work list to see if anyone else is already working on porting the extensions
- https://etherpad.openstack.org/NovaV3ExtensionPortWorkList
- Add your name to the work list indicating that you are working on the extension before starting work on it
- Check to see if it is an extension which we are intentionally not porting to the V3 API
- Volume related functionality which can be directly accessed via Cinder is not being ported
- Network related functionality which can be directly accessed via Quantum is not being ported
- Check the V3 API Work list to see if anyone else is already working on porting the extensions
- Things to look for when porting an extension
- Is this in the list considered for moving to part of the core API?
- https://etherpad.openstack.org/NovaV3APICore - may need to seek out further consensus on mailing list/Nova meeting
- This will change the ALIAS for the extension (eg does it start with os-), but little else
- Should the functionality in this extension be merged with another extension?
- Some extensions have in the past been added merely because we couldn't modify existing extensions and logically the functionality belongs together with another extension
- Do the methods follow REST principles
- eg PUT MUST be idempotent
- Rename policy name for the extension
- The policy auth name should be the extension ALIAS prefixed with v3: - eg instead of "fixed_ips" it should be "v3:os-fixed-ips"
- Is the JSON input/output format consistent with the XML input/output format
- eg parameter names are consistent
- Does the V2 version of the extension have any hooks in servers.py (eg need to modify flags for creating an instance). Looks in v3/servers.py
- Use or add if doesn't already exist an extension point so it can be done without any extension specific modifications to servers.py
- Python style attribute names
- eg imageRef -> image_ref
- Remove updated field, add a version field (see v3/fixed_ips.py as an example)
- Are there actions which should instead be methods
- Add expected_errors decorator for each method which declares what the expected HTTP status codes returned from each method are
- This relies on https://review.openstack.org/#/c/30045/ getting merged first though
- Unittests must be ported as well of course
- Make sure that the test file is importing the v3 version of the python module :-)
- Will need lots of v2 -> v3 renaming of paths
- Will need to remove the project_id/tenant_id from the path
- wsgi_app will need to be changed to wsgi_app_v3 or the test will run against the V2 API
- Is this in the list considered for moving to part of the core API?
