Cisco Intercloud Fabric User guide

Brand: Cisco

Model: Intercloud Fabric

Category: Development software

Type: User guide

This manual is also suitable for

Page 1

Cisco Intercloud Fabric Provider Platform Adapter

Developer Guide, Release 2.3.1

2015-11-13

Contents

INTRODUCING THE CISCO INTERCLOUD FABRIC PROVIDER PLATFORM ADAPTER DEVELOPER GUIDE ............... 3

GETTING STARTED ..................................................................................................................................................... 3

Tools and Environment .................................................................................................................................... 3

Service Provider Infrastructure Requirements ................................................................................................. 3

Deployment Network Topology ....................................................................................................................... 3

Provider Platform Capability ............................................................................................................................ 4

Provider Network Models ................................................................................................................................ 5

Cloud VM Deployment ..................................................................................................................................... 6

Public Network Address Assignment ................................................................................................................ 7

Multi-Site Support ............................................................................................................................................ 8

DEVELOPMENT ENVIRONMENT .................................................................................................................................... 9

Development Methodology ............................................................................................................................. 9

Development Steps .......................................................................................................................................... 9

CISCO ICFPP PROGRAMMING MODEL ........................................................................................................................ 10

ADAPTER JAVA DOCUMENTATION ............................................................................................................................... 11

SAMPLE ADAPTER CODE ........................................................................................................................................... 11

API PROGRAMMING ........................................................................................................................................ 11

OVERVIEW ............................................................................................................................................................. 11

SERVICE LOADER CONFIGURATION .............................................................................................................................. 12

RESOURCE FILES ...................................................................................................................................................... 12

BUILD INFRASTRUCTURE ........................................................................................................................................... 12

PACKAGING THE ADAPTER ......................................................................................................................................... 12

APIS.................................................................................................................................................................. 12

CAPIPLUGINSERVICESIF ............................................................................................................................................ 12

listLocations ................................................................................................................................................... 12

listCapabilities ................................................................................................................................................ 13

getName ........................................................................................................................................................ 14

getDescription ................................................................................................................................................ 14

getVersion ...................................................................................................................................................... 14

getNetworkService ......................................................................................................................................... 14

getSecurityService .......................................................................................................................................... 15

getSessionService ........................................................................................................................................... 15

Page 2

getStorageService .......................................................................................................................................... 15

getTemplateService........................................................................................................................................ 15

getVmService ................................................................................................................................................. 15

getVpcService ................................................................................................................................................. 16

CAPIPLUGINNETWORKIF ........................................................................................................................................... 16

listPublicIpAddress ......................................................................................................................................... 16

CAPIPLUGINSESSIONIF ............................................................................................................................................. 17

createClientSession ........................................................................................................................................ 17

deleteClientSession ........................................................................................................................................ 17

validateClientSession ..................................................................................................................................... 18

CAPIPLUGINSTORAGEIF ............................................................................................................................................ 18

CAPIPLUGINSECURITYIF ............................................................................................................................................ 18

createSecurityGroup ...................................................................................................................................... 18

deleteSecurityGroup....................................................................................................................................... 19

updateSecurityGroup ..................................................................................................................................... 20

addSecurityRule ............................................................................................................................................. 20

updateSecurityRule ........................................................................................................................................ 21

deleteSecurityRule.......................................................................................................................................... 21

CAPIPLUGINTEMPLATESIF ......................................................................................................................................... 22

createTemplate .............................................................................................................................................. 22

deleteTemplate .............................................................................................................................................. 24

discoverTemplate ........................................................................................................................................... 25

CAPIPLUGINVMIF .................................................................................................................................................... 26

deployVirtualMachine .................................................................................................................................... 26

destroyVirtualMachine .................................................................................................................................. 29

rebootVirtualMachine/ startVirtualMachine/ stopVirtualMachine ............................................................... 30

downloadVMInstance .................................................................................................................................... 32

listVirtualMachines ........................................................................................................................................ 33

getVirtualMachines ........................................................................................................................................ 33

updateVirtualMachine ................................................................................................................................... 33

updateVirtualMachines ................................................................................................................................. 35

CAPIPLUGINVPCIF ................................................................................................................................................... 35

listProviderVPC ............................................................................................................................................... 36

listVpcById ...................................................................................................................................................... 36

createVpc ....................................................................................................................................................... 37

deleteVpc ....................................................................................................................................................... 37

listVpcNetworkById ........................................................................................................................................ 38

createVpcNetwork ......................................................................................................................................... 39

deleteVpcNetwork.......................................................................................................................................... 40

