Beijing Scope

During the Beijing release the following capabilities are added or enhanced from the OOM capabilities available in the Amsterdam release:

• Deployment - with built-in component dependency management (including multiple clusters, federated deployments across sites, and anti-affinity rules)
• Configuration - unified configuration across all ONAP components
• Monitoring - 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
• Deletion - cleanup individual containers or entire deployments

The following sections describe these areas in more detail.

Deploy

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 deployment specifications describe the desired state of an ONAP deployment and instruct the Kubernetes manager as to how to maintain the deployment in this state. 

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 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
..

During the Beijing release the 'initContainers' constructs were updated from the previous beta implementation to the current released syntax under the JIRA Story  OOM-406 - Getting issue details... STATUS  

Configuration