Centos Lab9 : Orchestration – Kilo

The OpenStack Orchestration Service (Heat) provides a template-based orchestration service for OpenStack. The system leverages all of the other OpenStack services via direct API calls resulting in a deployed (and re-deployable) cloud application infrastructure. The templates enable configuration and creation of all of the Core OpenStack services and capabilities, and integrates closely with the Ceilometer service to enable auto-scaling of deployed templates.

In this lab, we will enable the OpenStack Heat engine, and create and deploy a simple template based system.

Heat Installation on AIO Node

Step 1: As with previous labs, ensure you are logged in to your AIO node from the lab-gateway, and have elevated your privileges to the root user.

ssh centos@aio110
sudo su -
source ~/openrc.sh

Step 2: Install the heat module your AIO node.

yum install openstack-heat-api openstack-heat-engine openstack-heat-api openstack-heat-engine openstack-heat-api-cfn python-heatclient -y

{{{{Note Replaced openstack-heat-api-cfn python-heatclient with openstack-heat-api openstack-heat-engine openstack-heat-api-cfn python-heatclient in above}}}}

You have just installed:
openstack-heat-api: Accepts and responds to end user compute API calls.
openstack-heat-engine: The heat engine does all the orchestration work and is the layer in which the resource integration is implemented
python-heatclient: The Command Line Interface and Client libraries for Heat.
openstack-heat-cfn: Provides an AWS Query API that is compatible with AWS CloudFormation, and perhaps more importantly, enables the ceilometer scale up/down trigger mechanisms.

Create Database for Orchestration Service

Step 3: As with prior service installations we need to create a database named “heat” for Heat by logging in to MariaDB and creating both the database and the user (heat) with password (pass)

mysql -uroot -ppass <<EOF
CREATE DATABASE heat;
GRANT ALL PRIVILEGES ON heat.* TO 'heat'@'localhost' IDENTIFIED BY 'pass';
GRANT ALL PRIVILEGES ON heat.* TO 'heat'@'%' IDENTIFIED BY 'pass';
exit
EOF

Define Users and User Roles

Step 4: As with the others services we have installed, we need to create a heat user that Heat uses to authenticate with Keystone:

openstack user create heat --password pass --email [email protected]

We will then assign the admin role as a part of the service tenant:

openstack role add --user heat admin --project service

In the Heat default policy.json (located in /etc/heat/policy.json), there is an additional set of roles created, one of which is the “heat_stack_user” role. To make use of this role, Keystone needs to be aware of it, so that users can be associated with it.

openstack role create heat_stack_owner

We will then assign the role to our admin user so that we can leverage Heat functions::

openstack role add --user admin heat_stack_owner --project admin

Define services and service endpoints

Now register the Heat API with the Keystone so that other OpenStack services and clients can locate the API.

Step 5: Register the services and specify the endpoints

First we create the orchestration service “heat”:

openstack service create --name heat --description "OpenStack Orchestration" orchestration

Then we add the endpoint mapping to the orchestration service:

openstack endpoint create --publicurl http://aio110:8004/v1/%\(tenant_id\)s --internalurl http://aio110:8004/v1/%\(tenant_id\)s --adminurl http://aio110:8004/v1/%\(tenant_id\)s --region RegionOne orchestration

Similarly register a service and endpoint for heat-cfn (the AWS model service and endpoint):

openstack service create --name heat-cfn --description "Orchestration CloudFormation" cloudformation

And register the endpoint with Keystone:

openstack endpoint create --publicurl http://aio110:8000/v1 --internalurl http://aio110:8000/v1 --adminurl http://aio110:8000/v1 --region RegionOne cloudformation

Configure Heat Service

Now that we have the base components installed, and have the database created, and our service endpoints created, we need to configure the processes.

As one might start to expect, we will point the system to our AMQP service (rabbitmq), configure keystone access, the database connection, and then we configure both ec2 access credentials (as a part of the CFN process configuration), and two CFN specific service connections, the metadata service (this being different than the Neutron MetaData service) and the call-back endpoint for Ceilometer integration (aka: waitcondition_server).

Step 6: Edit /etc/heat/heat.conf

openstack-config --set /etc/heat/heat.conf DEFAULT rpc_backend rabbit
openstack-config --set /etc/heat/heat.conf DEFAULT rabbit_host  aio110
openstack-config --set /etc/heat/heat.conf DEFAULT rabbit_userid test
openstack-config --set /etc/heat/heat.conf DEFAULT rabbit_password test
openstack-config --set /etc/heat/heat.conf keystone_authtoken auth_uri http://aio110:5000/v2.0
openstack-config --set /etc/heat/heat.conf keystone_authtoken identity_uri http://aio110:35357
openstack-config --set /etc/heat/heat.conf keystone_authtoken admin_tenant_name service
openstack-config --set /etc/heat/heat.conf keystone_authtoken admin_user heat
openstack-config --set /etc/heat/heat.conf keystone_authtoken admin_password pass
openstack-config --set /etc/heat/heat.conf database connection mysql://heat:pass@aio110/heat
openstack-config --set /etc/heat/heat.conf ec2authtoken auth_uri http://aio110:5000/v2.0
openstack-config --set /etc/heat/heat.conf DEFAULT heat_metadata_server_url http://10.1.64.110:8000
openstack-config --set /etc/heat/heat.conf DEFAULT heat_waitcondition_server_url http://10.1.64.110:8000/v1/waitcondition

