Blue Planet Orchestration uses definition modules to define data models (for example, Resource Types) or behavior (for example, system Service Templates). The information model is based on the TOSCA OASIS Standard.

Definition modules are stored in the Model Definitions area in the Assets component. Artifact Definitions are the main content of definition modules. The following table lists the types of artifacts.

A definition module can include plans that describe the management aspects of service instances, especially creation and termination. Plans are defined as process models or workflows of one or more steps that manipulate template components or interact with external systems.

Blue Planet treats all definition modules and subsidiary components as source files, managed using an integrated source-code management subsystem based on the open-source Git server. This treatment ensures change control, diff tracking, version control, reverting, and sandboxing.

Definition modules are listed in the Asset Manager and processed by Blue Planet when they are onboarded. RA installation handles processing the definition modules into Asset Manager. RAs appear in Asset Manager after successful installation. You do not need to onboard the RA into Asset Manager.

A domain describes a resource or grouping of resources you can configure using a common interface. In some cases, this interface is a CLI interface to a single device. In other cases, it is an API interface to a network management system (NMS) or virtual infrastructure manager (VIM) that pushes configurations to single or multiple resources or devices under their control. The grouping can contain physical and logical resources.

Blue Planet utilizes a resource adapter to communicate to these domains using their specific interface. The RA translates the BP API commands to communicate with the domain and resources controlled within the domain. This means that each domain pairs with an RA. There are several RAs included with the core BP software; other RAs require a separate plug-in you can purchase from Ciena.

Blue Planet possesses multi-domain service orchestration (MDSO) capabilities that allow it to communicate with all the necessary resources, even if in multiple domains, in order to combine the configurations that make up a full, end-to-end service. MDSO uses the concept of domains to connect, discover, and configure all of the resources using their specific interfaces. You can also add a domain to Blue Planet Orchestration by using the appropriate URL and port number necessary to connect to your domain controller.

Navigate to the Domains tab in the UI to add a domain. Fill out the information tabs with URL, port, and user credentials. For step-by-step instructions, see Creating a domain endif::book-build[].

Tenants are groups of users that work as part of the same organization. A user is a member of only one tenant. All domains and resources are owned by a tenant.

The relationship between tenants and domains are based on the following:

The Blue Planet User Access Control (UAC) application controls system back-end processes such as multi-tenancy. Users with access privileges can access User Administration using the UI or the REST API.

The Blue Planet Orchestration solution is responsible for associating its resources to respective tenants.

Keep the following rules and guidelines in mind when creating and using tenants and sub-tenants:

Solution Manager manages a directory structure within each application container under /bp2. The bp2 folder maps directly with subdirectory of the BP directory on the host. The bp2 directory on the host is persisted across upgrades and also backed up regularly by the platform.

A BP solution is a collection of BP applications linked together. A fig.yml file includes the application definition and how they connected to other apps. This file is derived from the fig project from Docker (http://www.fig.sh/yml.html). The Orchestration solution is one example of a BP solution.

A BP application (or app) is an application is a separate package that runs in the BP environment. Applications typically expose a north-bound API to communicate with other BP applications.

A BP application is a Docker container stored in the Docker registry (bpdr). Solution Manager is an example of a BP application.

Some BP applications implement specific functionality that allows the application to be easily reused by other applications. For example, some BP applications are wrappers for a database or a messaging queue.

Solution Manager is a BP application that manages the BP solutions within the BP environment. Solution Manager is the only BP application that must be installed to bootstrap the system. Solution Manager then deploys solutions based on the solution images that you add to it.