Hi Srini,
  Any run-time configuration updates to service components in DCAE should be 
handled through policy.  The pre-requisite here is the application (MS) 
configuration be modelled and available in Policy (and CLAMP). When 
configuration changes are necessary, the user can modify them and publish via 
Policy UI (or CLAMP) - which renders the UI based on models. DCAE Platform (in 
specific Policy Handler component) will watch for all DCAE MS policy update's 
and load into consul k-v store.

All DCAE application configurations (including dmaap topics) are stored under 
Consul KV during deployment. The applications (MS) are expected to use 
ConfigBindingService (CBS) Api's to retrieve them at startup and also when 
notified by DCAE platform on configuration change (notification mechanism is 
identified in application blueprint). Alternatively the application can 
periodically poll the CBS api and retrieve new configuration updates as well.
>From the MS point of view, regardless of how the configuration change is 
>introduced - either externally from Policy or via change in consul kv directly 
>or other flows - the interface to retrieve config will be same via CBS.

Additional info pertaining to this can be found here -
https://wiki.onap.org/pages/viewpage.action?pageId=36963506#ServicesPre-requisites/Requirement-ConfigBindingServiceIntegration(Codeenhancementrequired)
 - CBS apis and reconfiguration/notification flow.
https://wiki.onap.org/display/DW/MicroServices+Onboarding - Describes MS 
onboarding - which includes modelling/blueprint generation and distribution 
flows.

The guidelines for newer DCAE services will be as follows

  1.  Support the CBS api's for configuration retrieval
  2.  Support either config polling approach or notification mechanism flow.

Note:  For application targeted under PNDA,  notification mechanism will need 
worked DCAE-Controller - PNDA integration

  1.  Create spec file and onboard through SDC (DCAE-DS/tosca_lab) to create 
require models/blueprint and distribute to Policy/CLAMP/DCAE.
Note: The tosca_lab in ONAP requires enhancement to support K8S deployment; SDC 
team is looking to address this for Dublin. Current workaround is to generate 
the models/blueprint manually and distribute them into target components

Hope this helps; pls let me know if any further questions.

Regards,
Vijay

From: Addepalli, Srinivasa R <[email protected]>
Sent: Tuesday, November 13, 2018 12:13 PM
To: VENKATESH KUMAR, VIJAY <[email protected]>
Cc: [email protected]
Subject: Dynamic Configuration of Analytics applications

Hi Vijay,

There are some analytics applications (such as TCA) that are shared across 
multiple VNFs (Let us call them as shared micro services).
I would assume that there would be Day0 configuration of these micro services 
and Day 2 configuration.
How is Day2 configuration is expected to be handled. There are several methods:

  *   Restart the analytics app micro service for every new configuration.
  *   Use consul or some other mechanism to inform the new configuration and 
let the analytics app reload the configuration.

What is the method being used in TCA and more importantly is DCAE suggesting 
any guidelines in developing analytics micro-services?

Thanks
Srini



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#13715): https://lists.onap.org/g/onap-discuss/message/13715
Mute This Topic: https://lists.onap.org/mt/28124797/21656
Group Owner: [email protected]
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub  
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to