OOM restarts ONAP components after a failure.

OOM uses a Kubernetes controller to constantly monitor all of the deployed containers (pods) in an OOM deployment of ONAP automatically restarting any container that fails.  If you’d like to try this out for yourself stop one of the containers by using the following command:

	kubectl delete pod <pod name> -n <pod namespace>

You’ll see the pod go down and immediately be restarted.

OOM provides a real-time view of ONAP component health.

OOM deploys a Consul cluster that actively monitors the health of all ONAP components in a deployment.  To see what the health of your deployment looks like, enter the following url in your browser:

	http://<kubernetes IP>:30270/ui/

More information can be found on our wiki at Health Monitoring.

OOM supports deploying subsets of the ONAP components.

ONAP has a lot of components!  If you would like to focus on a select few components you can do so today by modifying the environment file setenv.bash and changing the list of components.

For example, in Beijing we have:

HELM_APPS=('consul' 'msb' 'mso' 'message-router' 'sdnc' 'vid' 'robot' 'portal' 'policy' 'appc' 'aai' 'sdc' 'dcaegen2' 'log' 'cli' 'multicloud' 'clamp' 'vnfsdk' 'uui' 'aaf' 'vfc' 'kube2msb' 'esr')

Simply modify the array to something like this:

HELM_APPS=('mso' 'message-router' 'sdnc' 'vid' 'robot' 'portal' 'policy' 'appc' 'aai' 'sdc')

Launch the “oneclick” installer and wait for your pods to startup.

# createAll.bash -n onap

OOM makes services available on any Node in a K8S cluster using a NodePort.

This allows a service to be reachable on any node in the cluster, using a statically assigned NodePort (default range: 30000-32767). NodePorts are automatically mapped to the internal port of a service.

Some examples of services available today using NodePorts:

30023 --> 8080 (m)so

All services are mapped here: in OOM wiki.

OOM manages dependencies between ONAP components.

OOM uses deployment descriptor files to define what components are deployed in ONAP.  Inside the descriptor files, initContainers are used to ensure that dependent components are running and are healthy (ie. ready) before a component's container is started.

Example mso deployment descriptor file shows mso's dependency on its mariadb component:

..
kind: Deployment
metadata:
  name: mso
..
spec:
..

      initContainers:
      - command:
        - /root/ready.py
        args:
        - --container-name
        - mariadb
..        
      containers:
      - command:
        - /tmp/start-jboss-server.sh
        image: {{ .Values.image.mso }}
        imagePullPolicy: {{ .Values.pullPolicy }}
        name: mso
..

OOM supports scaling stateful applications.

OOM leverages the kubernetes capability to scale stateful applications. And this is done without the need to change any application code.

kind: StatefulSet
metadata:
	name: sdnc-dbhost
	namespcae: "{{ .Values.nsPrefix }}-sdnc"
spec:
	serviceName: "dbhost"
	replicas: 2

You can try these examples today to scale out and back in the SDNC database. 

Scale out sdnc database to 5 instances:

   kubectl scale statefulset sdnc-dbhost -n onap-sdnc --replicas=5

Scale in sdnc database to 2 instances:

   kubectl scale statefulset sdnc-dbhost -n onap-sdnc --replicas=2