rcbops/rpc-hummingbird

Name: rpc-hummingbird

Owner: rcbops

Description: Hummingbird, it's like Swift, but faster!

Created: 2017-12-11 21:27:05.0

Updated: 2018-05-21 17:38:45.0

Pushed: 2018-05-21 17:38:44.0

Homepage: null

Size: 20908

Language: Shell

GitHub Committers

User	Most Recent Commit	# Commits

Other Committers

User	Email	Most Recent Commit	# Commits

README

rpc-hummingbird and hansible(ansible bits used to install hummingbird)

rpc-hummingbird deploys Hummingbird as an RPC stand-alone platform in a uniform, managed, and tested way to ensure version consistency and testing.

By adding automated tests, rpc-hummingbird provides a way to manage tested versions of hansible used in RPC deployments.

What is rpc-hummingbird?

rpc-hummingbird is a thin wrapper around the hansible repo. rpc-hummingbird manages the versions of ansible and hansible by providing:

• RPC integration testing (MaaS/Logging and WIP-OpenStack).
• Tested and versioned hansible and hummingbird releases.
• Default variables (still WIP) for base installs.
• Standarized deployments.
• Default playbooks for integration.
• Benchmarking tools using hummingbird bench.

Deploying rpc-hummingbird uses boostrap.sh, hansible, default group_vars, and a pre-created playbook.

NOTE: Anything that can be configured with hansible is configurable with rpc-hummingbird.

Deploying Hummingbired for multi-node and production environments

Architecture

We do not recommend or use containers for rpc-hummingbired production deployments. Containers are setup and used as part of the run_tests.sh (AIO) testing strategy only. The default playbooks are not set up to build containers or configure any of the required container specific roles.

The inventory should consist of the following:

• 1 admin node used for andrewd, ring work and a staging area.
• storage nodes used to run the conponents of hummingbird
• hummingbird hosts, pointing to the storage nodes
• monitoring host, pointing at the monitoring node
• rsyslog_all host, pointing to the existing rsyslog logging server.

Configuring your deployment host

1. Configure the following inventory:

2. An entry in the hummingbird section with a service_ip for each host.

3. Configure a variables file including the following hansible vars:

4. Devices, storage_devs for each host.

5. Given raw device set disks setup_storage: False

6. Set the hash prefix hash_prefix

7. Set the hash suffix hash_suffix

8. Auth Methoduse_temp_auth

9. Any other hansible settings you want to configure.

10. Run the bootstrap-ansible.sh inside the scripts directory:

    ripts/bootstrap-ansible.sh
    

11. This configures ansible at a pre-tested version and clones the required role repositories:

12. hansible

13. rsyslog_client

14. openstack-ansible-plugins (hansible aio uses the container template plugin from here).

15. Run the hansible playbook from the playbooks directory:

    /rpc-hummingbird-ansible-runtime/bin/ansible-playbook -i <link to your inventory file> playbooks/deploy-hummingbird.yml -e @<link to your vars file>
    

Your deployment should be successful.

NOTE: If there are any errors, troubleshoot as a standard hansible deployment.

Deploying hummingbird as an AIO

Virtual Machine requirements for AIO

• RAX Public Cloud general-8 (or equivalent) using:
• Ubuntu 16.04 (xenial)

To run an AIO build

For MaaS integration, perform the following export commands. Otherwise just use ./run_tests.sh to build the AIO.

rt PUBCLOUD_USERNAME=<username>
rt PUBCLOUD_API_KEY=<api_key>

Tested builds as AIO

• Hummingbird bench
• RPC-MaaS integration
• RPC-O integration (coming a bit less soon).

Currently not supported for AIO