ABBREVIATIONS AND ACRONYMS ................................................................................................................... 41

REFERENCES ..................................................................................................................................................... 41

OBTAINING DOCUMENTATION, OBTAINING SUPPORT, AND SECURITY GUIDELINES ........................................ 41

Page 3

Introducing the Cisco Intercloud Fabric Provider Platform Adapter

Developer Guide

Cisco Intercloud Fabric Provider Platform (ICFPP) is a virtual appliance deployed in the Service Provider (SP)

cloud data center that enables SP customers to access cloud resources. SPs can extend Cisco ICFPP to add

support for their cloud platform.

This document describes how to develop adapters for Cisco ICFPP. Cisco provides an adapter framework that

allows SPs to write adapters to expose their cloud platform to customers.

Note

The VMware vCloud Director cloud platform is one of the Cisco ICFPP supported platforms. Cisco ICFPP includes

a built-in adapter for this platform.

Getting Started

This document assumes that you are familiar with the Cisco ICFPP architecture. For information about the Cisco

ICFPP architecture, see the white papers at http://www.cisco.com/c/en/us/products/cloud-systems-

management/intercloud-fabric/white-paper-listing.html.

The Cisco ICFPP Software Development Kit (SDK) includes sample plug-in for the VMware vCloud Director cloud

platform. This documentation refers frequently to this sample plug-in.

Tools and Environment

The following tools are required for adapter development:

● Java Version 1.6─See http://www.oracle.com/technetwork/java/javase/downloads/java-archive-downloads-

javase6-419409.html.

Note

Only version 1.6 is supported.

● Ant Version 1.8.2─See http://archive.apache.org/dist/ant/binaries/.

● Eclipse─See http://www.eclipse.org.

Service Provider Infrastructure Requirements

Cisco ICFPP provides a simple programmable cloud adapter interface for ease of integration with service provider

cloud platforms. Most of the southbound adapter interfaces are straightforward and adapter developers can

develop the interfaces quickly. However, adapter developers must pay attention to the following areas in the

provider infrastructure:

● Deployment Network Topology

● Provider Platform Capability

● Provider Network Models

● Cloud VM Deployment Functions

● Public Network Address Assignment

Deployment Network Topology

Although the Cisco ICFPP deployment network topology is straightforward, its implementation can vary for different

SPs and different cloud platforms. Use the following conventions and guidelines when setting up Cisco ICFPP

deployment networks:

● Cisco ICFPP must be accessible from the Internet, SP-managed inter-data center networks, or both.

● Service providers usually can expose Cisco ICFPP through a NAT rule configured at an SP edge router or a

web-proxy.

● Cisco ICFPP and cloud platforms should be able to communicate to each other so they can initiate

management connections with each other.

● If uploading or downloading images is required, and Cisco ICFPP and the cloud platform use shared storage,

Cisco ICFPP must be able to access to the shared storage network.

Page 4

Figure 1 depicts an example of a Cisco ICFPP deployment network topology.

Figure 1 – Cisco ICFPP Deployment Network Topology Example

Provider Platform Capability

The provider platform must describe the capabilities supported by the platform.

The information in the following table is required:

Parameter Description Example Values

cloudStyle Tenant network. Shared network, isolated

networks

imageFormat

Image format.

VMDK, RAW

virtualizationType

Virtualization type.

KVM, XEN

hypervisorType

Hypervisor type.

ESXi, Xen, KVM

imageContainerType

Image package type.

OVA, None

platformType

Array of platform type of service appliances.

VSG, CSR

cloudAgent Array of VM agent types. Azure-WAA, AWS-getkeys,

Vmware-VMTools

templateContainment Template containment can be based on

Location-locationType or ProviderVpc. Location examples are:

Location-Region

Location-Zone

partitionType

Disk partition types.

Flat-Disk, Multi-Disk

securityGroupContainment Security group containment can be based

on Location, VM, ProviderVPCNetwork, and

ProviderVPC.

locationHierarchy The location hierarchy based on location

objects.

Region, Availability Zone

providerVpcManagement Provider supports create, update, and

delete of ProviderVpc. CREATE, UPDATE, DELETE,

READ, autoAssignSubnet in

which the provider automatically

assigns the subnet address

Page 5

Parameter Description Example Values

providerNetworkManagement Indicates whether or not the provider

supports create and delete of

ProviderVpcNetwork or discovery (read) of

ProviderVpcNetwork.

CREATE, DELETE, READ

supportedOsTypes Comma-separated list of supported

operating systems for cloud VMs in the

