Cisco Intercloud Fabric User guide

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 NetworkAll tenants share the same network infrastructure; isolation is achieved by using security-
groups.
Isolated NetworkA 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 4Cisco 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 5Cisco 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 1 1
  • Page 2 2
  • Page 3 3
  • Page 4 4
  • Page 5 5
  • Page 6 6
  • Page 7 7
  • Page 8 8
  • Page 9 9
  • Page 10 10
  • Page 11 11
  • Page 12 12
  • Page 13 13
  • Page 14 14
  • Page 15 15
  • Page 16 16
  • Page 17 17
  • Page 18 18
  • Page 19 19
  • Page 20 20
  • Page 21 21
  • Page 22 22
  • Page 23 23
  • Page 24 24
  • Page 25 25
  • Page 26 26
  • Page 27 27
  • Page 28 28
  • Page 29 29
  • Page 30 30
  • Page 31 31
  • Page 32 32
  • Page 33 33
  • Page 34 34
  • Page 35 35
  • Page 36 36
  • Page 37 37
  • Page 38 38
  • Page 39 39
  • Page 40 40
  • Page 41 41

Cisco Intercloud Fabric User guide

Category
Development software
Type
User guide
This manual is also suitable for

Ask a question and I''ll find the answer in the document

Finding information in a document is now easier with AI