Chapter 1. Overview

Cisco Intercloud Fabric

Cisco Intercloud Fabric for Providers

Cisco Intercloud Fabric Provider Platform

Cisco ICFPP Deployment Topology

Cisco ICFPP Operational Model

Chapter 2. Using Cisco ICFPP ShellAdmin Commands

Accessing the ShellAdmin Console

General Administration

Viewing Version Information

Starting Cisco Services

Stopping Cisco Services

Displaying Service Status

Changing Your Password

Synchronizing the System Time

Importing a CA Certificate JKS File

Pinging a Host by Hostname or IP Address

Configuring a Network Interface

Viewing Appliance Network Details

Viewing Tail Inframgr Logs

Applying a Patch to Cisco ICFPP

Configuring Multiple-Node Clusters

Configuring a Primary Node

Configuring a Service Node

Configuring NFS

Configuring HA

Configuring VIP Access for HA Nodes in OpenStack

Monitoring HA Status

Moving from a Standalone Setup to a Cluster

Restoring a Database onto an Existing HA Pair

Reconfiguring a Virtual IP Address

Reconfiguring a Service Node

Reconfiguring HA

Viewing HA Syslog Messages

Working with Databases

Starting the Database

Stopping the Database

Backing Up the Database

Restoring the Database

Accessing Root Privileges

Enabling Root Access

Configuring Root Access

Disabling Root Access

Logging in as Root

Chapter 3. Using the Cisco ICFPP GUI

Common Administrative Tasks

Configuring Syslog Servers

Importing a JKS Certificate File

Installing an Adapter

Upgrading Cisco ICFPP

Upgrading a Standalone Node

Upgrading a Multiple-Node Cluster

Managing Licenses

Updating a License

Viewing License Details

Monitoring Tasks

Obtaining Logs

Obtaining System Information

Downloading Logs for HA and Cluster Environments

Generating Reports

Managing Cloud Instances

Adding a Cloud Instance

Viewing a Cloud Instance's Details

Editing a Cloud Instance

Deleting a Cloud Instance

Managing Tenants

Adding a Tenant

Viewing a Tenant's Details

Editing a Tenant

Deleting a Tenant

Monitoring Tenants

Chapter 4. Cisco ICFPP Architecture

Architecture Overview

Northbound Cisco Intercloud Fabric Cloud APIs

Northbound Cisco Intercloud Fabric Provider APIs

Core Application Logic Module

Southbound Cloud Adapter Layer

Chapter 5. Southbound Cloud Adapter Framework

Creating Custom Cloud Adapters

Custom Cloud Adapter Programming Model

Installing or Upgrading an Adapter

Validating an Adapter

Chapter 6. Service Provider APIs

Supported Protocols and Formats

Recommended Tools

Login

Cloud Instance Management APIs

Provision Cloud Instance

Update Cloud Instance

Get Cloud Instance

Get All Cloud Instances

Delete Cloud Instance

Tenant Management APIs

Provision Tenant

Update Tenant

Get Tenant

Get Tenant Details

Get All Tenants

Delete Tenant

Purge Tenant

Get Server

Remote Syslog Configuration APIs

Configure Syslog Servers

Get Syslog Configuration

Logging APIs

Download Current Logs

Download All Logs

Chapter 7. Additional Information

Related Documentation for Cisco Intercloud Fabric Provider Platform

Obtaining Documentation and Submitting a Service Request

Documentation Feedback

Copyright Page

Chapter 1. Overview

- Cisco Intercloud Fabric

- Cisco Intercloud Fabric for Providers

- Cisco Intercloud Fabric Provider Platform

- Cisco ICFPP Deployment Topology

- Cisco ICFPP Operational Model

Cisco Intercloud Fabric

Cisco Intercloud Fabric offers two product configurations that address the following business needs:

- Cisco Intercloud Fabric for Providers

- Cisco Intercloud Fabric for Business

This document describes how to install, configure, and start working with Cisco Intercloud Fabric for Providers. For information about Cisco Intercloud Fabric for Business, see the Cisco Intercloud Fabric Getting Started Guide.

Cisco Intercloud Fabric for Providers

Cisco Intercloud Fabric for Providers is intended for provider cloud environments, allowing their enterprise customers to transparently extend their private cloud environments into the provider's public cloud, while keeping the same level of security and policy across cloud environments. Cisco Intercloud Fabric provides services for the following types of providers:

- Providers who offer managed services

- Providers who specialize in Intercloud Fabric hybrid workloads

For providers who offer managed services, Cisco Intercloud Fabric for Providers consists of the following components:

- Cisco Intercloud Fabric Provider Platform

- Cisco Intercloud Fabric Director

- Cisco Intercloud Fabric Extender

For providers who specialize in Intercloud Fabric hybrid workloads, Cisco Intercloud Fabric for Providers consists of the Cisco Intercloud Fabric Provider Platform component only.

Cisco Intercloud Fabric Provider Platform

Cisco Intercloud Fabric Provider Platform (ICFPP) simplifies and abstracts the complexity involved in working with a variety of public cloud APIs, and enables cloud API support for service providers who currently do not have API support. Cisco ICFPP provides an extensible adapter framework that allows integration with a variety of provider cloud infrastructure management platforms, such as OpenStack, CloudStack, VMware vCloud Director, and any other API that can be integrated through an software development kit (SDK) provided by Cisco.

Currently, service providers have their own proprietary cloud APIs—such as Amazon EC2 and Windows Azure—that give customers limited choices and provide no easy method for moving from one provider to another. Cisco ICFPP abstracts this complexity and translates Cisco Intercloud Fabric cloud API calls to cloud platform APIs of different provider infrastructure platforms, giving customers the option of moving their workloads regardless of the cloud API exposed by the service provider.

Many service providers do not provide cloud APIs that Cisco Intercloud Fabric can use to deploy customers' workloads. One option for these providers is to provide direct access to their virtual machine manager's SDK or API, such as vCenter or System Center, which exposes the provider environment and is not a preferred option for service providers due to security concerns. Cisco ICFPP, as the first point of authentication for the customer cloud so that it can consume provider cloud resources, enforces highly secure access to the provider environment. In addition, it provides the cloud APIs that are required for service providers to be part of the provider ecosystem for Cisco Intercloud Fabric.

As the interface between the Cisco Intercloud Fabric from customer cloud environments and provider clouds (public and virtual private clouds), Cisco ICFPP provides the following benefits:

- Standardizes and brings uniformity to cloud APIs, making it easier for Cisco Intercloud Fabric to consume cloud services from service providers that are part of the Cisco Intercloud Fabric ecosystem.

- Helps secure access to a service provider's underlying cloud platform.

- Limits the utilization rate per customer or tenant environment.

- Provides northbound APIs for service providers for integration with existing management platforms.

- Supports multitenancy.

- Monitors resource usage per tenant.

- Meters resource usage per tenant.

Cisco ICFPP Deployment Topology

To access a service provider's cloud resources, Cisco Intercloud Fabric must access the Cisco ICFPP virtual appliance from the public network. To do this, the network interface of the appliance must be deployed on a provider network that is exposed to the service provider's edge router. The network interface of the appliance must also connect to the private provider network that accesses the service provider cloud platform, such as OpenStack or CloudStack.

The Cisco ICFPP deployment topology varies for different service providers and cloud platforms. The following figure shows a standalone deployment with a VMware vCloud Director environment in the service provider. For deployment in a multiple-node cluster, a load balancer in the service provider environment is required to support the cluster configuration.

Cisco ICFPP Appliance Deployment Topology

The Cisco ICFPP appliance uses HTTPS connections to communicate with Cisco Intercloud Fabric and the service provider cloud platform. A firewall is not required in the network path between Cisco Intercloud Fabric and the Cisco ICFPP appliance, or between the Cisco ICFPP appliance and cloud platform endpoints, but can be used to reinforce the expected traffic flows to and from Cisco ICFPP.

Cisco ICFPP Operational Model

The Cisco ICFPP operational model consists of two main operational stages:

- Service provider operations—Operations performed in the service provider data center by a service provider administrator. These operations primarily involve installing and configuring Cisco ICFPP and provisioning tenant-related information to Cisco ICFPP.

- Business operations—Operations performed in a private data center environment by a Cisco Intercloud Fabric administrator and end users of the Cisco Intercloud Fabric solution. These operations are usually performed after Cisco ICFPP has been deployed and activated in the service provider data center. For example, queries related to metering and usage are are considered part of business operations.

The following figure illustrates the Cisco ICFPP operational model and stages.

Cisco ICFPP Operational Model and Stages

The following sections summarize the operations that constitute these two stages.

Service Provider Operation—Deployment and Initialization

The Cisco ICFPP virtual appliance is deployed in the service provider data center as part of the service provider cloud platform. The service provider administrator configures the virtual appliance with the following information:

- Appliance IP addresses

- SSL server and client configurations

- Initial administrator user credentials and privileges

Next, the service provider administrator adds instances of the cloud platform with which Cisco ICFPP will interface. These cloud platform instances can be assigned to tenants during tenant on-boarding. The following information is required for each cloud platform instance:

- Cloud platform type, such as Cisco Cloud Services

- Cloud platform endpoint IP address and port number

- Service provider administrator or tenant credentials for sign-on with a cloud platform

Service Provider Operation—Tenant On-Boarding

Cisco ICFPP supports multiple tenants concurrently. To enable a tenant on Cisco ICFPP, the service provider administrator must provide the following tenant-specific information on the virtual appliance:

- The cloud platform instance that is assigned to the tenant

- The resources domain (a predefined set of resources) that is assigned to the tenant

- Tenant credentials, such as the API key, which is used by Cisco ICFPP to sign a tenant onto the service provider cloud platform. Tenant credentials can be generated by the service provider management portal when the tenant is registered to a cloud account.

- Tenant account username, which is used to identify the tenant-specific record

The same process is used for both adding new tenants and updating existing tenants on Cisco ICFPP. After the Cisco ICFPP virtual appliance is deployed and tenants are provisioned, the service provider administrator must ensure that the Cisco ICFPP virtual appliance DNS information is published to the enterprise customer's portal so that the tenants can reach Cisco ICFPP through the Internet.

Business Operation—Cisco Intercloud Fabric Director Sign-On with the Cisco Intercloud Fabric Provider Platform

With the Cisco ICFPP virtual appliance DNS information and tenant credentials, the Cisco Intercloud Fabric Director (ICFD) administrator can sign on with Cisco ICFPP to start an ICFD-ICFPP management session. Before an ICFD end user can use the ICFD self-service portal, the ICFD administrator must set up the Secure Cloud Extension to extend tenant on-premises networks to the service provider cloud.

Business Operation—Setting Up the Secure Cloud Extension

With an established ICFD-ICFPP management session, the ICFD administrator can issue Intercloud Cloud Orchestration APIs to set up the Secure Cloud Extension for extending the tenant's enterprise network and demanded service appliances, such as virtual firewall and virtual routing services. The Secure Cloud Extension provides ICFD end users with a hybrid infrastructure, which allows the preservation of workload network identities and ensures that the workload security policy is persisted across private and public clouds.

The Secure Cloud Extension has several virtual appliance components that run in the provider cloud. These components consist of the Intercloud Fabric Switch (ICS), ICF Router (CSR), and Intercloud Fabric Firewall (also known as Virtual Security Gateway). As a part of the Secure Cloud Extension deployment, ICFD works with Cisco ICFPP to upload the appliance images to the public cloud, instantiate appliance instances, and bring up the entire ICF infrastructure.

Business Operation—Cloud Provisioning and Virtual Machine Life-Cycle Management

When a Secure Cloud Extension instance is established, ICFD provides different portals for ICFD administrators and end users. Administrators and users can use their respective portals to provision or migrate workloads to public clouds and manage workloads with virtual machine life-cycle management interfaces that are provided by the portals.

In addition to supporting cloud orchestration API requests that are issued by ICFD, Cisco ICFPP meters tenant resource usage and monitors tenant resources so that service providers can manage hybrid cloud services.

For more information, see the available data sheets and white papers on cisco.com at Click Here .

Chapter 2. Using Cisco ICFPP ShellAdmin Commands

- Accessing the ShellAdmin Console

- General Administration

- Configuring Multiple-Node Clusters

- Working with Databases

- Accessing Root Privileges

Accessing the ShellAdmin Console

The ShellAdmin console provides many options for managing and configuring Cisco ICFPP. You can access the ShellAdmin console by using SSH as described in this procedure.

Procedure

Step 1

Using SSH, connect to the ShellAdmin console by using the following information:

- IP address of the Cisco ICFPP virtual appliance.

- The username shelladmin.

- The password that you set when you installed Cisco ICFPP.

The ShellAdmin menu is displayed with the options available for the type of node: Standalone, Primary, or Service.

Step 2

Enter the number of the option you want, and press Enter. If additional information is required for the option that you choose, you will be prompted for it.

General Administration

You can execute common administration tasks such as changing your password, stopping and starting services, generating log and report data, and other common system administration tasks by using the ShellAdmin console.

- Viewing Version Information

- Starting Cisco Services

- Stopping Cisco Services

- Displaying Service Status

- Changing Your Password

- Synchronizing the System Time

- Importing a CA Certificate JKS File

- Pinging a Host by Hostname or IP Address

- Configuring a Network Interface

- Viewing Appliance Network Details

- Viewing Tail Inframgr Logs

- Applying a Patch to Cisco ICFPP

Viewing Version Information

You can view the Cisco ICFPP version and build number by choosing the Show Version option. This information is required for debugging purposes.

Procedure

Step 1

From the Intercloud Fabric Provider Platform Shell menu, choose the Show Version option and press Enter.
Information similar to the following displays:

Cisco UCS Director Platform
---------------------------
Platform Version  : 5.3.0.0
Platform build number : 74
Product Name     : Intercloud Fabric Provider Platform
Product Version  : 2.2.1.3690
Press return to continue ...

Step 2

Press Enter to return to the menu.

Starting Cisco Services

You can start all services that are part of Cisco ICFPP by choosing the Start Services option.

Note

Services started in the background are not displayed.

Procedure

Step 1

In the ShellAdmin console, choose the Start Services option.
The following information is displayed:

