Architecture

Basic architecture

The basic orchestration component architecture is illustrated in the following figure:

Data flow

The orchestration component receives requests through its API or through the Nimrod UI. It then orchestrates the fulfillment of those requests. During this orchestration process, the orchestration component and the Brent resource manager publish orchestration status events to Kafka topics. The Brent resource manager is responsible for orchestrating virtual infrastructure managers (VIMs) to control cloud infrastructure compute, storage, and network resources in support of their resource instances' standard life cycles.

The following illustrations show a sample data flow for the execution of an intent. First, the orchestration component receives a request for an intent through the Nimrod user interface or directly through a REST API on the Ishtar API gateway.

Then, the intent request is forwarded to the Daytona intent engine for processing.

Next, the Daytona intent engine retrieves data from the Apollo descriptor catalog and the Galileo instance repository. Daytona creates a process which is stored in the Talladega repository.

After Daytona creates the process, a response is sent to the submitter.

Daytona executes the process by calling transitions through the Brent resource manager. Daytona then updates the data in Galileo and Talladega.

Extending orchestration

Orchestration can be integrated with various external systems responsible for monitoring different aspects of an end-to-end service. These external systems, such as SQM or other assurance and analytics systems, can be extended in this way to do the following types of healing by using the orchestration northbound API: