# Daily Note 10/08/2020
###### tags: `Daily Notes` , `O-RAN` , `Acumos`
## Name : Christofel Rio Goenawan
## University : Bandung Institute of Technology (ITB)

---

## Schedule:
1. Study Demo Sample of Distributed Tracing Using OpenTracing in RIC.
2. Study Near-RT RIC Internal Statistics Collections.
3. Continue to try installing Acumos AI in NTUST Server.

## Outcome :
1. Explained Detailed Works of Sample Demo of Open Tracing using OpenTracing and Jaegers.
2. Explained Detailed Works of Data Collection Adaptions in Near- RT RIC.
3. Still couldn't find server name that asked by command when try to set up needed services in NTUST server.

## Further Plan :
- Continue to deploy Acumos AIO in NTUST server
- Study more detailed about AIO Installation in Kubernets

---

## Daily Log

### 1.Study Demo Sample of Distributed Tracing Using OpenTracing in RIC. <mark>(9.00)</mark>
- Study more detail explanation in [Video](https://www.youtube.com/watch?v=EdFYvUBaKbY ) and other sources.

### 2.Study Near-RT RIC Internal Statistics Collections. <mark>(12.00)</mark>
- Study more detail explanation in [Reference](https://github.com/nokia/ONAP-VESPA) and other sources.

### 3.Continue to try deploying Acumos AIO in NTUST server. <mark>(16.00)</mark>
- Continue to try to deploy Acumos AIO in NTUST server using Prep- Deploy Process based one previous [study notes](https://hackmd.io/@christofel04/TEEP_Daily_Notes_10_7_2020).

---

## Report

### 1. Demo Sample Using OpenTracing in RIC and Jaegers.

>In this note Writer use [Video](https://www.youtube.com/watch?v=EdFYvUBaKbY) and [Ferlinda's Notes](https://hackmd.io/RJevUxCzTKyaZ-Avdyxc_A) as study sources.

#### Data Analytics Integration
From reference , Jaegers can integrates with data analytics as below.


#### Jaeger Adapter on RIC Platform
From Ferlinda's notes , this repository contains helm charts for deploying a jaeger-all-in-one container.


#### Services

Services in Jaeger consisted of 3 parts as below.
1. **Agent Service**
2. **Collector Service**
3. **Query Services**

From references the source code of services can be seen as below.
* Agent-service
* 
* Collector-service
* 
* Query-sevice
* 

:::info
It also contains a config map for **creating a trace configuration for clients** using either **ric-plt/tracelibcpp** or **ric-plt/tracelibgo**.

:::

:::info
**Tracelibs** implements a function for creating a configured tracer instance and hides the underlaying tracer implementation from the application.
:::

#### Demo Sample
The result of Open Tracing using Jaegers from video can be seen as below.


## Relation to Other Repositories
> Writer using [Ferlinda's notes](https://hackmd.io/RJevUxCzTKyaZ-Avdyxc_A) as study source.

From [Ferlinda's readings](https://medium.com/@masroor.hasan/tracing-infrastructure-with-jaeger-on-kubernetes-6800132a677), it stated how the **tracing infrastructure needs to be monitored**.
Jaeger microservices expose metrics in Prometheus format on specific ports for each component.
This might applies in RIC as well, so maybe these system might also have connection to:
* ric-plt.vespamgr
* where it adapt near-RT RIC internal statistics collection using Prometheus to ONAP’s VES
* ric-plt.ric-dep
* deployment of Prometheus was found in this repository

---

### 2. Near-RT RIC Internal Statistics Collections Adaptations

>In this note Writer use [Documentation](https://www.o-ran.org/s/ORAN-WG3E2SM-v0100.docx), [Reference](https://medium.com/opentracing/towards-turnkey-distributed-tracing-5f4297d1736) and [Ferlinda's Notes](https://hackmd.io/3b9cWIIDR9qjN2EVdS6HbQ?view) as study sources.

#### What is VESPA Manager?

:::info
From documentation VESPA Manager can be explained as below.
1. **The VESPA manager** uses the VES Agent (https://github.com/nokia/ONAP-VESPA) to adapt near-RT RIC internal statistics’ collection using Prometheus (xApps and platform containers) to ONAP’s VES (VNF event streaming).
2. The **vesmgr** container runs two processes:
- The VESPA manager and the VES Agent (i.s. VESPA).
- The VESPA manager starts and configures the VES Agent.
- The VES Agent is a service acting as a *bridge* between Prometheus and ONAP’s VES Collector.
:::

So we can conclude that this VESPA Manager connects **Prometheus**, which is an xApps and platform containers to **ONAP's VNF Event Streaming**. Thus, this can adapt *near-RT RIC internal statistics’ collection*.

#### What is Prometheus?**

From references, Prometheus is **a systems and service monitoring system**. It **collects metrics from configured targets at given intervals, evaluates rule expressions, displays the results, and can trigger alerts** if some condition is observed to be true.

From [yesterday's notes](https://hackmd.io/@christofel04/TEEP_Daily_Notes_07_8_2020) we can seen RIC Cluster scheme as below.


:::info
***Info:***
On [PromCon EU 2019](https://promcon.io/2019-munich/talks/prometheus-and-jaeger-a-match-made-in-heaven/), Ferlinda found another combined use of Jaeger and Promotheus where Jaeger monitoring can be done with Prometheus.


:::

#### What is ONAP ?
ONAP is another project in Confluence, it is outside the scope of OSC. ONAP **integrate into the OSC OAM/NONRTRIC Functionality**.

ONAP consists of a number of software subsystems as below.

1. A design-time environment to design, define and program the platform
2. An execution-time environment to execute the logic programmed in the design phase.

#### ONAP Architectures
From documentation ONAP Architectures can be seen as below.


#### ONAP Integration to OSC OAM/NON Real- Time RIC

The detailed scheme of ONAP integration to OSC OAM/NON Real- Time RIC can be seen as below.


From schemes above Non-RT RIC resides inside ONAP.
While A1 interface uses REST API, O1/OAM interface **connects Near-RT RIC to ONAP's VES Collector using VES** and others as showed. VES Collector in ONAP has two types as below.
1. **VES Collector** is standard collector for rare events like CM, FM.
2. **High Volume VES Collector** is used for real-time event streaming needed for PM.

The connection with VESPA Manager is for this VNF event streaming.

:::info
**VES** is used within O1 Interface, picture below shows the component architecture of O1 Interface:
:::

:::info
**Next Writer Will Study More About Tracing Using Jaeger**
:::

---

### 3. Continue to try deploying Acumos AIO in NTUST server

>This deployment is continuation from [yesterday's notes]( https://hackmd.io/@christofel04/TEEP_Daily_Notes_30_7_2020 ).
In this note Writer use [Previous Notes](https://hackmd.io/@christofel04/TEEP_Daily_Notes_10_7_2020) as study sources.

Then Writer try to install needed services in server for Acumos AIO.

Writer use the next command as below.

bash system-integration/AIO/setup_prereqs.sh k8s ee705-7-ip113 $USER openshift 2>&1 | tee aio_prep.log


But when Writer use the command , the command ask for server's name that Writer don't know.

:::warning
After I discussed with Kevin, I try to find the server's name by command below.

But the command also ask for server's name
:::

:::info
**Next Writer Will Continue to Find the Server's Name For the Command**
:::

---



## Reference
1. https://www.o-ran.org/s/ORAN-WG3E2GAP-v0100.docx
2. https://docs.o-ran-sc.org/projects/o-ran-sc-ric-plt-jaegeradapter/en/latest/overview.html
3. https://medium.com/opentracing/towards-turnkey-distributed-tracing-5f4297d1736