Operate Resources in Public and Private Clouds Thanks to OpenStack

OpenStack needs, at least, 6 Go of RAM to run. And plenty more to start VMs on it. Therefore, this lab relies on Grid’5000, a testbed for experimental research, to acquire a Lab machine larger than your personal one. The Lab machine is a Ubuntu20.04 with 128Go of RAM and 32 CPU cores. This should be enough resources for this lab!

The lab makes use of Snap microstack: OpenStack in a Snap that you can run locally on a single machine. Snap is the Canonical’s App delivery mechanism. It enables developers to bundle all dependencies into a single app package. And so does Snap microstack for an all-in-one OpenStack on your machine.

An all-in-one OpenStack means that your machine will contain both services to operate and host virtualized resources. For instance, the nova-conductor to operate the boot of a VM, and nova-compute to host the VM. This is a good setup for a lab, but not for production. There are several other options such as DevStack, Puppet-OpenStack or Kolla-ansible and all matters. But, Snap microstack takes only 2 minutes to deploy OpenStack (instead of 30 minutes for other options).

Find the assignation list of Lab machine per student on the collaborative editor https://notes.inria.fr/2DjGmcZ6TwiQ0q8sSQO2gw.

First thing first, you have to connect to the Lab machine. Unfortunately, the Lab machine isn’t available publicly, but hides behind the Grid’5000 private network. One solution, as explained in the official tutorial, consists in opening an SSH connection to the publicly available access.grid5000.fr machine, and from there, doing a second SSH connection to the Lab machine. But this solution is fairly limited since it doesn’t give an access to services from your own machine¹.

To ease the interaction between your own machine and the Lab one, you should setup the Grid’5000 VPN. The Grid’5000 VPN gives you access to the Grid’5000 private network and thus, Lab machines wherever your are on the globe.

Next gives you the procedure on Ubuntu, but should be similar on other UNIX systems. You can also do it on Windows, however expect to be on your own in case of troubles.

1. Install the OpenVPN client

   sudo apt update -y && sudo apt install -y openvpn
   
   

2. Go on UMS > “My Account” tab > “VPN certificates” item.
3. “Create new certificate” > “Create with passphrase”, and fill the form with a new password (remember it!).

4. Click on “Zip file” Action > store it somewhere on your personal machine > unzip it. If the unzip program is unavailable, install it with sudo apt install unzip.

   unzip <g5k_login>_vpnclient.zip -d g5k_vpnclient
   
   

5. Run OpenVPN client with sudo

   cd g5k_vpnclient; sudo openvpn Grid5000_VPN.ovpn
   
   

6. Fill in the password of Step 3 to the question Enter Private Key Password:.

You correctly setup the VPN and can access Grid’5000 private network if your shell hangs and you see the following route in your routing table.

$ ip route

# ...
10.0.0.0/8 via 172.20.255.254 dev tun0
172.16.0.0/16 via 172.20.255.254 dev tun0
172.20.0.0/16 via 172.20.255.254 dev tun0
172.20.192.0/18 dev tun0 proto kernel scope link src 172.20.192.5
# ...

You can finally connect to your Lab machine in another shell with the following SSH command. Use lab-os as password.

ssh -l root <ip-of-your-lab-machine>

The rest of this lab proceeds on the Lab machine.

Don’t forget to use tmux! (see the pad)

Get the resources of the lab at https://raw.githubusercontent.com/Marie-Donnie/lectures/master/2021-2022/os-imt/tp.tar.gz:

curl https://raw.githubusercontent.com/Marie-Donnie/lectures/master/2021-2022/os-imt/tp.tar.gz -o tp.tar.gz -L
tar xzf tp.tar.gz
cd lab-os
chmod -R u+x rsc
chown -R root:root rsc

The archive contains:

setup.sh

Script that sets up the lab.

teardown.sh

Script that uninstalls the lab.

rsc

Resource directory with bash scripts useful for the lab.

Install snap.

sudo apt update
sudo apt install snapd

Install the latest version of OpenStack from the snap store.

sudo snap install microstack --beta --devmode

Execute the setup.sh file with sudo to initialize OpenStack (setup networks, flavors, images, …).

