API Support for

• Profile Management:
  • Adding new profile with unique profile name.
  • Updating profile with new environment (values information)
  • Updating profile with Day0 configuration for a given sub-helm chart.
  • Get profiles for a given resource-bundle
  • Get values of a given profile.
  • Delete profile
  • Delete some particular Day0 configuration.
• Information that help CLI/GUI folks
  • Ability to add some metadata as part of artifact. Meta data contains
    • Provide labels for each value that can be modifiable (Call it as UILables.yaml)
    • Set of paths to various workloads to identify Day0 configuration path. Each path to be qualified by human readable label.
  • API to get above information
    • For a given resource-bundle template, GET UILabels.
    • For a given resource-bundle template, GET Day0 Configuration paths

Storing profiles:

• Resource Bundle ID, Customer Name, Cloud Region, UUID will be part of the core selection parameters for a profile.
  • Customer Name and Cloud Region will support ANY to indicate any Customer Name or Cloud Region. Instantiation will happen on the default cloud region.
•  Considerations:
  • There could be multiple profiles for a given resource-bundle
  • Each profile has one overriding values file and multiple Day0 Configuration files - one for each resource of the resource-bundle
  • There could be multiple resource-bundles in the system.
  • Ability to store the profiles based on resource-bundle name
  • Ability to get hold of set of profiles using resource-bundle name.,
  • Ability to get/store values and individual Day0 configuration on per resource-bundle & profile basis.

Plugins:

• Profiles can have plugins which configure the RB
  • Some configuration files need to be loaded at instantiation time into config-map.  So, one plugin may be necessary here.
  • Some configuration files are really yaml files (normally these are put in to configure dependent services. For example, when you bring some Analytics application, it may require adding new topic to already existing Kafka broker. This yaml file will have information about that topic). 
  • Some configuration files can be helm charts (same as above, expect that instead of yaml files, they are represented as helm charts) - This is normally done to take care of any parameterization.
  • Note that in case of yaml files and helm charts, resource names used should follow the same rules asif they are part of helm charts of CSAR file. That is, resource names should be made unique and also store them as part of meta ID record.  Thereby, when RB is deleted, these resources also get deleted.
• The files corresponding to each profile are described in a single metadata.yaml file which contains an array of entries each containing information for each configuration file.

Note: Note that the cloud specific artifacts could be VNFs,  Networks and others.  That is CSAR can contain VNFD, Network Descriptors or something else or combination of them. Hence, it may be good to use the term "resource-bundle" CSAR