commit	7c12195918d37ef66658fe5c0565d73add60cfda	[log] [tgz]
author	Jack Lucas <jflucas@research.att.com>	Wed Apr 25 22:12:01 2018 +0000
committer	Jack Lucas <jflucas@research.att.com>	Wed Apr 25 22:13:32 2018 +0000
tree	49dec3445beccaad12f85d3966f43e2430c18c5f
parent	931c46bb5fef8383a26c817d1b36f13780f0be65 [diff]

tree: 49dec3445beccaad12f85d3966f43e2430c18c5f

README.md

config_binding_service

Interface Diagram

This repo is the thing in red:

Alt text

Overview

DCAE has a "templating language" built into components' configurations, as explained further below. The orchestrator populates one/two keys (depending on the blueprint) into Consul that are used to bind component configurations config, a "rels key" and a "dmaap key". If component A wants to connect to a component of type B, then A's rels key holds what specific service component name of B that A should connect to over direct HTTP. Service component name here means the full name that the component of type B is registered under in Consul (there can be multiple components of type B registered in Consul). The CBS (config binding service) then pulls down that rels key, fetches the connection information about that B (IP:Port), and replaces it into A's config. There is also a "dmaap key", which is the same concept, except what gets injected is a JSON of DMaaP connection information instead of an IP:Port.

In addition, this service provides the capability to retrieve either the DTI events (not history) or the policies for a given service_component.

Usage

hit url_of_this/service_component/service_component_name and you are returned your bound config.

hit url_of_this/dtievents/service_component_name and you are returned the dti events for your service_component.

hit url_of_this/policies/service_component_name and you are returned the policies for your service_component.

(Note: there is also a backdoor in the client module that allows you to pass in a direct JSON and a direct rels, but this isn't exposed via the HTTP API as of now)

Assumptions

CONSUL_HOST is set as an environmental variable where this binding service is run. If it is not, it defaults to the Rework Consul which is probably not what you want.
service_component_name is in consul as a key and holds the config
service_component_name:rel is in consul as a key if you are expecting a direct HTTP resolution, and holds the service component names of connections.
service_component_name:dmaap is in consul if you are expecting a DMaaP resolution, and holds the components DMaaP information.

Templating Language

The CBS tries to resolve a component's configuration with a templating language. We have two templating languages embedded in our component's configuration ({{...}} and <<...>>). There are two because the CBS has to be able to distinguish between a rels-key-resolve and a dmaap-key-resolve. That is, if component X is trying to bind their component, and they want to talk to Y, someone has to tell the CBS whether they are trying to talk via IP:port or a feed.

Specifically, if the CBS sees:

X's configuration:
{
    ...
    config_key : << F >> // will try to resolve via X:dmaap and look for F
    config_key : {{ F }} // will try to resolve via X:rels and look for F
}

Testing

You need tox:

pip install tox

Then from the root dir, not in a virtual env, just run:

tox

You may have to alter the tox.ini for the python envs you wish to test with.