sudo ./setup.sh

snap services microstack|sort

One service deployed is the OpenStack dashboard (Horizon). On your own machine, horizon is reachable from the web browser at https://<ip-of-your-lab-machine> with the following credentials:

• login: admin
• password: lab-os

From here, you can reach Project > Compute > Instances > Launch Instance and boot a virtual machine given the following information:

• a name (e.g., horizon-vm)
• an image (e.g., cirros) and set the Create New Volume to “No”
• a flavor to limit the resources of your instance (we recommend m1.tiny)
• and a network setting (must be test)

You should select options by clicking on the big arrow on the right of each possibility. When the configuration is OK, the Launch Instance button should be enabled. After clicking on it, you should see the instance in the Active state in less than a minute.

Now, you have several options to connect to your freshly deployed VM. For instance, after clicking on its name, Horizon provides a virtual console under the Console tab. So, you can use the following credentials to access the VM:

• login: cirros
• password: gocubsgo

However, as a real DevOps, you will prefer to access to your VM by the command line interface …

While Horizon is helpful to discover OpenStack features, this is not the tool of choice for an operator. An operator prefers command line interface 😄. You are lucky, OpenStack provides one.

All operations to manage OpenStack are done through one unique command line, called openstack <service> <action> .... Doing an openstack --help displays the really long list of services/possibilities provided by this command. The following gives you a selection of the most often used commands to operate your Cloud:

List OpenStack running services

openstack endpoint list

List images

openstack image list

List flavors

openstack flavor list

List networks

openstack network list

List computes

openstack hypervisor list

List VMs (running or not)

openstack server list

Get details on a specific VM

openstack server show <vm-name>

Start a new VM

openstack server create --image <image-name> --flavor <flavor-name> --network <network-name> <vm-name>

View VMs logs

openstack console log show <vm-name>

$ openstack endpoint list
Missing value auth-url required for auth plugin password

openstack server list --os-auth-url=https://<ip-of-your-lab-machine>:5000/v3/ \
                        --os-username=admin \
                        --os-password=lab-os \
                        --os-project-name=admin \
                        --os-user-domain-name=Default \
                        --os-project-domain-id=default

source ./admin-openrc.sh

$ env|fgrep OS_|sort

OS_AUTH_URL=http://<ip-of-your-lab-machine>:5000/v3/
OS_IDENTITY_API_VERSION=3
OS_INTERFACE=public
OS_PASSWORD=lab-os
OS_PROJECT_DOMAIN_ID=default
OS_PROJECT_ID=2bad71b9246a4a06a0c9daf2d8896108
OS_PROJECT_NAME=admin
OS_REGION_NAME=microstack
OS_USER_DOMAIN_NAME=Default
OS_USERNAME=admin

openstack server create \
  --image cirros \
  --flavor m1.tiny \
  --network test \
  cli-vm

Then, display the information about your VM with the following command:

openstack server show cli-vm

Note in particular the status of your VM.

openstack server show cli-vm -c status -f json

This status will go from BUILD: OpenStack is looking for the best place to boot the VM; to ACTIVE: your VM is running. The status could also be ERROR if you are experiencing hard times with your infrastructure.

$ openstack server create --help | fgrep -A 6 "output formatters:"
output formatters:
  output formatter options

  -f {json,shell,table,value,yaml}, --format {json,shell,table,value,yaml}
                        the output format, defaults to table
  -c COLUMN, --column COLUMN
                        specify the column(s) to include, can be repeated

A VM in ACTIVE state still has to go through the boot process and init. Hence, you may still have to wait for one minute or two that your VM finishes to boot. You can check that your VM finished to boot by looking at its logs with openstack console log show cli-vm. A CirrOS VM finished to boot when last lines are:

=== cirros: current=0.4.0 latest=0.4.0 uptime=29.16 ===
  ____               ____  ____
 / __/ __ ____ ____ / __ \/ __/
/ /__ / // __// __// /_/ /\ \
\___//_//_/  /_/   \____/___/
   http://cirros-cloud.net


login as 'cirros' user. default password: 'gocubsgo'. use 'sudo' for root.
cli-vm login:

