• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Grizzly summit: Quantum API

Grizzly summit: Quantum API



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

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



Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Grizzly summit: Quantum API Grizzly summit: Quantum API Presentation Transcript

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