Quantum API 1.1

Monday, October 3rd 9.30 AM

Openstack “Essex” design summitBoston – October 3-5 2001

Netstack track

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

Quantum API 1.1 Operational Status for resources

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

Session Goals

• Discuss and hopefully agree improvements for Quantum API v1.1

• Identify work items and assign them to team members

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

Operational Status Explained

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!

Quantum API 1.1 Improvements for client applications

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

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

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

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

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?

Balancing core versus extensions

The ‘1.0’ balance

• Extremely basic functionality in core• Anything which is not ‘basic’ goes into

extensions

The ‘1.1’ balance

Too little features in core will force most client applications to explicitly use extensions.• Quantum core API should be

enough for large majority of applications

• Small core will cause several client applications to be plugin-specific

Too many features in core will cause Quantum API to bloat• Many plugins will not be

able to implement large chunks of the API

• Complex API less appealing to users

“Goldilocks” region for Quantum API

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 clients

would 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

Extension Framework Improvements

Ying Liu

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?

Rollback Mechanism in/for Quantum

Sumit Naiksatam

The need for Rollback• Quantum API such as create_network,

create_port, etc. results in a series of steps in the plugin implementation

• 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.

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

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.

Follow-up actions discussion