Press return to continue ...nohup: appending output to `nohup.out'

Step 2

Press Enter to return to the menu.

Step 3

(Optional) To verify that the services have started, choose the Display Service Status option.

Stopping Cisco Services

You can stop all Cisco services that are part of Cisco ICFPP by choosing the Stop Services option. You can verify that all services are stopped by choosing the Display Service Status option.

Procedure

Step 1

In the ShellAdmin console, choose the Stop Services option.
Information similar to the following is displayed:

Stopping broker [PID=17364]/[Child=17365]
Stopping controller [PID=17402]/[Child=17404]
Stopping eventmgr [PID=17471]/[Child=17473]
Stopping client [PID=17535]/[Child=17537
17615
17678]
Stopping idaccessmgr [PID=17613]/[Child=]
/opt/infra/stopInfraAll.sh: line 35: kill: (17613) - No such process
Stopping inframgr [PID=17676]/[Child=]
Tomcat is running with [PID=17779]. Stoping it and its child process
Flashpolicyd is running with [PID=17807]. Stopping it
Stopping websock[PID=17812]
Press return to continue ...

Step 2

Press Enter to return to the menu.

Step 3

(Optional) To confirm that the services have stopped, choose the Display Service Status option.

Displaying Service Status

The Display Services Status option enables you to view the following services and their status:

- Broker

- Controller

- Eventmgr

- Client

- Idaccessmgr

- Inframgr

- Tomcat

- Websock (VNC interface)

- Database (mysqld)

Procedure

Step 1

In the ShellAdmin console, choose the Display Service Status option.
Information similar to the following is displayed with the service name, status and process ID (PID):

Service                  Status        PID
----------           ----------      -----
broker                  RUNNING      27533
controller              RUNNING      27558
eventmgr                RUNNING      27592
client                  RUNNING      27637
idaccessmgr             RUNNING      27681
inframgr                RUNNING      27726
TOMCAT                  RUNNING      27783
websock                 RUNNING      27812

4204 ?        00:00:00 mysqld_safe
4625 ?        00:14:45 mysqld

Step 2

Confirm that all services are running. If a service is not running, restart the service by choosing Start Services in the ShellAdmin console.

Changing Your Password

You can change the password for the Cisco ICFPP shelladmin account by choosing the Change ShellAdmin Password option.

Procedure

Step 1

In the ShellAdmin console, choose the Change ShellAdmin Password option.
Information similar to the following is displayed:

Changing password for user shelladmin.
New UNIX password:

Step 2

Enter and confirm the new shelladmin account password.
Information similar to the following is displayed:

passwd: all authentication tokens updated successfully. Press return to continue...

Synchronizing the System Time

You can synchronize the system time to the hardware time and a network time protocol (NTP) server by choosing the Time Sync option.

Procedure

Step 1

In the ShellAdmin console, choose the Time Sync option.
Information similar to the following is displayed:

System time is Tue May  7 14:19:19 UTC 2015
Hardware time is Tue 07 May 2015 02:19:20 PM UTC  -0.107647 seconds
Do you want to sync systemtime [y/n]?

Step 2

When asked if you want to synchronize the system time, enter Y.

Step 3

When asked if you want to synchronize with NTP, enter Y.

Step 4

If you choose to synchronize with NTP, enter the NTP server IP address when prompted.

Step 5

Press Enter to return to the ShellAdmin menu.

Importing a CA Certificate JKS File

You can import a CA signed certificate file by choosing the Import a CA Certificate (JKS) file option.

Procedure

Step 1

In the ShellAdmin console, choose the Import a CA Certificate (JKS) file option.
Information similar to the following is displayed:

Import CA signed certificate from URL.
E.g. URL --> http://host:port/cert.jks

URL:

Step 2

Enter the URL for the CA signed certificate file and press Enter.

Pinging a Host by Hostname or IP Address

You can use the ShellAdmin console to test your connectivity by pinging a host by hostname or IP address.

Procedure

Step 1

In the ShellAdmin console, choose the Ping Hostname/IP address option.

Step 2

When asked if you want to use the ping or ping6 command, enter V4.

Step 3

When prompted, enter the hostname or IP address of the host you want to ping.
Information similar to the following is displayed:

Do you want to run ping/ping6 [v4/v6] ? : v4
Enter IP Address : 209.165.200.224
PING 209.165.200.224 (209.165.200.224) 56(84) bytes of data.
64 bytes from 209.165.200.224: icmp_seq=1 ttl=64 time=9.90 ms
64 bytes from 209.165.200.224: icmp_seq=2 ttl=64 time=0.316 ms
64 bytes from 209.165.200.224: icmp_seq=3 ttl=64 time=0.254 ms
64 bytes from 209.165.200.224: icmp_seq=4 ttl=64 time=0.198 ms
64 bytes from 209.165.200.224: icmp_seq=5 ttl=64 time=0.267 ms

--- 209.165.200.224 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3999ms
rtt min/avg/max/mdev = 0.198/2.187/9.901/3.857 ms
Press return to continue ...

Step 4

Press Enter to return to the ShellAdmin menu.

Configuring a Network Interface

You can configure a network interface for a Cisco ICFPP virtual appliance by using the ShellAdmin console.

Procedure

Step 1

In the ShellAdmin console, choose the Configure a Network Interface option.
Information similar to the following is displayed:

Do you want to Configure DHCP/STATIC IP  [D/S] ? :

Step 2

Choose one of the following configuration selections:

- Enter D to configure a DHCP IP address.

- Enter S to configure a static IP address.

If you choose to configure a static IP address, information similar to the following is displayed:

Configuring STATIC configuration..
Enter the ethernet interface that you want configure E.g. eth0 or eth1:

Step 3

When prompted, enter the Ethernet interface to configure, such as eth1.
Information similar to the following is displayed:

Configuring STATIC IP for eth1...
IP Address: 209.165.200.224
Netmask: 255.255.255.0
Gateway: 209.187.108.1
DNS Server1: 198.51.100.1
DNS Server2: 203.0.113.1
Configuring Network with : INTERACE(eth1), IP(209.165.200.224), Netmask(255.255.255.0), Gateway(209.187.108.1),
DNS Server1(198.51.100.1), DNS Serverx 2(203.0.113.1)

Do you want to continue  [y/n]? :

Step 4

Enter Y to complete the configuration.

Viewing Appliance Network Details

You can view the details of a Cisco ICFPP virtual appliance network by using the ShellAdmin console.

Procedure

Step 1

In the ShellAdmin console, choose the Display Network Details option.
Information similar to the following is displayed:

Network details....
eth0      Link encap:Ethernet  HWaddr 00:50:56:97:1E:2D
inet addr:192.0.2.23  Bcast:192.0.2.255  Mask:255.255.255.0
inet6 addr: fe80::230:56gg:fe97:1e2d/64 Scope:Link
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
RX packets:189818223 errors:14832 dropped:17343 overruns:0 frame:0
TX packets:71520969 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:105749301003 (98.4 GiB)  TX bytes:27590555706 (25.6 GiB)
Interrupt:59 Base address:0x2000

lo        Link encap:Local Loopback
inet addr:127.0.0.1  Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING  MTU:16436  Metric:1
RX packets:1821636581 errors:0 dropped:0 overruns:0 frame:0
TX packets:1821636581 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:327846827946 (305.3 GiB)  TX bytes:327846827946 (305.3 GiB)

Press return to continue ...

Step 2

Press Enter to return to the ShellAdmin menu.

Viewing Tail Inframgr Logs

The ShellAdmin console enables you to see Infrastructure Manager (inframgr) log data, which is generated by using the UNIX tail command. This log data is useful for tracing information when you are debugging problems. Choose the Tail Inframgr Logs option to immediately tail the most recent inframgr logs and view the results.

Procedure

Step 1

In the ShellAdmin console, choose the Tail Inframgr Logs option.
Information similar to the following is displayed:

2015-05-20 23:17:43,500 [pool-23-thread-17]
INFO  getBestAgent(SystemTaskExecutor.java:308)
- No Agent available for remoting SnapMirrorHistoryStatusSchedulerTask
2015-05-20 23:17:43,502 [pool-23-thread-17]
INFO  updateStatus(SystemTaskStatusProvider.java:181)
- Task: task.SnapMirrorHistoryStatusSchedulerTask changed state to OK
2015-05-20 23:17:43,562 [pool-23-thread-17]
INFO  executeLocally(SystemTaskExecutor.java:133)
- Executing task locally: SnapMirrorHistoryStatusSchedulerTask
2015-05-20 23:17:43,562 [pool-23-thread-17]
INFO  getClusterLeaf(ClusterPersistenceUtil.java:81)
- Leaf name LocalHost
2015-05-20 23:17:43,571 [pool-23-thread-17]

Step 2

To exit from the log file display, press Ctrl-C and then Enter.

Applying a Patch to Cisco ICFPP

You can use the ShellAdmin console to apply Cisco ICFPP patches that include infrastructure changes. For more information or to obtain a patch file, contact your Cisco representative.

Before You Begin

- Download the patch file from Cisco. If you need assistance, contact your Cisco representative.

- Place the patch file on a web server or FTP server that is accessible from Cisco ICFPP.

- Review the patch release notes and README file.

- Take a snapshot of the Cisco ICFPP virtual appliance.

- Make a backup of the virtual appliance database. Although the Apply Patch option enables you to make a backup as part of the procedure, we recommend that you create a backup immediately before choosing the Apply Patch option.

Procedure

Step 1

In the ShellAdmin console, choose Stop Services.

Step 2

After the services have stopped, choose the Apply Patch option.
Information similar to the following is displayed:

Applying Patch...
Do you want to take database backup before applying patch (y/n)?

Step 3

Do one of the following:

- If you did not back up the appliance database before starting this procedure, enter Y, and then enter the IP address and credentials for the FTP server where the database is to be backed up.
Information similar to the following is displayed:

y
Backup will upload file to an FTP server.
Provide the necessary access credentials.
FTP Server IP Address: nnn.nnn.nnn.nnn
FTP Server Login:

- If you backed up the appliance database before starting this procedure, enter N and then enter the URL or location of the patch.
Information similar to the following is displayed:

n
Applying Patch:
Patch URL: http://nnn.nnn.nnn.nnn/icfpp-patch.zip

Applying the Patch http://nnn.nnn.nnn.nnn/icfpp-patch.zip [y/n]? y

Step 4

When prompted, enter Y to confirm that you want to apply the patch.

Step 5

After the patch has been applied, choose the Start Services option in the ShellAdmin console.

Configuring Multiple-Node Clusters

The topics in this section describe how to use the ShellAdmin console to configure Cisco ICFPP nodes for multiple-node clusters.

- Configuring a Primary Node

- Configuring a Service Node

- Configuring NFS

- Configuring HA

- Configuring VIP Access for HA Nodes in OpenStack

- Monitoring HA Status

- Moving from a Standalone Setup to a Cluster

- Restoring a Database onto an Existing HA Pair

- Reconfiguring a Virtual IP Address

- Reconfiguring a Service Node

- Reconfiguring HA

- Viewing HA Syslog Messages

Configuring a Primary Node

To configure a Cisco ICFPP virtual appliance that has been installed using the Standalone Mode role for a multiple-node cluster, you must first configure it as a primary node or service node by using the ShellAdmin console. This procedure describes how to configure a standalone node as a primary node. For information on configuring a standalone node as a service node, see Configuring a Service Node.

Before You Begin
Install a Cisco ICFPP virtual appliance using the Standalone Mode role.

Procedure

Step 1

Using SSH, log in to the ShellAdmin console of the node that will be the active node for the HA pair.

Step 2

At the ShellAdmin prompt, choose the Change Node Role option.

Step 3

When prompted, enter Y to change the node role.

Step 4

Enter A to configure the node as a primary node.

Step 5

Enter Y to confirm that you want to configure the node as a primary node. Information similar to the following is displayed:

user selected 'y'
Checking DB Status
2399 ?       00:00:00 mysqld_safe
2820 ?       00:04:21 mysqld
Configuring as Primary Node...
Stopping services before changing node role
Stopping the services...
Setting up current node as Primary node...
Enabling Remote Database access to ICFPP Service nodes
Checking the MySQL to be ready before enabling remote access to DB...
Waiting a maximum of 900 seconds for MySQL to be up on localhost

Trying a maximum of 900 seconds for enabling remote access to DB
Successfully enabled remote access for database

SUCCESS: Successfully changed node role to Primary Node

Stopping Database and restarting it for changes to take effect
Stopping database...
Database stopped...
Starting services that were previously stopped.
Starting the Database...
Starting the services...
In order for changes to take effect logout and log back in
Do you want to logout [y/n]?

Step 6

Enter Y when prompted to log out. You are logged out of the ShellAdmin console. When you log in again, the menu will include options for configuring HA and viewing HA status.

Configuring a Service Node

To configure a Cisco ICFPP virtual appliance that has been installed using the Standalone Mode role for a multiple-node cluster, you must first configure it as a primary node or as a service node by using the ShellAdmin console. This procedure describes how to configure a standalone node as a service node. For information on configuring a standalone node as a primary node, see Configuring a Primary Node.

Before You Begin

- Install a Cisco ICFPP virtual appliance using the Standalone role.

- Obtain the IP address of a primary node in the cluster or the virtual IP address (VIP) of an HA pair in the cluster.

- Back up any data in the virtual appliance database that you want to keep. When the virtual appliance is reconfigured as a service node, the existing data will be deleted.

Procedure

Step 1

Using SSH, log in to the ShellAdmin console of the standalone node that you want to configure as a service node.

Step 2

At the ShellAdmin prompt, choose the Change Node Role option.

Step 3

When prompted, enter Y to change the node role.

Step 4

Enter B to configure the node as a service node.

Step 5

Enter Y to confirm that you want to configure the node as a service node.

Step 6

When asked if you want to continue, do one of the following:

- Enter N to stop the configuration so that you can back up the database.

- Enter Y to confirm that you want to continue.

If you choose to continue, Cisco ICFPP confirms your choice.

Step 7

When prompted, enter the IP address of the primary node or the VIP of the HA pair that the service node is to use. Information similar to the following is displayed:

Configuring as Service Node...
Stopping services before changing node role
Stopping the services...
Setting up current node as ICFPP service node...with remote DB IP 123.45.1.60
Disabling Database service at startup

SUCCESS: Successfully changed node role to Service Node

Starting services that were previously stopped...
Starting the services...
In order for the changes to take effect, log out and log in again
Do you want to log out [y/n]?

Step 8

Enter Y to log out. The next time that you log in, the menu will include the options available for a service node.

Configuring NFS

If you did not configure an NFS server for a Cisco ICFPP virtual appliance when you installed it, you can configure the appliance for NFS by using the ShellAdmin console.

We recommend that you configure an NFS server for all Cisco ICFPP nodes. If NFS is not configured, all VM images that are uploaded from Cisco Intercloud Fabric Director are stored on the local disk. If NFS is not configured and a node fails, any images stored on that node will not be available and could cause template creation and VM migration to fail if the node is part of a cluster.

Before You Begin

- Upload all images on the Cisco ICFPP virtual appliance to the cloud. If the images are not uploaded to the cloud, they will be deleted when NFS is configured.

- Identify the NFS server IP address and the directory in which the files are to be stored.

Procedure

Step 1

Using SSH, log in to the ShellAdmin console for the Cisco ICFPP appliance that you want to configure for NFS.

Step 2

Choose the NFS Configuration option. Cisco ICFPP displays a menu with options for configuring, removing, and viewing an NFS configuration.

Step 3

At the prompt, enter A. Cisco ICFPP determines whether or not an NFS directory is mounted and displays the results:

Checking for mounted NFS directory...
NFS directory is not mounted
Note: Configuring NFS will delete any images that are not uploaded to the cloud! Proceed [y/n]?

Step 4

Enter Y to continue. Cisco ICFPP determines whether or not an NFS IP address or NFS directory has been configured and then prompts you for your input.

Step 5

When prompted, enter the NFS server IP address and the NFS directory path. Information similar to the following is displayed while NFS is configured:

Configuring NFS with : NFS Server IP=123.15.1.1, remote directory=/nfs/dir local mounting point=/mnt/icfpp-images
Creating /mnt/icfpp-images directory.
Starting portmap and nfs services...
Starting portmap:                                          [  OK  ]
mount -t nfs 123.15.1.1:/icfpp-images /mnt/icfpp-images
May wait for mount up to 12-0 seconds..., please be patient...
Successfully mounted 123.15.1.1:/icfpp-images  at /mnt/icfpp-images
Saving NFS Configuration
NFS IP address: 123.15.1.1
NFS Directory Path: /icfpp_images
Saved NFS Configuration
Setting up images directory to use NFS
Image directory setup to NFS done
Press Return to continue

Step 6

Press Enter to return to the ShellAdmin menu.
To view or remove the NFS configuration for this node, choose the NFS Configuration option in the ShellAdmin menu and choose the appropriate option from the NFS menu.

Configuring HA

After you deploy Cisco ICFPP virtual appliances, you can configure them for high availability (HA) by using the ShellAdmin console.

When configuring HA:

- You must configure the active node and standby node concurrently as described in this procedure for a successful HA deployment.

- The database on the standby node is deleted when the HA pair is configured.

Before You Begin

- Deploy or configure two Cisco ICFPP virtual appliances as primary nodes.

- Identify a virtual IP (VIP) address for the HA pair.

- Determine which node will be the active node and which will be the standby node.

- On the node that will be the standby node, move any existing data that you want to save to another location.

Procedure

Step 1

Using SSH, log in to the ShellAdmin console of the node that will be the active node for the HA pair.

Step 2

At the ShellAdmin prompt, choose the Setup HA option and press Enter. A warning is displayed stating that the contents of the database on the standby node will be deleted.

Step 3

When prompted, enter Y to configure the node for HA.

Step 4

Enter A to configure the node as the active node.

Step 5

When prompted, enter Y to configure the node as the active node. Cisco ICFPP detects and displays the IP address of the current node.

Step 6

Enter Y to confirm the node IP address.

Step 7

Enter the standby node IP address.

Step 8

Enter the VIP to use for the IP pair. Information similar to the following is displayed:

--------------------------------------------
HA Configuration Information:
--------------------------------------------
This node will be configured as active node
Active Node IP address:   123.45.1.61
Standby Node IP address:  123.45.1.62
Virtual IP address:       123.45.1.60
--------------------------------------------
Proceed with setting up HA with above configuration [y/n]:

Step 9

Enter Y to confirm the configuration and proceed or N to change the values. If you choose to proceed, Cisco ICFPP displays progress messages as it configures the active node for HA.

Step 10

While Cisco ICFPP is configuring the active node for HA, log in to the ShellAdmin console of the node that will be the standby node for the HA pair.

Step 11

At the ShellAdmin prompt, choose the Setup HA option and press Enter.

Step 12

Enter Y to configure the node for HA.

Step 13

Enter B to configure the node as the standby node.

Step 14

When prompted, enter Y to configure the node as the standby node. Cisco ICFPP detects and displays the IP address of the current node.

Step 15

Enter Y to confirm the node IP address.

Step 16

Enter the active node IP address.

Step 17

Enter the VIP to use for the HA pair. Information similar to the following is displayed:

--------------------------------------------
HA Configuration Information:
--------------------------------------------
This node will be configured as standby node
Active Node IP address:   123.45.1.61
Standby Node IP address:  123.45.1.62
Virtual IP address:       123.45.1.60
--------------------------------------------
Proceed with setting up HA with above configuration [y/n]:

Step 18

Enter Y to confirm the configuration. Cisco ICFPP displays progress messages as it configures the standby node for HA and synchronizes the database information on both nodes.

Step 19

When prompted, press Enter to return to the ShellAdmin menu.

What to Do Next

For OpenStack environments, continue with Configuring VIP Access for HA Nodes in OpenStack.

Configuring VIP Access for HA Nodes in OpenStack

After Cisco ICFPP primary nodes are configured for HA, the virtual IP address (VIP) is used in the event of failover. However, OpenStack Neutron does not allow a host to accept packets with an IP address in the packet header that does not match the destination host IP address. As a result, packets sent to the VIP do not reach the node to which the VIP is assigned. To allow the packets to reach HA pair, the VIP must be added as an allowed address for both nodes (active and standby) in the HA pair.

This procedure describes how to configure VIP access on the nodes in the HA pair by using the OpenStack neutron port-update command. For more information, see the OpenStack documentation at docs.openstack.org.

Before You Begin

- Confirm that HA has been configured on two Cisco ICFPP primary nodes in an OpenStack environment.

- Confirm that you have access to the OpenStack Neutron command line tool.

Procedure

Step 1

Obtain a list of networks by entering the following command:

$ neutron net-list

Information similar to the following is displayed:

+--------------------------------------+----------------------+-----------------------------------------------------+
| id                                   | name                 | subnets
|
+--------------------------------------+----------------------+-----------------------------------------------------+
| 2d84eaa4-8b81-4dc8-9897-dd8ef4719f8b | public-direct-600    | 3e0b77fe-fc66-4913-bc58-7f62d4ab247a 10.203.28.0/23 |
|                                      |                      | 5c2f73a9-4e2f-498c-8244-6aefe5129fdd 10.203.50.0/23 |
|                                      |                      | ba29165f-c88a-496a-9adc-99ee90407ebe 10.203.24.0/23 |
|                                      |                      | d5b69780-aefb-42a6-8ba5-aaf405fb36a0 10.203.30.0/24 |
| b5d8d461-74d7-45a4-a1f0-f7ac96586bd5 | Net1                 | c0921b42-2896-4b32-b33e-f54db9e5a3d6 192.168.0.0/24 |
| ca80ff29-4f29-49a5-aa22-549f31b09268 | public-floating-601  | 0cfde3f1-e28b-4b87-8095-e0014b0ee573                |
|                                      |                      | 348a808d-ce64-43bc-a9d9-c20e52d2ac06                |
|                                      |                      | 3784170e-5d7f-48b4-b63d-aab4a0fef769                |
| ff95095f-89f0-4005-b709-70a75212d73c | icfpp-ha-123-network | 1099b814-05d9-4da0-93d1-06167db4891f 192.168.1.0/24 |
+--------------------------------------+----------------------+-----------------------------------------------------+

Step 2

Obtain a list of ports on the network on which the active and standby nodes in the HA pair are deployed by entering the following command:

$ neutron port-list -- --network_id=net_id

where net_id is the identifier for the required network. In this example, the network name is icfpp-ha-123-network.

$ neutron port-list -- --network_id=ff95095f-89f0-4005-b709-70a75212d73c

Information similar to the following is displayed:

+--------------------------------------+------+-------------------+-------------------------------------------------------------------------------------+
| id                                   | name | mac_address       | fixed_ips
|
+--------------------------------------+------+-------------------+-------------------------------------------------------------------------------------+
| 4a439cf1-b95e-49ba-a8d6-0b03a8142dd2 |      | fa:16:3e:f6:f8:a9 | {"subnet_id": "1099b814-05d9-4da0-93d1-06167db4891f", "ip_address": "192.168.1.12"} |
| 93d0a69a-7bb8-4719-9ed7-63c10accd78b |      | fa:16:3e:1f:7f:d2 | {"subnet_id": "1099b814-05d9-4da0-93d1-06167db4891f", "ip_address": "192.168.1.11"} |
| 9d626a64-ee7c-410b-ae00-661dd275de79 |      | fa:16:3e:61:81:4b | {"subnet_id": "1099b814-05d9-4da0-93d1-06167db4891f", "ip_address": "192.168.1.14"} |
| cf56fd7b-2896-4e06-b520-1d2258ad6158 |      | fa:16:3e:ab:27:ca | {"subnet_id": "1099b814-05d9-4da0-93d1-06167db4891f", "ip_address": "192.168.1.13"} |
| d7457d29-44ba-46ef-b47a-4b94c9199902 |      | fa:16:3e:ad:d0:e9 | {"subnet_id": "1099b814-05d9-4da0-93d1-06167db4891f", "ip_address": "192.168.1.15"} |
+--------------------------------------+------+-------------------+-------------------------------------------------------------------------------------+

Step 3

In the output of the previous step, locate the port ID for the active node.

Step 4

Update the port so that it accepts traffic from the VIP by entering the following command:

$ neutron port-update active-port-id --allowed_address_pairs list=true type=dict ip_address=vip

where:

- active-port-id is the port ID of the active node.

- vip is the virtual IP address for the HA pair.

For example, if the IP address of the active node is 192.168.1.11 and the VIP is 192.168.1.10, your command would resemble the following:

$ neutron port-update 93d0a69a-7bb8-4719-9ed7-63c10accd78b --allowed_address_pairs list=true type=dict ip_address=192.168.1.10

Step 5

View the port details and confirm that the allowed_address_pairs field lists the VIP by entering the following command:

$ neutron port-show active-port-id

where active-port-id is the identifier for the port that you configured in the previous step.

Using the current example, the command and results would be:

$ neutron port-show 93d0a69a-7bb8-4719-9ed7-63c10accd78b

+-----------------------+-------------------------------------------------------------------------------------+
| Field                 | Value                                                                               |
+-----------------------+-------------------------------------------------------------------------------------+
| admin_state_up        | True                                                                                |
| allowed_address_pairs | {"ip_address": "192.168.1.10", "mac_address": "fa:16:3e:1f:7f:d2"}                  |
| device_id             | b7b8eeb5-70ad-49ac-a3b4-6d8a144293a2                                                |
| device_owner          | compute:alln01-1-csi                                                                |
| extra_dhcp_opts       |                                                                                     |
| fixed_ips             | {"subnet_id": "1099b814-05d9-4da0-93d1-06167db4891f","ip_address": "192.168.1.11"}  |
| id                    | 93d0a69a-7bb8-4719-9ed7-63c10accd78b                                                |
| mac_address           | fa:16:3e:1f:7f:d2                                                                   |
| name                  |                                                                                     |
| network_id            | ff95095f-89f0-4005-b709-70a75212d73c                                                |
| security_groups       | f995d22f-edb8-47c0-9aff-6339a15fb5be                                                |
| status                | ACTIVE                                                                              |
| tenant_id             | b1436740f8db42e39904ee9779f67eb8                                                    |
+-----------------------+-------------------------------------------------------------------------------------+

Step 6

Configure the standby node to accept VIP traffic by entering the following command:

$ neutron port-update standby-port-id --allowed_address_pairs list=true type=dict ip_address=vip

where:

- standby-port-id is the port ID of the standby node.

- vip is the virtual IP address for the HA pair.

Step 7

View the port details for the standby node and confirm that the allowed_address_pairs field lists the VIP:

$ neutron port-show standby-port-id

Step 8

(Optional) Complete the following steps to configure the VIP so that it is accessible from an external network and so that it uses a floating IP address:

1. Configure a port corresponding to the VIP by entering the following command:

$ neutron port-create --fixed-ip ip_address=ip --security-group security-group network-name

where:

- ip is the fixed IP address for the port.

- security-group is the name of the security group to use for this port.

- network-name is the name of the network to which the port belongs.

Using our example, the command and results would be:

$ neutron port-create --fixed-ip ip_address=192.168.1.10 --security-group default icfpp-ha-123-network

Created a new port:
+-----------------------+-------------------------------------------------------------------------------------+
| Field                 | Value                                                                               |
+-----------------------+-------------------------------------------------------------------------------------+
| admin_state_up        | True                                                                                |
| allowed_address_pairs |                                             |
| device_id             |                                                                                     |
| device_owner          |                                                         |
| fixed_ips             | {"subnet_id": "1099b814-05d9-4da0-93d1-06167db4891f","ip_address": "192.168.1.10"}  |
| id                    | ea35e2a9-1b45-4b05-b345-f4758e490052                                       |
| mac_address           | fa:16:3e:df:e9:69                                                     |
| name                  |                                              |
| network_id            | ff95095f-89f0-4005-b709-70a75212d73c                             |
| security_groups       | f995d22f-edb8-47c0-9aff-6339a15fb5be                                           |
| status                | DOWN                                              |
| tenant_id             | b1436740f8db42e39904ee9779f67eb8                                           |
+-----------------------+-------------------------------------------------------------------------------------+

2. In the OpenStack Horizon GUI, associate a floating IP address with the port to which the fixed IP address is assigned.

Monitoring HA Status

After configuring Cisco ICFPP for HA, you can view the configuration details, check status of the active and standby nodes, and view detailed replication status.

Procedure

Step 1

Log in to the ShellAdmin console for one of the nodes in the HA pair.

Step 2

At the menu prompt, choose Display HA Status. Information similar to the following is displayed:

Configured HA role for this node is:  Active
Current HA role for this node is: Active
HA Configuration properties for this node are:
ACTIVE_IP_ADDRESS=123.16.1.30
STANDBY_IP_ADDRESS=123.16.1.3
VIRTUAL_IP_ADDRESS=123.16.1.25

IP address of this node is: 123.16.1.30
Checking if Virtual IP Address is reachable...OK
Virtual IP Address service status on this node...OK
Checking DB replication from 123.16.1.30 to 123.16.1.3...OK
Checking DB replication from 123.16.1.3 to 123.16.1.30...OK

Do you want to view detailed replication status ? [y/n]

Step 3

To view detailed information, enter Y and press Enter. Information similar to the following is displayed:

Slave_IO_State : Waiting for master to send event
Master_Host : 123.16.1.3
Master_User : replicator
Master_Port : 3306
Connect_Retry : 60
Master_Log_File : mysql-bin.000002
Read_Master_Log_Pos : 645644
Relay_Log_File : mysqld-relay-bin.000004
Relay_Log_Pos : 361
Relay_Master_Log_File : mysql-bin.000002
Slave_IO_Running : Yes
Slave_SQL_Running : Yes
Replicate_Do_DB :
Replicate_Ignore_DB :
…

Step 4

Use your arrow keys to scroll through the information, and enter Q to return to the menu.

Moving from a Standalone Setup to a Cluster

Cisco ICFPP enables you to move from a standalone configuration to a cluster. Moving from a standalone configuration to a cluster involves moving the database contents from the existing standalone node to the active HA node in the cluster as described in this procedure.

After moving the database contents, you can configure and test the cluster setup without modifying or affecting the standalone setup. For more information about configuring a multiple-node cluster, see Deployment Workflows.

Before You Begin

- Confirm that you know the FTP server IP address and login credentials for backing up and restoring the database.

- Confirm that the standalone node and both nodes in the HA pair are running the same version of Cisco ICFPP.

Procedure

Step 1

In the ShellAdmin console for the standalone node, back up the existing database as follows:

1. Choose Stop Services to stop the Infrastructure Manager services.

2. Choose Backup Database.

3. Choose Start Services.

Step 2

Deploy or configure two primary nodes via any of the following methods:

- For VMware environments, deploy two new Cisco ICFPP virtual appliances using the Primary Node role. For more information, see the Cisco Intercloud Fabric Provider Platform Installation Guide.

- For OpenStack environments, deploy two new Cisco ICFPP virtual appliances using the Standalone Node role and then configure the appliances as primary nodes. For more information, see the Cisco Intercloud Fabric Provider Platform Installation Guide.

- Configure existing Cisco ICFPP virtual appliances using the Standalone Node role as primary nodes. For more information, see Configuring a Primary Node.

Step 3

In the ShellAdmin console for one of the new primary nodes, restore the database that you backed up from the standalone node as follows:

1. Choose Stop Services to stop the Infrastructure Manager services.

2. Choose Restore Database.

3. Choose Start Services.

Step 4

In the ShellAdmin console, configure the two primary nodes as an HA pair.
Note:
You must configure the primary node on which the database was restored as the active node in the HA pair. If you configure it as the standby node, the database on that node will be deleted.

For more information, see Configuring HA.

Step 5

Configure service nodes for the cluster. For more information, see Configuring a Service Node.

Restoring a Database onto an Existing HA Pair

Cisco ICFPP enables you to configure an HA pair and then restore a database from an existing standalone node to the HA pair.

Note

You must stop and start services in the sequence presented in this procedure to restore the database on the HA pair successfully.

Before You Begin

- Back up the required database from a standalone node onto an FTP server.

- Identify the active node in the HA pair onto which you will restore the database from the standalone node.

- Confirm that the standalone node and both nodes in the HA pair are running the same version of Cisco ICFPP.

Procedure

Step 1

Stop the VIP service on the current standby node in the HA pair as follows:

1. Log in to the ShellAdmin console for the current standby node.

2. Choose the Setup HA option.

3. When asked if you want to reconfigure HA, enter Y.

4. Enter C to stop the VIP service.

5. Enter Y to confirm the action.

6. Press Enter to return to the ShellAdmin menu.

Step 2

Stop the VIP service on the current active node in the HA pair as follows:

1. Log in to the ShellAdmin console for the current active node.

2. Choose the Setup HA option.

3. When asked if you want to reconfigure HA, enter Y.

4. Enter C to stop the VIP service.

5. Enter Y to confirm the action.

6. Press Enter to return to the ShellAdmin menu.

Stopping the VIP service on the active node in an HA pair automatically stops the Infrastructure Manager services if they are running.

Step 3

On the active node in the HA pair, restore the database backup that was obtained from the standalone node as follows:

1. In the ShellAdmin console for the active node, choose Restore Database.

2. When prompted, enter the FTP server IP address and login credentials.

3. Enter the path and filename for the backed up database file on the FTP server.

4. Follow the onscreen prompts to complete the process.

Step 4

Restart the VIP service on the active node as follows:

1. In the ShellAdmin console for the active node, choose Setup HA.

2. When asked if you want to reconfigure HA, enter Y.

3. Enter D to start the VIP service.

4. Press Enter to return to the ShellAdmin menu.

Starting the VIP service on the active node in an HA pair automatically starts the Infrastructure Manager services on the active node.

Step 5

Restart the VIP service on the standby node in the HA pair as follows:

1. In the ShellAdmin console for the standby node, choose Setup HA.

2. When asked if you want to reconfigure HA, enter Y.

3. Enter D to start the VIP service.

4. Press Enter to return to the ShellAdmin menu.

Reconfiguring a Virtual IP Address

If you change a virtual IP address (VIP) for an HA pair or on a primary node that supports a service node, you must reconfigure VIP as follows:

- On both nodes in the HA configuration

- On any service nodes that communicate with the HA pair

- On any service node that has been configured to communicate with the primary node

Reconfiguring a VIP involves the following high-level tasks:

1. Stop the VIP service on the standby node in the HA pair.

If you reconfigure the VIP on the active node in an HA pair without first stopping the VIP service on the standby node, HA will automatically fail over to the standby node.

2. Reconfigure the VIP service on the active node in the HA pair.

3. Reconfigure the VIP service on the standby node in the HA pair.

4. Reconfigure the VIP address on service nodes that used the old VIP to communicate with either the HA pair or the primary node.

The following procedure describes how to perform these tasks.

Procedure

Step 1

Stop the VIP service on the standby node as follows:

1. Log in to the ShellAdmin console for the standby node.

2. Choose the Setup HA option.

3. When asked if you want to reconfigure HA, enter Y.

4. Enter C to stop the VIP service.

5. Enter Y to confirm the action.

6. Press Enter to return to the ShellAdmin menu.

Step 2

To reconfigure VIP service on the active node in the HA pair, complete the following steps:

1. Log in to the ShellAdmin console for the active node.

2. Choose the Setup HA option.

3. When asked if you want to reconfigure HA, enter Y.

4. To reconfigure VIP service, enter A.

5. When prompted, enter Y to reconfigure the VIP.

6. When prompted, enter the new VIP and confirm the entry.

Information similar to the following is displayed:

Proceed with setting up VIP as 123.45.1.25 ? [y/n]: y
*******************************************************
Updating Virtual IP Address
*******************************************************
Updating Keepalived configuration for Virtual IP...
Setting up new keepalived configuration for active node...
Setting up IP addresses in keepalived configuration for active node...
Stopping Virtual IP service, Keepalived...
Starting Keepalived...

Successfully reconfigured Virtual IP

Step 3

Reconfigure the VIP service on the standby node by completing the following steps:

1. In the ShellAdmin console for the standby node, choose Setup HA.

2. When asked if you want to reconfigure HA, enter Y.

3. To reconfigure VIP service, enter A.

4. Enter Y to confirm the action.

5. When prompted, enter the new VIP and confirm the entry.

Step 4

Reconfigure any service nodes that were using the previous VIP by completing the following steps:

1. In the ShellAdmin console for the service node, choose Reconfigure Node.

2. When asked if you want to change the node role, enter Y.

3. At the submenu prompt, enter A to reconfigure the service node.

4. When asked if you want to continue, enter Y.

5. When prompted for the IP address of the Primary Node, enter the new VIP address. Information similar to the following is displayed:

Configuring as Service Node...
Stopping services before changing node role
Stopping the services...
Setting up current node as ICFPP service node...with remote DB IP 123.45.1.25
Disabling Database service at startup

SUCCESS: Successfully changed node role to Service Node

Starting services that were previously stopped...
Starting the services...
In order for changes to take effect logout and login back
Do you want to logout [y/n]?

6. Enter Y to log out.

Reconfiguring a Service Node

If you change the IP address of a primary node or the VIP of an HA pair that a service node uses for database services, reconfigure the service node to use the updated IP address or VIP through the ShellAdmin console.

Procedure

Step 1

In the ShellAdmin console for the service node, choose the Reconfigure Node option.

Step 2

When asked if you want to change the node role to configure multi-node setup, enter Y.

Step 3

At the submenu prompt, enter A to reconfigure the node as a service node.

Step 4

When prompted, enter Y to continue.

Step 5

When prompted, enter the IP address of the primary node or the VIP of the HA pair that the service node uses for database access. Information similar to the following is displayed:

Configuring as Service Node...
Stopping services before changing node role
Stopping the services...
Setting up current node as ICFPP service node...with remote DB IP 123.45.1.30
Disabling Database service at startup

SUCCESS: Successfully changed node role to Service Node

Starting services that were previously stopped...
Starting the services...
In order for changes to take effect logout and login back
Do you want to logout [y/n]?

Step 6

Enter Y to log out. You are logged out and the changes are applied. If you are also logged into the Cisco ICFPP GUI, you are logged out from the GUI as well. Logging back in can take a minute or two while Cisco ICFPP is reconfigured.

Reconfiguring HA

You can reconfigure an HA setup by using the ShellAdmin console.

When reconfiguring HA:

- You must reconfigure both the active and standby nodes for HA.

- Reconfiguring HA will restart all services for the current HA setup, including VIP and the database, which will disrupt service nodes.

- The database on the node that you specify as the standby node in this procedure will be deleted and will replicate the contents of the database on the node that you specify as the active node.

Procedure

Step 1

Log into the ShellAdmin console of the active or standby node in the HA pair.

Step 2

At the ShellAdmin prompt, choose the Setup HA option. Cisco ICFPP displays a message stating that HA is already configured on the node, provides additional information about the HA pair, and asks if you want to reconfigure HA on the node.

Step 3

Enter Y to reconfigure HA. The HA reconfiguration submenu is displayed.

Step 4

Enter B to reconfigure the HA setup. Cisco ICFPP displays informational messages and asks if you want to continue with the reconfiguration.

Step 5

Enter Y to continue. Information similar to the following is displayed:

NOTE: The DB contents of the node being configured as the Standby node will be deleted and
the Standby node DB will replicate the contents of the node configured as Active.

Do you want to change this node to configure HA [y/n]?

Step 6

Enter Y to configure HA on the current node.

Step 7

At the submenu prompt, enter A to configure the node as the active node or B to configure the node as the standby node.

Step 8

Enter Y to continue. Cisco ICFPP detects and displays the IP address of the current node.

Step 9

Enter Y to confirm the node IP address.

Step 10

Enter the IP address for the other node in the HA pair.

Step 11

Enter the VIP to use for the IP pair. Information similar to the following is displayed:

-------------------------------------------------
HA Configuration information:
-------------------------------------------------
This node will be configured as active node
Active Node IP address:  123.45.1.30
Standby Node IP address: 123.45.1.32
Virtual IP address:      123.45.1.25
-------------------------------------------------
Proceed with setting up HA with above configuration [y/n]:

Step 12

Enter Y to continue.

Step 13

While Cisco ICFPP is configuring the current node for HA, configure the other node in this HA pair by choosing the Setup HA option in the ShellAdmin menu and repeating the steps in this procedure. Cisco ICFPP displays progress messages as it configures the nodes for HA and synchronizes the databases on both nodes.

Step 14

When prompted, press Enter to return to the ShellAdmin menu.

Viewing HA Syslog Messages

After configuring Cisco ICFPP for HA, Cisco ICFPP checks HA status every five minutes. Any warning or failure messages that are issued are included in the log file for syslog messages. This log file commonly resides in /var/log/ with the name messages. To view these messages, log in as root and use a text editor as described in this procedure.

Procedure

Step 1

In the ShellAdmin console, choose the Log in as Root option.

Step 2

Enter Y to confirm the login request, and enter the root account password at the prompt.

Step 3

Enter the following command to view the contents of the log file:

vi /directory-path/filename

where directory-path is location of the log file and filename is the name of the log file. For example, you might enter the following:

vi /var/log/messages

Step 4

To identify messages that pertain to HA, look for entries that contain the string ICFPP HA as shown in the following example:

Mar 13 03:27:13 localhost logger: ICFPP HA: MySQL replication from 123.45.67.8 to 123.45.67.9 is in WARN state
Mar 13 03:27:13 localhost logger: ICFPP HA: Please use shelladmin to check HA status details
Mar 13 03:27:13 localhost logger: ICFPP HA: MySQL replication from 122.33.44.5 to 122.33.44.6 is in WARN state
Mar 13 03:27:13 localhost logger: ICFPP HA: Please use shelladmin to check HA status details

Step 5

Address any HA-related messages as indicated.

Working with Databases

You can enable, start, stop, back up, and restore a database.

- Starting the Database

- Stopping the Database

- Backing Up the Database

- Restoring the Database

Starting the Database

You can start the mysql daemon (mysqld) by choosing the Start Database option.

Note

This option starts the appliance database only.

Procedure

Step 1

In the ShellAdmin console, choose the Start Database option.
Information similar to the following is displayed:

Starting database.....
directory (/var/lib/mysql/data/confmgr_production) exists
directory (/var/lib/mysql/data/db_private_admin) exists
the file (/var/lib/mysql/data/ib_logfile1) exists
the file (/var/lib/mysql/data/ib_logfile0) exists
the file (/var/lib/mysql/data/ibdata1) exists
Database started
Press return to continue ...130917 10:10:54 mysqld_safe Logging to '/var/log/mysqld.log'.
130917 10:10:54 mysqld_safe Starting mysqld daemon with databaes from /var/lib/mysql/data

Step 2

Choose the Start Services option to start the Cisco services.

Stopping the Database

You can halt the mysql daemon (mysqld) by choosing the Stop Database option. This option stops all of the following Cisco services:

- Broker

- Controller

- Eventmgr

- Client

- Idaccessmgr

- Inframgr

- Tomcat

- Websock

Procedure

Step 1

From the Intercloud Fabric Provider Platform Shell menu, choose the Stop Database option.
The following information is displayed:

Do you want to stop the database [y/n]?  y
Stopping database....
Database stopped....
Stopping broker [PID=21921]/[Child=21923]
Stopping controller [PID=21959]/[Child=21961]
Stopping eventmgr [PID=21993]/[Child=21995]
Stopping client [PID=22052]/[Child=22054
22101
22160]
Stopping idaccessmgr [PID=22099]/[Child=]
Stopping inframgr [PID=22158]/[Child=]
Tomcat is running with [PID=22213]. Stoping it and its child process
Flashpolicyd is running with [PID=22237]. Stopping it
Stopping websock[PID=22242]
Press return to continue ...

Step 2

Follow the onscreen prompts to complete the process by choosing the Start Database option.

Backing Up the Database

Cisco ICFPP enables you to back up the entire database of a Cisco ICFPP virtual appliance to an FTP server.

Before You Begin
Collect the following information:

- The IP address of the FTP server to use to back up the database

- The FTP server login credentials

Procedure

Step 1

Log in to the ShellAdmin console for the node with the database that is to be backed up.

Step 2

In the ShellAdmin console, stop Cisco services by choosing the Stop Services option.

Step 3

After the services have been stopped, choose Backup Database.
Information similar to the following is displayed:

Backing database......
Backup will Upload file to an FTP server. Provide the necessary access credentials

FTP Server IP Address:

Step 4

When prompted, enter the FTP server IP address and login credentials. The procedure for backing up the database onto the FTP server begins and progress messages report the status of the backup operation.

Step 5

When the backup operation has completed, restart services by choosing the Start Services option.

Restoring the Database

Cisco ICFPP enables you to restore a backed up database from an FTP server. After you provide the FTP IP address, login credentials, and file details, Cisco ICFPP restores the database on the current node.

Before You Begin
Gather the following information:

- IP address of the FTP server from which you will restore the database

- FTP server login credentials

- Absolute path and filename of the backed up database file

Procedure

Step 1

In the ShellAdmin console, choose the Stop Services option.

Step 2

After the services have stopped, choose the Restore Database option.
Information similar to the following is displayed:

Restore database......
Restore will recover file from an FTP server. Provide the necessary access credentials

FTP Server IP Address:

Step 3

At the prompts, enter the FTP server IP address, login credentials, and the absolute path and filename of the backed up database file.

Step 4

After the database has been restored, choose the Start Services option to restart the Cisco services.

Accessing Root Privileges

Tasks that require root privileges include moving directories or files into other directories, providing or revoking user privileges, general system repairs, and occasionally installing applications.

Note

For security reasons, we recommend that you do not compile software as root.

- Enabling Root Access

- Configuring Root Access

- Disabling Root Access

- Logging in as Root

Enabling Root Access

You can enable root privileges by using the ShellAdmin console.

Procedure

Step 1

In the ShellAdmin console, choose the Manage Root Access option.
Information similar to the following is displayed:

Enable/Disable/Configure (root privalege) [e/d/c]:

Step 2

Enter E and press Enter. Information similar to the following is displayed:

Do you want to Enable Root Access [y/n]? :

Step 3

Enter Y and press Enter.
Information similar to the following is displayed:

Enabling root access...
Unlocking password for user root.
passwd: Success.
Root access enabled successfully
Press return to continue

Step 4

Press Enter to return to the ShellAdmin menu.

Configuring Root Access

You can configure root privileges in the ShellAdmin console.

Procedure

Step 1

In the ShellAdmin console, choose the Manage Root Access option.
Information similar to the following is displayed:

Enable/Disable/Configure (root privilege) [e/d/c]:

Step 2

Enter C to configure root access.
ShellAdmin console

Do you want to Configure/Set Root Privilege/Password [y/n]? :

Step 3

Enter Y set a new root password.
ShellAdmin console

Changing root password...
Changing password for user root.
New UNIX password:

Step 4

Enter the new root password and confirm it when prompted.
ShellAdmin console

passswd: all authentication tokens updated successfully.
Root passwd changed successfully
Press return to continue...

Step 5

Press Enter to return to the menu.

Disabling Root Access

You can disable root privileges by using the ShellAdmin console.

Procedure

Step 1

In the ShellAdmin console, choose the Manage Root Access option.
Information similar to the following is displayed:

Enable/Disable/Configure (root privalege) [e/d/c]:

Step 2

Enter D.
Information similar to the following is displayed:

Do you want to Disable Root Access [y/n]? :

Step 3

Enter Y.
Information similar to the following is displayed:

disabling root access...
Locking password for user root.
Passwd: Success
Root access disabled sucessfully
Press return to continue...

Step 4

Press Enter to return to the main menu.

Logging in as Root

You can log in as root from the ShellAdmin console.

Procedure

Step 1

From the ShellAdmin console, choose the Login As Root option.
Information similar to the following is displayed:

Do you want to Login As Root [y/n]? :

Step 2

Enter Y.
Information similar to the following is displayed:

Logging in as root
password:

Step 3

Enter the root password.
Information similar to the following is displayed:

Logging as root
Password:
[root@localhost shelladmin]#

Step 4

To log out, enter exit.
Information similar to the following is displayed:

[root@localhost shelladmin]# exit
exit
Successful logout
Press return to continue ...

Step 5

Press Enter to return to the ShellAdmin console.

Chapter 3. Using the Cisco ICFPP GUI

- Common Administrative Tasks

- Managing Cloud Instances

- Managing Tenants

Common Administrative Tasks

Cisco ICFPP enables you to perform a number of common administrative tasks via the GUI, such as managing Cisco ICFPP licenses, monitoring tasks, and accessing reports and logs.

- Configuring Syslog Servers

- Importing a JKS Certificate File

- Installing an Adapter

- Upgrading Cisco ICFPP

- Managing Licenses

- Monitoring Tasks

- Obtaining Logs

- Generating Reports

Configuring Syslog Servers

You can configure Cisco ICFPP so that it forwards log messages to a server instead of recording them in a local file or displaying them.

Procedure

Step 1

Choose Administration > System, and click the Syslog tab.

Step 2

Check the Enable Syslog Forward check box.

Step 3

In the Minimum Severity drop-down list, choose the minimum severity of the messages that are to be forwarded to the server. For example, if you choose Minor, messages with the severity Minor or Major will be forwarded to the server. If you choose Major, only messages with the severity Major will be forwarded to the server.

Step 4

Provide the following information for both the primary and secondary syslog server, and then click Save:

Field

Description

Server Address

IP address of the syslog server.

Protocol

Protocol to be used for the messages (read-only).

Importing a JKS Certificate File

Cisco ICFPP enables you to import a Java KeyStore (JKS) file, which is a repository of certification authority (CA) security certificates used in SSL encryption.

Procedure

Step 1

In the Cisco ICFPP GUI, choose Administration > System and click the Certificate Setup tab.

Step 2

Click Upload.

Step 3

In the Upload Certificate in JKS Format dialog box, in the Keystore File field, browse to and choose the JKS file.

Step 4

Click Upload.

Step 5

After the file has uploaded, enter the password in the Keystore Password field and click Submit.

Installing an Adapter

You can use the GUI to install (add) or update an adapter.

Procedure

Step 1

Log in to the Cisco ICFPP GUI.

Step 2

Choose Install.

Step 3

In the Adapters pane, click Install.

Step 4

In the Install Adapter dialog box, complete the following fields:

Field

Description

Adapter Type

Choose the adapter type: Cisco or Custom.

Adapter Name

The name of the adapter. If you chose CISCO as the adapter type, this field defaults to CAPI and cannot be edited.

Adapter Description

The description of the adapter.

Adapter File

The adapter file to use for this adapter. Browse to the required adapter file and click Open.

Step 5

Click Upload. The file is uploaded to Cisco ICFPP.

Step 6

After the upload is complete, click Submit.

Upgrading Cisco ICFPP

Cisco ICFPP enables you to upgrade standalone appliances and multiple-node clusters for bug fixes and updated adapters. For more information, see the following topics:

- Upgrading a Standalone Node

- Upgrading a Multiple-Node Cluster

- Upgrading a Standalone Node

- Upgrading a Multiple-Node Cluster

Upgrading a Standalone Node

Cisco ICFPP provides an upgrade mechanism that allows for Cisco bug fixes and upgrading adapters. Upgrading Cisco ICFPP to a newer version is similar to upgrading a custom adapter.

The procedures for upgrading a standalone node and a multiple-node cluster are different. For information on upgrading a multiple-node cluster, see Upgrading a Multiple-Node Cluster.

Before You Begin

- Obtain the Cisco ICFPP upgrade file (icfpp-upgrade-2.2.1.tar.gz) from cisco.com. For assistance, contact your Cisco representative.

- Confirm that the upgrade file is accessible from the Cisco ICFPP virtual appliance.

Procedure

Step 1

In the Cisco ICFPP GUI, choose Install > Adapters, and click Install.

Step 2

In the Install Adapter dialog box, enter the following information:

Field

Description

Adapter Type

Choose Cisco.

Adapter Name

This field displays CAPI by default. No input is required.

Adapter Description

Enter the desired description.

Adapter File

Browse to the Cisco ICFPP upgrade file and click Open.

Step 3

Click Upload.

Step 4

After the unload is complete, click Submit.

Step 5

Using SSH, log in to the ShellAdmin console for the virtual appliance.

Step 6

Choose the Stop Services option.

Step 7

Choose the Start Services option. Cisco ICFPP is upgraded to the new version, and updated version information is displayed in the Adapters tab in the GUI.

Upgrading a Multiple-Node Cluster

This procedure describes how to upgrade a multiple-node cluster for bug fixes and updated adapters. For information on upgrading a standalone (single-node) Cisco ICFPP virtual appliance, see Upgrading a Standalone Node.

The high-level tasks involved in upgrading a cluster are:

1. Upgrading the HA primary active node.

2. Stopping the virtual IP services on the upgraded primary active node.

3. Monitoring status as services fail over to the primary standby node.

4. Upgrading the HA primary standby node.

5. Stopping the virtual IP services on the upgraded primary standby node.

6. Starting the virtual IP services on the primary active node.

7. Starting the virtual IP services on the primary secondary node.

8. Upgrading and restarting Infra services for each service node.

The following procedure describes how to perform these tasks.

Before You Begin

- Obtain the Cisco ICFPP upgrade file (icfpp-upgrade-2.2.1.tar.gz) from cisco.com. For assistance, contact your Cisco representative.

- Ensure that the upgrade file is accessible from the Cisco ICFPP appliance.

Procedure

Step 1

Using the node management IP address (instead of the virtual IP address for the HA pair), log in to the Cisco ICFPP GUI for the primary active node in the HA pair.

Step 2

Upgrade the primary active node as follows:

1. Choose Install > Adapters > Install.

2. In the Install Adapter dialog box, provide the required information.
For more information about the fields in this dialog box, see Upgrading a Standalone Node.

3. Click Upload.

4. After the upload is complete, click Submit.

Note:
Do NOT restart Infra services after upgrading the primary active node.

Step 3

Log in to the ShellAdmin console for the primary active node that was upgraded in Step 2.

Step 4

In the ShellAdmin console for the primary active node, stop the Virtual IP service as follows:

1. Choose the Setup HA option.

2. When asked if you want to reconfigure HA, enter Y.

3. Enter C to stop the VIP service.

4. Enter Y to confirm the action.

5. Press Enter to return to the ShellAdmin menu.

Step 5

Log in to the ShellAdmin console for the primary standby node for the HA pair.

Step 6

In the ShellAdmin console for the primary standby node, choose Display Services Status to monitor the following events as they occur:

- HA services fail over to the primary standby node in the HA pair.

- Infra services start running on the primary standby node.

- The primary standby GUI becomes available for logging in.
It can take a few minutes for the services to start and for the GUI of the primary standby node to be accessible from the browser.

Step 7

Using the node management IP address (instead of the virtual IP address for the HA pair), log in to the Cisco ICFPP GUI for the primary standby node.

Step 8

Upgrade the primary standby node by uploading and submitting the upgrade package as described in Step 2 of this procedure.
Note:
Do NOT restart Infra services after upgrading the primary standby node.

Step 9

In the ShellAdmin console for the primary standby node that was upgraded in Step 8, stop the Virtual IP service as described in Step 4 of this procedure.

Step 10

In the ShellAdmin console for the primary active node that was upgraded in Step 2, start the Virtual IP service as follows:

1. Choose the Setup HA option.

2. When asked if you want to reconfigure HA, enter Y.

3. Enter D to start the VIP service.

4. Press Enter to return to the ShellAdmin menu.

Step 11

In the ShellAdmin console for the primary standby node that was upgraded in Step 8, start the Virtual IP service as described in Step 10.

Step 12

For each service node in the cluster:

1. Log in to the Cisco ICFPP GUI for the service node.

2. Upgrade each service node by uploading and submitting the upgrade package as described in Step 2.

3. Using the ShellAdmin console, restart Infra services by first choosing the Stop Services option and then choosing the Start Services option.

Managing Licenses

Cisco ICFPP is installed with an evaluation license and support for 20 VMs. The topics in this section describe how to view license details and update a license.

- Updating a License

- Viewing License Details

Updating a License

To ensure continuous operation, update the Cisco ICFPP license before the current license expires.

Before You Begin
Confirm that the license file is accessible from Cisco ICFPP.

Procedure

Step 1

Choose Administration > License.

Step 2

In the License Keys tab, click Update License.

Step 3

In the Update License dialog box, do either of the following:

- Select a license file to upload:

1. Browse to and choose the license file.

2. Click Open.

3. Click Upload.

- Enter the license text:

1. Check the Enter License Text check box.

2. Copy the text of the license file and paste it into the License Text field.

Step 4

Click Submit.

Viewing License Details

After you install Cisco ICFPP, you can view license details at any time to confirm the term of the license, view the number of VMs supported, and obtain the license identifier.

Procedure

Step 1

In the Cisco ICFPP GUI, choose Administration > License.

Step 2

In the License Keys table, expand the required entry. The license details are displayed, including the expiration date, license identifier, and the number of supported VMs.

Monitoring Tasks

You can use the Cisco ICFPP GUI to monitor the tasks of the tenants.

Procedure

Step 1

Log in to the Cisco ICFPP GUI.

Step 2

Choose Tenants and then click the Tasks tab. The Tasks pane displays the details and status of all of the tasks for the tenants.

Obtaining Logs

You can use Cisco ICFPP logs to debug issues, collect system information, and review detailed information related to HA or cluster environments. For more information, see the following topics:

- Obtaining System Information

- Downloading Logs for HA and Cluster Environments

- Obtaining System Information

- Downloading Logs for HA and Cluster Environments

Obtaining System Information

Cisco ICFPP can provide general or detailed system information, and can assist in troubleshooting issues. This information can also be helpful if you need to contact Cisco for technical support.

Procedure

Step 1

In the Cisco ICFPP GUI, choose Administration > Support Information.

Step 2

From the Support Information drop-down list, choose the required option as described in the following table:

Option

Description

System Information (Basic)

Displays status for system services, the Cisco ICFPP license, and accounts and resource usage.

System Information (Advanced)

Displays detailed system information including system configuration, running processes, memory usage, processor details, and task status.

Show Log

Displays the log that you select:

- Infra Manager

- Web Context Cloud Manager

- Tomcat Log

- Authenticator Log

- Mail Delivery Log

- Patch Log

Download All Logs

Downloads a zipped file of all logs.

Debug Logging

Enables debug logging and records up to 30 minutes of activity.

Downloading Logs for HA and Cluster Environments

Cisco ICFPP enables you to download the following logs associated with HA and cluster environments:

- Infra Manager log

- MySQL log

- Apache Catalina log

- OpenAPI log

- Scalability log

- HA log

- Install log

- System messages log

If you select a log that is not applicable to your environment (for example, if you choose the HA log but HA is not configured in your environment), Cisco ICFPP will generate and download all logs except the one that does not apply.

Procedure

Step 1

In the Cisco ICFPP GUI, choose Administration > System, and click the Logs tab.

Step 2

Check the check box for each log that you want to download, and click Download. A zipped file containing all requested logs is downloaded to your system.

Generating Reports

Cisco ICFPP reports are available from the GUI in three formats: Tabular, Historical, or Snapshot. Cisco ICFPP dynamically updates the lists of the reports that are available to you and provides graphic renderings of each type of report. For each context, a different set of reports (each identified by a reportId) is available.

The available reports are:

- Tenant report

- Cloud instance report

- Virtual machine report

- Adapters report

- Faults report

- System tasks report

To generate a report:

Procedure

Step 1

In the Cisco ICFPP GUI, navigate to the required object type. For example, to generate a VM report, you would choose Tenants > All Tenants, and click the VM tab.

Step 2

In the toolbar, click Export Report.

Step 3

In the Export Report dialog box, choose the required report format (PDF, CSV, or XLS) and click Generate Report.

Step 4

After the report has been generated, click Download.

Managing Cloud Instances

A cloud instance has a unique identifier that ties the back-end cloud URI with a southbound adapter that is installed by the service provider. Multiple back-end URIs should have multiple cloud instances. A tenant is part of only one cloud instance. You can manage cloud instances by using the Cisco ICFPP GUI.

- Adding a Cloud Instance

- Viewing a Cloud Instance's Details

- Editing a Cloud Instance

- Deleting a Cloud Instance

Adding a Cloud Instance

You can use the Cisco ICFPP GUI to add (provision) a cloud instance.

Procedure

Step 1

In the Cisco ICFPP, choose Cloud Instances.

Step 2

In the Cloud Instances pane, click Add.

Step 3

In the Add Cloud Instance dialog box, provide the following information, and then click Add:

Field

Description

Cloud Instance Name

The name of the cloud instance.

Type

The cloud instance type: Cisco or Custom.

Module Name

For a CISCO cloud instance type, choose the module name, such as OSP for OpenStack.

For a CUSTOM cloud instance type, enter the custom module name.

Image Conversion Support on Cloud

Displayed for OSP modules only.

Indicate whether or not image conversion on the cloud is required.

FTP Server Name

For Dimension Data (DiData) modules only, the name of the FTP server.

Endpoint URI

The endpoint URI for the cloud instance.

Viewing a Cloud Instance's Details

You can use the Cisco Intercloud Fabric Provider Platform (ICFPP) GUI to view a cloud instance's details.

Procedure

Step 1

Log in to the ICFPP.

Step 2

Choose Cloud Instances.

Step 3

In the Cloud Instances pane, choose a cloud instance.

Step 4

Click View.
The Cloud Instance Details dialog box appears, which contains the details of the cloud instance.

Step 5

Click Close.

Editing a Cloud Instance

You can use the Cisco ICFPP GUI to edit (update) a cloud instance.

To edit a cloud instance using the APIs, see Update Cloud Instance.

Procedure

Step 1

In the ICFPP GUI, choose Cloud Instances.

Step 2

In the Cloud Instances pane, choose a cloud instance and click Edit.

Step 3

In the Edit Cloud Instance dialog box, update the information as needed and click Save:

Field

Description

Cloud Instance Name

The name of the cloud instance (read-only).

Type

The cloud instance type (read-only).

Image Conversion Support on Cloud

Displayed for custom cloud instance types only.

Indicate whether or not image conversion on the cloud is required.

Module Name

The module name (read-only).

FTP Server Name

For Dimension Data modules only, the FTP server name.

Endpoint URI

The endpoint uniform resource identifier (URI) for the cloud instance.

Deleting a Cloud Instance

You can use the Cisco Intercloud Fabric Provider Platform (ICFPP) GUI to delete a cloud instance.

To delete a cloud instance using the APIs, see Delete Cloud Instance.

Procedure

Step 1

Log in to the ICFPP.

Step 2

Choose Cloud Instances.

Step 3

In the Cloud Instances pane, choose a cloud instance.

Step 4

Click Delete.

Step 5

In the Delete Cloud Instance dialog box, click Delete.

Managing Tenants

You can manage tenants by using the Cisco Intercloud Fabric Provider Platform (ICFPP) GUI.

- Adding a Tenant

- Viewing a Tenant's Details

- Editing a Tenant

- Deleting a Tenant

- Monitoring Tenants

Adding a Tenant

After you create a cloud instance, you can add (provision) a tenant on the cloud.

For a CloudStack cloud instance, you must obtain the API Key and Secret Key for the tenant before adding the tenant. After the tenant is created, Cisco ICFPP generates a Pass Key, which is available in the View Tenant dialog box (Tenants > All Tenants > tenant > View). This Pass Key is required by Cisco Intercloud Fabric Director when configuring a cloud. For more information, see the Cisco Intercloud Fabric User Guide.

Before You Begin
Confirm the following:

- A cloud has been created to which the tenant can be assigned.

- For a VMware vCloud Director cloud instance, you have the name of the organization for the tenant. For more information, see the VMware vCloud Director documentation.

- For a CloudStack cloud instance, you have the API Key and Secret Key for the tenant. For more information, see the Apache Cloudstack documentation.

Procedure

Step 1

In the Cisco ICFPP GUI, choose Tenants and click the Accounts tab.

Step 2

Click Add.

Step 3

In the Add Tenant dialog box, provide the information as described in the following table, and then click Add:

Field

Description

Tenant Name

Enter the tenant name.

Note:
You cannot change this entry after the tenant is added.

Cloud Instance Name

Choose the name of the cloud instance.

Note:
You cannot change this entry after the tenant is added.

Enable Tenant Account

Enabled

The account is enabled by default (read-only).

Org Name

For VMware vCloud Director clouds only, enter the name of the organization to which the tenant belongs.

Resource Limits

Max Servers

The maximum number of servers provisioned for the tenant, including stopped VMs.

User Account

Username

The account username.

Email

The email address for the account.

API Key

For CloudStack clouds only, enter the API key for the tenant.

Secret Key

For CloudStack clouds only, enter the Secret key for the tenant.

Viewing a Tenant's Details

You can use the Cisco Intercloud Fabric Provider Platform (ICFPP) GUI to view a tenant's details.

To view a tenant's details using the APIs, see Get Tenant Details.

Procedure

Step 1

Log in to the ICFPP.

Step 2

Choose Tenants.

Step 3

Click the Accounts tab.

Step 4

In the Accounts pane, choose a tenant.

Step 5

Click View.
The Tenant Details dialog box appears, which contains the details of the tenant.

Step 6

Click Close.

Editing a Tenant

You can edit existing tenants as needed by using the Cisco ICFPP GUI.

Procedure

Step 1

In the Cisco ICFPP GUI, choose Tenants and click the Accounts tab.

Step 2

In the Accounts pane, choose a tenant and click Edit.

Step 3

In the Edit Tenant dialog box, update the information as needed, and then click Save:

Field

Description

Tenant Name

The name of the tenant (read-only).

Cloud Instance Name

The name of the cloud instance (read-only).

Enable Tenant Account

Enable

Check the check box to enable the account, or uncheck the check box to disable the account.

Org Name

For VMware vCloud Director clouds only, the name of the organization to which the tenant belongs (read-only).

Resource Limits

Max Servers

The maximum number of servers provisioned for the tenant, including stopped VMs.

User Account

Username

The account username (read-only).

Email

The account email address.

API Key

For CloudStack clouds only, the API Key for the tenant.

Secret Key

For CloudStack clouds only, the Secret Key for the tenant.

Deleting a Tenant

You can use the Cisco ICFPP GUI to delete a tenant.

To delete a tenant using the APIs, see Delete Tenant.

Procedure

Step 1

Log in to the Cisco ICFPP GUI.

Step 2

Choose Tenants and then click the Accounts tab.

Step 3

Choose the tenant that you want to delete, and then click Delete.

Step 4

In the Delete Tenant dialog box:

1. Do one of the following:

- Check the Purge check box to remove all tenant resources from the database. If you choose this option, the tenant will be removed from the database and the GUI.

- Uncheck the Purge check box to retain the tenant resources in the database. If you choose this option, the tenant will be visible in the GUI with a state of Deleted and the tenant's resources will remain in the database.

2. Click Delete.

Monitoring Tenants

You can use the Cisco ICFPP GUI to monitor tenants' VMs.

Procedure

Step 1

Log in to the Cisco ICFPP GUI.

Step 2

Choose Tenants and then click the VM tab. The VM pane displays the details and status of all VMs for the tenants.

Chapter 4. Cisco ICFPP Architecture

- Architecture Overview

- Northbound Cisco Intercloud Fabric Cloud APIs

- Northbound Cisco Intercloud Fabric Provider APIs

- Core Application Logic Module

- Southbound Cloud Adapter Layer

Architecture Overview

Cisco ICFPP, which is a virtual appliance that is deployed on the service provider cloud data center, enables service provider customers to access cloud resources using Cisco Intercloud Fabric APIs. The virtual appliance provides a virtual network interface that enables a customer's Cisco Intercloud Fabric Director to reach the Cisco ICFPP appliance instance from public networks. The following figure shows the Cisco ICFPP appliance architecture.

Cisco ICFPP Appliance Architecture

The ICFPP architecture includes four major interfacing modules:

Module

Description

Northbound Cisco Intercloud Fabric Cloud API

Implements the Cisco Intercloud Fabric Cloud API, which is consumed by the Cloud API translations (customer private cloud) for workload provisioning purposes.

Northbound Cisco Intercloud Fabric Provider API

Implements two sets of APIs for the service provider administrator to use to:

- Configure the virtual appliance

- Provision tenants and resources assigned to the tenant

- Monitor tenant operations

- Retrieve statistics for tenants and the virtual appliance.

Core Application Logic

Implements the main application logic of ICFPP, such as Cloud API translations.

Southbound Cloud Adapter Layer

Implements the various cloud platform interfacing adapters, each of which is responsible for interfacing with a specific cloud platform, such as the Cisco Hybrid Cloud Bundle – in partnership with Dimension Data.

Northbound Cisco Intercloud Fabric Cloud APIs

The northbound Cisco Intercloud Fabric module uses Representational State Transfer (REST) APIs that are consumed by the Cisco Intercloud Fabric (customer private cloud) for provisioning workloads and managing workload images and templates.

Northbound Cisco Intercloud Fabric Provider APIs

A service provider administrator uses the northbound Cisco Intercloud Fabric provider APIs to configure and manage the Cisco ICFPP virtual appliance. These APIs belong to the following categories:

- Cloud instance management APIs

- Tenant management APIs

- Remote syslog configuration APIs

- Logging APIs

For details on these APIs, see Service Provider APIs.

Cloud Instance Management API

The following table identifies the cloud instance management APIs:

Category

HTTP Method

Request URL

Request Header / Body

Response Body

Comments

Cloud Instance Management

POST

/capi/v1/cloudinstances

API session key, cloud instance

Cloud instance ID

Creates a new cloud instance.

PUT

/capi/v1/cloudinstances/ cloudID

API session key, cloud instance ID

Cloud instance ID

Updates an existing cloud instance.

GET

/capi/v1/cloudinstances/ cloudID

API session key, cloud instance ID, cloud credentials

Cloud record

Gets a cloud record.

GET

/capi/v1/cloudinstances

API session key

Cloud record

Gets all cloud records in the database.

DELETE

/capi/v1/cloudinstances/ cloudID

API session key, cloud instance ID

Cloud record

Deletes a cloud instance.

Tenant Management API

The following table identifies the tenant management APIs:

Category

HTTP Method

Request URL

Request Header / Body

Response Body

Comments

Tenant Management

POST

/capi/v1/tenants

API session key, tenant record (such as name and resource limits)

Tenant ID

Provisions a new tenant record.

PUT

/capi/v1/tenants/ tenantID

API session key, tenant ID

Tenant ID

Updates an existing tenant record.

GET

/capi/v1/tenants/ tenantID

Tenant ID

Tenant record

Gets a tenant record.

GET

/capi/v1/tenants/ tenantID/details

API session key, tenant ID

Tenant record

Gets the details of a tenant.

GET

/capi/v1/tenants

API session key

Tenant record

Gets all tenant records in the database.

DELETE

/capi/v1/tenants/ tenantID

API session key, tenant ID

Tenant record

Deletes a tenant.

DELETE

/capi/v1/tenants/ tenantID/purge

API session key, tenant ID

Tenant record

Deletes a tenant and all of its resources from the database.

GET

/capi/v1/servers/ serverID

API session key, server ID

Server record

Gets a server record.

Many APIs can be used with other troubleshooting tools to build diagnostic suites that a service provider administrator can use to debug appliance-level and tenant-level problems.

Remote Syslog Configuration APIs

Category

HTTP Method

Request URL

Request Header / Body

Response Body

Comments

Remote Syslog Configuration

POST

/capi/v1/logs/syslogconfig

API session key, log level, remote syslog server

Syslog server configuration

Configures the remote syslog server in Cisco ICFPP.

GET

/capi/v1/logs/syslogconfig

API session key

Syslog server configuration

Retrieves the remote syslog server from Cisco ICFPP.

Logging APIs

Category

HTTP Method

Request URL

Request Header / Body

Response Body

Comments

Logging

GET

/capi/v1/logs/current

API session key

Zipped file of current logs

Downloads the current logs in a zipped file.

GET

/capi/v1/logs/all

API session key

Zipped file of all logs

Downloads all logs in a zipped file.

Many APIs can be used with other troubleshooting tools to build diagnostic suites that a service provider administrator can use to debug appliance-level and tenant-level problems.

Core Application Logic Module

The core application logic module handles the following functions:

Function

Description

Intercloud cloud API back-end processing

The back end of Intercloud cloud API processing. Based on the cloud platform type that is configured for the tenant, this function calls the appropriate cloud adapter function for fulfilling the cloud orchestration requests that are issued by Cisco Intercloud Fabric Director (ICFD).

Cloud instance and tenant provisioning

Creates and manages cloud platform instance records and tenant records.

Tenant resource usage limit enforcing

Enforces the usage limit based on per-tenant resource usage limits, such as the number of virtual machines, that the provider administrator has configured for a tenant.

Tenant resource usage metering

Collects all relevant resource usage rates for usage-metering applications, based on cloud resource allocation and provisioning requests and responses.

Tenant resource monitoring

Issues relevant cloud platform API requests for resource monitoring purposes. The service provider can use the relevant northbound APIs to retrieve the resource monitoring status on demand.

Southbound Cloud Adapter Layer

The southbound cloud adapter layer implements cloud adapters that communicate with cloud platforms to provision workloads and orchestrate cloud infrastructures. The Cisco ICFPP cloud adapter layer defines APIs that are to be implemented by the cloud platforms.

Cisco ICFPP supports built-in cloud adapters that facilitate the integration with the following cloud platforms in the service provider's environment:

- VMware vCloud Director

- Cisco Hybrid Cloud Bundle – in partnership with Dimension Data

- CloudStack

- OpenStack

The service providers who use these cloud platforms can use these built-in cloud adapters. Service providers who use other cloud platforms must build platform-specific adapters for Cisco ICFPP to work the targeted cloud platforms. To facilitate the cloud adapter development, Cisco's Custom Cloud Adapter Integration framework simplifies cloud adapter development for service provider customers.

Cloud adapters must issue one or more API requests to the targeted cloud platforms and expect an asynchronous event when they receive corresponding API responses from the cloud platforms. The following figure shows the logical flow of the Cisco ICFPP cloud adapter infrastructure when it is shared between built-in and custom adapters.

Cisco ICFPP Cloud Adapter Integration

Chapter 5. Southbound Cloud Adapter Framework

- Creating Custom Cloud Adapters

- Custom Cloud Adapter Programming Model

- Installing or Upgrading an Adapter

- Validating an Adapter

Creating Custom Cloud Adapters

Service developers and service provider customers can create their own custom cloud adapters for use with Cisco ICFPP by using the Cisco ICFPP developer guidelines. These guidelines ensure that any custom cloud adapter will work seamlessly with Cisco ICFPP. To obtain a copy of the guidelines, contact your Cisco representative.

Custom Cloud Adapter Programming Model

After a custom cloud adapter is developed, customers can load the adapter code into Cisco ICFPP and enable the cloud adapter functions for the targeted tenants as described in the following workflow:

1. Service provider developers download the cloud adapter SDK from www.cisco.com to develop a custom cloud adapter. For assistance, contact your Cisco representative.

2. When the customer cloud adapter code is ready to use, the developer loads the adapter package using the Cisco ICFPP GUI.

3. The service provider administrator uses the cloudinstances API to create a new instance for the custom adapter. In the Cloud Instance Provision API request, the service provider administrator enters the name of the southbound adapter in the Cloud Module field. The name must be the same name that is used in the service interface API implementation. The API binds the adapter code with the cloud instance to be added.

4. When a service provider administrator provisions a tenant on the Cisco ICFPP platform using the tenant management API, the service provider administrator can bind the tenant with the cloud instance created in the previous step.

5. When the tenant issues Cisco Intercloud Fabric cloud API requests with a Cisco Intercloud Fabric Director instance, the API requests are handled by the newly added cloud adapter code.

The following figure illustrates how custom cloud adapter code can be loaded into Cisco ICFPP and be used to process incoming Cisco Intercloud Fabric cloud API requests that are issued by a tenant.

Cisco ICFPP Programming Model Overview

The following tables summarize the current southbound API stub functions that are supported in the cloud adapter classes.

Management Session Interface API

Class API Category

API Name

Input Parameters

Output Parameters

Comments

Management Session Interface

createClientSession

CapiTenantAccountVO account

Session ID

Creates a management session with a cloud platform instance.

deleteClientSession

Session ID

Deletes a management session.

validateClientSession

CapiTenantAccountVO account

Validates a current management session.

Service Management Interface API

Class API Category

API Name

Input Parameters

Output Parameters

Comments

Service Management Interface

listCapabilities

Provider Capability

Lists the cloud platform capabilities.

listLocations

Location Details

Lists the locations or sites supported by the provider.

Network Management Interface API

Class API Category

API Name

Input Parameters

Output Parameters

Comments

listPublicIpAddress

CapiTenantAccountVO account

IP address List

Gets the list of public IP addresses.

Template Management Interface API

Class API Category

API Name

Input Parameters

Output Parameters

Comments

Template Management Interface API

createTemplate

CapiTenantAccountVO account, capiTemplate template

Template ID

Creates a template based on an image.

deleteTemplate

CapiTenantAccountVO account, Template ID

Deletes a template.

VM Management Interface API

Class API Category

API Name

Input Parameters

Output Parameters

Comments

VM Management Interface API

deployVirtualMachine

CapiTenantAccountVO account, capiServer server

capiServer server

Deploys a virtual machine based on the template ID.

destroyVirtualMachine

CapiTenantAccountVO account, Server ID

Destroys a virtual machine based on the server ID.

downloadVirtualMachine

CapiTenantAccountVO account, capiServer server, string diskId, capiVMAction vmAction

Downloads the VM disk from the cloud provider catalog toCisco ICFPP.

listVirtualMachine

CapiTenantAccountVO account, capiServer server

capiServer server

Lists all of the virtual machines that were instantiated by the tenant.

rebootVirtualMachine

CapiTenantAccountVO account, capiServer serverserver, capiAction actionType

Reboots a virtual machine based on the server.

startVirtualMachine

CapiTenantAccountVO account, capiServer server, capiAction actionType

Starts a virtual machine that was previously stopped.

stopVirtualMachine

CapiTenantAccountVO account, capiServer server, capiAction actionType

Stops a virtual machine.

updateVirtualMachine

CapiTenantAccountVO account, capiServer server

Updates attributes of a virtual machine, such as the IP address.

Virtual Private Cloud (VPC) Management Interface API

Class API Category

API Name

Input Parameters

Output Parameters

Comments

VPC Management Interface API

createVpc

CapiTenantAccountVO account, capiProviderVpcDetail model

capiProviderVpcDetails vpcdetails

Creates a provider VPC.

createVpcNetwork

CapiTenantAccountVO account, capiProviderVpcNetwork networkModel, capiProviderVpcDetails model

capiProviderVpcNetwork networkModel

Creates a VPC network.

deleteVpc

CapiTenantAccountVO account, vpcId

Deletes a VPC.

deleteVpcNetwork

CapiTenantAccountVO account, vpcId, networkId

Deletes a network from a VPC.

listProviderVpc

CapiTenantAccountVO account

Lists the VPCs of a tenant.

listVpcById

CapiTenantAccountVO account, vpcId

Lists the specified VPC of a tenant.

listVpcNetworkById

CapiTenantAccountVO account, vpcId, networkId

Lists a network of a VPC from a tenant.

updateVpc

CapiTenantAccountVO account, capiProviderVpcDetail model

Updates a VPC.

Installing or Upgrading an Adapter

You can install or upgrade an adapter by using this procedure.

Before You Begin
Confirm that the adapter file is:

- Accessible from the Cisco ICFPP virtual appliance.

- A .tar.gz file.

Procedure

Step 1

Log in to the Cisco ICFPP GUI as an administrator.

Step 2

Choose Install > Adapters and click Install.

Step 3

In the Install Adapter dialog box, provide the required information and select the adapter file.

Step 4

Click Upload.

Step 5

After the file is uploaded, click Submit.

Step 6

Using SSH, log in to the ShellAdmin console for the virtual appliance as the shelladmin user.

Step 7

Choose the Stop Services option.

Step 8

Choose the Start Services option.

Validating an Adapter

You can validate whether an adapter was installed or upgraded successfully by choosing Install > Adapters in the Cisco ICFPP GUI. The Adapters table lists all installed adapters, the version currently installed, the creation date, and the date that the adapter was last updated.

Chapter 6. Service Provider APIs

- Supported Protocols and Formats

- Recommended Tools

- Login

- Cloud Instance Management APIs

- Tenant Management APIs

- Remote Syslog Configuration APIs

- Logging APIs

Supported Protocols and Formats

The Cisco ICFPP APIs are compatible with any HTTPS browser. The APIs use code formatted in XML.

For information about using XML-formatted Representational State Transfer (REST) API requests, see Installing or Upgrading an Adapter.

Recommended Tools

The Cisco ICFPP APIs use HTTPS. Any compatible browser or client with a user account access can be used to submit requests to the Cisco ICFPP API. Most programming languages have built-in or open source libraries that provide REST API access and parsing of XML.

To test the APIs, we recommend that you use the Mozilla Firefox RESTClient add-on. The RESTClient is a Mozilla FireFox add-on that provides useful options for parsing and viewing API requests and responses. See Click Here , although you should check for more recent releases.

Login

Description

Enables a user to log in to Cisco ICFPP. Use an administrator account to provision a tenant and cloud.

Resource URL

URL Type

Value

Resource URL

/capi/v1/login

Sample URL

https://myserver/capi/v1/login

HTTP Methods

Method

Description

POST

Allows a user to log in to Cisco ICFPP and returns the session key value pair that is used to form the header for subsequent requests.

Request Body

<GetKeys username='admin' password='abc123' expiration='90' />

Response

Status

Response

200

User is authenticated.

<GetKeys status="valid" value="A6665E4664FD416EA903774A5103D760" name="X-Capi-Request" username="admin" />

400

Invalid input.

403

Account login failed.

500

Internal server error.

Request Details

Tag

Attribute

Description

Format

Presence

GetKeys

username

Use "admin" for the username to log in through an administrator account. This is used only for the service provider APIs.

Use "username@tenant" to log in through a tenant account.

The tenant username is the same string that was provisioned by the service provider. This username is expected to be passed by the service provider to the Intercloud Fabric administrator on the customer portal.

String

Mandatory

password

The password that is associated with the specified account.

String

Mandatory

expiration

The time in minutes after which a new key must be requested. The maximum allowed expiration time is 120 minutes.

String

Mandatory

Cloud Instance Management APIs

A cloud instance is a unique identifier that ties the back-end cloud URI with a southbound adapter that is installed by the service provider. Multiple back-end URIs should have multiple cloud instances. A tenant is part of only one cloud instance. The Cisco Intercloud Fabric Provider Platform (ICFPP) provides APIs that can manage cloud instances.

- Provision Cloud Instance

- Update Cloud Instance

- Get Cloud Instance

- Get All Cloud Instances

- Delete Cloud Instance

Provision Cloud Instance

Description

Provisions (adds) a cloud instance. The caller must save the response cloud instance ID to make subsequent modifications to the cloud instance, such as a URI change.

To provision a cloud instance using the GUI, see Adding a Cloud Instance.

Resource URL

URL Type

Value

Resource URL

/capi/v1/cloudinstances

Sample URL

https://myserver/capi/v1/cloudinstances

HTTP Methods

Method

Description

POST

Creates a new cloud instance.

HTTP Headers

Header Name

Value

Description

X-Capi-Request

A6665E4664FD416EA903774A5103D760

The API session key.

Request Body

<CloudInstances instanceName="mycloud" type="cisco" moduleName="CSP" >
<CloudCredentials endpointURI="http://csserver:8080/client/api" />
</CloudInstances>

Response

Status

Response

201

Cloud instance is created.

<CloudInstances status="ACTIVE" instanceName="mycloud"
cloudId="a7e4a384-afb8-418e-a958-a978496fa95c"/>

400

Invalid input.

401

Resource not authorized.

401

User is not allowed to perform this operation.

403

Module module-name is not supported.

403

Cloud instance instance-name already exists.

403

Required fields error.

500

Internal server error.

Request Details

Tag

Attribute

Description

Format

Presence

CloudInstances

instanceName

A unique name that ties a moduleName to a back-end cloud URI address. This name is used for provisioning a new tenant.

String

Mandatory

type

The following values are valid:

- custom—Third-party developed plugin

- cisco—The plugin is part of the existing Cisco delivery

The type also serves to make sure that the moduleName is unique in the system.

String

Mandatory

moduleName

A unique string that maps a plugin to Cisco ICFPP. This must be the same name by which the plugin has been developed as a prefix for all the code/classes.

String

Mandatory

CloudCredentials

CloudCredentials tag inside the CloudInstances tag.

Mandatory

endpointURI

The endpoint to reach the cloud provider server. The value can be an IP address, hostname, or URI.

String

Mandatory

ParameterList

ParameterList tag inside CloudInstances tag. This tag allows an API user to pass additional parameters.

Optional

Parameter

Parameter tag under ParameterList tag.

Optional

name

Parameter name. For a Dimension Data cloud, a parameter with the name "ftpservername" must be passed in ParameterList.

String

Optional

value

Parameter value.

String

Optional

Update Cloud Instance

Description

Updates (edits) the URI of a cloud instance.

To update a cloud instance using the GUI, see Editing a Cloud Instance.

Resource URL

URL Type

Value

Resource URL

/capi/v1/cloudinstances/cloudId

Sample URL

https://myserver/capi/v1/cloudinstances/a7e4a384-afb8-418e-a958-a978496fa95c

HTTP Methods

Method

Description

PUT

Updates an existing cloud instance.

HTTP Headers

Header Name

Value

Description

X-Capi-Request

A6665E4664FD416EA903774A5103D760

The API session key.

Request Body

<CloudInstances>
<CloudCredentials endpointURI="http://newcsserver:8080/client/api" />
</CloudInstances>

Response

Status

Response

200

Cloud instance is updated.

<CloudInstances status="ACTIVE" instanceName="mycloud"
cloudId="a7e4a384-afb8-418e-a958-a978496fa95c"/>

400

Invalid input.

401

Resource not authorized.

401

User is not allowed to perform this operation.

403

Required fields error.

404

Cloud instance does not exist.

500

Internal server error.

Request Details

Tag

Attribute

Description

Format

Presence

CloudCredentials

CloudCredentials tag inside CloudInstances tag.

Mandatory

endpointURI

The endpoint to reach the cloud provider server. The value can be an IP address, hostname, or URI.

String

Mandatory

ParameterList

ParameterList tag inside CloudInstances tag. This tag allows the API user to pass additional parameters.

Optional

Parameter

Parameter tag under the ParameterList tag.

Optional

name

Parameter name.

String

Optional

value

Parameter value.

String

Optional

Get Cloud Instance

Description

Retrieves the details of the specified cloud instance. The cloud identifier is obtained as part of creating a cloud instance.

Resource URL

URL Type

Value

Resource URL

/capi/v1/cloudinstances/cloudId

Sample URL

https://myserver/capi/v1/cloudinstances/a7e4a384-afb8-418e-a958-a978496fa95c

HTTP Methods

Method

Description

GET

Queries the specified cloud instance.

HTTP Headers

Header Name

Value

Description

X-Capi-Request

A6665E4664FD416EA903774A5103D760

The API session key.

Request Body

No Body

Response

Status

Response

200

<CloudInstances moduleName="CSP" type="CISCO" instanceName="mycloud"
cloudId="a7e4a384-afb8-418e-a958-a978496fa95c "/>

400

Invalid input.

401

Resource is not authorized.

401

User is not allowed to perform this operation.

404

Cloud instance does not exist.

500

Internal server error.

Get All Cloud Instances

Description

Retrieves a list of all cloud instances provisioned on Cisco ICFPP.

Resource URL

URL Type

Value

Resource URL

/capi/v1/cloudinstances

Sample URL

https://myserver/capi/v1/cloudinstances

HTTP Methods

Method

Description

GET

Returns a list of all cloud instances.

HTTP Headers

Header Name

Value

Description

X-Capi-Request

A6665E4664FD416EA903774A5103D760

The API session key.

Request Body

No Body

Response

Status

Response

200

<CloudInstancesList>
<CloudInstances moduleName="CSP" type="CISCO"
instanceName="mycloud" cloudId="a7e4a384-afb8-418e-a958-a978496fa95c" />
<CloudInstances moduleName="OSP" type="CISCO"
instanceName="ci2" cloudId="baaffdf95-4dd6-5103-0db2-ab3cd8dfca65" />
</CloudInstancesList>

400

Invalid input.

401

Resource is not authorized.

401

User is not allowed to perform this operation.

404

Cloud instance does not exist.

500

Internal server error.

Delete Cloud Instance

Description

Deletes a cloud instance. A cloud instance cannot be deleted if one or more tenants are associated with it.

To delete a cloud instance using the GUI, see Deleting a Cloud Instance.

Resource URL

URL Type

Value

Resource URL

/capi/v1/cloudinstances/cloudId

Sample URL

https://myserver/capi/v1/cloudinstances/a7e4a384-afb8-418e-a958-a978496fa95c

HTTP Methods

Method

Description

DELETE

Deletes an existing cloud instance.

HTTP Headers

Header Name

Value

Description

X-Capi-Request

A6665E4664FD416EA903774A5103D760

The API session key.

Request Body

No Body

Response

Status

Response

200

Cloud instance is deleted.

<CloudInstances status="DELETED" cloudId="a7e4a384-afb8-418e-a958-a978496fa95c"/>

401

Resource is not authorized.

401

User is not allowed to perform this operation.

403

Cannot delete. One or more tenants are associated with the cloud instance.

404

Cloud instance does not exist.

500

Internal server error.

Tenant Management APIs

Cisco Intercloud Fabric Provider Platform (ICFPP) provides APIs that can provision tenants and add users.

- Provision Tenant

- Update Tenant

- Get Tenant

- Get Tenant Details

- Get All Tenants

- Delete Tenant

- Purge Tenant

- Get Server

Provision Tenant

Description

Provisions (adds) a tenant. You must provision a cloud instance before you can provision a tenant.

To provision a tenant using the GUI, see Adding a Tenant.

Resource URL

URL Type

Value

Resource URL

/capi/v1/tenants

Sample URL

https://myserver/capi/v1/tenants

HTTP Methods

Method

Description

POST

Creates a new tenant.

HTTP Headers

Header Name

Value

Description

X-Capi-Request

A6665E4664FD416EA903774A5103D760

The API session key.

Request Body

<Tenants tenantName="acme" instanceName="mycloud">
<ResourceLimits maxServers="100"/>
<ParameterList>
<Parameter name="paramone" value="param_one_value"/>
<Parameter name="paramtwo" value="param_two_value"/>
</ParameterList>
<AccountsList>
<Accounts username="peter" apiKey="ABCDEF" secretKey="AB12345"/>
</AccountsList>
</Tenants>

Response

Status

Response

201

Tenant is created.

<Tenants status=”ACTIVE” tenantId="8116a2f7-7f8c-4961-8ee1-9e486b6b2aa4"
tenantName="acme" instanceName="mycloud">
<ResourceLimits maxServers="100"/>
<ParameterList>
<Parameter name="paramone" value="param_one_value"/>
<Parameter name="paramtwo" value="param_two_value"/>
</ParameterList>
<AccountsList>
<Accounts username="peter" passkey=”23455#adfcc” apiKey="ABCDEF" secretKey="AB12345” />
</AccountsList>
</Tenants>

400

Invalid input.

401

Resource is not authorized.

401

User is not allowed to perform this operation.

403

Required fields error.

403

Validation error. @ is not allowed in tenant name.

Cloud instance instance-name does not exist.

Required: Org name.

Required: API Key and Secret Key.

403

Tenant tenant-name already exists.

500

Internal server error.

Request Details

Tag

Attribute

Description

Format

Presence

Tenants

tenantName

A unique name associated with the tenant.

String

Mandatory

instanceName

The cloud instance name.

String

Mandatory

enabled

Indicates whether the tenant is enabled or disabled. To disable the tenant and any accounts under it, set the value to "false". The default value is "true".

String

Optional

orgName

The name of the organization that is associated with the tenant. Different back-end cloud providers have parallel concepts. For CloudStack, this name need not be passed as it can be dynamically provisioned.

String

Optional

ResourceLimits

The resource limits tag.

Optional

maxServers

The maximum server count. The default value is 1000.

Integer

Mandatory

ParameterList

ParameterList tag inside the Tenants tag. This tag allows the API user to pass additional parameters.

Optional

Parameter

Parameter tag under ParameterList tag.

Optional

name

Parameter name.

String

Optional

value

Parameter value.

String

Optional

AccountsList

A list of accounts.

Mandatory

Accounts

The accounts tag.

Mandatory

username

The username of the tenant account. The name is used to log in to the Cisco ICFPP REST API. For example, username@tenant

String

Mandatory

apiKey

This attribute is specific to some cloud providers that require a key for any back-end API access.

This attribute is mandatory for CloudStack-based tenants.

String

Optional

secretKey

This attribute is used with the apiKey parameter for some cloud providers.

This attribute is mandatory for CloudStack-based tenants.

String

Optional

enabled

Indicates whether the account is enabled or disabled. To disable the account, set the value to "false". The default value is "true".

String

Optional

email

The email address that is associated with the user. If this attribute is not provided, the value defaults to the following:

username@tenantName

String

Optional

passkey

Password key generated as a response for the apiKey and secretKey. This attribute is mandatory for CloudStack-based tenants. For cloud providers that use usernames and passwords, this attribute will not be created or presented to the API.

String

Optional

Update Tenant

Description

Updates (edits) the attributes of an existing tenant.

To update a tenant using the GUI, see Editing a Tenant.

Resource URL

URL Type

Value

Resource URL

/capi/v1/tenants/tenantId

Sample URL

https://myserver/capi/v1/tenants/8116a2f7-7f8c-4961-8ee1-9e486b6b2aa4

HTTP Methods

Method

Description

PUT

Updates an existing tenant.

HTTP Headers

Header Name

Value

Description

X-Capi-Request

A6665E4664FD416EA903774A5103D760

The API session key.

Request Body Example 1

<Tenants>
<ResourceLimits maxServers="200"/>
<ParameterList>
<Parameter name="paramone" value="param_one_new_value"/>
</ParameterList>
<AccountsList>
<Accounts username="peter"
email="peter@acme" apiKey="ABCDEFXYZ" secretKey="AB12345678"/>
</AccountsList>
</Tenants>

Request Body Example 2

<Tenants enabled=”false” >
<AccountsList>
<Accounts username="peter"
email="peter@acme" apiKey="ABCDEFXYZ" secretKey="AB12345678"/>
</AccountsList>
</Tenants>

Response

Status

Response

200

Tenant is updated.

<Tenants status=”ACTIVE” tenantId="8116a2f7-7f8c-4961-8ee1-9e486b6b2aa4"
tenantName="acme" instanceName="mycloud">
<ResourceLimits maxServers="100" />
<ParameterList>
<Parameter name="paramone" value="param_one_value" />
<Parameter name="paramtwo" value="param_two_value" />
</ParameterList>
<AccountsList>
<Accounts username="peter" passkey=”1255#adfbc” apiKey="ABCDEFXYZ"
secretKey="AB12345678" />
</AccountsList>
</Tenants>

400

Invalid input.

401

Resource is not authorized.

401

User is not allowed to perform this operation.

404

Tenant with the tenant ID does not exist.

500

Internal server error.

Request Details

Tag

Attribute

Description

Format

Presence

Tenants

Mandatory

enabled

Indicates whether the tenant is enabled or disabled. To disable this tenant for a period of time, set the value to "false". This attribute is set to "true" by default.

String

Optional

ResourceLimits

The resource limits tag.

Optional

maxServers

The maximum server count.

Integer

Optional

ParameterList

ParameterList tag inside Tenants tag. This attribute allows the API user to pass additional parameters.

Optional

Parameter

Parameter tag inside the ParameterList tag.

Optional

name

The parameter name.

String

Optional

value

The parameter value.

String

Optional

AccountsList

A list of accounts.

Mandatory

Accounts

The accounts tag.

Mandatory

username

The username of the tenant account.

String

Mandatory

apiKey

This attribute is specific to some cloud providers that require a key for any back-end API access. This attribute is mandatory for CloudStack-based tenants.

String

Optional

secretKey

This attribute is used in combination with the apiKey attribute for some cloud providers. This attribute is mandatory for CloudStack-based tenants.

String

Optional

enabled

Indicates whether the account is enabled or disabled. To disable an account for a period of time, set the value to "false". This attribute is set to "true" by default.

String

Optional

email

The email address of the tenant account.

String

Optional

passkey

The password key is generated in response to the apiKey and secretKey attributes. This attribute is mandatory for CloudStack-based tenant.s

String

Optional

Get Tenant

Description

Retrieves the tenant details of the specified tenant ID.

Resource URL

URL Type

Value

Resource URL

/capi/v1/tenants/tenantId

Sample URL

https://myserver/capi/v1/tenants/8116a2f7-7f8c-4961-8ee1-9e486b6b2aa4

HTTP Methods

Method

Description

GET

Returns tenant details.

HTTP Headers

Header Name

Value

Description

X-Capi-Request

A6665E4664FD416EA903774A5103D760

The API session key.

Request Body

No Body

Response

Status

Response

200

Response for an existing tenant.

<Tenants tenantId="8116a2f7-7f8c-4961-8ee1-9e486b6b2aa4" status=”ACTIVE”
instanceName="mycloud" tenantName="acme">
<ResourceLimits maxServers="200"/>
<ParameterList>
<Parameter name="paramone" value="param_one_new_value"/>
<Parameter name="paramtwo" value="param_two_value"/>
</ParameterList>
<AccountsList>
<Accounts secretKey="AB12345678" apiKey="ABCDEFXYZ" username="peter" passkey=”123#2445” accountId="141a5ce8-e9b8-45d6-88e9-dbf851634786" email="peter@acme">
<Servers inactiveServers="0" activeServers="0"/>
</Accounts>
</AccountsList>
</Tenants>

200

Response for a tenant that has been deleted.

A resource in the response can have the value of "server", "template", or "network". The value for backendResourceId is the ID that the cloud platform understands. If FaultList is included in the response, those resources must be removed manually.

<Tenants tenantId="8116a2f7-7f8c-4961-8ee1-9e486b6b2aa4" status="DELETED"
tenantName="acme">
<AccountList>
<Accounts username="abcuser"
<FaultList>
<!-- Information from CapiFaults -->
<Fault locationId="867a374b-b5ff-4190-9b7b-d9f602bea503"
locationName="Zone-1" resource="server" resourceName="myserver"
resourceId="abc-xyz-123" backendResourceId="defal-1020" errorCode="ICFPP specific error"
errorMessage="can be anything, exception from backend" />
<Fault locationId="867a374b-b5ff-4190-9b7b-d9f602bea503"
locationName="Zone-1" resource="server" resourceName="myserver2"
resourceId="abc-def-456" backendResourceId="defal-5678" errorCode="ICFPP specific error"
errorMessage="can be anything, exception from backend" />
</FaultList>
</Accounts>
</AccountsList>
</Tenants>

400

Invalid input.

401

Resource is not authorized.

401

User is not allowed to perform this operation.

404

The specified tenant does not exist.

500

Internal server error.

Response Details

Tag

Attribute

Description

Format

Presence

Servers

The server tag.

Mandatory

inactiveServers

Number of servers that are not in Running state (such as stopped, failed, or any other indeterminate state).

String

Mandatory

activeServers

Number of servers that are in Running state, and with a private IP address assigned.

String

Mandatory

Get Tenant Details

Description

Retrieves the details of the tenant and any servers that are associated with the specified tenant.

Resource URL

URL Type

Value

Resource URL

/capi/v1/tenants/tenantId /details

Sample URL

https://myserver/capi/v1/tenants/8116a2f7-7f8c-4961-8ee1-9e486b6b2aa4/details

Pagination Options

Pagination options limit the number of records (servers) displayed per tenant. The pageSize option sets the number of records in each query and the page option identifies the index of the page being fetched.

Resource URL

URL Type

Value

Resource URL

/capi/v1/tenants/tenantId /details?pageSize=size &page=index

Sample URL

https://myserver/capi/v1/tenants/8116a2f7-7f8c-4961-8ee1-9e486b6b2aa4/

details?pageSize=5&page=3

Date Filter Options

The date filter options retrieve all VM activity for the tenant between the specified startDate and time and endDate and time.

Resource URL

URL Type

Value

Resource URL

/capi/v1/tenants/tenantId/details?startDate=yyyy-MM-ddTHH:mm:ss

&endDate=yyyy-MM-ddTHH:mm:ss

Sample URL

https://myserver/capi/v1/tenants/8116a2f7-7f8c-4961-8ee1-9e486b6b2aa4/

details?startDate=2014-09-07T08:00:00&endDate=2014-09-15T23:00:00

HTTP Methods

Method

Description

GET

Returns tenant details.

HTTP Headers

Header Name

Value

Description

X-Capi-Request

A6665E4664FD416EA903774A5103D760

The API session key.

Request Body

No Body

Response

Status

Response

200

<Tenants tenantId="8116a2f7-7f8c-4961-8ee1-9e486b6b2aa4" status=”ACTIVE”
instanceName="mycloud" tenantName="acme">
<ResourceLimits maxServers="100" />
<AccountsList>
<Accounts secretKey="AB12345678" apiKey="ABCDEFXYZ"
username="peter" accountId="141a5ce8-e9b8-45d6-88e9-dbf851634786"
email="peter@acme">
<ServerList>
<Servers type="APPLICATION" inactiveServers="2"
activeServers="1">
<Server startTime="09/05/2014 08:40:51 GMT-0700"
activeHours="04:05:35" status="Running"
serverid="c0aafcd9-d65daa0e-2f38-a49e42af1758" name="myserver"
backendServerId="12345-232accaa-ccd-ddd" serviceOffering="abcd12345-efghi-sdfsdfsd-098765"
locationId="c0aafcd9-d65daa0e-abc12-a49e42af1758" resourceCpu="2"
resourceMem="2048" />
<Server startTime="09/07/2014 08:40:51 GMT-0700"
activeHours="12:45:59" status="Stopped"
serverid="dec44172-35fd-7900-fde7-d9bed5edca5e" name="myserver2"
backendServerId="12345-232accee-ccd-ddd" serviceOffering="abcd12345-efghi-sdfsdfsd-098765"
locationId="c0aafcd9-d65daa0e-abc12-a49e42af1758" resourceCpu="2"
resourceMem="4096" />
<Server startTime="09/07/2014 08:40:51 GMT-0700"
deleteTime="09/07/2014 09:40:51 GMT-0700" activeHours="1:00:00"
status="Deleted" serverid="deaa172-35fd-7900-fde7-d9bed5edca5e"
backendServerId="12345-232accdd-ccd-ddd" name="mydelServer"
serviceOffering="abcd12345-efghi-sdfsdfsd-098765" locationId="c0aafcd9-d65daa0e-abc12-a49e42af1758"
resourceCpu="2" resourceMem="4096" />
</Servers>
<Servers type="INFRA_CSR" inactiveServers="0"
activeServers="1">
<Server startTime="09/15/2014 11:40:51 GMT-0700"
activeHours="04:05:35" status="Running"
serverid="t1aafcd9-d65daa0e-2f38-b49e42af1758" name="mycsr"
backendServerId="12345-232acccc-ccd-ddd" serviceOffering="xyzd12335-efghi-sdfsdfsd-098765"
locationId="c0aafcd9-d65daa0e-abc12-a49e42af1758" resourceCpu="2"
resourceMem="4096" />
</Servers>
</ServerList>
</Accounts>
<Accounts>
.......
</Accounts>
</AccountsList>
</Tenants>

400

Invalid input.

401

Resource is not authorized.

401

User is not allowed to perform the operation.

404

The specified tenant does not exist.

500

Internal server error.

Get All Tenants

Description

Retrieves a list of all tenants.

Resource URL

URL Type

Value

Resource URL

/capi/v1/tenants

Sample URL

https://myserver/capi/v1/tenants

Pagination Options

Pagination options limit the number of records to be displayed for each entry. The pageSize option sets the number of records in each query, and the page option identifies the index of the page being fetched.

URL Type

Value

Resource URL

/capi/v1/tenants?pageSize=size&page=index

Sample URL

https://myserver/capi/v1/tenants?pageSize=5&page=3

HTTP Methods

Method

Description

GET

Returns a list of all tenants.

HTTP Headers

Header Name

Value

Description

X-Capi-Request

A6665E4664FD416EA903774A5103D760

The API session key.

Request Body

No Body

Response

Status

Response

200

<TenantsList>
<Tenants tenantId="8116a2f7-7f8c-4961-8ee1-9e486b6b2aa4" status=”ACTIVE”
instanceName="mycloud" tenantName="acme">
<ResourceLimits maxServers="100"/>
<AccountsList>
<Accounts secretKey="AB12345678" apiKey="ABCDEFXYZ" username="peter" passkey=”fff1243343#” accountId="141a5ce8-e9b8-45d6-88e9-dbf851634786" email="peter@acme">
<ServerList>
<Servers type="APPLICATION" inactiveServers="0" activeServers="0" />
</ServerList>
</Accounts>
</AccountsList>
</Tenants>
<Tenants tenantId="d4af5cbc-a2dd-430e-b3cd-205846784feb" status=”ACTIVE”
instanceName="mycloud" tenantName="mytenant">
<ResourceLimits maxServers="50"/>
<AccountsList>
<Accounts secretKey="DEF98765" apiKey="ABCXYZ" username="parker" passkey=”fff12456343#” accountId="c9cb6428-f295-43ca-929e-4e314f6181fc" email="parker@mytenant">
<ServerList>
<Servers type="INFRA_ICS" inactiveServers="0" activeServers="0" totalServers="0"/>
</ServerList>
</Accounts>
</AccountsList>
</Tenants>
</TenantsList>

400

Invalid input.

401

Resource is not authorized.

401

User is not allowed to perform the operation.

500

Internal server error.

Delete Tenant

Description

Deletes a tenant and all servers associated with the tenant.

The initial response of this call is "DELETING". Subsequent queries using the Get Tenant API call will eventually result with the status of "DELETED".

To delete a tenant using the GUI, see Deleting a Tenant.

Resource URL

URL Type

Value

Resource URL

/capi/v1/tenants/tenantId

Sample URL

https://myserver/capi/v1/tenants/8116a2f7-7f8c-4961-8ee1-9e486b6b2aa4

HTTP Methods

Method

Description

DELETE

Deletes an existing tenant.

HTTP Headers

Header Name

Value

Description

X-Capi-Request

A6665E4664FD416EA903774A5103D760

The API session key.

Request Body

No Body

Response

Status

Response

200

Tenant is deleting.

<Tenants status="DELETING" tenantName="acme"
tenantId="8116a2f7-7f8c-4961-8ee1-9e486b6b2aa4"/>

400

Invalid input.

401

Resource is not authorized.

401

User is not allowed to perform the operation.

404

Tenant is currently being deleted.

404

Tenant is already deleted.

404

The specified tenant does not exist.

500

Internal server error.

Purge Tenant

Description

Purges a tenant and all of its resources (such as servers, images, and templates) from the database. Run the delete tenant request before issuing the purge tenant request. If the tenant is deleted before the purge request, all of the tenant's resources will be removed from the database. If the tenant is active when the purge tenant request is issued, only the inactive servers will be deleted and removed from the database.

The response of this call shows the status of "PURGED".

Resource URL

URL Type

Value

Resource URL

/capi/v1/tenants/tenantId/purge

Sample URL

https://myserver/capi/v1/tenants/8116a2f7-7f8c-4961-8ee1-9e486b6b2aa4/purge

HTTP Methods

Method

Description

DELETE

Purges an existing tenant.

HTTP Headers

Header Name

Value

Description

X-Capi-Request

A6665E4664FD416EA903774A5103D760

The API session key.

Request Body

No Body

Response

Status

Response

200

Tenant is purged.

<Tenants status="PURGED" tenantName="acme" tenantId="8116a2f7-7f8c-4961-8ee1-9e486b6b2aa4"/>

400

Invalid input

401

Resource is not authorized.

401

User is not allowed to perform the operation.

404

The specified tenant does not exist.

500

Internal server error.

Get Server

Description

Retrieves the server details of the specified server ID.

Resource URL

URL Type

Value

Resource URL

/capi/v1/servers/serverId

Sample URL

https://myserver/capi/v1/servers/dec44172-35fd-7900-fde7-d9bed5edca5e

HTTP Methods

Method

Description

GET

Returns server details.

HTTP Headers

Header Name

Value

Description

X-Capi-Request

A6665E4664FD416EA903774A5103D760

The API session key.

Request Body

No Body

Response

Status

Response

200

<Server status="Stopped" serverid="dec44172-35fd-7900-fde7-d9bed5edca5e" name="mytestvm-5F7E1410264747593" providerVpcId="cd58fd3c-ad28-8dd8-4f5d-fe39c5b1bdb7" templateId="943c3728-4799-07ab-918e-45f7c7fe1731" locationId="867a374b-b5ff-4190-9b7b-d9f602bea503" resourceCpu="2" resourceMem”4096” >
<VnicInfoList>
<VnicInfo providerVpcNetworkId="39c4d1d1-9d0e-d5f4-651e-4ac2353dbdfd">
<VnicIpInfoList>
<VnicIpInfo assignPublicIp="false" privateIpNetmask="255.255.255.0" privateIp="10.0.0.186" isPrimary="true"/>
</VnicIpInfoList>
</VnicInfo>
</VnicInfoList>
<Disks>
<Disk downloadStatus="none" size="33554432" diskId="97952a38-729b-4277-b09e-95efdeac685a" index="0"/>
</Disks>
<Tags>
<Tag>VNMC_RES_ID-0004f5b6-4000-4273-0004-f5b640004273</Tag>
</Tags>
<ParameterList>
<Parameter value="0004f5b6-4000-4273-0004-f5b640004273" name="resource-id"/>
</ParameterList>
</Server>

400

Invalid input.

401

Resource is not authorized.

404

The specified server does not exist.

500

Internal server error.

Remote Syslog Configuration APIs

You can configure Cisco ICFPP to send messages to remote syslog servers. If remote syslog is enabled, Cisco ICFPP sends messages to the remote syslog server whenever a tenant, cloud instance, template, or server is created or deleted.

- Configure Syslog Servers

- Get Syslog Configuration

Configure Syslog Servers

Description

Configures remote syslog servers in Cisco ICFPP. This API also enables, disables, or updates remote syslog server configurations in Cisco ICFPP.

Resource URL

URL Type

Value

Resource URL

/capi/v1/logs/syslogconfig

Sample URL

https://myserver/capi/v1/logs/syslogconfig

HTTP Methods

Method

Description

POST

Posts the remote syslog configuration.

HTTP Headers

Header Name

Value

Description

X-Capi-Request

A6665E4664FD416EA903774A5103D760

The API session key.

Request Body

<SyslogConfig logLevel="MINOR" enabled="true">
<PrimaryServer protocol="UDP" port="514" host="192.168.10.101"/>
<SecondaryServer protocol="UDP" port="514" host="192.168.10.102"/>
</SyslogConfig>

Response

Status

Response

200

Configures the remote syslog servers in Cisco ICFPP and returns the current configuration.

<SyslogConfig logLevel="MINOR" enabled="true">
<PrimaryServer protocol="UDP" port="514" host="192.168.10.101"/>
<SecondaryServer protocol="UDP" port="514" host="192.168.10.102"/>
</SyslogConfig>

400

Invalid input.

401

Resource is not authorized.

401

User is not allowed to perform this operation.

403

Required: Primary server address.

Primary and Secondary server address mst be different.

Required: Syslog Level.

Invalid Syslog Level.

500

Internal server error.

Request Details

Tag

Attribute

Description

Format

Presence

SyslogConfig

enabled

Enable syslog configuration.

Allowed values are "true" or "false". If enabled is "false", the PrimaryServer configuration is not required.

String

Mandatory

logLevel

Allowed values: DEBUG, NORMAL, MINOR, or MAJOR.

String

Mandatory

PrimaryServer

Primary syslog server configuration.

Mandatory

host

Primary syslog server hostname or IP address.

String

Mandatory

port

Primary syslog server port. Allowed port: 514.

Mandatory

protocol

Remote syslog messaging protocol. Allowed protocol: UDP.

Mandatory

SecondaryServer

Secondary syslog server configuration.

Optional

host

Secondary syslog server hostname or IP address.

String

Optional

port

Primary syslog server port. Allowed port: 514.

Optional

protocol

Remote syslog messaging protocol. Allowed protocol: UDP.

Optional

Get Syslog Configuration

Description

Retrieves the remote syslog configuration from Cisco ICFPP.

Resource URL

URL Type

Value

Resource URL

/capi/v1/logs/syslogconfig

Sample URL

https://myserver/capi/v1/logs/syslogconfig

HTTP Methods

Method

Description

GET

Get syslog configuration.

HTTP Headers

Header Name

Value

Description

X-Capi-Request

A6665E4664FD416EA903774A5103D760

The API session key.

Request Body

No Body

Response

Status

Response

200

<SyslogConfig logLevel="MINOR" enabled="true">
<PrimaryServer protocol="UDP" port="514" host="192.168.10.101"/>
<SecondaryServer protocol="UDP" port="514" host="192.168.10.102"/>
</SyslogConfig>

401

Resource is not authorized.

401

User is not allowed to perform this operation.

500

Internal server error.

Logging APIs

Cisco ICFPP provides APIs that enable you to download the current logs or all logs.

- Download Current Logs

- Download All Logs

Download Current Logs

Description

Downloads the current Cisco ICFPP logs in a zipped file.

Resource URL

URL Type

Value

Resource URL

/capi/v1/logs/current

Sample URL

https://myserver/capi/v1/logs/current

HTTP Methods

Method

Description

GET

Returns the Cisco ICFPP application and web server logs.

HTTP Headers

Header Name

Value

Description

X-Capi-Request

A6665E4664FD416EA903774A5103D760

The API session key.

Request Body

No Body

Response

Status

Response

200

reply: 'HTTP/1.1 200 OK\r\n'
header: Content-Disposition: attachment;
filename="CurrentLogs.zip"
header: Content-Type: application/zip

400

Invalid input.

401

Resource is not authorized.

401

User is not allowed to perform this operation.

500

Internal server error.

Download All Logs

Description

Downloads all Cisco ICFPP in a zipped file.

Resource URL

URL Type

Value

Resource URL

/capi/v1/logs/all

Sample URL

https://myserver/capi/v1/logs/all

HTTP Methods

Method

Description

GET

Returns all Cisco ICFPP logs.

HTTP Headers

Header Name

Value

Description

X-Capi-Request

A6665E4664FD416EA903774A5103D760

The API session key.

Request Body

No Body

Response

Status

Response

200

reply: 'HTTP/1.1 200 OK\r\n'
header: Content-Disposition: attachment;
filename="AllLogs.zip"
header: Content-Type: application/zip

400

Invalid input.

401

Resource is not authorized.

402

User is not allowed to perform this operation.

500

Internal server error.

Chapter 7. Additional Information

- Related Documentation for Cisco Intercloud Fabric Provider Platform

- Obtaining Documentation and Submitting a Service Request

- Documentation Feedback

Related Documentation for Cisco Intercloud Fabric Provider Platform

The documentation listed below is available for Cisco Intercloud Fabric Provider Platform at the following URL:

Click Here

General Information

Cisco Intercloud Fabric Provider Platform Release Notes

Install and Upgrade

Cisco Intercloud Fabric Provider Platform Installation Guide

Administration

Cisco Intercloud Fabric Provider Platform Administrator Guide

Troubleshooting and Alerts

Cisco Intercloud Fabric Provider Platform Troubleshooting Guide

Cisco Intercloud Fabric Documentation

The documentation listed below is available for Cisco Intercloud Fabric at the following URL:

Click Here

Cisco Intercloud Fabric Release Notes

Cisco Intercloud Fabric Getting Started Guide

Cisco Intercloud Fabric Director REST API Guide

Cisco Intercloud Fabric Configuration Guide

Cisco Intercloud Fabric Firewall Configuration Guide

Cisco vPath and vServices Reference Guide for Intercloud Fabric

Cisco Intercloud Fabric User Guide

Cisco Intercloud Fabric Troubleshooting Guide

Cisco Nexus 1000V Documentation

Cisco Nexus 1000V for VMware vSphere

Cisco Nexus 1000V for KVM

Cisco Nexus 1000V for Microsoft Hyper-V

Cisco Virtual Security Gateway Documentation

Cisco Virtual Security Gateway

Cisco Cloud Services Router Documentation

Cisco Cloud Services Router 1000V

Obtaining Documentation and Submitting a Service Request

For information on obtaining documentation, using the Cisco Bug Search Tool (BST), submitting a service request, and gathering additional information, see What's New in Cisco Product Documentation, at: Click Here .

Subscribe to What's New in Cisco Product Documentation, which lists all new and revised Cisco technical documentation as an RSS feed and delivers content directly to your desktop using a reader application. The RSS feeds are a free service.

Documentation Feedback

To provide technical feedback on this document, or to report an error or omission, please send your comments to: intercloud-fabric-doc-feedback@cisco.com.

We appreciate your feedback.

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: Click Here . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)