...
- Component spec creation
- Every component to be onboarded into DCAE, should prepare a component spec (a.k.a spec) - which is meta data represented in json describing the component configuration model. Details on spec creation can be found here - RTD spec
- Validation of spec and docker image using dcae_cli
- The dcae_cli tools enables MS owner to validate the component spec and data_Formats created and also "test" the container deployment of MS itself. This allows components to mimic the configuration returned from ConfigBinding Service as expected on typical cloudify based deployment by DCAE platform (Documentation on spec format and tool usage can be found under RTD dcae_cli). There is vagrant setup available which can be used to dcae_cli test/validation (vagrant vm includes Consul and Configbindingservice).
Alternatively dcae_cli can be configured to interface with OOM/DCAE Platform - steps for setup and testing is documented here
- The dcae_cli tools enables MS owner to validate the component spec and data_Formats created and also "test" the container deployment of MS itself. This allows components to mimic the configuration returned from ConfigBinding Service as expected on typical cloudify based deployment by DCAE platform (Documentation on spec format and tool usage can be found under RTD dcae_cli). There is vagrant setup available which can be used to dcae_cli test/validation (vagrant vm includes Consul and Configbindingservice).
- Blueprint creation (manual for R4; new tool will be available post R4)
- Components developer can hand-craft the cloudify blueprints. For blueprint reference - check existing services k8s blueprint template under - DCAE Blueprint repository (refer only to blueprint with prefix - "k8s-" for OOM deployment)
- Blueprint should include policy_node and taking policy_id as input (refer TCA policy enabled blueprint)
- Policy Model creation (using SDC Tosca_lab)
- Policy model creation require policy schema definition in spec specifying the structure of configuration to be exposed in policy. Follow Tosca Lab Tool Instructions to generate the policy models
- Verify with policy team if the created policy model conforms to the specification Policy team expects
- For Testing
- Step 1- Service owners are required to upload the policy model into Policy and create a configuration policy (policy_id created) before deployment of MS itself
- Step 2 - Validate the blueprint by deployment in DCAE k8s cluster. The policy_id obtained in step 1 should be specified as input and deployed using cfy command as documented here - Cloudify Blueprint validation under OOM
- Once the spec, policy model and blueprints are validated, add it under service component gerrit repo under following directory structure - dpo/spec, dpo/data-formats, dpo/tosca_models, dpo/blueprints.
- Note: Both dpo/tosca_models and dpo/blueprints are temporary place holders for Dublin
- Documentation
- As the MS will be deployed on-demand in ONAP, include the instruction for deployment of MS and validation. This info should be submitted as"readme" in gerrit and on ONAP Usecase wiki used by Integration team.
Mitigation strategy
Policy is migrating toward new design/architecture for Dublin, this requires interfacing clients to use new LC API’s and onboarding MS to use new tosca policy model
Constrains with this new Policy API migration
- Toscalab tool under SDC not ready to generate policy model under new structure expected by Policy
- Policy update not supported. Any change in Policy, will require re-deployment of MS for Dublin
Possible Work around for Services
- MS requiring only Day0 configuration be set for Dublin
- In this case, the installation configuration can be provided as input in the blueprint. Configuration such as remote xnf host – can be defined as input in the cloudify blueprint and sourced under application from the input
Example:
inputs:
pg_ipAddress:
type: string
default: hbpostgres-write
pg_userName:
type: string
default: heartbeat
node_templates:
heartbeat:
properties:
application_config:
pg_ipAddress:
get_input: pg_ipAddress
pg_userName:
get_input: pg_userName
Once deployed, the configuration can be modified in consul for Application to source from without redeployment. This mode of deployment can be done from either CLAMP or within DCAE using Cloudify CLI (or Dashboard); no policy model associated in this mode and any action required on Policy.
Note: Any change in consul is temporal; will required to be reapplied if onap/consul is reinstalled.
- MS requires active Day2 configuration update supported.
- Follow documented procedure for Policy tosca_model creation (manual for Dublin) and blueprint (manual) and upload into SDC repository for distribution to CLAMP/DCAE (and Policy?)
- The policy model will also be required to loaded manually into Policy for Dublin.