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>
|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|
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. The following command lists the hosts for the project based on the credentials available in the environment.
nova host-list command 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>]
||Name or ID of the server.|
||Name or ID of the target host. If no host is specified, the scheduler will choose one.|
||(Optional) Set the provided admin password on the evacuated server. Not applicable if the server is on shared storage.|
Compute Host Evacuation
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>
||Name of host.|
||(Optional) Name of target host. If no host is specified, the scheduler will select a target.|
||(Optional) 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>
||Name of host.|
||(Optional) Name of target host.|
||(Optional) Enable block migration. Default=
||(Optional) 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 QOS Settings:
|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 and Resume Stack Creation
The following 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]
The following 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]
This command allows end users and admins to preview the types and number of resources that will be deployed by a Heat template. This 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>
||Name of the stack to preview.|
||Path to the template.|
||Path to the environment, it can be specified multiple times.|
||URL of template.|
||URL to retrieve template object (e.g. from swift).|
||Stack creation timeout in minutes. This is used during validation in preview.|
||Enable rollback on failure. This option is not used during preview and exists for symmetry with stack-create.|
||Parameter values used to preview the stack. This can be specified once or multiple times, with parameters separated by semicolon.|
||Parameter values from file used to create the stack. This can be specified multiple times. Parameter value is the content of the file.|
||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.
heat resource-list [-n <DEPTH>] [--with-detail] [-f <KEY=VALUE>] <NAME or ID>
||Name or ID of stack to show the resources for.|
||Depth of nested stacks to display resources from.|
||Enable detail information presented for each resource in resources list.|
||Filter parameters to apply on returned resources based on their name, status, type, action, id, and physical_resource_id. This can be specified multiple times.|
There are no reported bug fixes for this release.
The following known issues have been reported in this release:
- The Orchestration scaling operation in a Heat template does not work due to Fernet tokens.
- The Docker plug-in as an Orchestration resource
type: DockerInc::Docker::Containeris not supported in Heat templates.
Supported API Versions
Supported OpenStack Projects and Versions
Supported Image Types
|Image Storage Location||Local Storage||NFS-backed Storage||Ceph-backed Storage|
|QCOW2 (KVM, Xen)||x||x||N/A|