Proposal for improvements in Quantum API v1.1 Slides discussed at the Openstack Essex design summut

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

2. Agenda Quantum API v1.0 summary Introducing the “Operational status” concept Making the API better for clients Balancing core and extensions Improving the extension framework Rollback for Quantum API Follow-up actions

3. Quantum API 1.1 Operational Status for resources

4. Quantum API 1.0 summary Very small operation set Allowed us to be quick and release 1.0 for Diablo Only two resources managed by Quantum Network and port Attachments are plugged into ports but managed by the ‘interface’ service E.g. Nova

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

6. The Operational Status concept Reflects the current provisioning state of a resource A resource could exist in the API layer but be ‘operationally’ unavailable Still being provisioned by plugin No more available due to fault or not enough capabilities in the physical layer The operational status concept will help Quantum client deal with: Asynchronous behaviour of Quantum Plugins Failures in Quantum Networks

7. Operational Status Explained

8. Operating on resourcesnot operationally available When a resource is not operationally ‘UP’, there are several options: Quantum API accepts the operation The operation is queued or put on hold until the resource will be operational The API layer dispatches anyway the operation to the plugin Quantum API rejects the operation and returns error message It 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 clients Quantum API 1.0 is simple and easy but: Does not handle properly ‘LIST’ operations Unable to specify filters on responses Unable to organize responses in navigable pages Does not provide clear references to resources Client must extrapolate identifier from response and then use it to build subsequent request URIs Does not discipline request from different clients

11. Response Filtering Examples: Return only ACTIVE PORTS for a given network Return only PORTS WITH ATTACHMENT for a given network Return only NETWORKS WITH ATTACHED PORTS for a given tenant Problem already solved by Openstack API Using URL Query parameters Example: GET /tenants/ABC/networks/XYZ/ports?state=ACTIVE

12. Pagination and Links Responses can contain a large number of items Client can request pagination by specifying a page number and the number of elements per page ATOM links can be provided for: easy navigation between pages Accessing resources in the page itself

13. Rate Limiting This probably does not need further discussion  Not really for improving client app development, but still an important thing to have on the API layer Already provided by several OpenStack services Can be implemented as a standalone middleware module Orthogonal to Quantum API

14. Community feedback Do 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’ balance Extremely basic functionality in core Anything which is not ‘basic’ goes into extensions

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

20. Achieving the new balance Look at the API from a different perspective Not Largest Subset of features implemented by every vendor But Shortest Subset of features that all clientswould like to have in the API. Bring some extensions (e.g.: QoS) in the Core Discuss on new features for the Core (e.g: ACLs) Vendor-specific extensions should stay extensions

21. Extension Framework Improvements Ying Liu

22. Improvements to extension framework Vendor ID enforcement Each vendor needs to use a unique ID as vendor ID URL, data extension and action extensions must have this vendor ID as prefix Extension directory’s organization: each vendor has a separate directory with the name of vendor ID Fine granularity extension checking Check the availability of an extended action or an extended data attribute Other suggestions?

23. Rollback Mechanism in/for Quantum Sumit Naiksatam

24. The need for Rollback Quantum API such as create_network, create_port, etc. results in a series of steps in the pluginimplementation Often 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 Approaches Rollback of logical operations onus 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 rollback Rollback support within plugin A utility component to cater to the rollback can be developed within Quantum and provided to the plugin

26. Rollback support within plugin Register rollback points in the system. Each rollback point would require providing a reference to a corresponding rollback function, and a context to be passed to that function. The framework would associate a time-stamp and ID with each rollback point and maintain this ordered list of rollback points. Ability to initiate a rollback by providing the reference to a particular rollback point (either via the ID or the timestamp). Ability to perform rollback on a range of rollback points. Ability to inspect the rollback points. If parallel operations are permitted by the plugin, the framework would need to ensure that the rollback points are ordered correctly.

27. Follow-up actions discussion