Nova/PortingAPIExtensionToV3

Porting a V2 API extension to the V3 API

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
    • 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
• Things to look for when porting an extension
  • Is this in the list considered for moving to part of the core API?
    • TODO: Add url to etherpad discussion over proposed moves
    • 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