format category_version_architecture. The

version can be major or major.minor.

The architecture is optional.

RHEL_6, CentOS_6_3,

Windows_2008.R2_64

serverMemoryRange In MB, the memory range supported by the

VM.

Default range: 512-65536

fractionalMemorySupport Whether the memory specified for the VM

should not be at the gigabyte boundary.

Default: True

serverCpuRange Range of virtual CPUs supported by the

VM.

Default range: 1-64

initICSOnFirstBoot Whether to initialize the Intercloud Switch

(ICS) on the first boot.

Default: True

Based on the values returned, Cisco Intercloud Fabric Director (ICFD) determines:

● How to transform a workload image to an appropriate format.

● How to allocate the required network resources (such as public IP addresses, network segments, subnets, and

so on) to build the secure network extender.

● The platform type to use for deploying infrastructure VMs (such as CSR or VSG).

● How to create template containments based on the provider's cloud site hierarchy (such as a region or

availability zone).

● How to create a security group within a cloud site containment.

For more information about provider capability details, see the CapiPluginServicesIf interface API listCapabilities.

Provider Network Models

Cisco Intercloud Fabric (ICF) extends enterprise network segments to a public cloud data center by means of a

secure network extension that facilitates enterprise workload migration. The secure network extension is achieved

through a Layer 2 overlay network that is built on top of a provider's network. The overlay network functions are

transparent to the underlying provider network architecture. However, the provider network architecture impacts

how Cisco ICFD deploys infrastructure VMs and operationally builds the secure extender.

Cloud service providers commonly offer the following network architectures:

● Shared Network─All tenants share the same network infrastructure; isolation is achieved by using security-

groups.

● Isolated Network─A tenant dynamically creates one or more tenant-specific, isolated networks, which protect

and isolate the tenant from other networks.

Based on the values of cloudStyle and providerVpcManagement returned from the provider platform, Cisco ICFD

performs the operations required to build the overlay networks and deploy the infrastructure VMs, such as Cisco

Cloud Services Router 1000V (CSR) and Cisco VSG (VSG).

Figure 2 depicts how Cisco ICF Secure Extender can be built on a shared network architecture. Because all

overlay network functions are provided by the infrastructure VMs (such as the ICS, CSR, and VSG), the only

infrastructure requirements needed from the provider are:

● Cloud VM deployment

● Provider private IP address assignments

● Provider public IP address assignment to ICS

For more information about VM deployment, see the CapiPluginVmIf interface API.

Page 6

Figure 2 – Secure Extender Built on a Shared Provider Network

Figure 3 depicts how ICF Secure Extender can be built on an isolated network architecture. In addition to the

infrastructure requirements mentioned previously, Cisco ICFD must be able to access provider network

management APIs for dynamically allocated networks. In many cases, provider isolated-network functions are built

on top of a VPC-based tenant provisioning architecture, which isolates the network, compute, and storage

resources from other tenants.

See the CapiPluginVmIf and CapiPluginVpcIf interface APIs for more detail.

Figure 3 – Secure Extender Built on an Isolated Per-Tenant Network

Cloud VM Deployment

In the current Cisco Intercloud Fabric implementation, four types of cloud VMs must be deployed in public cloud

provider data centers:

● Application VM – VM running business customers’ applications

● Infra-ICS – VM providing Intercloud Fabric Switch overlay functions

Page 7

● Infra-CSR – VM providing routing, NAT, and VPN functions

● Infra-VSG – VM offering firewall and isolation functions

The following table identifies the infrastructure VM deployment requirements:

Provider VM

Deployment

Requirements

Cloud VM Types

Infra-CSR Application VM, and Infra-ICS and

Infra-VSG

O/S Platform Supported 64-bit Monta Vista Linux with

2.6.32 Kernel

N/A

OVF Customization

Required

N/A

VM Tool Installation

VMware VM-Tool Required

Open VM-Tool Required

Provider IP Address

Assignments

Static DHCP or Static

The OVF customization required for an infrastructure VM, such as Infra-CSR, allows a cloud orchestrator (Cisco

ICFPP) to programmatically pass a set of OVF configuration parameters to the Infra-CSR VM during VM

instantiation. Depending on the approach that the SP cloud platform takes in supporting OVF parameter-passing

features, the OVF customization process can vary.

Using the CloudStack platform as an example, passing OVF parameters involves the following tasks:

1. Obtaining all necessary OVF parameters from the enterprise IT admin. These parameters include the IP

address, netmask address, gateway IP address, DNS server address, domain name, and hostname. Cisco

