Cisco Metacloud April 2015 Update

Posted on April 14, 2015

Feature Updates

Orchestration is here!

With our latest update we are happy to announce general availability support for OpenStack Orchestration (Heat). Cisco Metacloud Private Cloud customers can now count on the same reliability with Heat that they get with all other OpenStack services. With OpenStack Heat you can deploy application templates, also known as stacks, to your Cisco Metacloud Private Cloud Availability zones. These application templates define the various resources and their relationships in a simple human readable manner. Heat currently supports two template formats HOT and AWS CloudFormation (CFN).

More documentation on Heat templates and resources can be found here.

Stacks

Topology

We currently support OS::Nova, OS::Cinder, OS::Glance, and OS::Heat HOT resource types.

Heat also includes an API for instance scaling. With this release we have exposed this API so customers can write applications to seamlessly scale their applications. Here’s an example of the API and how you would use it to setup an auto-scaling policy and a simple python example of how a program might call that API.

$  from heat.engine import api as engine_api 
   from heat.engine import notification

   def send(stack,
    adjustment=None,
    adjustment_type=None,
    capacity=None,
    groupname=None,
    message='error',
    suffix=None):
  event_type = '%s.%s' % ('autoscaling', suffix)
    body = engine_api.format_notification_body(stack)
    body['adjustment_type'] = adjustment_type
    body['adjustment'] = adjustment
    body['capacity'] = capacity
    body['groupname'] = groupname
    body['message'] = message
   level = notification.get_default_level()
    if suffix == 'error':
    level = notification.ERROR
   notification.notify(stack.context, event_type, level, body)

An example template that creates an Auto Scaling Group can be found here.  This template also outputs 2 URLs that can be used to trigger scaling events.  A post to the scale up URL triggers a scale up event and a post to the scale down URL triggers a scale down event.  Additionally there is a cool down period that controls how often you can trigger these events.  This prevents any run away scaling issues you may encounter by limiting how often your stack can scale.  

$ curl command to trigger a scaling event: curl -i -d "" "{scaling URL}"

In order for users to be able to properly leverage Heat they will need to be a member of the project. Admin only users will not be able to access Heat. You can add the member role to a user for a specific project through the Dashboard via Admin -> Projects -> Modify Users.

In upcoming releases we will be working on integrating fully automated instance scaling into the offering as we know that this is an important feature for customers.

Docker Plugin for Heat

With the Docker Plugin you can now orchestrate Docker containers within your Metacloud environment. These containers are defined just like other Heat resources and are fully managed by Heat. These Docker containers run inside of Virtual Machines and allow you to manage application deployment more easily all by leveraging Heat templates. Docker containers allow for the separation of processes which can help achieve additional security standards or operational efficiencies.

Affinity and Anti-Affinity Scheduling

We know many customers would like more control over instance placement on their hypervisors. With this release we are introducing support for affinity and anti-affinity filters. These two filter types ensure instances are scheduled to the same hypervisor (affinity) or to different hypervisors (anti-affinity) based on a set of rules. When deploying applications in an high availability manner you can now ensure the VMs running the application services are deployed to different hosts. This will ensure that the application, if architected correctly, will continue to operate if a single hypervisor fails. Additionally network traffic and latency can be reduced by scheduling instances that have a lot of instance to instance communication needs to the same host.

The first step is to create a server group with the correct policy. For anti-affinity this can be done using this command:

nova server-group-create --policy anti-affinity group-1

and for affinity

nova server-group-create --policy affinity group-1

and then boot instances into the desired group

nova boot --image IMAGE_ID --flavor 1 --hint group=SERVER_GROUP_UUID server-1

To find the existing server groups and details about those groups use this command:

nova server-group-list

More documentation on scheduling filters can be found here. Currently server group creation and booting instances into those groups must be done via API or CLI tools.

Cisco Metacloud Private Cloud Dashboard Updates

Image virtual size can now be seen under Image details. The Image virtual size is the Instance root disk size required to be able to boot the image. Previously only image file size could be seen from the dashboard and could be misleading to users. Image storage quotas now also exclude deleted images. Images and Snapshots has been renamed to Images in order to reflect upstream OpenStack changes.

Default project quotas has been moved under System Info in the Admin section of the dashboard. This reduces the number of links on the left hand side of the dashboard and aggregates similar data into a single panel.

Disabled Icehouse Features

Cisco Metacloud Private Cloud continues to focus on user experience and platform stability and because of that focus has chosen to disable a few Icehouse based features in this release. Cinder volume encryption, Live Migrations via the UI, Volume Snapshots and Extend volume have all been disabled in order to guarantee the best customer experience possible. The Cisco Metacloud Private Cloud team will continue to work to improve the customer experience of these features and enable them in upcoming releases.

Note
This release is can only support green field availability zone deployments. Our engineers are hard at work testing the upgrade process to ensure a seamless upgrade from our previous release. Upgrades will be supported with the next release of Cisco Metacloud Private Cloud.

In order for users to be able to properly leverage Heat they will need to be a member of the project. Admin only users will not be able to access Heat. You can add the member role to a user for a specific project through the Dashboard via Admin -> Projects -> Modify Users.     In upcoming releases we will be working on integrating fully automated instance scaling into the offering as we know that this is an important feature for customers.  

Bug Fixes

Nova

  • CLI Resizes by admins are checked against the wrong project quota
  • Resizing instances exhausts quota
  • “nova server-group-list” does not show members of the group
  • Deadlocks during concurrent quota reservations
  • Instances cannot be deleted if unplugging VIF fails

Keystone

  • User gets same group auth if IDs are the same
  • keystone.tenant.list_user returns user multiple times when user has multiple roles

Cinder

  • cinder-volume-usage-audit does not work with certain notifiers

Heat

  • Deletion of Stack containing servers fails
  • Heat engine stopping during delete results in stacks not being able to be deleted
  • Stacks cannot be deleted if they contain Nova network floating IPs

Known Issues

There are no known issues reported in this release.

Supported API Versions

Service API Version
Compute v2
Image v1
CloudFormation v1
Volume v1
EC2 N/A
Orchestration v1
Identity v2

Supported OpenStack Projects and Versions

Project Version
Nova Icehouse
Cinder Icehouse
Keystone Icehouse
Glance Icehouse
Heat Juno
Horizon Icehouse

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