CORD : Service On-boarding (Dangerous-Addition)

Created by Scott Baker, last modified by Larry Peterson on Sep 14, 2017

Summary

This document describes the design of the CORD build-time on-boarding system. This a feature of XOS, and allows a set of services from a profile to be built into the XOS core containers.

The following is relative to the Dangerous-Addition release. For the Mysterious-Decision release, click here.

XOS Containers

XOS is deployed in a set of containers:

  • DB
  • UI
  • Core
  • Chameleon
  • Synchronizers

The DB container holds a Postgres database, which is used by the UI and Core containers. The Core container exports a gRPC API that is usable by other components. Chameleon sits on top of the Core container, and converts the gRPC API to REST.

The UI container is handles a set of legacy tasks, including serving the legacy XOS Admin, the legacy XOS REST API (currently used by VTN), the legacy Tosca engine, and database migration.

Important TOSCA Objects

The ServiceController and Library TOSCA Objects that existed in Mysterious-Decision (cord-2.0) still exist in Dangerous-Addition (cord-3.0). While in Mysterious-Decision these TOSCA objects led to service controller configuration being stored in the XOS data model, that's no longer the case in Dangerous-Addition. These TOSCA objects are now exclusively build-time entities that are used by the corebuilder container to build the xos-ui and xos-core containers.

Each XOS service defines a <servicename>-onboard recipe that contains the ServiceController object that tells XOS how to onboard the service.

Corebuilder

Corebuilder is a build tool used to generate the xosproject/xos-ui container image from the xosproject/xos container image. Corebuilder is described at https://github.com/opencord/xos/blob/master/xos/tools/corebuilder/README.md. Corebuilder imports the set of on-boarding recipes and uses those recipes to configure a build tree that contains the models, admins, APIs, and other service-related files. This build tree is then used to build the xosproject/xos-ui docker container image, which is later used to instantiate the xos-core and xos-ui containers.

Service On-boarding

While Mysterious-Decision features Makefiles that controlled Service On-boarding, Dangerous-Addition now uses a set of Ansible variables and Ansible playbooks. The overall process is summarized as follows:

  1. Each profile has a manifest in the profile_manifests directory of the platform-install repository. This profile includes a list of services and libraries that will be onboarded. For example, the rcord.yml profile includes the volt, vtn, openstack, onos, vrouter, vsg, vtr, fabric, and exampleservice services. It also optionally contains a profile_library, rcord, which contains objects that are global to the profile as a whole, as opposed to specific to an individual service.

  2. During the buildImages gradle stage for platform-install, the following steps occur
    1. Corebuilder is invoked, taking each onboarding recipe (for example, volt-onboard.yaml, vtn-onboard.yaml, etc) and using it to construct the profile-specific build tree. Xproto tools are invoked as necessary to convert xproto files into python and store the resulting python in the build tree.
    2. Dockerfile.UI is built, which takes the xosproject/xos container image and applies the build tree created in (a) to create the xosproject/xos-ui container image

To add a new service, it's necessary to edit the profile_manifest to list the new service, and then re-invoke the necessary build, publish, and deploy gradle steps.