Any cirros VMs share the same credentials (i.e., cirros, gocubsgo) which is a security problem. As a IaaS DevOps, you want that only some clients can SSH on the VMs. Fortunately, OpenStack helps with the management of SSH keys. OpenStack can generate a SSH key and push the public counterpart on the VM. Therefore, doing a ssh on the VM will use the SSH key instead of asking the client to fill the credentials.

Make an SSH key and store the private counterpart in ./admin.pem. Then, give that file the correct permission access.

openstack keypair create --private-key ./admin.pem admin
chmod 600 ./admin.pem

Start a new VM and ask OpenStack to copy the public counterpart of your SSH key in the ~/.ssh/authorized_keys of the VM (i.e., note the --key-name admin).

openstack server create --wait --image cirros \
  --flavor m1.tiny --network test \
  --key-name admin cli-vm-adminkey

Attach it a floating IP.

openstack server add floating ip \
  cli-vm-adminkey \
  $(openstack floating ip create -c floating_ip_address -f value external)

Now you can access your VM using SSH without filling credentials.

openstack server ssh cli-vm-adminkey \
  --login cirros \
  --identity ./admin.pem

ssh -i ./admin.pem -l cirros $(openstack server show cli-vm-adminkey -c addresses -f value | sed  -Er 's/test=.+ (10\.20\.20\.[0-9]+).*/\1/g')

openstack server show cli-vm-adminkey -c addresses -f value | sed  -Er 's/test=.+ (10\.20\.20\.[0-9]+).*/\1/g'

Contextualizing is the process that automatically installs software, alters configurations, and does more on a machine as part of its boot process. On OpenStack, contextualizing is achieved thanks to cloud-init. It is a program that runs at the boot time to customize the VM.

You have already used cloud-init without even knowing it! The previous command openstack server create with the --identity parameter tells OpenStack to make the public counterpart of the SSH key available to the VM. When the VM boots for the first time, cloud-init is (among other tasks) in charge of fetching this public SSH key from OpenStack, and copy it to ~/.ssh/authorized_keys. Beyond that, cloud-init is in charge of many aspects of the VM customization like mounting volume, resizing file systems or setting an hostname (the list of cloud-init modules can be found here). Furthermore, cloud-init is able to run a bash script that will be executed on the VM as root during the boot process.

Every time you do an openstack server create ..., your request hits, at some point, the nova services. It starts by the nova-api that processes the REST request. The API, in turn, calls the nova-conductor that orchestrates the boot: performs some checks, finds eligible computes and chooses one to transmit the boot order to its nova-compute. Finally, the nova-compute asks to the underlying hypervisor to start the VM.

In your current setup, the hypervisor of your nova-compute runs QEMU. QEMU is a free emulator for hardware virtualization. It supports a large variety of guest operating systems, but the emulation is a bit slow. Fortunately, QEMU can be used with KVM to run virtual machines at near-native speed. KVM (Kernel-based Virtual Machine) is a free full virtualization solution for Linux that takes advantage of x86 hardware extensions (Intel VT or AMD-V).

To check if the x86 of your Lab machine provides hardware virtualization, execute the following command.

egrep -c '(vmx|svm)' /proc/cpuinfo

If it outputs a number greater than 0, then proceed with the following to speed up the VMs execution. Seek the Nova documentation for some help.

Finally, create a new VM such as in the previous section and appreciate how fast your VM displays the figlet "The Art of Contextualizing a VM with KVM" | lolcat command.

$ microstack.virsh list
$ microstack.virsh edit instance-0000005
<domain="kvm">
...

In this last part, the teacher has setup an OpenStack in a DataCenter (here, on top of Grid’5000) and created member account and project for each of you (not admin). As a preamble, you should connect to the Grid’5000 VPN (Sec. 1.2) and then do the following. You can do it on your own machine, or from the rennes frontend (ssh <user>@access.grid5000.fr and ssh rennes).

• Install the OpenStack CLI and Heat CLI. Here is the process for Grid’5000. You may omit the 3 first lines if you do it on your own machine.

  $ pip3 install --upgrade --user pip
  $ echo "export PATH=~/.local/bin:${PATH}" >> ~/.profile
  $ source ~/.profile
  $ pip install --user python-openstackclient python-heatclient
  

