There are two ways the configuration updates happen in K8S world.

1. Using K8S kinds (typically CRDs) implemented by application specific operators
2. Updating by overwriting (config-map) and updating via 'helm upgrade' (Incremental configuration)
3. Using K8S kinds via operators, but expect all the configuration to be given every time (currently this is done via helm upgrade)

Since we have multiple charts in a bundle, both of above would need to be supported as part of Day2 configuration.

Day2 configuration templates:

Since we believe that for a given application, type of configuration is similar (but not the values), it is felt that configuration templates are created by applications.  These templates are for each application and are expected to be created even before Day 2 configuration is applied.

Day2 configuration template management API:

• Each template record is identified by "application name" and "record name".
• Content of the API
  • Meta data file (Similar to the way Day0 configuration profile to map the actual micro-service with the config-map files in the tar )
  • Tar file consisting of
    • config-maps files (to satisfy method 2 as described above) with templating.
    • additional helm charts (to satisfy method 1 - Configurations via operators who support incremental configuration)
    • Set of additional helm charts (to satisfy method3)
• CRUD operations are expected to be provided.

It is expected that templates are created by ONAP users that know about the possible deployment scenarios for the application.

Day2 configuration values:

Once the configuration templates are created,  configuration can be applied by choosing the right template.

Day 2 configuration is applied by users as and when new configuration is required.

As a user, he/she should select the template and supply values to apply new configuration. 

Day2 apply configuration API includes:

• Each instance of 'configuration' is identified by  "application name", "record name", "VNF instance ID" (on which VNF instance to apply this configuration on)
• Body of the API:
  • Set of parameter and value list

Internally,

K8S plugin finds out the Day2 configuration template using "application name" and "record name".  Also validates that application identified by VNF is already instantiated.  Then, it uses template and values from the body of the API and then applies configuration. then it updates the 'resource Bundle ID' map with additional resource names.  On 'applying configuration', it does something similar to 'helm update' for full configuration update methods (method 1 and method 3) and similar what 'helm install' for incremental configuration on the incremental helm charts that are there in the template.

 This work is required for Distributed Analytics use case to start with. Hence, this is to be tested with Distributed Analytics use case.