ICFPP uses this information to create an OVF configuration XML file named ovf-env.xml.

2. Converting the ovf-env.xml file to an ISO image and using the registerIso ( ) API to register the image so

it can be attached to a given user.

3. Deploying a VM in a Stopped state (that is, with the startvm parameter set to False) with the

deployVirtualMachine ( ) API.

4. Attaching the OVF configuration XML file ovf-env.xml to the previously deployed VM with the attachIso ( )

API.

5. Starting the VM with the startVirtualMachine ( ) API. The VM will pick up the parameters passed through the

configuration file.

For more information about any of the CloudStack API operations, see http://cloudstack.apache.org/api.html.

For more information about VM deployment, see the CapiPluginVmIf interface APIs.

Public Network Address Assignment

Depending on the situation, cloud VMs might need to communicate with systems on external networks, such as the

Internet. Examples of such situations include:

● An application VM hosts a web server.

● An application VM must communicate with external web servers.

● An application VM provides VPN services for branch offices.

● An infrastructure VM, such as Infra-ICS, must provide a secure network extension for the enterprise.

In the Cisco ICF Secure Extender architecture, most external connectivity is handled by the CSR. The exception is

the Infra-ICS VM, which is responsible for establishing the Cisco ICF Secure Extension by connecting with the

Intercloud Extender (ICX) running in the enterprise. The following table summarizes the public IP address

assignment requirements and how NAT rules can be configured to address various situations.

Page 8

ICF Use

Cases Infrastructure Configuration Required

Application VM Infra-CSR Infra-ICS Provider Router

Hosting a

Web Server Set the default

gateway to CSR NAT rules for

translating the

enterprise private IP

address to the

provider private IP

address

N/A NAT rules for translating the

provider private address to

the provider public IP

address

Connecting

to Internet

Servers

Offering

VPN

Services

Offering

Secure

Extension

N/A N/A Set the default

gateway to the

provider router

For more information about VM public network address assignment, see the CapiPluginVmIf interface APIs.

Multi-Site Support

Provider cloud platforms commonly support multiple regions and availability zones for scaling and high availability

purposes:

● A region has a separate API endpoint for each cloud platform deployment, allowing for a more discrete

separation of locations and, thus, services. Users who want to run instances across sites must explicitly select

a region.

● An availability zone is a logical separation within a cloud platform deployment that provides physical isolation

or redundancy. When users provision resources, they specify the availability zone to use for an instance. This

allows cloud consumers to ensure that their application resources are spread across multiple machines and

benefit from high availability configurations in the event of hardware failure.

Cisco ICF architecture adheres to the following guidelines with regard to multi-site support:

● Cisco ICF assumes that the service provider will deploy one Cisco ICFPP instance per region and provides a

separate URL or IP address for each Cisco ICFPP instance.

● After the Cisco ICFPP cloud adapter has signed on with the cloud platform, Cisco ICFPP uses the southbound

adapter listLocations API to determine the number of availability zones that are supported by the platform and

provides a list of the availability zones and regions to Cisco ICFD.

● Upon receiving the availability zone information, Cisco ICFD displays the information in the Cisco ICFD admin

and end-user portals, where users can specify the availability zone to use for an instance.

Page 9

Figure 4 depicts an overview of multi-site support in Cisco ICF. For more information about multi-site support, see

the CapiPluginServicesIf interface API (for example, listLocations).

Figure 4 – Cisco Intercloud Fabric Multi-Site Support Overview

Development Environment

Development Methodology

We recommend that you use the following method when developing an adapter for use with Cisco ICFPP:

1. Create a custom module project.

2. Implement the cloud adapter plug-in interfaces.

3. Unit test with a Java test framework to verify that the adapter makes the correct API calls to the backend cloud

platform.

4. After verifying that the API calls are successful, test with Cisco ICFPP.

5. To validate each cloud adapter interface in Cisco ICFPP, use the Python-based test harness that is provided

with the SDK.

6. After validating the cloud adapter interfaces, perform integration testing with Cisco ICFD and the provider

cloud platform.

Development Steps

The following conventions and guidelines are required when developing the plug-in so that it will be compatible with

Cisco ICFPP. If adapter development does not adhere to the naming conventions and identified procedures, the

plug-in might fail to function.

1. Choose a unique name for the Custom Module Type. The Custom Module Type name that you choose must

be the same string that is passed when the Service Provider provisions a cloud instance on Cisco ICFPP. For

this discussion, we will assume that the Custom Module Type name is “custom1”.

