Jump to: navigation, search


Revision as of 23:30, 17 February 2013 by Ryan Lane (talk | contribs) (Text replace - "__NOTOC__" to "")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Quantum Design Principles

questions/comments? email: dan@nicira.com

Quantum is a "virtual network service" that aims to provide a powerful API to define the network connectivity between "interface" devices implemented by other OpenStack services (e.g., vNICs from Nova virtual servers). Based on the design discussions and the Diablo summit, below are three core design principles for Quantum.

Design Principal #1: Abstract API and Pluggable Back-end

Similar to Nova, Quantum exposes an abstract API to allow tenants to define "what" they want (e.g., I want these three servers on the same private L2 network) without requiring the tenant to be aware of "how" this network connectivity is implemented. The Quantum design provides a plug-in architecture to enable different approaches to implementing the abstract network connectivity described via the API. The goal here is to provide a standard interface to consume the virtual network service regardless of the underlying technology used to implement the network fabric.

To start, Quantum is focused on providing L2 connectivity between "interfaces". However, the Quantum API will be extensible, allowing plugins to introduce new logical network abstractions, for example, to provide more advanced security or QoS policies. Extensions provide an avenue for innovation by allowing new functionality to be exposed. The goal is that API extensions that prove valuable will be adopted by multiple plugins and can then be standardized.

Design Principal #2: Quantum as a "Building Block"

A key output of the summit was splitting up the large space of "Openstack network-related functionality" into more well-defined efforts where were either specifically targeted "building block" services or "orchestration" services for combining building blocks into higher-level abstractions. Building block services have a well-defined scope (e.g., network connectivity between devices, ip address management, load-balancing). This keeps the building block service simple and provides OpenStack operators with the ability to mix and match different technologies for different building blocks (it is always possible that a single vendor solution can implements multiple services).

A building block and can be consumed in several ways:

  • by tenants who want fine-grained control.
  • by OpenStack operators on behalf of tenants
  • by high-level "orchestration" services

Quantum is just one of the building blocks that was proposed for implementing network-related functionality in OpenStack. Quantum is focused on managing the connectivity between interfaces of other OpenStack services (to start, this is just L2 connectivity but the goal is to expand this over time). There is also Melange for network address management, Atlas for load-balancing, etc. During the summit we also proposed an orchestration service called Donabe, which is a "container service" to provide tenants with higher-level abstractions for combining multiple building blocks into rich application topologies (e.g., a secure three-tier web application).

Design Principal #3: Openstack Project Affinity

While it is possible to use Quantum independent of OpenStack, a primary goal is that it work well with OpenStack and is easily accessible to OpenStack community members. Therefore, the default principle when looking to implement an aspect of the system is to look at and follow (stealing code if possible) the behavior of other OpenStack projects. For example, for API extensibility we look to follow the proposal for OpenStack API Extensions. For API authentication we look to use Keystone. For unit testing, we leverage existing OpenStack frameworks.

This approach of following the lead of other Openstack products is not an ironclad rule, but it does serve as the starting point for our design discussions.