Cisco Metacloud 4.0 Release Notes

July 11, 2016

We are happy to announce the 4.0 (Liberty) release of Cisco Metacloud™. 

Now Based on Red Hat OpenStack Platform 8

With the 4.0 release, Cisco Metacloud is now based off of Red Hat OpenStack Platform (OSP) 8. The Cisco Metacloud team has partnered with Red Hat to provide the highest quality OpenStack platform and deliver industry leading SLAs. The partnership with Red Hat allows Cisco Metacloud to focus more on bringing OpenStack enhancements to customers while utilizing Red Hat’s immense expertise. The coordination between the two companies has produced an OpenStack platform that will lead the industry both in features and stability. This release is targeted at new Metacloud deployments only. An update will deliver upgrade support from previous Metacloud releases.

vCPU Typology Definition

This feature provides users and administrators the ability to control the vCPU topology that is exposed to guests and enables them to avoid any of the vCPU topology limitations that Operating System vendors place on their projects.

glance image-update <IMG UUID> --property <key>=<value>
Key Description Type
hw_cpu_sockets The preferred number of sockets to expose to the guest. Integer
hw_cpu_cores The preferred number of cores to expose to the guest. Integer
hw_cpu_threads The preferred number of threads to expose to the guest. Integer

Instance Evacuation

Evacuates a single instance off of a failed compute host while preserving IP Addresses, network configuration, and access controls to the instance.  If the instance leverages shared storage (with Ceph or NFS) for the Compute root disks, Metacloud preserves all the instance disk data and, at the end of the evacuation the instance will be rebooted.

To Find a Host for the Evacuated Instance, List All Hosts

nova host-list

This command lists the hosts for the project based on the credentials available in the environment. Typically, nova host-list is run with administrator credentials. Once you have the hostname, you can use the nova evacuate command as shown below, or let the schedule choose a host by leaving the host name or ID off the command line. Optionally, you can use the –password PWD option to pass the instance password to the command. If you do not specify a password, the command generates and prints one to the terminal after it finishes successfully. The following command evacuates a server from a failed host to HOST_B.

nova evacuate [--password <password>] <server> [<host>]

Positional Arguments

<server>

Name or ID of server.

<host>

Name or ID of the target host. If no host is specified, the scheduler will choose one.

Optional Arguments:

--password <password>

Set the provided admin password on the evacuated server. Not applicable if the server is on shared storage.

Compute Host Evacuation

Evacuate All Instances from Failed Host

The nova host-evacuate command evacuates all instances off of a failed compute host and will result in the rebooting of all VMs after evacuation.  Use this command to recover instances on a failed compute host (MCP).  If your users require zero VM downtime use “nova host-evacuate-live” which is defined later in the release notes.

nova host-evacuate [--target_host <target_host>] [--on-shared-storage] <host>

Positional Arguments

<host>

Name of host.

Optional Arguments

--target_host <target_host>

Name of target host. If no host is specified, the scheduler will select a target.

--on-shared-storage

Specifies whether all instances’ files are on shared storage (NFS or Ceph).

Evacuate All Instances from a Running Host

Live migrate all instances of the specified host to other available hosts.  Use this command on a running compute host (MCP).  If the compute host has failed use “nova host-evacuate” which is defined earlier in the release notes.

nova host-evacuate-live [--target-host <target_host>] [--block-migrate] \
 [--max-servers <max_servers>] <host>

                            

Positional Arguments

<host>

Name of host.

Optional Arguments

--target-host <target_host>

Name of target host

--block-migrate

Enable block migration. (Default=auto)

--max-servers <max_servers>

Maximum number of servers to live migrate simultaneously

QoS Settings for Cinder Volumes

