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

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

3.
Quantum API 1.1 Operational Status for resources<br />

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

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

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

7.
Operational Status Explained<br />

8.
Operating on resourcesnot operationally available<br />When a resource is not operationally ‘UP’, there are several options:<br />Quantum API accepts the operation<br />The operation is queued or put on hold until the resource will be operational<br />The API layer dispatches anyway the operation to the plugin<br />Quantum API rejects the operation and returns error message<br />It is important the API exposes a consistent behaviour regardless of the particular plugin!<br />

9.
Quantum API 1.1 Improvements for client applications<br />

10.
Making the API better for clients<br />Quantum API 1.0 is simple and easy but:<br />Does not handle properly ‘LIST’ operations<br />Unable to specify filters on responses<br />Unable to organize responses in navigable pages<br />Does not provide clear references to resources<br />Client must extrapolate identifier from response and then use it to build subsequent request URIs<br />Does not discipline request from different clients<br />

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

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

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

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

15.
Balancing core versus extensions<br />

16.
The ‘1.0’ balance<br />Extremely basic functionality in core<br />Anything which is not ‘basic’ goes into extensions<br />

17.
The ‘1.1’ balance<br />Too many features in core will cause Quantum API to bloat<br /><ul><li>Many plugins will not be able to implement large chunks of the API

18.
Complex API less appealing to users</li></ul>Too little features in core will force most client applications to explicitly use extensions.<br /><ul><li>Quantum core API should be enough for large majority of applications

19.
Small core will cause several client applications to be plugin-specific</li></ul>“Goldilocks” region for Quantum API<br />

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

21.
Extension Framework Improvements<br />Ying Liu<br />

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

23.
Rollback Mechanism in/for Quantum<br />Sumit Naiksatam<br />

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

25.
Proposed Approaches<br />Rollback of logical operations<br />onus of initiating the rollback on a different (possibly orchestration) service.<br />Issue - it’s likely that some or the entire context has been lost when the higher level service decides to rollback<br />Rollback support within plugin<br />A utility component to cater to the rollback can be developed within Quantum and provided to the plugin<br />

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

27.
Follow-up actions discussion<br />