2. Implement the adapter interfaces. The interfaces that must be implemented are available in the Java

documentation under com.cloupia.feature.capiController.api package.

Page 10

3. Unit test each interface that is implemented by using any Java unit test harness. Cisco ICFPP is not required

to validate the API. Developers can write unit test programs that exercise the feature being implemented to

confirm that it works as expected.

4. After the adapter interfaces are implemented and unit-tested, test with Cisco ICFPP by using the Cisco ICFPP

test harness.

Cisco ICFPP Programming Model

After a custom cloud adapter is developed, use the following workflow to load the adapter plug-in code on to the

Cisco ICFPP platform and enable the cloud adapter functions for the targeted tenants:

1. SP developers download the cloud adapter plug-in SDK from Cisco Connection Online (CCO) site for

developing a custom cloud adapter.

2. When the customer cloud adapter plug-in code is ready to use, the developer can load the package file (for

example, custom.tar.gz that contains jars/custom1.jar) to the file system on the targeted Cisco ICFPP by using

standard Linux tools or the GUI.

3. The Cloud Instance Provision Intercloud Provider API is used to add an instance to the Cisco ICFPP platform.

In the Cloud Instance Provision API request, an SP admin can use the cloud module field to specify the name

of the JAR file (for example, custom1). This will bind the plug-in code with the cloud instance to be added.

4. When an SP admin provisions tenants on the Cisco ICFPP platform using the Tenant Provision Intercloud

Provider API, the SP admin can bind the tenants with the newly added cloud instance.

5. When a tenant issues Intercloud cloud API requests with a Cisco ICFD instance, the API requests are handled

by the newly added cloud adapter plug-in code.

Figure 5 depicts the logical flow for loading custom cloud adapter plug-in code on to a Cisco ICFPP platform and

processing incoming Intercloud cloud API requests issued by a tenant.

Page 11

Figure 5 – Cisco ICFPP Programming Model Overview

Adapter Java Documentation

To support other new cloud platforms, the Cisco ICFPP Adapter defines a set of Java-based interfaces. Java

documentation is available from your Cisco ICFPP virtual appliance by using the URL http://icfpp-ip-

address/capi/docs/index.html.

Sample Adapter Code

Cisco ICFPP supports vcdp, which is a southbound cloud adapter. The vcdp adapter was written to interact with

the back end of the VMware vCloud Director cloud infrastructure. It is a fully working adapter and provides an

implementation example for developers. This example adapter is provided only as a reference implementation, and

will not work with other cloud platforms.

API Programming

This section describes how to code an adapter. Details about the methods specified in this section can be found in

the Java documentation that is provided with the Cisco ICFPP software. All of the following APIs have an object

CapiTenantAccountVO, which is used to derive any and all information for the user performing the cloud

operations. This can be an API key or password details.

Overview

Each adapter is expected to implement the interfaces mentioned in the following sections.

Do not directly access the database from the adapter code. Doing so could break the adapter when the

infrastructure is updated.

Note

Do not populate class variables that are marked Read-Only in the Java documentation. Those items are

candidates for removal in future drops. For the exact details of the following classes, refer to the Java

documentation.

Page 12

Service Loader Configuration

You must define a provider configuration file in the META-INF/services directory. The filename is the fully qualified

com.cloupia.feature.capiController.api.CapiPluginServicesIf. The content of this file is the package name in which

the CapiPluginServicesIf is implemented.

META-INF

|____services

| |____com.cloupia.feature.capiController.api.CapiPluginServicesIf

Resource Files

To control the timeouts of various tasks spawned in the system, create an <adapter_type>.properties file. When

packaged in the final JAR, this file must reside in the top-level resources directory. The following example shows a

directory structure for an adapter JAR:

|____com

|____META-INF

| |____MANIFEST.MF

| |____services

| | |____com.cloupia.feature.capiController.api.CapiPluginServicesIf

|____resources

|____CSP.properties

Build Infrastructure

Adapter developers are welcome to use any build infrastructure, such as Ant, Maven, or Gradle. The example

provided in this release is an Ant-based adapter. Only one dependency JAR is provided by Cisco; it must be

appropriately incorporated as a dependency library.

Packaging the Adapter

After building an adapter, you must package the adapter in a specific directory structure so that it can be installed

by the Cisco ICFPP infrastructure, as follows:

1. Create a jars directory.

2. Copy the adapter and other required JAR files into the jars directory by using the following command:

tar –czvf adapter.tar.gz jars

APIs

CapiPluginServicesIf

This umbrella defines service-related interfaces. Methods are identified in the following subsections.

