Grizzly summit: Quantum API

895 views

Published on

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

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
895
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
26
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Grizzly summit: Quantum API

  1. 1. Openstack Grizzly Summit Update on Quantum API San Diego, California Monday, October 15thhttp://etherpad.openstack.org/quantumapigrizzly
  2. 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. 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. 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. 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. 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. 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. 8. Extension Framework Improvements• Bob Kukura
  9. 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?

×