Names

"What's in a name?"

Introduction

To achieve idempotent behavior, the names of blueprint resources are considered identifiers. In some venues (Azure) the name is part of the resource's identity, while in others (AWS) the name is handled as a tag and has nothing do with the identity. In the Tuono Schema, the name is normally expressed as part of the resource path:

storage:
  disk:
    records:               # blueprint name
      size: 2 TiB
      type: ssd

In this example the blueprint name of the disk is records. The fully qualified blueprint name of the disk is storage.disk.records.

Naming

Blueprint names have specific naming rules:

• Names must begin and end with an alphanumeric.

• Names may contain alphanumeric, hyphens, or underscores.

• Names must be between 2 and 63 characters in length.

Some valid names for resources:

• mysql-server

• MySqlServer

• dataDisk-3

• vm_0

The period character (.) is a path separator in the Tuono Schema and is not allowed in a blueprint name, however if you want to use a period in your resource's name, you can specifically declare a name property:

storage:
  disk:
    records:               # blueprint name
      name: records.safe   # resource name
      size: 2 TiB
      type: ssd

In this example, after provisioning the disk would have the name records.safe in the venue. During blueprint loading if a resource has no name property, it is derived from the blueprint name.

Our blueprint name regular expression is:

^(?:[a-zA-Z0-9])(?:[a-zA-Z0-9\-_]{0,61})?(?:[a-zA-Z0-9])$

Renaming

Names are an immutable part of the resources you provision, therefore changing the name of a resource is the same as declaring a new resource. If you rename something in a blueprint, you are telling the provisioning engine:

1. I no longer need the resource named old name.

2. Please make me a resource named new name.

Renaming a folder in particular can cause quite a bit of churn, since the folder and all of its contents will be destroyed and then re-provisioned in the new folder.

Do not rename resources unless it is critical and you can tolerate service interruption.

Why?

On Azure, the name is an immutable component in a resource's identity, therefore changing the name is impossible. Resource Groups (which equate to Tuono Folders) also have an immutable name.

In AWS names are more flexible, but only in the EC2 resource space. In many other subsystems, names are an immutable part of resource identities (S3, ACM, ELBv2, ...).

Standardizing on names as part of resource identities is one reason why blueprints are portable across venues.

Auto-Naming

We automatically apply intelligent naming rules to your resources so they are more easily located in the venue management interface. We designed our auto-naming to ensure resources are:

• Easily identified as being part of something bigger.

• Sorted together when sorting by name.

• Following (or perhaps, leading) industry best practices.

Auto-Naming is particularly useful for resources that are consumed by other resources, for example a subnet in a virtual network, or a disk inside a virtual machine. When looking at a list of resources, having the virtual machine and the disk appear close to (or next to) each-other in the resource list is preferable. Consider a blueprint that creates a network interface (NIC):

location:
  region:
    preferred:
      country: USA
      area: northwest
  folder:
    example:
      region: preferred

networking:
  network:
    test:
      range: 10.0.0.0/16
      public: true
  subnet:
    public:
      network: test
      range: 10.0.0.0/24
      public: true
  firewall:
    only-ssh-access:
      rules:
        - action: allow
          from: any
          to: self
          protocol: ssh
  protocol:
    ssh:
      rules:
        - port: 22
          proto: tcp

compute:
  nic:
    external:
      firewall: only-ssh-access
      ips:
        - private:
            type: dynamic
          public:
            type: static
      subnet: public

If during provisioning we created a nic named "external" or a subnet named "public", that may be sufficient for a small number of resources. These resources would quickly become more difficult to locate as more resources are deployed. To solve this, we apply prefix and suffix auto-naming based on the references between resources. For this example, a subnet will be named based on the network it is in, and a NIC will be named based on the subnet it is connected to:

Class	Blueprint Name	Resource Auto-Name
networking.subnet	public	test-public
compute.nic	external	external-test-public

If the NIC were to be consumed by a virtual machine named mysql then the nic auto-name would become mysql-external-test-public which is an understandable name for a nic. It contains both sides of the nic - what it is "plugged into" inside (a vm) and outside (a subnet), virtually. In a list of nics you can immediately recognize the vm it belongs to and what it is connected to.

Disabling Auto-Naming

If you declare a name property in the blueprint, auto-naming is disabled.

Renaming

Names are part of the resource identity, therefore renaming is a complex and multi-step operation that can lead to service interruption. The following blueprint modifications will lead to resources being destroyed and re-created:

• Changing the name property of a resource.

• Changing the blueprint name of a resource that has no name property explicitly defined.

The preferred method to rename resources is to destroy the environment, modify the names of resources in blueprints, and then apply the environment.

It is possible to rename resources already deployed into AWS by visiting the AWS Management Console and modifying the name tag on the resources in question, then modifying the blueprint and applying it. It is not possible to do this on Azure, as the name is inherently part of the resource identification.