listLocations

This method returns the list of locations supported for this account. Depending on the cloud, the locations can be

either flat or in a hierarchy. For example, a cloud provider might have a region that contains multiple zones.

Alternatively, it might have a flat Region/Data Center with no hierarchy. Cisco ICFPP uses this API to determine

the number of locations supported by the platform and reports the realized location information to Cisco ICFD.

Upon receiving this information, Cisco ICFD displays it to the end-user portals, where users can select the desired

location for deploying services.

API

public CapiLocationDetailsList listLocations(

CapiTenantAccountVO tenantAccountInfo)

throws CapiPluginServicesException;

Page 13

Adapter Development

Adapters must:

1. Fetch locations from the respective cloud providers and/or manually populate the CapiLocationDetailsList

object and return it.

2. In the event of a failure, return a CapiPluginServicesException exception with a message that clearly states

the reason for the failure.

Code Stub

VcdpPluginServices.java

public CapiLocationDetailsList listLocations(

CapiTenantAccountVO tenantAccountInfo)

throws CapiPluginServicesException {

CapiLocationDetailsList locationList = null;

try {

locationList = new CapiLocationDetailsList();

CapiLocationDetails locationElement = new CapiLocationDetails();

// Cloud Specific Code Start

// Cloud Specific Code End

List<CapiLocationDetails> locationElementArray = new

ArrayList<CapiLocationDetails>();

locationElementArray.add(locationElement);

locationList.setLocations(locationElementArray);

} catch (Exception e) {

logger.error(e.getMessage(), e);

throw new CapiPluginServicesException(

CapiPluginErrorCodes.SERVICE_ERROR,

"Location could not be fetched", e);

}

return locationList;

}

listCapabilities

This method returns the capabilities supported for this account. Based on the platform capability values returned,

Cisco ICFD can determine:

● How to transform a workload image to an appropriate format.

● How to build the secure network extender.

● How to pass VM parameters to the infrastructure and/or workload VMs.

API

public CapiCapabilities listCapabilities(

CapiTenantAccountVO tenantAccountInfo)

throws CapiPluginServicesException;

Adapter Development

1. Populate and return the CapiCapabilities object with values that reflect the cloud provider and its supported

features. It is important to accurately obtain all elements of this object because it determines Cisco ICFD’s

interaction with the cloud.

2. In the event of a failure, return a CapiPluginServicesException exception with a message that clearly states

the reason for the failure.

Page 14

Code Stub

VcdpPluginServices.java

public CapiCapabilities listCapabilities(

CapiTenantAccountVO tenantAccountInfo)