• Import the source of this lab (Sec. 1.3).
• Go on the horizon dashbord of teacher’s OpenStack and download the “OpenStack RC File” (Sec. 2.2) on your own machine.
  • user name: your Grid’5000 login
  • password: lab-os
• Source the “OpenStack RC File”.
• Create your admin SSH key (Sec. 2.3).

Resource names change a bit from previously. Do not hesitate to run some commands such as the following to know about new names.

• openstack network list
• openstack image list
• openstack flavor list
• …

The simplest HOT template you can declare describes how to boot a VM.

# The following heat template version tag is mandatory:
heat_template_version: 2017-09-01

# Here we define a simple decription of the template (optional):
description: >
  Simply boot a VM!

# Here we declare the resources to deploy.
# Resources are defined by a name and a type which described many properties:
resources:
  # Name of my resource:
  heat-vm:
    # Its type, here we want to define an OpenStack Nova server:
    type: "OS::Nova::Server"
    properties:
      name: hello_world      # Name of the VM
      image: debian-10       # Its image (must be available in Glance)
      flavor: m1.mini        # Its flavor (must exist in Nova)
      key_name: admin        # Name of its SSH Key (must exist in Nova)
      networks:              # List of networks to connect to
        - {network: private}

As depicted in this example, the different OpenStack resources can be declared using types. OpenStack resource types are listed in the documentation, browsing this page, you can see that resources exist for most OpenStack services (e.g. Nova, Neutron, Glance, Cinder, Heat). Here, we declare a new resource called heat-vm which is defined by the type OS::Nova::Server to declare a new virtual machine. A type specifies different properties (some are mandatory, some are optional, see the documentation for more details). The OS::Nova::Server properties should be familiar to you since it is the classical properties Nova requires to boot a VM (i.e. name, image, flavor, key name). Once you have written this template in a file, you can now deploy the stack as following:

openstack stack create -t ./rsc/heat-templates/1_boot_vm.yaml hw1
openstack stack list
openstack stack show hw1
watch openstack server list
openstack stack delete --wait --yes hw1

This simple template is enough to run a virtual machine. However, it is very static. In the next subsection, we are going to manipulate parameters to add flexibility.

Templates can be more flexible with parameters. To that end you can:

• Declare a set of parameters to provide to your template.
• Use the intrinsic function get_param to map those parameters in your resource declarations.

The next template is an example with four parameters. The first one is related to the VM name and must be provided during the stack creation. The second one is the name of the VM image with a debian-10 as default value. The third argument corresponds to the flavor and defaults to m1.small. Finally, the last one defines the SSH key to use and defaults to admin.

heat_template_version: 2017-09-01

description: >
    Simply boot a VM with params!

# Here we define parameters
# Parameters have a name, and a list of properties:
parameters:
  the_vm_name:
    type: string                     # The type of the parameter (required)
    description: Name of the server  # An optional description
  the_image:
    type: string
    description: Image to use for servers
    default: debian-10               # An optional default value
  the_flavor:
    type: string
    description: Flavor to use for servers
    default: m1.small
  the_key:
    type: string
    description: Key name to use for servers
    default: admin

# Here we use intrinsic functions to get the parameters:
resources:
  heat-vm:
    type: "OS::Nova::Server"
    properties:
      name:     { get_param: the_vm_name }
      image:    { get_param: the_image }
      flavor:   { get_param: the_flavor }
      key_name: { get_param: the_key }
      networks:
       - {network: private}

To deploy this stack, run the next command. It deploys the VM by overriding the default flavor value m1.mini with m1.small. This can be checked in openstack server list.

openstack stack create -t ./rsc/heat-templates/2_boot_vm_with_params.yaml \
  --parameter the_vm_name=hello_params \
  --parameter the_flavor=m1.small \
  hw2
openstack server list
openstack stack delete --wait --yes hw2

The parameter the_vm_name is required since no default value is provided. If you try to create a stack without providing this parameter, you end with an error.

openstack stack create -t ./rsc/heat-templates/2_boot_vm_with_params.yaml \
    --parameter the_flavor=m1.medium \
    hw2_error