cinder qos-create high-iops consumer="front-end" maxIOPS=[max IOPS]
cinder type-create high-iops
cinder qos-associate [QOS UUID] [VOLUME TYPE UUID
cinder create --display-name high_iops --volume-type high_iops 1
nova volume-attach cirrOS [VOLUME UUID] /dev/vdc

QoS enforcement can happen either at the compute host level (“front-end”) or at the storage device (“back-end”).  This is defined with the consumer flag.  Use “front-end” since not all storage systems support enforcement.

Supported Consumers

Storage Type Front-end Back-end
Ceph x N/A
NFS x N/A

Supported QOS Settings

QoS Key Notes Ceph NFS
maxIOPS The QoS I/O issue count rate limit. If not set, the I/O issue count rate has no limit. x x
minIOPS The QoS I/O issue count minimum goal. If not set, the I/O issue count has no minimum goal. x x

Suspend/Resume Stack Creation

Suspend Stack Creation

This command allows an end user or admin to pause a Heat stack creation.  Previously, a user could only cancel stack creation which could result in lost time when trying to recreate a stack.  Not all operations can be suspended; some actions must complete before stack creation is suspended.

heat action-suspend [NAME or UUID]

Resume Stack Creation

This command allows an end user or admin to resume the creation of a stack after creation was suspended.  Stack creation will resume at the step where it was suspended.

heat action-resume [NAME or UUID]

Preview Stack

This command allows end users and admins to preview the types and number of resources that will be deployed by a Heat template.  This command is particularly useful when running Heat templates that were authored by someone other than the end user.

heat stack-preview [-f <FILE>] [-e <FILE or URL>] [-u <URL>] [-o <URL>]
                           [-t <TIMEOUT>] [-r]
                           [-P <KEY1=VALUE1;KEY2=VALUE2...>] [-Pf <KEY=FILE>]
                           [--tags <TAG1,TAG2>]
                           <STACK_NAME>

Positional Arguments

<STACK_NAME> Name of the stack to preview.  

Optional Arguments

-f <FILE>, --template-file <FILE>

Path to the template.

-e <FILE or URL>, --environment-file <FILE or URL>

Path to the environment, it can be specified multiple times.

-u <URL>, --template-url <URL>

URL of template.

-o <URL>, --template-object <URL>

URL to retrieve template object (e.g. from swift)

-t <TIMEOUT>, --timeout <TIMEOUT>

Stack creation timeout in minutes. This is used during validation in preview.

-r, --enable-rollback

Enable rollback on failure. This option is not used during preview and exists for symmetry with stack-create.

-P <KEY1=VALUE1;KEY2=VALUE2...>, --parameters <KEY1=VALUE1;KEY2=VALUE2

Parameter values used to preview the stack. This can be specified once or multiple times, with parameters separated by semicolon.

-Pf <KEY=FILE>, --parameter-file <KEY=FILE>

Parameter values from file used to create the stack. This can be specified multiple times. Parameter value is the content of the file.

--tags <TAG1,TAG2>

A list of tags to associate with the stack.

Heat Resource List

List all the resources that belong to a Stack along with their status. 

logical_resource_id resource_type resource_status updated_time
DemoResource AWS::EC2::Instance CREATE_COMPLETE 2013-04-03T23:25:56Z
heat resource-list [-n <DEPTH>] [--with-detail] [-f <KEY=VALUE>]
<NAME or ID> 

Positional Arguments

<NAME or ID>

Name or ID of stack to show the resources for.

Optional Arguments

-n <DEPTH>, --nested-depth <DEPTH>

Depth of nested stacks to display resources from.

--with-detail Enable detail information presented for each resource in resources list.

-f <KEY=VALUE>, --filter <KEY=VALUE>

Filter parameters to apply on returned resources based on their name, status, type, action, id, and physcial_resource_id. This can be specified multiple times.

Known Issues

[990] Heat scaling operation does not work due to Fernet tokens

Supported API Versions

Service API Version
Compute v2.1 (New)
Image v2 (New)
CloudFormation v1
Volume v2 (New)
Orchestration v1
Identity v3 (New)
Networking v2

Supported OpenStack Projects and Versions 

Project Version
Nova Liberty
Cinder Liberty
Keystone Liberty
Glance Liberty
Heat Liberty
Horizon Liberty
Neutron Liberty

Supported Image Types

Image Storage Location Local Storage NFS-backed Storage Ceph-backed Storage
AMI (AWS) x x x
ISO9660 x x N/A
QCOW2 (KVM, Xen) x x N/A
RAW x x x
VDI (VirtualBox) x x N/A
VHD (Hyper-V) x x N/A
VDMK (VMWare) x x N/A