Step 7: Final confguration: database migration and service startup:

Now that the heat processes know how to talk to the database, we can trigger the migration of the database to the current state:

su -s /bin/sh -c "heat-manage db_sync" heat

We also want to start the services, and enable their auto-start on boot if the control server (AIO node) reboots:

systemctl enable openstack-heat-api.service openstack-heat-api-cfn.service openstack-heat-engine.service
systemctl start openstack-heat-api.service openstack-heat-api-cfn.service openstack-heat-engine.service
systemctl status openstack-heat-api.service openstack-heat-api-cfn.service openstack-heat-engine.service

Verify the Orchestration service installation

Step 8: The resoruces described the a Heat Orchestration Template (HOT), are also known as a ‘stack’. We’ll create a simple template that enables a VM and attaches it to our private network in order to ensure that the system functions.

The following will create a file called test-stack.yml.

cat > ~/test-stack.yml << EOF
heat_template_version: 2013-05-23
description: |
  Simple template to deploy a single compute instance, 
  and associate it with our private network.

parameters:
  Priv_Net:
    type: string
    description: Private Network Name for the server
    default: private-net

resources:
  my_instance:
    type: OS::Nova::Server
    properties:
      name: Stack-VM
      key_name: mykey
      image: CirrOS 0.3.2
      flavor: m1.tiny
      networks:
      - network:  { get_param: Priv_Net }

outputs:
  private_ip:
    description: IP address of the server in the private network
    value: { get_attr: [ my_instance, first_address ] }
EOF

The file above provides a metadata section that provides a template version and name, parameters that are user-defined variables and finally the resources section of the template that specifies exactly what the heat template is to create, and an output parameter that determines the allocated internal IP address of the VM after it has been created.

This test file automates the creation of a VM, but the private network name for the server was left as a user-defined parameter. While we did include a default for this parameter,we will pass this parameter to Heat when we create the stack. Recall that we can determine the names of our networks from the output of the “net-list” command if using the neutron CLI, or from Horizon.

So now, let’s create your first stack:

heat stack-create -f test-stack.yml -P "Priv_Net=private-net" Stack1

While it may take a minute or two for the stack automation to complete, we can check on the current status with the “stack-list” command:

heat stack-list

Example output:  

+--------------------------------------+---------------+-----------------+----------------------+
|                  ID                  | stack_name    | stack_status    | creation_time        | 
+--------------------------------------+---------------+-----------------+----------------------+
| 847ee6a4-61ff-4bbe-953a-7d080cbac2f8 |   Stack1      | CREATE_COMPLETE | 2014-08-30T15:08:15Z |                    
+--------------------------------------+---------------+-----------------+----------------------+

Step 9: Deploy another version of the stack via Horizon:

If you don’t already have a browser pointing to Horizon, you can log on to Horizon by opening a web browser on your laptop and type the following (assuming you followed the tunnel configuration instructions for connecting to the jumpbox):

http://127.0.0.1:8080/dashboard

Log in with the admin user and pass password.

Go to Project > Orchestration > Stacks Click on Stack1, from which you should see the same information about Stack1 as we received from the CLI command previously.

You can also create a new stack, give it a different name (e.g. “Stack2”), and use the same HOT template. If you save the following to a file on your laptop, you can point Horizon to it. Or, you can just paste the template into the browser window (copy the code below and paste it into the template section). You don’t have to include anything in the environment section.

heat_template_version: 2013-05-23
description: |
  Simple template to deploy a single compute instance, 
  and associate it with our private network.

parameters:
  Priv_Net:
    type: string
    description: Private Network Name for the server
    default: private-net

resources:
  my_instance:
    type: OS::Nova::Server
    properties:
      name: Stack-VM
      key_name: mykey
      image: CirrOS 0.3.2
      flavor: m1.tiny
      networks:
      - network:  { get_param: Priv_Net }

outputs:
  private_ip:
    description: IP address of the server in the private network
    value: { get_attr: [ my_instance, first_address ] }

Start the stack, and add in the name, a user password (this isn’t used in these systems but does apply to other hypervisor types), and ensure that the Newtork name is still private-net.

This stack should be created in the same fashion as our command line created stack.

Goto Project > Compute > Instance to confirm that this worked (you should now see two instances with Stack-XXXXX names).