Update ElasticsearchClient during application update process

[PrathibaJee]

Context :
In EaTL , we are storing the “execution trace” records in the profile-collection as “service-record-profile” instance.
Based on the decision from the ApplicationPattern#issues#105 , we have to separate the application date from the configuration data.
Also in EaTL , continuous parallel updation in the profile-collection sometimes makes the application down.
So , we are in a plan to include a database (or) opensource logging framework (or) flat file to store the application data.

Discussion on July 15th SDN application call :

To store the application data , dev team(Martin) is currently analysing about ElasticSearch.
Using the REST interface of ElasticSearch,

• data can be transferred and stored from the EaTL application.
• json data can be stored in the index specifically created for EaTL application.
• data can be retrieved from ElasticSearch for list-records, list-records-of-flow APIs using REST interface.

Open points :

1. Where to store the connection string, username and password for access the ElasticSearch ?
   proposals :

   • Maintaining an application names ElasticSearchAuthProvider(ESAP) to holds the connection details of elastic search. On application approval by RegistryOffice , this ESAP application will communicate the connection details to EaTL.
   • Maintaining the connection details in configuration data. During upgradation , old application will transfer the connection details to new application.

2. During bequeath-your-data-and-die , how we are going to transfer the application data ? (From recent mail chain)
   Proposal :

   • EATL-v2 should just use the same index "eatl-records" as EATL-v1. It should just connect to the same ES and not doing any data transfer from EATL-v1 to EATL-v2 via REST API.

[openBackhaul]

Where to store the connection string, username and password for access the ElasticSearch?

An ElasticsearchClient, which is client to the usual HttpClient has been defined for holding these information.
Handover of these information during application update is manual work either by editing the CONFIGfile of the new application or configuration via the OaM layer of the REST interface.
An operation of the process could be discussed, designed and implemented on request by Operations Dept.

During bequeath-your-data-and-die , how we are going to transfer the application data?

After disconnecting e.g. EATL-v1, EATL-v2 shall just connect to the same ES and not doing any data transfer from EATL-v1 to EATL-v2 via REST API, EATL-v2 shall just use the same index as EATL-v1.

Issue shall be kept open for initiating discussion with Operations Dept., but milestone shall be re-configured to next release.