Cue, Message Broker Provisioning for OpenStack¶

Required Cue Components¶

• Cue API
• Cue Worker

Required Dependencies¶

• MySQL
• Zookeeper

Optional Components¶

• Cue Command-line Client (python-cueclient)
• Cue Dashboard (cue-dashboard)
• Openstack Client (python-openstackclient)

Additional Setup¶

Additional setup beyond installing Cue services is required in Keystone to allow authentication of user credentials against Keystone. Also the Keystone service catalog must be updated to include Cue’s service endpoints.

Install¶

$ sudo apt-get install zookeeper zookeeperd python-mysqldb

MySQL¶

Create the MySQL user

$ GRANT ALL ON cue.* TO 'cue'@'localhost' IDENTIFIED BY 'cue'

Create the database

$ CREATE DATABASE cue

Create directories¶

Since we are not running packages some directories are not created for us.

$ sudo mkdir /var/lib/cue /var/log/cue
# Needed if you are running cue as a non root user.
$ sudo chown cue_user /var/lib/cue /var/log/cue

Register Cue with Keystone¶

1. Create new user for cue service

keystone user-create --name cue --tenant <tenant_uuid> --pass <password

2. Add admin role for cue_admin user

keystone user-role-add --user cue_admin --tenant cue_admin_service --role=admin

Add Cue Service Endpoint to Keystone¶

1. Add cue service to keystone

keystone service-create --type message_broker --name cue --description "Message Broker provisioning service"

2. Create a new endpoint for the cue service in keystone

keystone endpoint-create --region RegionOne --service <cue_service_uuid> --publicurl http://<cue_api_ip>:8795/ --adminurl http://<cue_api_ip>:8795/ --internalurl http://<cue_api_ip>:8795/

Create Message Broker Image¶

The Cue service makes use of custom Ubuntu images with required messaging broker (e.g. RabbitMQ) installed. Building images uses the Tripleo diskimage-builder tools. Image elements for the RabbitMQ image are found in cue/contrib/image-elements/, you will also find the ‘image-build-rabbitmq.sh’ script which will build a custom image compatible with Cue.

The images are based on the latest base Ubuntu cloud image with the following elements:

• os-apply-config
• os-refresh-config
• ntp
• hosts
• cue-rabbitmq-base (cue/contrib/image-elements/cue-rabbit-base)
• ifmetric (cue/contrib/image-elements/ifmetric)

Note: building images will require a machine with more than 4GB of memory.

Once the image is built, it must be uploaded to Glance (disk format is qcow2) and message broker details added to Cue database through cue-management.

1. Create new Message Broker and set it as active broker

$ cue-manage --config-file etc/cue/cue.conf broker add <name> true

2. Add metadata indicating image id (created above) for new Message Broker

$ cue-manage --config-file etc/cue/cue.conf broker add_metadata <broker-uuid> --image <image-uuid>

Cue Config¶

$ sudo editor /etc/cue/cue.conf

Copy or mirror the configuration from this sample file here:

[DEFAULT]
management_network_id = <uuid>
os_security_group = <uuid>
policy_file = /etc/cue/policy.json
# Show more verbose log output (sets INFO log level output)
verbose = True
# Show debugging output in logs (sets DEBUG log level output)
debug = True
# Log levels for Zookeeper client and Stevedore
default_log_levels = kazoo.client=INFO,stevedore=INFO

[database]
# Database connection string - to configure options for a given implementation
connection = mysql://<user>:<password>@<ip-address>/cue

[api]
# Cue REST API specific configuration
api_port = 8795
api_host = <rest-api-ip-address>
auth_strategy = keystone

[taskflow]
# Zookeeper host node
zk_hosts=<zookeeper-ip-address>

[openstack]
# Credentials used by Cue to access OpenStack services
os_password = <password>
os_username = <username>
os_auth_url = http://192.168.131.199:35357/v3
os_auth_version = 3
os_project_name = <project-name>
os_project_domain_name = <project-domain-name>
os_user_domain_name = <user-domain-name>

[keystone_authtoken]
# Credentials used by Cue for KeyStone authentication
auth_url = http://<keystone-ip-address>:35357
auth_plugin = <auth-password>
project_name = service
password = <password>
username = <username>

More details on configuration values:

Sync Database schemas¶

Initialize database schema for Cue

$ cue-manage --config-file /etc/cue/cue.conf database upgrade

Notes:

• magement_network_id must be different than provided user network id through API.

Worker¶

$ cue-worker --config-file /etc/cue/cue.conf

