FEATURE

https://issues.apache.org/jira/browse/CLOUDSTACK-10189

GOALS

1. Nuage VSD managed Isolated Network

2. Nuage VSD managed VPC

3. Nuage VSD managed Domain (VSD Enterprise)

SPECIFICATIONS

Isolated networks

As a CloudStack operator
I want to provision a CloudStack Isolated Network based on a pre-existing Domain/Zone/Subnet in Nuage VSD (SDN policy manager)
In order to consume Nuage VSD side provisioning in CloudStack such that i can deploy VM’s in it, a.o.

This is achieved by specifying a new generic externalID attribute in the createNetwork request, allowing CloudStack operators to associate a network to an identifier to an entity known to  external system. In the mentioned Nuage use case, the field can be set to a Subnet ID in the Nuage VSD, in order to associate the CloudStack created Network to this Nuage pre-created Subnet.

VPC’s

As a CloudStack operator
I want to provision a CloudStack VPC Tier Network based on a pre-existing Domain/Zone/Subnet in Nuage VSD (SDN policy manager)
In order to consume Nuage VSD side provisioning in CloudStack such that i can deploy VM’s in it, a.o.  Note that the VPC itself it not VSD-managed as such; only the tiers are.

Similar to as for Isolated networks, the way this is achieved is by specifying a new externalID in the createNetwork request, which refers to the Subnet ID in VSD.

Domains

As a CloudStack operator
I want to provision a CloudStack Domain based on a pre-existing Enterprise in Nuage VSD (SDN policy manager)
In order to relate a CloudStack Domain to a pre-provisioned Enterprise in Nuage VSD

The way this is achieved is by specifying a UUID in the createDomain request, which refers to the Enterprise ID in VSD. The reason we use UUID here is because this is something existing already which we can perfectly reuse.

API CHANGES

Isolated networks

• added externalId attribute to createNetwork

• Added externalId field to listNetworks response

VPC

• see above mentioned change (no delta)

Domain

• no API changes  (existing field UUID is reused)

UI CHANGES

externalID added as optional field in the Create Network panel.

DomainId added as optional field in the create domain panel.

Database changes

We added a new column to the networks table. This column is named external_id and stores the externalId that is provided during the createNetwork cmd.

IMPLEMENTATION ASPECTS

The feature makes use of the VSD ID caching framework i.e. the implementation relies on the fact that VSD object identifiers are already kept in memory cache in the CS plugin, and for VSD managed networking the design clue is that we pre-populate those ID’s based on config, rather than post-create when creating resources in VSD. We store the VSD subnet id in the externalId field which was added in the createNetworkCmd. In case of VSD managed domains we specify the UUID of the external object that maps on a domain in CloudStack as the uuid of the domain (we re-use already existing options in CS).

Core changes

We extended the NetworkGuruAdditionalFunctions interface. We added the extra parameter named externalId to the void finalizeNetworkDesign(long networkId, String vlanIdAsUUID, String externalId) function. This is necessary because during network creation we store vsd information linked to the network in the network_details table based on the externalId. The interface NetworkGuruAdditionalFunctions was already present and was previously used by nicira, now the Nuage plugin also implements this interface.

Caching

Client

In the client, the VSD Id’s are contained in the NetworkRelatedVsdIds class.
API:

• public Optional<String> getVsdEnterpriseId()

• public Optional<String> getVsdDomainId()

• public Optional<String> getVsdZoneId()

• public Optional<String> getVsdSubnetId()

The NetworkRelatedVsdIds object is an attribute of VspNetwork, and will be read during NuageVspGuruClient.implement. Also NuageVspGuruClient.implement will return a NetworkRelatedVsdIds object with vsd id’s after implementation.

Plugin

NuageVspEntityBuilder has been adapted to search the vsd Id’s in the metadata of the Network, and of the vpc, if the network is a vpc tier.
As part of NuageVspGuestNetworkGuru.implement(), the client is called,
And the VSD id’s returned by the client are stored in metadata again.

VSD Managed Subnet

Client

Besides implement, NuageVspGuruClient now also has a addPermissionL3Network method.
This method will be used in case the network is VSD Managed. This method checks if the network exists on the VSD, fetches it’s information and set correct permissions on the network.

TrashNetworkVspCommand: will return immediately when the trashed network is a vsdManaged network

API

CreateNetworkCmd now has a new attribute externalId, which  - if present - will be stored in the NetworkVO object. After the network has been designed by the guru, if the guru implements NetworkGuruAdditionalFunctions, NetworkOrchestrator will call guru.finalizeNetworkDesign, passing the network id, and the specified externalId.

Plugin

NuageVspGuestNetworkGuru now implements NetworkGuruAdditionalFunctions.
As part of finalizeNetworkDesign we will store the given externalId, as vsdSubnetId in metadata. An additional metadata tag is set on the network to flag is as Vsd Managed:
NetworkDetails: isVsdManaged = true

VSD Managed VPC

In current state, the changes done for Isolated Network, are good enough to be able to consume a VPC, by defined external Id as part of each tier creation.

The NetworkRelatedVsdIds returned by addPermissionL3Network will be stored as metadata, And the additional tiers, can make use of the cached id’s of the domain and zone.

Similar to TrashNetworkVspCommand, when executing ShutdownVpcCommand, the client won’t remove anything, when it’s vsd managed.

VSD managed domain

Nuage already created domains based on their uuid. In this case a user can just provide the uuid of a VSD enterprise (aka domain in CS). If the VSD enterprise already exist, the VSD will re-use it.

Important restriction: removed domains vsdDomains can not be added again in CloudStack. Because the uuid has to be unique and removed CloudStack objects are still present in the database.