Authoring

Writing Effective Blueprints

Blueprints are written using the Tuono Schema. The Tuono Schema allows you create a portable description of your infrastructure that may be customized and reused. To make a blueprint you will need to understand some basics about the Tuono Schema.

We based our schema language on the popular YAML text format. YAML is an acronym that stands for “YAML Ain’t Markup Language” (which was clearly funny to someone, once), and is designed to be a human-friendly data file. Let’s familiarize ourselves with basic YAML concepts by defining a disk using the Tuono Schema:

# this is a comment

storage:                   # category
  disk:                    # class
    records:               # blueprint name
      size: 2 TiB          # properties of the disk
      type: ssd
      tags:
        # tags are key: value string pairs
        totally: awesome
    logs:
      size: 64gb
      type: hdd

One of the core design goals behind our schema is that it should be immediately recognizable and understandable if you are familiar with standard IT concepts such as disks, networks, and virtual machines. In this example we have defined two disks with different characteristics that are self-evident. Our schema language even allows for flexible units when describing size and throughput. Each disk is a separate resource that can be provisioned.

Comments in a blueprint start with a pound sign (#). Examples of whole-line and inline comments are shown above as well.

In a blueprint, any line without whitespace at the beginning declares a category. There can only be one category of a given name in a blueprint. If the same category is provided twice in the same blueprint, the first one is ignored (this is a known issue).

The next indentation are classes of items within that category. In this example we have a storage category and a disk class. There can be only one class of a given name in a category If the same class is provided twice in the same category, the first one is ignored (this is also a known issue).

At the third indentation level we are defining a resource within the disk class. In this example there are two disks defined. Each of these disks is considered an independent resource that will be provisioned. Their respective fully-qualified blueprint identities are storage.disk.records and storage.disk.logs.