During the Beijing release the following capabilities are added or enhanced from the OOM capabilities available in the Amsterdam release:
- DeploymentDeploy - with built-in component dependency management (including multiple clusters, federated deployments across sites, and anti-affinity rules)
- Configuration Configure - unified configuration across all ONAP components
- MonitoringMonitor - real-time health monitoring feeding to a Consul UI and Kubernets
- Heal- failed ONAP containers are recreated automatically
- Clustering and Scaling - cluster ONAP services to enable seamless scaling
- Upgrade - change-out containers or configuration with little or no service impact
- DeletionDelete - cleanup individual containers or entire deployments
...
The OOM team with assistance from the ONAP project teams, have built a comprehensive set of Kubernetes deployment specifications, yaml files very similar to TOSCA files, that describe the composition of each of the ONAP components and the relationship within and between components. These These deployment specifications describe the desired state of an ONAP deployment and instruct the Kubernetes container manager as to how to maintain the deployment in this state. These dependencies dictate the order in-which the containers are started for the first time such that such dependencies are always met without arbitrary sleep times between container startups. For example, the SDC back-end container requires the Elastic-Search, Cassandra and Kibana containers within SDC to be ready and is also dependent on DMaaP (or the message-router) to be ready - where ready implies the built-in "readiness" probes succeeded - before becoming fully operational.
When an initial deployment of ONAP is requested the current state of the system is NULL so ONAP is deployed by the Kubernetes manager as a set of Docker containers on one or more predetermined hosts. The hosts could be physical machines or virtual machines. When deploying on virtual machines the resulting system will be very similar to “Heat” based deployments, i.e. Docker containers running within a set of VMs, the primary difference being that the allocation of containers to VMs is done dynamically with OOM and statically with “Heat”.The intra and inter component dependencies described by the deployment descriptors are used to control the order in-which the components are brought up. If component B depends on A, A will be started first and only when the “readiness” probe is successful will B we started. OOM has created readiness probes that look for an indication that container is ready for use by other containers.
Example mso SO deployment descriptor file shows msoSO's dependency s dependency on its mariadb component:
...
During the Beijing release the 'initContainers' constructs were updated from the previous beta implementation to the current released syntax under the JIRA Story
| Jira | ||||||
|---|---|---|---|---|---|---|
|
Configuration
Each project within ONAP has its own configuration data generally consisting of: environment variables, configuration files, and database initial values. Many technologies are used across the projects resulting in significant operational complexity and an inability to apply global parameters across the entire ONAP deployment. OOM solves this problem by introducing a common configuration technology, Helm charts, that provide a hierarchical configuration configuration with the ability to override values with higher level charts or command line options. For example, if one wishes to change the OpenStack instance oam_network_cidr and ensure that all ONAP components reflect this change, one could change the vnfDeployment/openstack/oam_network_cidr value in the global configuration file as shown below:
...