stacktach-sandbox/ansible
Sandy Walsh 8995b349a7 Status utility now support different vhosts per cell.
Minor tweaks also include:
- shoebox handler now wraps notification with region/cell info
- pip_freeze_versions.txt is updated after each ./build and
  copied into the VENV directory for inclusion in tarball.

Change-Id: Ibe4027770b859ea7878c9f0952fccf94fb496c43
2015-04-16 12:04:47 -07:00
..
roles Status utility now support different vhosts per cell. 2015-04-16 12:04:47 -07:00
vars tox verification and tarball venv packaging support. 2014-12-08 13:15:43 -08:00
api.yaml Cell Support 2014-12-22 10:14:37 -08:00
database.yaml tox verification and tarball venv packaging support. 2014-12-08 13:15:43 -08:00
README.md tox verification and tarball venv packaging support. 2014-12-08 13:15:43 -08:00
workers.yaml Cell Support 2014-12-22 10:14:37 -08:00

stv3-config

Configuration playbooks for StackTach.v3 deployments

Assumes an inventory value that has nodes or groups that start with "stv3-api" or "stv3-workers".

Execution would look like:

ansible-playbook workers.yaml

Assumes a stv3-db setup already exists.

There are also roles for database and api. The common role is responsible for installing the tarball and creating the necessary user/group accounts. Both the API and workers depend on the common role since they both require the codebase and winchester configuration files.

What it does

  • Creates stv3 user and stv3 group
  • Creates /etc/stv3 directory for configuration data
  • Creates /var/run/stv3 directory for pid files
  • Creates /var/log/stv3 directory for log files
  • Copies config files to /etc/stv3
  • Copies init.d files to /etc/init.d for yagi-events and pipeline-worker
  • Copies and expands the StackTach.v3 tarball to /opt/stv3
  • Starts the yagi worker daemon and the winchester worker (yagi-events and pipeline-worker respectively)

The init.d files handle the .pid file creation and running as stv3 user.

While yagi-events and pipeline-worker are capable to running daemonized, we don't use that code. Instead, we let the init.d scripts handle the backgrounding and process management.

The connection from the host machine to the target machine has to have a secure account already created for anisble to run. Currently it assumes an account called stacktach and it has root capabilities. When the daemons run, they run as stv3 ... which is just a service account.