Self-api

The aeriOS self-api module is one of the essential modules within the aeriOS self-* capabilities set. The aeriOS Self-API module is part of the aeriOS system, enabling interactions with various self-* capabilities like self-healing, self-optimization, self-orchestration, self-scaling, and self-security. This module exposes the API endpoints for each service and displays them in Swagger, making it easy to view and interact with the endpoints of the system.

Relationships with another self-* capabilities

The following figure describe the self-api module and the relationships with another self-* modules.

Figure 1. Self-* capabilities relationships

Controllers Overview

The self-api module contains several controllers, each responsible for communicating with a different self-* service in aeriOS. The controllers interact with different services by sending HTTP requests using axios.

1. HEALING Controller

The Healing Controller communicates with the self-healing service to handle alerts. This controller exposes an endpoint to retrieve the current healing alerts from the system.

Endpoints:

• GET /healing/alerts: Fetches healing alerts from the self-healing system.

2. OPTIMIZATION Controller

The OPTIMIZATION Controller communicates with the self-optimization service to manage optimization tasks such as anomaly detection and power consumption optimization. It provides the following endpoints:

Endpoints:

• GET /optimization/anomaly/parameters/:type: Fetches anomaly parameters for a specific type, where :type is a variable parameter in the URL. This is used to get different anomaly detection parameters based on the type specified.
• GET /optimization/anomaly/models: Retrieves all the available anomaly models from the optimization system. This allows you to view the models used for anomaly detection.
• GET /optimization/sampling/parameters/:type: Fetches the sampling parameters for a specific type, where :type is a variable parameter in the URL. It is used to get the sampling parameters based on the specified type.
• GET /optimization/sampling/models: Retrieves all available sampling models from the system. This helps in identifying and managing different sampling models.
• POST /optimization/optimize: Sends a request to optimize the system based on the provided body data. This endpoint is used for initiating the optimization process.
• POST /optimization/optimize/powerConsumption: Sends a request to optimize power consumption, based on the provided body data. This endpoint focuses specifically on optimizing energy usage.
• PUT /optimization/sampling/parameters/:type: Updates the sampling parameters for a specific type, where :type is a variable parameter in the URL. This is used to modify the existing sampling parameters for the given type.
• PUT /optimization/anomaly/parameters/:type: Updates the anomaly detection parameters for a specific type, where :type is a variable parameter in the URL. This is used to adjust the anomaly detection settings based on the type specified.

3. ORCHESTRATOR Controller

The ORCHESTRATOR Controller manages the orchestration rules and operations related to rules within the system. It communicates with the orchestrator service to handle various rule-based operations, such as fetching, creating, updating, and deleting rules.

Endpoints:

• GET /orchestrator/rules: Fetches all the rules available in the system.
• GET /orchestrator/rule: Fetches a specific rule by its name, where name is provided as a query parameter (?name=<rule_name>).
• POST /orchestrator/rules: Creates new rules in the system using the provided body data.
• PUT /orchestrator/rule: Updates an existing rule in the system based on the provided body data.
• DELETE /orchestrator/rule: Deletes a specific rule by its name, where name is provided as a query parameter (?name=<rule_name>).
• DELETE /orchestrator/rules: Deletes all the rules in the system.

4. SCALING Controller

The SCALING Controller manages scaling operations related to training, inference, enablers, versioning, health checks, and exporting APIs. It communicates with the scaling service to handle requests for enabler management, training processes, and system health checks.

Endpoints:

• GET /scaling/enablers: Fetches all enablers available in the system
• POST /scaling/enablers: Creates new enablers in the system using the provided body data.
• GET /scaling/train-values: Fetches training values based on the provided query parameter name.
• POST /scaling/train-values: Creates new training values in the system using the provided body data.
• GET /scaling/train: Fetches training data based on the provided query parameter name.
• GET /scaling/inference: Fetches inference data based on the provided query parameter name.
• GET /scaling/version: Fetches the version of the scaling service based on the provided query parameter name.
• GET /scaling/health: Fetches the health status of the scaling service based on the provided query parameter name.
• GET /scaling/api-export: Fetches API export data based on the provided query parameter name.

5. SECURITY Controller

The SECURITY Controller is responsible for managing security events within the system. It communicates with the security service to handle event data retrieval.

Endpoits:

• GET /security/events: Fetches security events from the system, which are used for monitoring and analyzing system security.

Swagger

In an openapi.yaml file, Swaggger is defined. This file contains all the structured information that describes how to interact with the APIs, including routes, parameters, responses, status codes, and more. The Swagger UI will display information and allow users to interact with endpoints.

Environment Variables

Below are the environment variables you need to configure for the self-api module:

• PORT: The port on which the self-api is running.

• URL: The base URL where the self-api is accessible.

• SELF_ORCHESTRATOR_IP: The IP address or URL where the self-orchestrator is running.

• SELF_ORCHESTRATOR_PORT: The port where the self-orchestrator is accessible.

• SELF_OPTIMIZATION_IP: The IP address or URL where the self-optimization module is running.

• SELF_OPTIMIZATION_PORT: The port where self-optimization is accessible.

• SELF_SECURITY_IP: The IP address or URL where the self-security module is running.

• SELF_SECURITY_PORT: The port where self-security is accessible.

• SELF_SCALING_IP: The IP address or URL where the self-scaling module is running.

• SELF_SCALING_PORT: The port where self-scaling is accessible.

• SELF_HEALING_IP: The IP address or URL where the self-healing module is running.

• SELF_HEALING_PORT: The port where self-healing is accessible.

Example of a .env file:

PORT='8600'
URL='0.0.0.0'

SELF_ORCHESTRATOR_IP='10.0.0.186'
SELF_ORCHESTRATOR_PORT='8001'

SELF_OPTIMIZATION_IP='10.0.0.238'
SELF_OPTIMIZATION_PORT='8090'

SELF_SECURITY_IP='10.0.0.238'
SELF_SECURITY_PORT='8000'

SELF_SCALING_IP='10.0.0.238'
SELF_SCALING_PORT='8005'

SELF_HEALING_IP='10.0.0.238'
SELF_HEALING_PORT='8500'

Local deployment

To test the code locally, follow these steps:

1. Download all the project https://github.com/eclipse-aerios/self-api

2. In the same directory where the files were downloaded, run the following command to install the necessary dependencies:

npm install

3. In the same directory where the files were downloaded, run the following command to launch the self-api:

npm run dev

4. Accessing the Swagger: Once the self-api module is running locally, you can access the Swagger documentation by visiting the following URL:

http://<local_URL>:<local_PORT>