throws CapiPluginServicesException {

try {

CapiCapabilities providerCapability = new CapiCapabilities();

// Cloud Specific Code Start

// Cloud Specific Code End

return providerCapability;

} catch (Exception e) {

logger.error(e.getMessage(), e);

throw new CapiPluginServicesException(

CapiPluginErrorCodes.SERVICE_ERROR,

"Capablities could not be fetched", e);

}

getName

This API returns the name of the adapter. This name is used for all subsequent adapter operations, including

upgrading the existing adapter.

API

public String getName();

Adapter Development

Return a string name of the adapter. The name cannot include any special characters or spaces.

getDescription

Provide a brief description of the adapter (display only).

API

public String getDescription();

Adapter Development

Return a string with the description.

getVersion

Return the adapter version.

API

public String getVersion();

Adapter Development

Return a string with the version number.

getNetworkService

Return the adapter class object associated with the CapiPluginNetworkIf service. The service loader uses this

object.

API

public CapiPluginNetworkIf getNetworkService();

Page 15

Adapter Development

Return the class.

getSecurityService

Return the adapter class object associated with the CapiPluginSecurityIf service. The service loader uses this

object.

API

public CapiPluginSecurityIf getSecurityService();

Adapter Development

Return the class.

getSessionService

Return the adapter class object associated with the CapiPluginSessionIf service. The service loader uses this

object.

API

public CapiPluginSessionIf getSessionService();

Adapter Development

Return the class.

getStorageService

Return the adapter class object associated with the CapiPluginStorageIf service. The service loader uses this

object.

API

public CapiPluginStorageIf getStorageService();

Adapter Development

Return the class.

getTemplateService

Return the adapter class object associated with the CapiPluginTemplateIf service. The service loader uses this

object.

API

public CapiPluginTemplatesIf getTemplateService();

Adapter Development

Return the class.

getVmService

Return the adapter class object associated with the CapiPluginVmIf service. The service loader uses this object.

API

public CapiPluginVmIf getVmService();

Adapter Development

Return the class.

Page 16

getVpcService

Return the adapter class object associated with the CapiPluginVpcIf service. The service loader uses this object.

API

public CapiPluginVpcIf getVpcService();

Adapter Development

Return the class.

CapiPluginNetworkIf

This umbrella defines methods that are relevant for network-related operations. This umbrella currently supports

listing public IP addresses only.

listPublicIpAddress

This method lists the public IP addresses assigned for the tenant user. In some Cisco ICF environments, cloud

VMs might need to communicate with systems on external networks such as the Internet. Examples of these

situations are the following:

● An application VM hosts a web server.

● An application VM must communicate with external web servers.

● An application VM provides VPN services for branch offices.

● An infrastructure VM, such as Infra-ICS, must provide a secure network extension for the enterprise.

There are several variations for different cloud providers. For example, some cloud providers initially allocate public

IP addresses while others return a few IP addresses initially and subsequent queries must be made by the account

admin.

API

CapiPublicIpPools listPublicIpAddress(

CapiTenantAccountVO tenantAccountInfo)

throws CapiPluginNetworkException;

Adapter Development

1. Fetch the required public IP details from the cloud backend and populate and return the CapiPublicIpPools

object.

2. Clearly define any exception with a message that can be used by the account admin.

Note

If the cloud platform does not have the concept of a public IP pool, it can return empty object. The adapter is

responsible for programming or assigning a public IP address during virtual machine deployment.

Code Stub

public class VcdpPluginNetwork implements CapiPluginNetworkIf {

private Logger logger = Logger.getLogger(VcdpPluginNetwork.class);

* (non-Javadoc)

* @seecom.cloupia.feature.capiController.api.CapiPluginNetworkIf#

* listPublicIpAddress()

public CapiPublicIpPools listPublicIpAddress(

CapiTenantAccountVO tenantAccountInfo)

throws CapiPluginNetworkException {

CapiPublicIpPools publicIpPools = null;

try {

// Cloud Specific Code Start

// Cloud Specific Code End

Page 17

} catch (Exception e) {

logger.error("Exception while getting public ip pools ", e);

throw new CapiPluginNetworkException(

CapiPluginErrorCodes.NETWORK_ERROR, e.getMessage(),

e.getCause());

}

return publicIpPools;

}

CapiPluginSessionIf

This section defines all session-based methods. These methods are used to either validate a cloud provider

session, or create or destroy a session for each transaction performed on the cloud backend.

createClientSession

API

boolean createClientSession(

CapiTenantAccountVO tenantAccountInfo)

throws CapiPluginSessionException;

Adapter Development

1. Use account credentials and establish a session with the backend.

2. Create the session object and save it as part of the class.

3. If a session handle cannot be established, return an exception.

Code Stub

public boolean createClientSession(CapiTenantAccountVO tenantAccountInfo)

throws CapiPluginSessionException {

try {

// Cloud Specific Code Start

// Cloud Specific Code End

} catch (Exception e) {

throw new CapiPluginSessionException(

CapiPluginErrorCodes.CONNECTION_NOT_AVAILABLE,

e.getMessage(), e.getCause());

}

return true;

}

deleteClientSession

API

boolean deleteClientSession() throws CapiPluginSessionException;

Adapter Development

1. Fetch the session that was created as part of the createSession() method.

2. Delete the session and return.

3. If a session cannot be deleted, return an exception.

Page 18

Code Stub

public boolean deleteClientSession(CapiTenantAccountVO tenantAccountInfo)

throws CapiPluginSessionException {

try {

// Cloud Specific Code Start

// Cloud Specific Code End

} catch (Exception e) {

throw new CapiPluginSessionException(

CapiPluginErrorCodes.CONNECTION_NOT_AVAILABLE,

e.getMessage(), e.getCause());

}

return true;

}

validateClientSession

This method validates a session whenever the adapter makes a call to the cloud provider API. All adapters must

populate this method.

API

boolean validateClientSession(

CapiTenantAccountVO tenantAccountInfo)

throws CapiPluginSessionException;

Adapter Development

This method validates connectivity to the cloud backend. Adapters can do one of the following:

● Use the tenantAccountInfo API and, depending on the cloud, either the username and password or the API

key and Secret key combination can be used to validate connectivity to the cloud provider infrastructure.

● After a connection is validated, return a boolean to reflect the operation.

Code Stub

public boolean validateClientSession(CapiTenantAccountVO tenantAccountInfo)

throws CapiPluginSessionException {

boolean validated = false;

// Cloud Specific Code Start

// Cloud Specific Code End

} else {

logger.error("Can not create connection to "

+ tenantAccountInfo.getCloudEndPoint());

throw new CapiPluginSessionException(

CapiPluginErrorCodes.CONNECTION_NOT_AVAILABLE,

"Unable to connect", null);

}

return validated;

}

CapiPluginStorageIf

No APIs are currently implemented as part of this interface.

CapiPluginSecurityIf

This interface deals with create, read, update, and delete (CRUD) operations that pertain to security rules applied

to a virtual machine or a network in the cloud.

createSecurityGroup

This method creates a security group.

Page 19

API

CapiSecurityResource createSecurityGroup(

CapiTenantAccountVO tenantAccountInfo,

CapiSecurityResource securityResourceModel)

throws CapiPluginSecurityException;

Adapter Development

If the cloud backend supports the security group concept:

1. Read securityResourceModel.

2. Fetch the providerVpcId and locationId.

3. Invoke the cloud API to create a security group.

4. Return the status SecurityGroupEnum.CREATED.

Code Stub

@Override

public CapiSecurityResource createSecurityGroup(CapiTenantAccountVO tenantInfo,

CapiSecurityResource securityResource) throws CapiPluginSecurityException

{

try {

// Cloud Specific Code Start

// Cloud Specific Code End

securityResource.setStatus(SecurityGroupEnum.CREATED.value());

} catch (final Exception e) {

logger.error(e.getMessage(), e);

throw new CapiPluginSecurityException(

CapiPluginErrorCodes.SECURITY_ERROR,

"Error while creating security group" + e.getMessage(),

e);

}

return securityResource;

}

deleteSecurityGroup

API

boolean deleteSecurityGroup(

CapiTenantAccountVO tenantAccountInfo, String securityRuleId)

throws CapiPluginSecurityException;

Adapter Development

1. Use securityGroupId to fetch providerVpcId and locationId.

2. Invoke the cloud API to delete the security group.

3. Update the status to DELETED.

4. In the event of a failure, issue an exception.

Code Stub

@Override

public boolean deleteSecurityGroup(CapiTenantAccountVO tenantInfo,

String securityGroupId) throws CapiPluginSecurityException {

try {

// Cloud Specific Code Start

// Cloud Specific Code End

securityResource.setStatus(SecurityGroupEnum.DELETED.value());

} catch (final Exception e) {

logger.error(e.getMessage(), e);

Page 20

throw new CapiPluginSecurityException(

CapiPluginErrorCodes.SECURITY_ERROR,

"Error while deleting security group" + e.getMessage(),

e);

}

return true;

}

updateSecurityGroup

API

CapiSecurityResource updateSecurityGroup(

CapiTenantAccountVO tenantAccountInfo,

CapiSecurityResource securityResourceModel)

throws CapiPluginSecurityException;

Adapter Development

1. Using securityGroupId, fetch providerVpcId and locationId.

2. Invoke the cloud API to update the security group information.

3. Update the status to UPDATED.

4. In the event of failure, issue an exception.

Code Stub

@Override

public CapiSecurityResource updateSecurityGroup(CapiTenantAccountVO tenantInfo,

CapiSecurityResource securityResource) throws CapiPluginSecurityException

{

try {

// Cloud Specific Code Start

// Cloud Specific Code End

securityResource.setStatus(SecurityGroupEnum.UPDATED.value());

} catch (final Exception e) {

logger.error(e.getMessage(), e);

throw new CapiPluginSecurityException(

CapiPluginErrorCodes.SECURITY_ERROR,

"Error while updating security group" + e.getMessage(),

e);

}

return securityResource;

}

addSecurityRule

API

CapiSecurityRule addSecurityRule(

CapiTenantAccountVO tenantAccountInfo,

String securityGroupId, CapiSecurityRule securityRule)

throws CapiPluginSecurityException;

Adapter Development

1. Using securityGroupId, fetch providerVpcId and locationId.

2. Read the security rule and apply it on the cloud back end.

3. In the event of failure, issue an exception.

Code Stub

@Override

public CapiSecurityRule addSecurityRule(CapiTenantAccountVO tenantInfo,

Page is loading ...

Cisco Intercloud Fabric User guide

Brand: Cisco

Model: Intercloud Fabric

Category: Development software

Type: User guide

This manual is also suitable for

Download PDF

report

Cisco Intercloud Fabric User guide

This manual is also suitable for

Cisco Intercloud Fabric User guide

Related papers

Other documents