Latest revision as of 21:39, 16 February 2013

Use Cases For Quantum API

Quantum is a project to provide "network connectivity as a service" between devices managed by other Openstack services such as nova. For more information on Quantum and the other network-related projects please check the Quantum home page and the Network projects home page.

This page describes common use cases for the Quantum Service API

Create Network

Customer uses Quantum API for creating a Layer-2.

1. Customer creates Layer-2 network;

.Quantum returns network identifier and invokes plugin;

Create Network and Spawn VM

Customer uses Quantum for creating a network and then the Openstack compute service to create a virtual machine to be connected to this network.

The Openstack compute Service, while creating the VM interacts with Quantum for creating a logical port and plugging the virtual network interface into this port. IP Configuration is not provided by Quantum.

Moreover, compute service can either explicitly create a port or just instruct Quantum to plug the virtual NIC into the Network. In this case Quantum will either use an available logical port or create a new port (see second diagram for this use case).

1. Customer Creates a Layer-2 network;

Quantum returns network identifier, ‘xyz’;

1. Customer Creates a VM using Cloud Controller API (e.g.: POST /Servers) and specifies a network for the VM’s virtual NICs in the create server request;

The Cloud Controller dispatches the call to the Compute Service which creates the VM;

1. Compute Service tells Quantum to create a logical port on the ‘xyz’ network;

Quantum creates the logical port and returns the port number;

1. Compute Service instructs Quantum to plug the VM’s Virtual NIC into the previously created port;

The Virtual NIC's unique identifier is provided in the request body.
Quantum invokes the plugin to attach the Virtual NIC to the logical network. This operation might require the plugin to contact the hypervisor on which the VM has been created in order to setup networking according to the technology adopted by the plugin.

1. Customer can verify that the attachment has been plugged into the network by querying Quantum for attachments for the ‘xyz’ network.

Quantum returns a list of currently configured attachments, together with their state (e.g.: in Progress, Attached/DOWN, Attached/UP, Failed).

The following diagram shows instead the case in which the logical port is not created, and the virtual NIC for the newly created VM is plugged in the first available port of the Quantum Network.

Spawn VM with multiple virtual NICs

This use case is very similar to the previous one, with the only difference that the VM being spawned has two virtual NICs. The compute service repeats the following sequence of operations for each virtual NIC:

• Create logical port;
• Plug Virtual NIC into logical port;

The sequence diagram below explains how the compute service interacts with Quantum to do so.

Change Network for Virtual NIC

The customer wants to remove a virtual NIC from an IP subnet and attach it to another IP subnet defined for a different network. In the diagram reported below, the virtual NIC is moved from subnet ‘sub1’, defined for network ‘net1’, to subnet ‘sub2’, defined for network ‘net2’. This will involve the following Quantum operations:

• Unplug virtual NIC from network ‘net1’;
• Plug virtual NIC into network ‘net2’;

NOTE: The plugin might not allow users to unplug virtual NCI attachments belonging to VM which are already running. In this case an error code will be returned by the operation.

Delete Network

The customer wants to destroy a Quantum network and all the resources associated with it. This will require using Quantum for the following operations:

• For each attachment connected to the network, unplug it;
• Destroy the network object;