kjaniak | 53ba170 | 2018-10-25 14:25:13 +0200 | [diff] [blame] | 1 | .. This work is licensed under a Creative Commons Attribution 4.0 International License. |
| 2 | .. http://creativecommons.org/licenses/by/4.0 |
| 3 | |
| 4 | .. _run_time_configuration: |
| 5 | |
| 6 | Run-Time configuration |
| 7 | ====================== |
| 8 | |
| 9 | (see :ref:`deployment`) |
| 10 | |
Filip Krzywka | 12acf3e | 2019-03-19 15:53:15 +0100 | [diff] [blame^] | 11 | HV-VES fetches configuration from Config Binding Service in the following JSON format: |
kjaniak | 53ba170 | 2018-10-25 14:25:13 +0200 | [diff] [blame] | 12 | |
| 13 | .. code-block:: json |
| 14 | |
| 15 | { |
| 16 | "dmaap.kafkaBootstrapServers": "message-router-kafka:9093", |
| 17 | "collector.routing": [ |
| 18 | { |
| 19 | "fromDomain": "perf3gpp", |
| 20 | "toTopic": "HV_VES_PERF3GPP" |
| 21 | }, |
| 22 | { |
| 23 | "fromDomain": "heartbeat", |
| 24 | "toTopic": "HV_VES_HEARTBEAT" |
| 25 | }, |
| 26 | ... |
| 27 | ] |
| 28 | } |
| 29 | |
| 30 | HV-VES does not verify the correctness of configuration data and uses them as is, in particular: |
| 31 | |
| 32 | - **KafkaBootstrapServers** is used as host name and port for publishing events to Kafka service. |
| 33 | - Every **routing** array object specifies one event publishing route. |
| 34 | |
| 35 | - **fromDomain** node should be a case-sensitive string of single domain taken from VES Common Event Header specification. |
| 36 | - **toTopic** should be a case-sensitive string of Kafka topic. |
| 37 | - When HV-VES receives VES Event, it checks the domain contained in it. If the route from that domain to any topic exists in configuration, then HV-VES publishes that event to topic in that route. |
| 38 | - If there are two routes from the same domain to different topics, then it is undefined which route will be used. |
| 39 | |
| 40 | The configuration is created from HV-VES Cloudify blueprint by specifying **application_config** node during ONAP OOM/Kubernetes deployment. Example of the node specification: |
| 41 | |
| 42 | .. code-block:: YAML |
| 43 | |
| 44 | node_templates: |
| 45 | hv-ves: |
| 46 | properties: |
| 47 | application_config: |
| 48 | dmaap.kafkaBootstrapServers: message-router-kafka:9092 |
| 49 | collector.routing: |
| 50 | fromDomain: perf3gpp |
| 51 | toTopic: HV_VES_PERF3GPP |
| 52 | |
Filip Krzywka | 12acf3e | 2019-03-19 15:53:15 +0100 | [diff] [blame^] | 53 | HV-VES waits 10 seconds (default, configurable during deployment with **firstRequestDelay** option, see :ref:`configuration_file`) before the first attempt to retrieve configuration from CBS. This is to prevent possible synchronization issues. During that time HV-VES declines any connection attempts from xNF (VNF/PNF). |
kjaniak | 53ba170 | 2018-10-25 14:25:13 +0200 | [diff] [blame] | 54 | |
Filip Krzywka | 12acf3e | 2019-03-19 15:53:15 +0100 | [diff] [blame^] | 55 | After first request, HV-VES asks for configuration in fixed intervals, configurable from file configuration (**requestInterval**). By default interval is set to 5 seconds. |
kjaniak | 53ba170 | 2018-10-25 14:25:13 +0200 | [diff] [blame] | 56 | |
Filip Krzywka | 12acf3e | 2019-03-19 15:53:15 +0100 | [diff] [blame^] | 57 | In case of failing to retrieve configuration, collector retries the action. After five unsuccessful attempts, container becomes unhealthy and cannot recover. HV-VES in this state is unusable and the container should be restarted. |