API¶

The API can be started as is (through shell) or can be started behind Apache. Starting the API behind Apache is the recommended method for running the API (section below).

Starting with command shell:

$ cue-api --config-file /etc/cue/cue.conf

Networks¶

• API Network - This is the network that the Cue API will expose its API endpoint to. This network will need to be routable/reachable by all Cue users and will likely need to be a “public” network.
• Cue Control Plane Network - This is the network that all Cue Control Plane components (API, MySQL, Zookeeper, Worker) will use to communicate with each other. It is recommended this network be isolated from all other traffic. This network can optionally be connected to a “service” network that provides access to shared services like monitoring.
• Management Network - This is the network that the Cue Worker and all Broker VMs attach to. The Cue Worker connects to Broker VMs through the management network to monitor and control each Broker VM.
• Tenant Network - The tenant network is not a single network, it is any network that the Cue user specifies. Cue creates and attaches a port from the tenant network to the Broker VM in order to provide access to Message Broker services.
• External/Services Network - This is a network that the Cue Control Plane might optionally be attached to. This network, if attached to the Cue Control Plane, should be isolated from Tenant/User traffic in order to prevent possible attacks to the Cue Control Plane.

Security Groups¶

All security groups should have a default deny policy and allow only the specific ports as specified below:

• API - The API listens on the Cue service port (8795 by default) and must allow incoming requests to this port from the API network.
• Control Plane - The Cue API and Cue Worker access MySQL and Zookeeper for persisting data and coordination. It is highly recommended that MySQL and Zookeeper both be clustered, which requires that respective clustering ports be opened to members of each respective cluster. If the firewall is implemented with Security Groups, a group rule can be used to allow access to all members of the control plane, or explicit rules can be used to limit access to specific ports.
• Message Broker Internal - There exists a unique “Message Broker Internal” security domain/zone for each Message Broker type that is supported by Cue. The Message Broker VM must allow access from Cue Worker in order to allow Cue to manage the Message Broker VM. Depending on the Message Broker, it will also need to allow cluster traffic between the Message Broker VMs to facilitate clustering.
• Message Broker Public - There exists a unique “Message Broker Public” security domain/zone for each Message Broker type that is supported by Cue. The Message Broker VM must allow access to the public endpoints for the Message Broker service it is providing.

Cue Tenant and Users¶

Cue requires its own Tenant, which is used to create all Broker VMs.

Cue uses two logically separate users to interact with Openstack:

• Cue Service User
• Cue Tenant User

Cue Service User is used by Cue API to communicate with Keystone for authenticating user tokens. The Cue Service User must have an appropriate Keystone role to be able to authenticate Keystone auth tokens.

Cue Tenant User is used by Cue Worker to communicate with Openstack services like nova, neutron, and cinder, to create and manage Broker VMs. The Cue Tenant User must have appropriate access to the Cue Tenant for creating VMs. The Cue Tenant User must also have an appropriate neutron role to be able to create ports on networks not owned by the Cue Tenant.

It is also recommended that the Cue Tenant User has appropriate quotas set for Nova, Cinder, and Neutron. These settings reflect the capacity available to Cue for provisioning Broker Clusters.

Deploying Cue Through Vagrant¶

1. Clone the Cue repo from GitHub

$ git clone https://github.com/openstack/cue.git

2. Startup Vagrant VM

$ cd cue/contrib/vagrant
$ vagrant up ubuntu

3. SSH into Vagrant VM

$ vagrant ssh ubuntu

4. Install Devstack

$ cd devstack
$ ./stack.sh

You are now in the Vagrant VM with DevStack installed/configured with Cue API, and Cue Worker.

Unit and Functional Testing¶

Unit are located in: cue/cue/tests/unit

Functional tests are located in: cue/cue/tests/functional

To run all unit and function tests, execute ‘tox’ from Cue project folder:

$ cd cue
$ tox

Integration Tests¶

Integration tests verify Cue through calling the REST API directly. These tests make use of the Tempest framework and are located in: cue/tests/integration

To run all integration tests, ssh into the Vagrant VM with DevStack/Cue installation (above) and run the following script:

$ ./cue/tests/integration/run_tests.sh

Scenario Tests¶

Scenario tests verify Cue through the Python Cue Client. These tests make use of Rally Benchmark framework and are located in: cue/rally-jobs

To run all scenario tests, ssh into the Vagrant VM with DevStack/Cue installation (above) and run the following script:

$ rally task start --task ~/cue/rally-jobs/rabbitmq-scenarios.yaml