ERROR: The Parameter (the_vm_name) was not provided.

Parameters are the inputs of templates. The next subsection, focuses on declaring outputs, so that a stack can return a set of attributes (e.g., the IP address of a deployed VM).

Templates can declare a set of attributes to return. For instance, you might need to know the IP address of a resource at runtime. To that end, you can declare attributes in a new section called outputs:

heat_template_version: 2017-09-01

description: >
  Boot a VM and return its IP address!

resources:
  heat-vm:
    type: "OS::Nova::Server"
    properties:
      name: hello_outputs
      image: debian-10
      flavor: m1.mini
      key_name: admin
      networks:
        - { network: private }

# We set here outputs (stack returned attributes).
# Outputs are defined by a name, and a set of properties:
outputs:
  HOSTIP:
    # The description is optional
    description: IP address of the created instance
    # Use `get_attr` to find the value of `HOSTIP`. The `get_attr`
    # function references an attribute of a resouces, here the
    # `addresses.private[0].addr` of `heat-vm`.
    #
    # The following should be read:
    # - on `heat-vm` resource (which is an object ...)
    # - select the `addresses` attribute (which is an object ...)
    # - select the `private` attribute (which is a list ...)
    # - pick the element at indices `0` (which is an object ...)
    # - select the `addr` attribute (which is a string)
    value: { get_attr: [heat-vm, addresses, private, 0, addr] }
  HOSTNAME:
    description: Hostname of the created instance
    value: { get_attr: [heat-vm, name] }

The template declares an output attribute called HOSTIP which stores the IP address of the VM resource. To find the IP address, it uses another intrinsic function: get_attr. Same with the HOSTNAME output. Output attributes can be exploited in two ways: they can be displayed from the CLI, or they can be fetched by other stack templates (we will see this last case latter):

openstack stack create -t ./rsc/heat-templates/3_boot_vm_with_output.yaml hw3
openstack stack output list hw3
openstack stack output show hw3 HOSTIP

get_attr: [heat-vm, networks, private, 0]

get_attr: [heat-vm, first_address]

python -c "import pprint; pprint.pprint($(openstack stack resource show hw3 heat-vm -c attributes -f value))"

{u'OS-DCF:diskConfig': u'MANUAL',
 # ...
 u'addresses': {u'private': [{u'OS-EXT-IPS-MAC:mac_addr': u'fa:16:3e:73:10:fe',
                           u'OS-EXT-IPS:type': u'fixed',
                           u'addr': u'192.168.222.84',
                           u'version': 4}]},
 # ...
 u'image': {u'id': u'3c91bbf5-5d1f-4e72-bf77-6dbc19c8351c',
            u'links': [{u'href': u'http://10.20.20.1:8774/images/3c91bbf5-5d1f-4e72-bf77-6dbc19c8351c',
                        u'rel': u'bookmark'}]},
 # ...
 u'name': u'hello_outputs'}

Remember to delete your stack at the end to release resources.

openstack stack delete --wait --yes hw3

It is possible to declare a post-installation script in the template with the user_data property.

heat_template_version: 2017-09-01

description: >
  Boot a VM with a post-installation script!

resources:
  heat-vm:
    type: "OS::Nova::Server"
    properties:
      name: hello_cloud_init
      image: debian-10
      flavor: m1.mini
      key_name: admin
      networks:
        - { network: private }
      # We set here the user-data:
      user_data: |
        #!/usr/bin/env bash

        # Fix DNS resolution
        echo "" > /etc/resolv.conf
        echo "nameserver 8.8.8.8" >> /etc/resolv.conf

        # Install stuff and configure the MOTD
        apt-get update
        apt-get install -y fortune fortunes cowsay lolcat
        echo "#!/usr/bin/env bash" > /etc/profile.d/cowsay.sh
        echo "fortune | cowsay -n | lolcat" >> /etc/profile.d/cowsay.sh

openstack stack create -t ./rsc/heat-templates/4_boot_vm_with_user-data.yaml hw4

Associating a floating IP is a bit tricky with Heat, so let’s do it manually for now. Then, wait for cloud-init to finish and finally, SSH on the VM (the wait_contextualization function comes from section 2.4.2).

