Jump to: navigation, search

Difference between revisions of "QuantumOverview"

 
m (Text replace - "__NOTOC__" to "")
 
(5 intermediate revisions by one other user not shown)
Line 1: Line 1:
__NOTOC__
 
What is Quantum?
 
  
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). 
+
== Quantum Design Principles ==
  
Design Principal #1: Abstract API and Pluggable Back-end
+
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.   
 
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.   
Line 10: Line 12:
 
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.     
 
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"  
+
'''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 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:  
 
A building block and can be consumed in several ways:  
- by tenants who want fine-grained control.  
+
* by tenants who want fine-grained control.  
- by [[OpenStack]] operators on behalf of tenants
+
* by [[OpenStack]] operators on behalf of tenants
- by high-level "orchestration" services
+
* 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).
 
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
+
'''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.   
 
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.
 
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.

Latest revision as of 23:30, 17 February 2013

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.