Orchestrating GP4L service provisioning¶
Overview¶
The goal of orchestrating GP4L service provisioning is to automate the configuration of experiments over the infrastructure of the GP4L experimental testbed. As such, GP4L service provisioning targets an adaptation to GP4L of the work done in the Polish NREN PIONIER network.
As a first step towards this goal, we deploy a virtual twin of the GP4L core network that can be used as a target to validate the service provisioning workflows developed. Using Maat as a source of truth, and using TM Forum APIs for Resource Inventory and Service Inventory, the state of the digital twin is kept as shown in the image below.
In the first phase of GP4L service provisioning, the L2 Circuit creation service is supported. The workflows involved in each service are designed to maximize reusability across services, and several tools and platforms are used for this purpose.
Ansible is used for the configuration of GP4L devices. A setup playbook can launch an HTTP API service available in RARE/freertr devices in order to accept subsequent configuration of services via HTTP requests. All Ansible configuration employs Jinja templates for their flexibility in parametrizing said configuration provided by higher orchestration layers. Additionally, the execution of Ansible playbooks is done via GÉANT Lightweight Service Orchestrator (LSO). LSO acts as a proxy that can wait for a given playbook to complete in order to return feedback. This is useful to ensure the smooth execution of service workflows. LSO accepts a JSON file with parameters and vars for Ansible, that eventually the playbook tasks use to fill up Jinja templates. This means that the core functionality can be reused across services.
Finally, Apache Airflow is used as workflow orchestrator, also following the approach taken in the PIONIER network. For the L2 circuit service provisioning, a DAG has been prepared, that contains three main tasks.
- First the user introduces parameters for the service, including origin and destination switch and interfaces, and other service parameters like VLAN ID and bandwidth.
- Next, the DAG validates the inputted data and triggers the configuration in the relevant switches via LSO.
- Finally, if the configuration has taken place correctly, the DAG triggers an update of the source of truth in Maat, by submitting two new Service Attachment Point (SAP) services and a L2 Circuit service, using schemas aligned with the TMF 638 API.
The following diagram represents the L2 Circuit provisioning workflow.
