High-level view of the steps required for implementing a basic connectivity (L2 networking) manager for CloudStack
The aim of this document is to provide an overview of the work required to extend CloudStack’s networking infrastructure in order to allow folks to plug new networking solutions into CloudStack. This document is only concerned with providing basic connectivity, i.e. layer-2 networking.
...
CloudStack has a modular set of interfaces and a dynamic configuration management system, which allows folks to replace the traditional way in which CloudStack manages guest networks. It is intended to further evolve these interfaces to make this integration easier.
...
This section introduces the components of CloudStack’s virtual networking infrastructure, which might be implemented in order to allow folks to plug new solutions into CloudStack.
...
Network Gurus are responsible for:
...
From com.cloud.network.guru.NetworkGuru JavaDoc:A Network goes through the following life cycles through the NetworkGuru.
...
Network Elements represent components that are present in a CloudStack network. Such components can provide any kind of network service or support the virtual networking infrastructure and their interface is defined by com.cloud.network.element. NetworkElement.
...
Returns the service provider associated with the current instance of the Network Element. For instancecom.cloud.network.element.ExternalDhcpElement is associated with the ‘ExternalDHCPServer’ provider.
...
Not to be confused with CloudStack networking manager, which implements the interface com.cloud.network.NetworkManager, they are in charge of handling the resources managed by the network elements. They typically extend the genericcom.cloud.utils.component.Manager interface, and are therefore loaded at startup through CloudStack’s configuration manager.
For instance, the manager for setting up L2-in-L3 networks with Open vSwitch is com.cloud.network.ovs.OvsTunnelManagerImpl, whereas Virtual Router lifecycle is managed by com.cloud.network.router.VirtualApplianceManagerImpl.
...
The resource class abstract the physical (or virtual) resource being managed. CloudStack defines several resource classes, including hypervisors as well as Load Balancers and Storage devices. Resources are manager classes as well, as they implement thecom.cloud.resource. ServerResource interface which extends the Manager.
The most important method of a Resource class is probably executeRequest which is invoked by the agent manager1. This method is typically implemented with a cascaded if statement which invokes a different method according to the command dispatched by the agent manager.
...
This section discusses some operational flows regarding CloudStack networking. This is only as far as basic connectivity is concerned; details about virtual router, security groups, and external network services, such as NetScaler or SRX, are outside the scope of this document.
...
The following is, in brief, the flow within CloudStack when a new guest network is created. Relevant points for integration with additional network managers are highlighted in red.
...
The following is, in brief, the sequence of operations CloudStack performs for setting up networking when a new instance is started. Relevant points for integration with additional network managers are highlighted in red.
...
This section contains some notes concerning the implementation of the previously discussed interfaces in order to allow additional virtual networking solutions to plug into CloudStack.
...
It is worth starting from the class com.cloud.network.guru.GuestNetworkGuru, which should be regarded as the base class for all gurus dealing with guest networks.
...
...
Each appliance, physical or virtual, participating in some form in the network should get its own element. For instance, when OVS is used for building L2-in-L3 network, it is regarded as a network element. In a scenario where an external software component is used for building and managing virtual network, it makes sense for this component to be modelled as a network element in CloudStack.
...
...
Network managers can be implemented in order to provide an interface which reflects the peculiarities of the new solution being plugged into CloudStack, while the interface implemented by the network element reflects CloudStack’s process for setting up networks. For instance, the OVS network element implements the prepare method for setting up the network for a given NIC; this method invokes the CheckAndCreateTunnel method on the OVS Tunnel Manager, which in turns dispatches commands to the resource where OVS is running (XenServer or KVM hypervisor).
Network managers are not constrained to a particular interface, apart from the generic Manager interface. Several manager components in CloudStack networking subsystem define completely different interfaces. Please note that these components are not strictly necessary, as in theory the network element could communicate directly with the managed resource.
...
A new network manager could define as many resources as required. CloudStack already provides several resource components which can be used as guidance for implementing them.
...
Just like managers, resources are not strictly necessary. In theory a Network Element could implement a client for the API of the new controller and therefore be completely self-contained. 2
...
...
When new components are added (managers, elements, resources, gurus) they must be loaded into CloudStack. The easiest way for doing so is to declare them in CloudStack component configuration files and let the ‘Component Locator’ instantiate them.
...