openstack server add floating ip hello_cloud_init \
  $(openstack floating ip create -c floating_ip_address -f value public)
wait_contextualization hello_cloud_init
openstack server ssh --login debian --identity ./admin.pem hello_cloud_init
openstack stack delete --wait --yes hw4

Let’s mix parameters and cloud-init to write a template with a flexible post-installation script. With Heat, it is possible to provide a parameter to your user-data at run-time by using a new intrinsic function: str_replace.

heat_template_version: 2017-09-01

description: >
  Boot a VM by installing a set of packages given as parameters!

parameters:
  package-names:
    label: List of packages to install
    type: string

resources:
  heat-vm:
    type: "OS::Nova::Server"
    properties:
      name: hello_cloud_init_params
      image: debian-10
      flavor: m1.mini
      key_name: admin
      networks:
        - { network: private }
      user_data:
        # This intrinsic function can replace strings in a template
        str_replace:
          # We define here the script
          template: |
              #!/usr/bin/env bash
              apt-get update
              apt-get install -y ${PKG-NAMES}
          # We define here the parameters for our script
          params:
            ${PKG-NAMES}: { get_param: package-names }

The template uses str_replace to instantiate variables in the template. In this example, the parameter should be a string containing a set of packages to install in the VM. You can deploy the stack as follow:

openstack stack create \
    -t ./rsc/heat-templates/5_boot_vm_with_user-data2.yaml \
    --parameter package-names="vim cowsay fortune fortunes lolcat" \
   hw5
openstack stack delete --wait --yes hw5

This mechanism is crucial to dynamically configure our services during the deployment. For instance, service-A might require an IP address in its configuration file to access service-B, which runs on another VM. This IP address is only known at run-time, so it must be represented by a variable managed in Heat templates. In the next subsections, we are going to study how to declare such variable, so that Heat resources can exchange information.

Let’s declare a template with two VMs: user and provider. The idea is to configure user’s static lookup table for hostnames (more information can be found by typing: man hosts), so that user can target provider from its hostname rather than its IP address. To that end, the template uses the user_data property together with the get_attr function to edit the /etc/hosts file on user, and map the IP address of provider with its hostname.

heat_template_version: 2017-09-01

description: >
  Boot two VMs and ease the access from user to provider!

resources:
  user-vm:
    type: "OS::Nova::Server"
    properties:
      name: user
      image: debian-10
      flavor: m1.mini
      key_name: admin
      networks:
        - { network: private }
      user_data:
        str_replace:
          template: |
            #!/usr/bin/env bash
            # With the following line, provider is reachable from its hostname
            echo "${IP_ADDRESS} provider" >> /etc/hosts
          params:
            # `get_attr` references the following `provider-vm` resource.
            ${IP_ADDRESS}: { get_attr: [provider-vm, addresses, private, 0, addr] }

  provider-vm:
    type: "OS::Nova::Server"
    properties:
      name: provider
      image: debian-10
      flavor: m1.mini
      key_name: admin
      networks:
        - { network: private }

In this example, user requires the IP address of provider to boot. The Heat engine is in charge of managing dependencies between resources. Take a look during the deployment, and check that provider is deployed prior to user.

openstack stack create -t ./rsc/heat-templates/6_boot_vms_with_exchange.yaml hw6 \
  && watch openstack server list
openstack server add floating ip user \
  $(openstack floating ip create -c floating_ip_address -f value public)
openstack server ssh --login debian --identity ./admin.pem --address-type public user
debian@user:~$ ping provider -c 2
PING provider (192.168.222.238) 56(84) bytes of data.
64 bytes from provider (192.168.222.238): icmp_seq=1 ttl=64 time=1.27 ms
64 bytes from provider (192.168.222.238): icmp_seq=2 ttl=64 time=3.07 ms

debian@user:~$ exit
openstack stack delete --wait --yes hw6

Heat is able to compose templates to keep human-readable files, using nested templates. For instance, we can use a first template that describes a virtual machine, and a second template which deploys multiple VMs by referencing the first one. Rather than creating the first template, we can re-use the one from section 4.3.

heat_template_version: 2017-09-01

