The Newton release of Heat adds support for a yaql intrinsic function, which allows you to evaluate yaql expressions in your Heat templates. Unfortunately, the existing yaql documentation is somewhat limited, and does not offer examples of many of yaql’s more advanced features.

I am working on a Fluentd composable service for TripleO. I want to allow each service to specify a logging source configuration fragment, for example:

parameters:
  NovaAPILoggingSource:
    type: json
    description: Fluentd logging configuration for nova-api.
    default:
      tag: openstack.nova.api
      type: tail
      format: |
        /(?<time>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}.\d+) (?<pid>\d+) (?<priority>\S+) (?<message>.*)/
      path: /var/log/nova/nova-api.log
      pos_file: /var/run/fluentd/openstack.nova.api.pos

This generally works, but several parts of this fragment are going to be the same across all OpenStack services. I wanted to reduce the above to just the unique attributes, which would look something like:

Next week is the Red Hat Summit in Boston, and I’ll be taking part in a Project Atomic presentation in which I will discuss various (well, two) options for deploying Atomic into an OpenStack environment, focusing on my heat-kubernetes templates.

As part of that presentation, I’ve put together a short demonstration video:

This shows off the autoscaling behavior available with recent versions of these templates (and also serves as a very brief introduction to working with Kubernetes).

I ran a Google Hangout this morning on Deploying with Heat. You can find the slides for the presentation on line here, and the Heat templates (as well as slide sources) are available on github.

If you have any questions about the presentation, please feel free to ping me on irc (larsks).

I spent some time today learning about Heat autoscaling groups, which are incredibly nifty but a little opaque from the Heat command line, since commands such as heat resource-list don’t recurse into nested stacks. It is possible to introspect these resources (you can pass the physical resource id of a nested stack to heat resource-list, for example)…

…but I really like visualizing things, so I wrote a quick hack called dotstack that will generate dot language output from a Heat stack. You can process this with Graphviz to produce output like this, in which graph nodes are automatically colorized by resource type:

This is a companion to my article on the Docker plugin for Heat.

While writing that article, I encountered a number of bugs in the Docker plugin and elsewhere. I’ve submitted patches for most of the issues I encountered:

Bugs in the Heat plugin

• https://bugs.launchpad.net/heat/+bug/1364017

  docker plugin fails to delete a container resource in CREATE_FAILED state.

• https://bugs.launchpad.net/heat/+bug/1364041

  docker plugin volumes_from parameter should be a list.

• https://bugs.launchpad.net/heat/+bug/1364039

  docker plugin volumes_from parameter results in an error

This is a companion to my article on the Docker plugin for Heat.

DockerInc::Docker::Container

Properties

• cmd : List

  Command to run after spawning the container.

  Optional property.

  Example:

    cmd: [ 'thttpd', '-C', '/etc/thttpd.conf', '-D', '-c', '*.cgi']
  

• dns : List

  Set custom DNS servers.

  Example:

    dns:
      - 8.8.8.8
      - 8.8.4.4
  

• docker_endopint : String

  Docker daemon endpoint. By default the local Docker daemon will be used.

  Example:

    docker_endpoint: tcp://192.168.1.100:2375
  

• env : String

I have been looking at both Docker and OpenStack recently. In my last post I talked a little about the Docker driver for Nova; in this post I’ll be taking an in-depth look at the Docker plugin for Heat, which has been available since the Icehouse release but is surprisingly under-documented.

The release announcement on the Docker blog includes an example Heat template, but it is unfortunately grossly inaccurate and has led many people astray. In particular:

This post accompanies my article on the Docker plugin for Heat.

In order for WaitCondition resources to operate correctly in Heat, you will need to make sure that that you have:

• Created the necessary Heat domain and administrative user in Keystone,
• Configured appropriate values in heat.conf for stack_user_domain, stack_domain_admin, and stack_domain_admin_password.
• Configured an appropriate value in heat.conf for heat_waitcondition_server_url. On a single-system install this will often be pointed by default at 127.0.0.1, which, hopefully for obvious reasons, won’t be of any use to your Nova servers.
• Enabled the heat-api-cfn service,
• Configured your firewall to permit access to the CFN service (which runs on port 8000).

Steve Hardy has a blog post on stack domain users that goes into detail on configuring authentication for Heat and Keystone.

Heat is a template-based orchestration mechanism for use with OpenStack. With Heat, you can deploy collections of resources – networks, servers, storage, and more – all from a single, parameterized template.

In this article I will introduce Heat templates and the heat command line client.

Writing templates

Because Heat began life as an analog of AWS CloudFormation, it supports the template formats used by the CloudFormation (CFN) tools. It also supports its own native template format, called HOT (“Heat Orchestration Templates”). In this article I will be using the HOT template syntax, which is fully specified on the OpenStack website.