Just some thoughts on things we might do to make the Quantum API better for the Grizzly release

1. Openstack Grizzly Summit
Update on Quantum API
San Diego, California
Monday, October 15th
http://etherpad.openstack.org/quantumapigrizzly

2. Summary
• Where are we (Folsom)
• Where are we going (Grizzly)
– Backward compatibility
– Promoting Extension to Core API
– XML support
• Miscellaneous rubberstamp items
• Extension Framework
• Formally describing Quantum API with a
schema

3. Folsom – Quantum API v2.0
• Core resources: Networks, Ports and Subnets
• Extended resources: Routers, Floating Ips
• Other notable extensions: Provider Networks, External Networks, Quotas
• What has been working well:
– A generic framework for manipulating resources and operating on them
• Data validation and conversion, response formatting, authZ policies
• Where we can make things better:
– Handling extended models
– Enhanced data validation at the API layer
– Reducing DB operations
– Self-documenting API operations
– Client-side stub generation
– Anything else?

4. Towards Grizzly
• Quantum API will stay backward compatible
– Unit/System tests should ideally enforce this
– Moving Quantum API version to 2.1
– Long term API evolution plan? For example…
• new major API version every 4 sw release)
• Define strategy for deprecating attributes and resources
• Extending the core API
– Bring in widely-used, plugin-independent extensions:
• L3, Provider Nets, and Quotas
– Do this in a way which preserves backward
compatibility!

5. XML Support
• Do we need it?
– If yes, we need to ensure it is supported and
documented at least throughout all the 2.x API cycle
• The API controllers are format-agnostic
• Adding XML support boils down to having
appropriate serializer/deserializer.
– Issues to be addressed:
• null values, formatting of sequences, namespaces, and
schemas
• Note: for what is worth, Quantum v1.1 already
supported both XML and JSON

6. Feedback
• Is it ok to move API version to 2.1?
• Opinions on API bw-compatibility strategy?
• Should we include extensions in the core?
• Any opinion on XML support?

7. Miscellaneous API items
• Keystone v3 API is renaming tenant_id to
project_id; options are:
– Follow up, ensuring no bw-incompatible change is
introduced
– Ignore the change and keep using tenant_id
• Paginated responses are not yet available in
Quantum v2
• Responses contain references to other resource
might return links to them
• The last two items are potential blueprints for
Grizzly

8. Extension Framework Improvements
• Bob Kukura

9. Formally describing the Quantum API
• Quantum API layer is pretty much generic
• RESOURCE_ATTRIBUTE_MAP drives the behavior of the API
layer
• Could be formalized using an appropriate schema (e.g.
JSON schema)
• Advantages:
– Easier to understand and control how attributes are
characterized
– Richer characterization of API resources (e.g.: validation
requirements, relationship between resources)
– Generation of API reference documentation
– Generation of client-side stubs
• Disadvantages?