A service to process unstructured serialized configuration data and facilitate exchange of this data between deployment services such as Fuel or Puppet Master and deployed OpenStack components.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
OpenDev Sysadmins dd3d11e643 OpenDev Migration Patch 2 months ago
doc/source Replace openstack.org git:// URLs with https:// 3 months ago
examples Put, post operations implemented for environments 2 years ago
specs Scripts for upgrade/downgrade tuningbox DB added 3 years ago
tools Prepare for using standard python tests 2 years ago
tuning_box Resource value modification inhanced in the fuel2 2 years ago
.coveragerc Initial Cookiecutter Commit. 3 years ago
.gitignore Add testdb and .cache to .gitignore 3 years ago
.gitreview OpenDev Migration Patch 2 months ago
.mailmap Initial Cookiecutter Commit. 3 years ago
.testr.conf Add logging capture to tests 3 years ago
CONTRIBUTING.rst Initial Cookiecutter Commit. 3 years ago
HACKING.rst Initial Cookiecutter Commit. 3 years ago
LICENSE Initial Cookiecutter Commit. 3 years ago
MAINTAINERS Maintainers file added to project 3 years ago
MANIFEST.in Fix MANIFEST.in to inlcude migrations 3 years ago
README.rst API documentation 2 years ago
TODO Add template value compilation 3 years ago
alembic.ini Add version_table to alembic.ini for autogenerate to work locally 3 years ago
babel.cfg Initial Cookiecutter Commit. 3 years ago
bindep.txt ibpq-dev requirement added 2 years ago
openstack-common.conf Initial Cookiecutter Commit. 3 years ago
requirements.txt Environments operations handled in the fuel2 2 years ago
setup.cfg Hierarchy levels API handled in the fuel2 2 years ago
setup.py Fix tox run issues 3 years ago
test-requirements.txt Components operations handled in the fuel2 2 years ago
tox.ini Ignore warning from a known issue in flask-sqlalchemy in tests 3 years ago

README.rst

Tuning Box

Tuning Box is a configuration storage for your clouds.

Tuning Box can be used as a centralized storage for all configurations. It supports Keystone authentication. By default, Tuning Box installs as a Fuel extension but also it can be run as a service.

Features

ConfigDB entities:

  • Environment
  • Component
  • Hierarchy level
  • Resource definition
  • Resource value
  • Resource value override

Installation

  1. Download Tuning Box RPM package or code to the Fuel Master node. The package can be built from the source code using:

    $ python setup.py bdist_rpm
  2. Tuning Box installs as a Fuel Nailgun extension. Therefore, perform the DB migration and restart the Nailgun service:

    $ nailgun_syncdb
    $ systemctl restart nailgun.service
  3. Configure the Tuning Box keystone service:

    $ export OS_USERNAME=admin OS_PASSWORD=admin OS_PROJECT_NAME=admin OS_AUTH_URL=http://10.20.0.2:5000
    $ openstack service create --name tuning-box config
    $ openstack endpoint create --publicurl http://10.20.0.2:8000/api/config --region RegionOne tuning-box

Now, you have enabled a set of config commands in the fuel2 CLI.

Commands groups for fuel2 CLI

The fuel2 CLI commands groups are the following:

  • config comp - CRUD operations for components
  • config def - CRUD operations for resource definitions
  • config env - CRUD operations for environments
  • config get, config set, config del - CRUD operations for resource values
  • config override, config rm override - operations for resource values overrides

API

For all operations authentication is required. Auth token should be passed in the X-Auth-Token HTTP header. Tuning Box installed as a Fuel Nailgun extension thus base API URL is placed at http://MASTER_NODE_IP:8000/api/v1/config All operations URLs should be concatenated with the base API URL.

Environments operations

URL: /environments Operations:

  • (GET) list environments
  • (POST) create environment

For environment creation POST:

Environment operations

URL: /environments/<int:component_id> Operations:

  • (GET) get environment
  • (PUT/PATCH) update environment
  • (DELETE) delete environment

Components operations

URL: /components Operations:

  • (GET) list components
  • (POST) create component

For component creation POST:

Component operations

URL: /components/<int:component_id> Operations:

  • (GET) get component
  • (PUT/PATCH) update component
  • (DELETE) delete component

Hierarchy levels operations

URL: /environments/<int:environment_id>/hierarchy_levels Operations:

  • (GET) list environment hierarchy levels

Hierarchy levels modifications performed via environment modifications.

Hierarchy level operations

URL: /environments/<int:component_id>/<string:level> Operations:

  • (GET) get hierarchy level

Keys operations

For performing keys operation send PATCH request to the appropriate URL. As data use list of keys written in the order of access. For instance you have the following data:

For access to the val02 key path will be: ['k0', 'k2'] If you want to modify value add required value to the keys path. For instance, if you want change 'val02' to 'val02_new' key paths will be: ['k0', 'k2', 'val02_new']

If you want to delete 'k4' key use key path ['k0', 'k3', 0, 'k4']

Key operations work only in batch mode, so you should pass list of keys paths to the appropriate API handler:

[['k0', 'k1', 'val01_new'], ['k0', 'k2', 'val02_new']]

For adding new key 'new_k' to the data you should send the following keys paths:

[['new_k', 'new_val']]

Resource definitions operations

URL: /resource_definitions Operations:

  • (GET) list resource definitions
  • (POST) create resource definition

For resource definition creation POST:

Resource definition operations

URL: /resource_definitions/<int:resource_definition_id> Operations:

  • (GET) get resource definition
  • (PUT/PATCH) update resource definition
  • (DELETE) delete resource definition

Resource definition keys operations

Operations with keys modifies resource definition content only. These operations supports nested keys. For details see: keys operations.

URL: /resource_definitions/<int:resource_definition_id>/keys/<keys_operation:operation> Handled keys operations:

  • get resource value key
  • update resource definition key
  • delete resource definition key

Resource values operations

URL: /environments/<int:environment_id>/<levels:levels>resources/<id_or_name:resource_id_or_name>/values Operations:

  • (GET) get resource value
  • (PUT) create/update resource value

For resource value creation set PUT HTTP request with data as workload. This data will be stored to the resource values bound to the appropriate level value.

For merging data from all levels specify 'effective' parameter for GET HTTP request.

For tracing the level from which data is got specify 'show_lookup' parameter for the GET HTTP request. Lookup has sense only if you are fetching the effective values.

Resource values keys operations

Operations with keys modifies resource values only. These operations supports nested keys. For details see: keys operations.

URL: /environments/<int:environment_id>/<levels:levels>resources/<id_or_name:resource_id_or_name>/values/keys/<keys_operation:operation> Handled keys operations:

  • get resource values key
  • update resource values key
  • delete resource values key

Resource overrides operations

URL: /environments/<int:environment_id>/<levels:levels>resources/<id_or_name:resource_id_or_name>/overrides Operations:

  • (GET) get resource overrides
  • (PUT) create/update resource overrides

For resource value creation set PUT HTTP request with data as workload. This data will be stored to the resource override bound to the appropriate level value.

Resource values keys operations

Operations with keys modifies resource overrides only. These operations supports nested keys. For details see: keys operations.

URL: /environments/<int:environment_id>/<levels:levels>resources/<id_or_name:resource_id_or_name>/overrides/keys/<keys_operation:operation> Handled keys operations:

  • get resource value key
  • update resource value key
  • delete resource value key