QuantumAPIUseCases

= 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. .Quantum returns network identifier and invokes plugin;
 * 1) Customer creates Layer-2 network;



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). Quantum returns network identifier, ‘xyz’; The Cloud Controller dispatches the call to the Compute Service which creates the VM; Quantum creates the logical port and returns the port number; 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.'' Quantum returns a list of currently configured attachments, together with their state (e.g.: in Progress, Attached/DOWN, Attached/UP, Failed).
 * 1) Customer Creates a Layer-2 network;
 * 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;
 * 1) Compute Service tells Quantum to create a logical port on the ‘xyz’ network;
 * 1) Compute Service instructs Quantum to plug the VM’s Virtual NIC into the previously created port;
 * 1) Customer can verify that the attachment has been plugged into the network by querying Quantum for attachments for the ‘xyz’ network.



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: The sequence diagram below explains how the compute service interacts with Quantum to do so.
 * Create logical port;
 * Plug Virtual NIC into logical port;



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: 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.
 * Unplug virtual NIC from network ‘net1’;
 * Plug virtual NIC into network ‘net2’;



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;