Openstack Heat is an "orchestration tool" which is used to define a collection of virtual resources (Servers, networks, volumes, firewalls etc) which should be created in bulk. To define such a collection of resources you use text-files in a YAML format called the "Heat Orchestration Template", or HOT files. When a collection of resources is defined you can create one or more instances of that collection. A typical use-case can be to create a HOT-template describing a single lab-instance for a student-group, and then instantiate it multiple times to create multiple identical LAB scenarios.
Documentation
Heat is a large tool, with online documentation which is updated by the team developing Heat. The online documentation is found HERE, and it is recommended to familiarize yourself with it. It might be a bit overwhelming at first, so the guide on the following wiki-page might be a good starting-point to understand some of the Heat functionality.
Example-case
To demonstrate the use of heat we are going to create a virtual lab infrastructure consisting of two virtual servers connected to a single network. One of the servers should have an extra disk connected which it is going to share to the other using NFS, to demonstrate multiple bits of Heats functionality. We are going to create two Heat-templates for this example, one for some common resources needed by all the labs, and one for each server-pair. The following figure might help visualize the intended setup:
Common infrastructure
The common infrastructure is in this case a virtual network connected to a virtual switch. In addition we create a common firewall-group allowing traffic to/from our servers.
Base template structure
A heat-template is a YAML file, and the base structure looks something like so:
heat_template_version: 2018-08-31
description:
# a description of the template
parameters:
# declaration of input parameters
resources:
# declaration of template resources
outputs:
# declaration of output parameters
Basicly there is a block for inputs, a block for resources and a block for outputs.
Heat template for our common infrastructure
For our common infrastructure we do not need any inputs, but we would like to create som resources and give the ID of the created resources as output so that we can use them as inputs for other templates. This can result in a template looking like this:
heat_template_version: 2018-08-31
description: >
A template to create common base infrastructure for the heat-guide at
https://www.ntnu.no/wiki/display/skyhigh/Openstack+Heat
resources:
network:
type: OS::Neutron::Net
subnet_v4:
type: OS::Neutron::Subnet
properties:
network_id: { get_resource: network }
cidr: '192.168.0.0/24'
dns_nameservers: [ '129.241.0.200', '129.241.0.201' ]
ip_version: 4
router:
type: OS::Neutron::Router
properties:
external_gateway_info: { network: ntnu-internal }
router_interface_v4:
type: OS::Neutron::RouterInterface
properties:
router_id: { get_resource: router }
subnet: { get_resource: subnet_v4 }
secgroup_generic:
type: OS::Neutron::SecurityGroup
properties:
description: |
A security group allowing users connect to the VM's using ssh
rules:
- protocol: icmp
remote_ip_prefix: '0.0.0.0/0'
- protocol: tcp
port_range_min: 22
port_range_max: 22
remote_ip_prefix: '0.0.0.0/0'
- protocol: tcp
remote_ip_prefix: '192.168.0.0/24'
port_range_min: 111
port_range_max: 111
- protocol: udp
remote_ip_prefix: '192.168.0.0/24'
port_range_min: 111
port_range_max: 111
- protocol: tcp
remote_ip_prefix: '192.168.0.0/24'
port_range_min: 2049
port_range_max: 2049
- protocol: udp
remote_ip_prefix: '192.168.0.0/24'
port_range_min: 2049
port_range_max: 2049
- protocol: tcp
remote_ip_prefix: '192.168.0.0/24'
port_range_min: 32767
port_range_max: 32768
- protocol: udp
remote_ip_prefix: '192.168.0.0/24'
port_range_min: 32767
port_range_max: 32768
outputs:
network:
description: The network created by the template
value: { get_resource: network }
secgroup_generic:
description: The security-group allowing generiv VM access.
value: { get_resource: secgroup_generic }
Basically we are here telling heat to create a network for us (line 8-9) with a subnetwork connected to it (line 11-17). The subnetwork should use the address 192.168.0.0/24. Next up we create a router connected to the 'ntnu-internal' network, and attaching it to the newly created subnet. The final resource defined is a security-group allowing incoming ssh-connections from anywhere, incoming ICMP (ie: ping) from anywhere and incoming NFS-connections from any hosts at the supplied subnet.
The "get resource" functions used allows heat to reffer to resources it creates elsewhere in the template. For instance we reffer to the network "{ get_resource: network }" when creating the subnet, and that basicly means "use the ID from the network you are creating". As an alternative you could have given a network ID ther manually instead.
Actually create the resources defined in our template
When a template is defined it is possible to use it to create a "heat stack". A "stack" is the resources created based on a template, and you can create multiple stacks using the same template if you want to have multiple copies of the same infrastructure. Creating the stack can be done through both the webinterface and the commandline-client. Even though most of this article will use the commandline we will also show the creation of the first stack through the webclient.
Creating a Heat Stack in the webinterface
To create a Heat stack in the webinterface you should navigate to "Orchestration → Stacks" and click the "Launch Stack" button. There you can either select template-files from your computer, or you can paste the templates into text-fields.
After a little bit of time the stack should be "Create Complete", and you can now browse the networks/routers/security group pages to see the newly created resources.
Creating a Heat Stack using the command line
Creating a heat-stack using the commandline is done through the use of a single "openstack stack create" command. The stacks can be listed afterwards using the "openstack stack list" command.
$ openstack stack create -t common.yaml Common-CLI
+---------------------+-------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+---------------------+-------------------------------------------------------------------------------------------------------------------+
| id | 925313a9-be62-45ef-80f2-f811e57fe4fa |
| stack_name | Common-CLI |
| description | A template to create common base infrastructure for the heat-guide at |
| | https://www.ntnu.no/wiki/display/skyhigh/Openstack+Heat |
| | |
| creation_time | 2022-08-30T14:07:36Z |
| updated_time | None |
| stack_status | CREATE_IN_PROGRESS |
| stack_status_reason | Stack CREATE started |
+---------------------+-------------------------------------------------------------------------------------------------------------------+
$ openstack stack list
+--------------------------------------+------------+-----------------+----------------------+--------------+
| ID | Stack Name | Stack Status | Creation Time | Updated Time |
+--------------------------------------+------------+-----------------+----------------------+--------------+
| 925313a9-be62-45ef-80f2-f811e57fe4fa | Common-CLI | CREATE_COMPLETE | 2022-08-30T14:07:36Z | None |
+--------------------------------------+------------+-----------------+----------------------+--------------+
Displaying the status of the heat stack.
Navigating using the web-client lets us see the resources created and managed by the stack, and also the output from the stack. In this case the output is the ID of the created network and the ID of the created security group.
The same information is also available through the CLI:
$ openstack stack show Common
+-----------------------+-----------------------------------------------------------------------------------------------------------------+
| Field | Value |
+-----------------------+-----------------------------------------------------------------------------------------------------------------+
| id | 2abc3c47-044a-4075-a1f6-422ee49376d8 |
| stack_name | Common |
| description | A template to create common base infrastructure for the heat-guide at |
| | https://www.ntnu.no/wiki/display/skyhigh/Openstack+Heat |
| | |
| creation_time | 2022-08-30T13:51:20Z |
| updated_time | None |
| stack_status | CREATE_COMPLETE |
| stack_status_reason | Stack CREATE completed successfully |
| parameters | OS::project_id: 74729572aad24d93b9a4cac7301ef9d1 |
| | OS::stack_id: 2abc3c47-044a-4075-a1f6-422ee49376d8 |
| | OS::stack_name: Common |
| | |
| outputs | - description: The security-group allowing generiv VM access. |
| | output_key: secgroup_generic |
| | output_value: 30586c14-7bc1-4ef4-91dc-2089eb32ec23 |
| | - description: The network created by the template |
| | output_key: network |
| | output_value: db265ea1-1d85-47f1-ba3a-714174da114e |
| | |
| links | - href: https://api.stack.it.ntnu.no:8004/v1/74729572aad24d93b9a4cac7301ef9d1/stacks/Common/2abc3c47-044a-4075- |
| | a1f6-422ee49376d8 |
| | rel: self |
| | |
| deletion_time | None |
| notification_topics | [] |
| capabilities | [] |
| disable_rollback | True |
| timeout_mins | 60 |
| stack_owner | eigilo |
| parent | None |
| stack_user_project_id | 9865a03e9eb042bc9de03578a9eca6ed |
| tags | [] |
| | |
+-----------------------+-----------------------------------------------------------------------------------------------------------------+
Student Lab
The second template we are going to create two virual machies; one fileserver connected to an extra volume and one client connecting to this fileserver. This template should be possible to start multiple times to create multiple machines. It will also demonstrate how to configure machines using both cloud-config and shell-scripts.
Parameters
This template should be able to recieve parameters when it is created, to allow variations of the template being created. Parameters can in heat be defined like so:
parameters:
flavor:
type: string
label: Fileserver flavor
description: The flavor used to spawn the fileserver
constraints:
- custom_constraint: nova.flavor
ubuntu:
type: string
label: Fileserver image
description: The image used to spawn the fileserver
constraints:
- custom_constraint: glance.image
admin-ssh-key:
type: string
label: SSH Key admin
description: The SSH-key to inject in the fileserver for admin-purposes.
user-ssh-key:
type: string
label: SSH Key User
description: The SSH-key to inject in the fileserver for the user user.
secgroup_generic:
type: string
network:
type: string
volume_type:
type: string
label: Volume type
description: The cinder-type used to create the volume for the fileserver
default: 'HDD-300'
constraints:
- custom_constraint: cinder.vtype
volume_size:
type: number
label: Volume size
default: 2
description: The size of the exported volume from the fileserver
The parameters for this template would thus be:
- flavor: An openstack flavor defining the specifications for the two virtual machines we are going to make
- ubuntu: The ID of the openstack-image which we are using to create our VM's
- admin-ssh-key: An ssh-key to be injected into the "administrator" user of the machines
- user-ssh-key: An ssh-key to be injected into the "user" user of the machines
- secgroup_generic: The ID of the security-group to use
- network: The ID of the network to connect the machines to
- volume_type: The name of the Openstack volume type to use. This one defaults to "HDD-300", and you do not need to specify it unless you want another type.
- volume_size: The size og the volume attached to the fileserver. This one defaults to "2", an you do not need to specify it unless you want another size.
Defining the fileserver VM
Creating the fileserver VM is going to need a couple of resources:
- A cloud-config snippet creating the users and injecting the ssh-keys
- A cloud-config snippet installing the nfs-server packages, creating the /etc/exports file and formatting the extra disk.
- A shell-script altering the NFS-server configuration, and mounting the extra disk.
- A floating IP
- A virtual server
- A volume
The configuration-snippets and shellscript can be defined as three seperate resources, and then joined together to a single resource which can be given to a VM like so:
cloudconf_fileserver:
type: OS::Heat::MultipartMime
properties:
parts:
- config: {get_resource: cloudconf_base}
- config: {get_resource: cloudconf_fileservers}
- config: {get_resource: script_fileserver}
cloudconf_base:
type: OS::Heat::CloudConfig
properties:
cloud_config:
package_update: true
package_upgrade: true
timezone: "Europe/Oslo"
users:
- name: administrator
sudo: ALL=(ALL) NOPASSWD:ALL
lock_passwd: True
shell: /bin/bash
ssh_authorized_keys:
- { get_param: admin-ssh-key }
- name: user
lock_passwd: True
shell: /bin/bash
ssh_authorized_keys:
- { get_param: user-ssh-key }
power_state:
mode: 'reboot'
message: 'Reboots after installing'
condition: True
cloudconf_fileservers:
type: OS::Heat::CloudConfig
properties:
cloud_config:
packages:
- 'nfs-kernel-server'
- 'pwgen'
write_files:
- content: '/opt/data/shared 192.168.0.0/24(rw,sync,no_subtree_check)'
path: '/etc/exports'
- content: |
options lockd nlm_udpport=32768 nlm_tcpport=32768
options nfs callback_tcpport=32764
path: '/etc/modprobe.d/local.conf'
disk_setup:
/dev/vdb:
table_type: gpt
layout: true
overwrite: false
fs_setup:
- filesystem: 'ext4'
label: 'datapartition'
device: '/dev/vdb'
partition: 'auto'
script_fileserver:
type: OS::Heat::SoftwareConfig
properties:
group: ungrouped
config: |
#!/bin/bash
# Restrict NFS ports
sed -i -r 's/STATDOPTS=.*/STATDOPTS="--port 32765 --outgoing-port 32766"/' /etc/default/nfs-common
sed -i -r 's/RPCMOUNTDOPTS=.*/RPCMOUNTDOPTS="-p 32767"/' /etc/default/nfs-kernel-server
# Mount disks
echo "/dev/vdb1 /opt/data ext4 defaults,comment=cloudconfig 0 0" >> /etc/fstab
mkdir /opt/data
mount /dev/vdb1 /opt/data
mkdir /opt/data/shared
chown user:user /opt/data/shared
The next part is to create the fileserver, and the floating IP to attach to it. For some reason Heat does not let us add floating IP's to servers, but we are allowed to add it to ports which can be attached to the servers. So, creating a server with a floating IP requires three resources: a server, an IP and an IP attachment. The server also uses the "cloudconf_fileserver" resource created above, and it gets a custom hostname set which is "STACK-fileserver" where we replace "STACK" with the name of the stack when it is created. The port we attach to the server gets both an floating IP and the security-group.
fileserver:
type: OS::Nova::Server
properties:
name:
str_replace:
template: 'STACK-fileserver'
params:
STACK: { get_param: OS::stack_name }
image: { get_param: ubuntu }
flavor: { get_param: flavor }
networks:
- {"port": { get_resource: fileserver_port }}
user_data_format: RAW
user_data: { get_resource: cloudconf_fileserver }
fileserver_port:
type: OS::Neutron::Port
properties:
admin_state_up: true
network_id: { get_param: network }
security_groups: [{ get_param: secgroup_generic }]
fileserver_floatingip:
type: OS::Neutron::FloatingIP
properties:
floating_network: 'ntnu-internal'
port_id: { get_resource: fileserver_port }
The only bits left now is creating a volume and attaching to the server:
volume:
type: OS::Cinder::Volume
properties:
size: { get_param: volume_size }
volume_type: { get_param: volume_type }
volume_attach:
type: OS::Cinder::VolumeAttachment
properties:
instance_uuid: { get_resource: fileserver }
volume_id: { get_resource: volume }
Defining the client VM
In addition to the server we want to have a client. This client uses one of the cloudconfig-snippets from the server (the one creating the users) in addition to a cloudconfig-snippet instructing the server to mount the volume. The client can be deined like so:
cloudconf_nfsmount:
type: OS::Heat::CloudConfig
properties:
cloud_config:
packages:
- 'nfs-common'
write_files:
- content:
str_replace:
template: 'IP:/opt/data/shared /mnt/filserver nfs4 defaults 0 0'
params:
IP: { get_attr: [ fileserver, networks, {get_param: network}, 0 ] }
path: '/etc/fstab'
append: true
cloudconf_client:
type: OS::Heat::MultipartMime
properties:
parts:
- config: {get_resource: cloudconf_base}
- config: {get_resource: cloudconf_nfsmount}
nfsclient:
type: OS::Nova::Server
properties:
name:
str_replace:
template: 'STACK-client'
params:
STACK: { get_param: OS::stack_name }
image: { get_param: ubuntu }
flavor: { get_param: flavor }
networks:
- {"port": { get_resource: nfsclient_port }}
user_data_format: RAW
user_data: { get_resource: cloudconf_client }
nfsclient_port:
type: OS::Neutron::Port
properties:
admin_state_up: true
network_id: { get_param: network }
security_groups: [{ get_param: secgroup_generic }]
nfsclient_floatingip:
type: OS::Neutron::FloatingIP
properties:
floating_network: 'ntnu-internal'
port_id: { get_resource: nfsclient_port }
Stitching it all together
Adding all the components for the client/server VM's together in a single file, and adding some outputs letting us easily see the IP-addresses assigned to the VM's we get a Heat-Template looking like so:
heat_template_version: 2018-08-31
description: >
This template creates, installs and configures a fileserver, and fileclient
for the heat-guide.
parameters:
flavor:
type: string
label: Fileserver flavor
description: The flavor used to spawn the fileserver
constraints:
- custom_constraint: nova.flavor
ubuntu:
type: string
label: Fileserver image
description: The image used to spawn the fileserver
constraints:
- custom_constraint: glance.image
admin-ssh-key:
type: string
label: SSH Key admin
description: The SSH-key to inject in the fileserver for admin-purposes.
user-ssh-key:
type: string
label: SSH Key User
description: The SSH-key to inject in the fileserver for the user user.
secgroup_generic:
type: string
network:
type: string
volume_type:
type: string
label: Volume type
description: The cinder-type used to create the volume for the fileserver
default: 'HDD-300'
constraints:
- custom_constraint: cinder.vtype
volume_size:
type: number
label: Volume size
default: 2
description: The size of the exported volume from the fileserver
resources:
fileserver:
type: OS::Nova::Server
properties:
name:
str_replace:
template: 'STACK-fileserver'
params:
STACK: { get_param: OS::stack_name }
image: { get_param: ubuntu }
flavor: { get_param: flavor }
networks:
- {"port": { get_resource: fileserver_port }}
user_data_format: RAW
user_data: { get_resource: cloudconf_fileserver }
fileserver_port:
type: OS::Neutron::Port
properties:
admin_state_up: true
network_id: { get_param: network }
security_groups: [{ get_param: secgroup_generic }]
fileserver_floatingip:
type: OS::Neutron::FloatingIP
properties:
floating_network: 'ntnu-internal'
port_id: { get_resource: fileserver_port }
volume:
type: OS::Cinder::Volume
properties:
size: { get_param: volume_size }
volume_type: { get_param: volume_type }
volume_attach:
type: OS::Cinder::VolumeAttachment
properties:
instance_uuid: { get_resource: fileserver }
volume_id: { get_resource: volume }
cloudconf_fileserver:
type: OS::Heat::MultipartMime
properties:
parts:
- config: {get_resource: cloudconf_base}
- config: {get_resource: cloudconf_fileservers}
- config: {get_resource: script_fileserver}
cloudconf_base:
type: OS::Heat::CloudConfig
properties:
cloud_config:
package_update: true
package_upgrade: true
timezone: "Europe/Oslo"
users:
- name: administrator
sudo: ALL=(ALL) NOPASSWD:ALL
lock_passwd: True
shell: /bin/bash
ssh_authorized_keys:
- { get_param: admin-ssh-key }
- name: user
lock_passwd: True
shell: /bin/bash
ssh_authorized_keys:
- { get_param: user-ssh-key }
power_state:
mode: 'reboot'
message: 'Reboots after installing'
condition: True
cloudconf_fileservers:
type: OS::Heat::CloudConfig
properties:
cloud_config:
packages:
- 'nfs-kernel-server'
- 'pwgen'
write_files:
- content: '/opt/data/shared 192.168.0.0/24(rw,sync,no_subtree_check)'
path: '/etc/exports'
- content: |
options lockd nlm_udpport=32768 nlm_tcpport=32768
options nfs callback_tcpport=32764
path: '/etc/modprobe.d/local.conf'
disk_setup:
/dev/vdb:
table_type: gpt
layout: true
overwrite: false
fs_setup:
- filesystem: 'ext4'
label: 'datapartition'
device: '/dev/vdb'
partition: 'auto'
script_fileserver:
type: OS::Heat::SoftwareConfig
properties:
group: ungrouped
config: |
#!/bin/bash
# Restrict NFS ports
sed -i -r 's/STATDOPTS=.*/STATDOPTS="--port 32765 --outgoing-port 32766"/' /etc/default/nfs-common
sed -i -r 's/RPCMOUNTDOPTS=.*/RPCMOUNTDOPTS="-p 32767"/' /etc/default/nfs-kernel-server
# Mount disks
echo "/dev/vdb1 /opt/data ext4 defaults,comment=cloudconfig 0 0" >> /etc/fstab
mkdir /opt/data
mount /dev/vdb1 /opt/data
mkdir /opt/data/shared
chown user:user /opt/data/shared
cloudconf_nfsmount:
type: OS::Heat::CloudConfig
properties:
cloud_config:
packages:
- 'nfs-common'
write_files:
- content:
str_replace:
template: 'IP:/opt/data/shared /mnt/filserver nfs4 defaults 0 0'
params:
IP: { get_attr: [ fileserver, networks, {get_param: network}, 0 ] }
path: '/etc/fstab'
append: true
cloudconf_client:
type: OS::Heat::MultipartMime
properties:
parts:
- config: {get_resource: cloudconf_base}
- config: {get_resource: cloudconf_nfsmount}
nfsclient:
type: OS::Nova::Server
properties:
name:
str_replace:
template: 'STACK-client'
params:
STACK: { get_param: OS::stack_name }
image: { get_param: ubuntu }
flavor: { get_param: flavor }
networks:
- {"port": { get_resource: nfsclient_port }}
user_data_format: RAW
user_data: { get_resource: cloudconf_client }
nfsclient_port:
type: OS::Neutron::Port
properties:
admin_state_up: true
network_id: { get_param: network }
security_groups: [{ get_param: secgroup_generic }]
nfsclient_floatingip:
type: OS::Neutron::FloatingIP
properties:
floating_network: 'ntnu-internal'
port_id: { get_resource: nfsclient_port }
outputs:
fileserver_address:
description: Fileserver address
value: { get_attr: [ fileserver_floatingip, fixed_ip_address ] }
fileserver_floating_address:
description: Fileserver floating IP address
value: { get_attr: [ fileserver_floatingip, floating_ip_address ] }
client_address:
description: Client address
value: { get_attr: [ nfsclient_floatingip, fixed_ip_address ] }
client_floating_address:
description: Client floating IP address
value: { get_attr: [ nfsclient_floatingip, floating_ip_address ] }
Creating stacks with client/server in it:
Creating a parameter file
The easiest way to create a stack needing parameters is to create a parameter-file. Based on the output of the first heat-stack, and from retrieving ID's using commands like "openstack flavor list" and "openstack image list" we can create a parameter-file like so:
parameters:
flavor: gx2.2c3r
ubuntu: fe8be799-21f4-489a-9e3f-9b8a2e15c015
user-ssh-key: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGOUa4umWBvM+++eVKXHs4CDrir+aWqrcMtLkPhQR1UF eigil@lungo
admin-ssh-key: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGOUa4umWBvM+++eVKXHs4CDrir+aWqrcMtLkPhQR1UF eigil@lungo
secgroup_generic: 30586c14-7bc1-4ef4-91dc-2089eb32ec23
network: db265ea1-1d85-47f1-ba3a-714174da114e
Creating a stack with parameters using the CLI
To create a stack using the CLI you use the openstack stack create command:
$ openstack stack create -t clientserver-lab.yaml -e clientserver-lab-parameters.yaml Group1
+---------------------+-------------------------------------------------------------------------------------------------+
| Field | Value |
+---------------------+-------------------------------------------------------------------------------------------------+
| id | 10ab8264-6a8d-438a-9aa6-05f99a986b87 |
| stack_name | Group1 |
| description | This template creates, installs and configures a fileserver, and fileclient for the heat-guide. |
| | |
| creation_time | 2022-08-31T09:03:59Z |
| updated_time | None |
| stack_status | CREATE_IN_PROGRESS |
| stack_status_reason | Stack CREATE started |
+---------------------+-------------------------------------------------------------------------------------------------+
$ openstack stack show Group1
+-----------------------+-----------------------------------------------------------------------------------------------------------------+
| Field | Value |
+-----------------------+-----------------------------------------------------------------------------------------------------------------+
| id | 10ab8264-6a8d-438a-9aa6-05f99a986b87 |
| stack_name | Group1 |
| description | This template creates, installs and configures a fileserver, and fileclient for the heat-guide. |
| | |
| creation_time | 2022-08-31T09:03:59Z |
| updated_time | None |
| stack_status | CREATE_IN_PROGRESS |
| stack_status_reason | Stack CREATE started |
| parameters | OS::project_id: 74729572aad24d93b9a4cac7301ef9d1 |
| | OS::stack_id: 10ab8264-6a8d-438a-9aa6-05f99a986b87 |
| | OS::stack_name: Group1 |
| | admin-ssh-key: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGOUa4umWBvM+++eVKXHs4CDrir+aWqrcMtLkPhQR1UF |
| | eigil@lungo |
| | flavor: gx2.2c3r |
| | network: db265ea1-1d85-47f1-ba3a-714174da114e |
| | secgroup_generic: 30586c14-7bc1-4ef4-91dc-2089eb32ec23 |
| | ubuntu: fe8be799-21f4-489a-9e3f-9b8a2e15c015 |
| | user-ssh-key: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGOUa4umWBvM+++eVKXHs4CDrir+aWqrcMtLkPhQR1UF |
| | eigil@lungo |
| | volume_size: '2' |
| | volume_type: HDD-300 |
| | |
| outputs | - description: Client floating IP address |
| | output_key: client_floating_address |
| | output_value: 10.212.25.246 |
| | - description: Fileserver floating IP address |
| | output_key: fileserver_floating_address |
| | output_value: 10.212.26.229 |
| | - description: Client address |
| | output_key: client_address |
| | output_value: 192.168.0.192 |
| | - description: Fileserver address |
| | output_key: fileserver_address |
| | output_value: 192.168.0.177 |
| | |
| links | - href: https://api.stack.it.ntnu.no:8004/v1/74729572aad24d93b9a4cac7301ef9d1/stacks/Group1/10ab8264-6a8d-438a- |
| | 9aa6-05f99a986b87 |
| | rel: self |
| | |
| deletion_time | None |
| notification_topics | [] |
| capabilities | [] |
| disable_rollback | True |
| timeout_mins | None |
| stack_owner | eigilo |
| parent | None |
| stack_user_project_id | 3c919ba549dd4838b7d2b473ac05abf7 |
| tags | [] |
| | |
+-----------------------+-----------------------------------------------------------------------------------------------------------------+
At this point there is created two VM's with the floating IP's 10.212.25.246 and 10.212.26.229. Afther they have booted, gotten their updates installed, and being rebooted, they are ready to use. You can then log into them using the username "admin" or "user" if you have the correct SSH private keys. You can also see the servers using the regular openstack commands:
$ openstack server list
+-------------------------------+-------------------+--------+-------------------------------+---------------------------------+----------+
| ID | Name | Status | Networks | Image | Flavor |
+-------------------------------+-------------------+--------+-------------------------------+---------------------------------+----------+
| f87a91d8-2736-47b0-ab21- | Group1-client | ACTIVE | Common-network- | Ubuntu Server 20.04 (Focal) | gx2.2c3r |
| d70da05e50b8 | | | w4u67666kl7f=10.212.25.246, | amd64 20200424 | |
| | | | 192.168.0.192 | | |
| 180542c9-a988-40d7-8bc9- | Group1-fileserver | ACTIVE | Common-network- | Ubuntu Server 20.04 (Focal) | gx2.2c3r |
| 02523b776b3b | | | w4u67666kl7f=10.212.26.229, | amd64 20200424 | |
| | | | 192.168.0.177 | | |
+-------------------------------+-------------------+--------+-------------------------------+---------------------------------+----------+
At this point you can create as many stacks using the clientserver-lab.yaml file as you want, as long as your project have sufficient quotas for the defined resources. And if a server/client is not needed any more, or is the need of a reinstall, it is simply a matter of an "openstack stack delete" and an "openstack stack create" to re-create the resources.
