This document summarizes discussions from the Quantum API track at the OpenStack "Essex" design summit. Key topics discussed include: 1) Proposed improvements to the Quantum API 1.1, including adding an "operational status" concept to help clients handle asynchronous behavior and failures, improving response filtering, pagination, and rate limiting. 2) Balancing the scope of core API functionality versus extensions to avoid bloating the core or making it too minimal. Bringing some extensions like QoS into the core was proposed. 3) Enhancements to the extension framework such as enforcing unique vendor IDs and checking extension availability. 4) Adding rollback support within plugins to handle failures and leave the

1. Openstack “Essex” design summitBoston – October 3-5 2001Netstack trackQuantum API 1.1Monday, October 3rd9.30 AM

2. AgendaQuantum API v1.0 summaryIntroducing the “Operational status” conceptMaking the API better for clientsBalancing core and extensionsImproving the extension frameworkRollback for Quantum APIFollow-up actions

3. Quantum API 1.1 Operational Status for resources

4. Quantum API 1.0 summaryVery small operation setAllowed us to be quick and release 1.0 for DiabloOnly two resources managed by QuantumNetwork and portAttachments are plugged into ports but managed by the ‘interface’ serviceE.g. Nova

5. Session GoalsDiscuss and hopefully agree improvements for Quantum API v1.1Identify work items and assign them to team members

6. The Operational Status conceptReflects the current provisioning state of a resourceA resource could exist in the API layer but be ‘operationally’ unavailableStill being provisioned by pluginNo more available due to fault or not enough capabilities in the physical layerThe operational status concept will help Quantum client deal with:Asynchronous behaviour of Quantum PluginsFailures in Quantum Networks

7. Operational Status Explained

8. Operating on resourcesnot operationally availableWhen a resource is not operationally ‘UP’, there are several options:Quantum API accepts the operationThe operation is queued or put on hold until the resource will be operationalThe API layer dispatches anyway the operation to the pluginQuantum API rejects the operation and returns error messageIt is important the API exposes a consistent behaviour regardless of the particular plugin!

9. Quantum API 1.1 Improvements for client applications

10. Making the API better for clientsQuantum API 1.0 is simple and easy but:Does not handle properly ‘LIST’ operationsUnable to specify filters on responsesUnable to organize responses in navigable pagesDoes not provide clear references to resourcesClient must extrapolate identifier from response and then use it to build subsequent request URIsDoes not discipline request from different clients

11. Response FilteringExamples:Return only ACTIVE PORTS for a given networkReturn only PORTS WITH ATTACHMENT for a given networkReturn only NETWORKS WITH ATTACHED PORTS for a given tenantProblem already solved by Openstack APIUsing URL Query parametersExample:GET /tenants/ABC/networks/XYZ/ports?state=ACTIVE

12. Pagination and LinksResponses can contain a large number of itemsClient can request pagination by specifying a page number and the number of elements per pageATOM links can be provided for:easy navigation between pagesAccessing resources in the page itself

13. Rate LimitingThis probably does not need further discussion Not really for improving client app development, but still an important thing to have on the API layerAlready provided by several OpenStack servicesCan be implemented as a standalone middleware moduleOrthogonal to Quantum API

14. Community feedbackDo you agree the previously mentioned features should be available in the next release of the Quantum API?Is there any other feature which you would like to see in the next release of the Quantum API?

15. Balancing core versus extensions

16. The ‘1.0’ balanceExtremely basic functionality in coreAnything which is not ‘basic’ goes into extensions

17. The ‘1.1’ balanceToo many features in core will cause Quantum API to bloatMany plugins will not be able to implement large chunks of the API

18. Complex API less appealing to usersToo little features in core will force most client applications to explicitly use extensions.Quantum core API should be enough for large majority of applications

19. Small core will cause several client applications to be plugin-specific“Goldilocks” region for Quantum API

20. Achieving the new balanceLook at the API from a different perspectiveNot Largest Subset of features implemented by every vendorBut Shortest Subset of features that all clientswould like to have in the API.Bring some extensions (e.g.: QoS) in the CoreDiscuss on new features for the Core (e.g: ACLs)Vendor-specific extensions should stay extensions

21. Extension Framework ImprovementsYing Liu

22. Improvements to extension frameworkVendor ID enforcementEach vendor needs to use a unique ID as vendor IDURL, data extension and action extensions must have this vendor ID as prefixExtension directory’s organization: each vendor has a separate directory with the name of vendor IDFine granularity extension checkingCheck the availability of an extended action or an extended data attributeOther suggestions?

23. Rollback Mechanism in/for QuantumSumit Naiksatam

24. The need for RollbackQuantum API such as create_network, create_port, etc. results in a series of steps in the pluginimplementationOften touch heterogeneous independent systems (via the management plane). If one of these steps fails, it leaves the system in an inconsistent state. It would be desirable to have the ability to rollback the state of the system to a previously consistent state.

25. Proposed ApproachesRollback of logical operationsonus of initiating the rollback on a different (possibly orchestration) service.Issue - it’s likely that some or the entire context has been lost when the higher level service decides to rollbackRollback support within pluginA utility component to cater to the rollback can be developed within Quantum and provided to the plugin