2.2.1. FL Orchestrator

2.2.1.1. Introduction 

FL Orchestrator is one of the enablers developed in the context of the FL System of the `ASSIST-IoT project.

2.2.1.2. Features 

FL Orchestrator is responsible of specifying details of FL workflow(s)/pipeline(s). Among these details or features are:

FL job scheduling
Manage the FL life cycle
Selecting and delivering initial version(s) of the shared algorithm
Delivering the version(s) of modules used in various stages of the process, such as training stopping criteria
Handling the different “error conditions” that may occur during the FL process

2.2.1.3. Place in architecture 

Next picture depicts the FL architecture

It is in the centre of the image. It is the core element of the architecture and is responsible for initiating the different iterations of model training.

2.2.1.4. User guide 

In order to manage the training of the models in a simple way, an interface has been developed to start the training rounds of the different models available in the FL Repository.

This is how it looks like.

This is the meaning of the numbers shown in the picture:

1. List of models retrieved from the FL Repository.
2. Reload the list of models.
3. Option that allows filtering by the modelName field to search for a model from those retrieved from the FL Repository.

The Actions colummn includes these functionalities:

View model. Displays the JSON of the model. It can be seen in the following picture.

Edit model. Displays a form to insert/update the training configuration of the selected model. The following picture depicts the appearance of this form.

Taking these functionalities into account, the steps to start a training round are as follows:

Select one of the models from the list retrieved from the FL Repository.

Verify that a configuration exists for the selected model. If we pass over the Train model button and it appears disabled, it is because there is no configuration, So, the next step is to register one going to the Edit model option. Once the configuration has been saved, click on the Train model button. If the Train model is enabled, click on this option for start the training.
Click over the Train model button will show this form to confirm that will start the training for the model selected.

Once the user clicks over the Start button the training starts. UI will receive updates each time a round finishes.

2.2.1.5. Prerequisites 

The main prerequisites are the installation of Docker and Docker-compose.

The following links provide information on how to install Docker and Docker-compose.

These prerequisites are necessary in case of running the enabler as a container (Docker). However, it is also possible to run the component independently. In this case, it’s mandatory to have Python installed on the machine where the Orchestrator will be executed. At least version 3.8 is recommended (this is the version of the Python image being used). It is also necessary to install some additinal libraries or packages. These additional packages can be seen in the requirements.txt file (inside the orchestrator folder).

The following image illustrates the libraries needed for the orchestrator.

Additional pacckages in the requirements.txt file

2.2.1.6. Installation 

The first version of FL Orchestrator will be deployed with docker-compose. This file includes all the services needed to be able to deploy the FL Orchestrator API.

Next picture depicts the content of this docker-compose.

This version of docker-compose file includes 2 services:

orchestrator. Core of the enabler. Includes the definition of the API, interaction with other enablers and their main features.
mongo. Deploys a MongoDB instance used by the orchestrator to store and retrieve the configurations for the models stored in MongoDB (FL Repository).

2.2.1.6.1. Verification

FL Orchestrator and the other enablers have been conceived as APIs that will have methods that interact with each other. Therefore, the best to verify their correct deployment and operation is to test these APIs.

FL Orchestrator has a Swagger that allows to test all its methods. This swagger is deployed at the following URL: http://localhost:5000/api/docs

Next picture shows the appearance of the swagger and its methods.

Expanding the method area (/getConfigurations) in our case. The Execute option appears. Clicking on this button and if the method has the required parameters, the result code is obtained (200, in case it has gone well). Also in the curl area, it is possible to see the request that would be made to execute this method externally. In the Response body area it is possible to see the result, the list of the configurations that currently are stored in the FL Orchestrator.

Next picture depicts what has been explained in the previous paragraph. The areas code, curl and Response body are highlight.

Testing models method of FL Orchestrator API

2.2.1.6.2. Building the Docker image

The different Docker images needed to be able to deploy all the services are defined / created in files called Dockerfile.

These files are based on an initial image and the rest of the packages / libraries needed to execute the Python scripts (in our case) are installed on top of it.

Next picture depicts the content of one of this Dockerfile.