...
During the Beijing release the 'initContainers' constructs were updated from the previous beta implementation to the current released syntax under the JIRA Story
Jira |
---|
server | ONAP JIRA |
---|
serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
---|
key | OOM-406 |
---|
|
Jira Charts |
---|
border | false |
---|
showinfor | false |
---|
server | ONAP JIRA |
---|
jql | %22Epic%20Link%22%20in%20(%22OOM-6%22) |
---|
statType | statuses |
---|
chartType | pie |
---|
width | |
---|
isAuthenticated | true |
---|
serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
---|
|
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:
...
The migration from the disparate configuration methodologies to Helm charts is tracked under the
Jira |
---|
server | ONAP JIRA |
---|
serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
---|
key | OOM-460 |
---|
|
JIRA story. Within each of the projects a new configuration repository contains all of the project specific configuration artifacts. As changes are made within the project, it's the responsibility of the project team to make appropriate changes to the configuration data.
The Jira |
---|
server | ONAP JIRA |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
---|
key | OOM-10 |
---|
|
Epic tracks this work with the following status: Jira Charts |
---|
border | false |
---|
showinfor | false |
---|
server | ONAP JIRA |
---|
jql | %22Epic%20Link%22%20in%20(%22OOM-10%22) |
---|
statType | statuses |
---|
chartType | pie |
---|
width | |
---|
isAuthenticated | true |
---|
serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
---|
|
Monitoring
OOM provides two mechanims to monitor the real-time health of an ONAP deployment: a Consul GUI for a human operator or downstream monitoring systems and Kubernetes liveness probes that enable automatic healing of failed containers. The liveness probes are described in the following section.
...
The
Jira |
---|
server | ONAP JIRA |
---|
serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
---|
key | OOM-327 |
---|
|
JIRA
story Epic tracks this work
.with the following status: Jira Charts |
---|
border | false |
---|
showinfor | false |
---|
server | ONAP JIRA |
---|
jql | %22Epic%20Link%22%20in%20(%22OOM-7%22) |
---|
statType | statuses |
---|
chartType | pie |
---|
width | |
---|
isAuthenticated | true |
---|
serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
---|
|
Heal
Liveness probes are used by the Kubernetes manager to monitor the real-time health of the containers in an ONAP deployment. If the liveness probe fails, Kubernetes will kill off the failed container and start a new container to replace it. The liveness probe have same parameters as the readiness probes described in the Deploy section. For example, to monitor the SDNC component has following liveness probe can be found in the SDNC DB deployment specification:
...
In-order to avoid the loss of an entire ONAP component by the failure of a single container, OOM enables the creation of clusters of pods hidden behind a load balancer in the form of a service. . As an example of what can be done, please refer to the SDN-C Clustering on Kubernetes wiki page.
Upgrade
OOM uses Helm K8S package manager to deploy ONAP components.
...