description: >
  Boot two different VMs by exploiting nested templates!

resources:
  provider-vm:
    # Template can be provided as resource type (relatively to
    # that template)
    type: ./2_boot_vm_with_params.yaml
    # The related properties are given as template's parameters:
    properties:
      the_vm_name: provider
      the_flavor: m1.mini

  user-vm:
    type: ./2_boot_vm_with_params.yaml
    properties:
      the_vm_name: user

To compose a template, a new resource can be defined by specifying its type as the target of the desired template. A set of properties can be provided to the nested template and will be interpreted as parameters.

openstack stack create -t ./rsc/heat-templates/7_nested_template.yaml hw7 \
  && watch openstack server list
openstack stack delete --wait --yes hw7

Nested templates are very convenient to keep your code clean and re-usable. Next section extends nested templates with data dependency.

Let’s describe the same deployment as in section 4.7 by using nested templates. For that we need a new template:

heat_template_version: 2017-09-01

description: >
  Boot a VM, ease access to a remote host and return its IP address!

parameters:
  the_vm_name:
    type: string
    description: Name of the server
  the_remote_hostname:
    type: string
    description: Host name of the remote host
    default: provider
  the_remote_ip:
    type: string
    description: IP address of the remote host

resources:
  hostname-vm:
    type: "OS::Nova::Server"
    properties:
      name:     { get_param: the_vm_name }
      image:    debian-10
      flavor:   m1.mini
      key_name: admin
      networks:
        - {network: private}
      user_data:
        str_replace:
          params:
            ${HOSTNAME}: { get_param: the_remote_hostname }
            ${IP_ADDRESS}: { get_param: the_remote_ip }
          template: |
            #!/usr/bin/env bash
            # With the following line, the remote host is reachable from its hostname
            echo "${IP_ADDRESS} ${HOSTNAME}" >> /etc/hosts

outputs:
  HOSTIP:
    description: IP address of the created instance
    value: { get_attr: [hostname-vm, networks, private, 0] }

We can now declare the main template. While it defines three VMs, this template is easy to read since it points to the template created previously and template in section 4.4.

heat_template_version: 2017-09-01

description: >
  Boot three VMs and ease the access to provider using nested
  templates!

resources:
  provider-vm:
    type: ./3_boot_vm_with_output.yaml

  user-vm1:
    type: ./8_nested_template_boot_vm.yaml
    properties:
      the_vm_name: user1
      the_remote_ip: { get_attr: [provider-vm, HOSTIP] }
      the_remote_hostname: { get_attr: [provider-vm, HOSTNAME] }

  user-vm2:
    type: ./8_nested_template_boot_vm.yaml
    properties:
      the_vm_name: user2
      the_remote_ip: { get_attr: [provider-vm, HOSTIP] }
      the_remote_hostname: { get_attr: [provider-vm, HOSTNAME] }

openstack stack create -t ./rsc/heat-templates/8_nested_template_exchange.yaml hw8 \
  && watch openstack server list
openstack stack delete --wait --yes hw8

It’s Floating IP time!

heat_template_version: 2017-09-01

description: >
  Boot a VM and associate a floating IP.

resources:
  server:
    type: OS::Nova::Server
    properties:
      name: hello_fip
      image: debian-10
      flavor: m1.mini
      key_name: admin
      networks:
        - { network: private }

  floating-ip:
    type: OS::Neutron::FloatingIP
    properties:
      floating_network: public

  association:
    type: OS::Neutron::FloatingIPAssociation
    properties:
      floatingip_id: { get_resource: floating-ip }
      port_id: { get_attr: [server, addresses, private, 0, port]}

openstack stack create -t ./rsc/heat-templates/9_floating_ip.yaml --wait hw9

You may find the floating IP by listing servers.

openstack server list

Or by asking Heat about attributes of the floating-ip resource.

FIP_RSC_ATTRIBUTES=$(openstack stack resource show -c attributes -f value hw9 floating-ip)
python -c "print('floating ip is %s' % ${FIP_RSC_ATTRIBUTES}['floating_ip_address'])"

Remember to delete your stack at the end to release resources.

openstack stack delete --wait --yes hw9