SLICES-RI / CONVERGE Summer School 2025 -
Post5G blueprint hands-on

Damien Saucez

► To cite this version:

Damien Saucez. SLICES-RI / CONVERGE Summer School 2025 - Post5G blueprint hands-on. Converge summer school 2025, Jun 2025, Porto, Portugal. . hal-05477316

HAL Id: hal-05477316

https://inria.hal.science/hal-05477316v1

Submitted on 26 Jan 2026

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
<figure><img src="image_2.png" /></figure>

README.md

<figure><img src="image_3.png" /></figure>

full text

SAUCEZ Damien authored 6 months ago

<figure><img src="image_4.png" /></figure>

README.md 14.66 KiB

# SLICES-RI / CONVERGE Summer School 2025

<figure><img src="image_5.png" /></figure>

## Objectives

Understand how to create, execute, and publish an experiment from zero.

## Prerequisites

* You have a browser and Internet access

* You have basic knowledge of bash

**Important:** It is NOT POSSIBLE yet to run this experiment directly from your own machine. It is mandatory to use the shell we provide.

## Building an experiment from A to Z

The post-5G blueprint is designed to simplify the definition and execution of custom experiments involving 5G technologies, as extensively described in doc.slices-ri.eu.

It mostly relies on two files:

* deploy.sh, which orchestrates the experiment.

* xp.sh, which contains the actual experiment script.

When you launch an experiment with the post5g experiment launch command, it calls deploy.sh, which provisions the environment and then runs the xp.sh script on the deployment node.
To simplify experimentation and reduce the learning curve, SLICES-RI offers a graphical user interface that generates configuration files as well as the deploy.sh file. However, users can construct their own deployment and experimentation scripts.

This document will guide you step by step on how to write your own scripts.

For the sake of the example, we will measure and publish the delay between two virtual machines deployed on the fly.

For details on how to run actual Post-5G experiments, visit [doc.slices-ri.eu](https://doc.slices-ri.eu).

# Step 1 - Access the SLICES-RI infrastructure and register to the Post 5G beta program

**TL;DR:**

* register at [https://portal.slices-ri.eu/invite/post5g-beta](https://portal.slices-ri.eu/invite/post5g-beta)

**Details:**

The entrypoint of SLICES is the [SLICES-RI portal](https://portal.slices-ri.eu), it allows you to manage your account, access to the documentation, the blueprints, the services offered by SLICES.

Post-5G experiments are carried out within the SLICES framework, where resources are structured into *projects* and *experiments*. Each experiment is associated with a project. For testing purposes, we created the *Post-5G beta* project that you can register to via [https://portal.slices-ri.eu/invite/post5g-beta](https://portal.slices-ri.eu/invite/post5g-beta) and log in using your [Slices account](https://portal.slices-ri.eu/investigate/post5g-beta).

> **NOTE:** The Post-5G beta program is part of an open data community initiative. By joining, all your actions, code, and data within the program will be shared openly with other members.

# Step 2 - setup the post-5G environment

**TL;DR:**

* Visit [https://post-5g-web.slices-ri.eu](https://post-5g-web.slices-ri.eu) and follow *pos Webshell*

* Execute `slices auth login` in this shell

* In the shell, copy this repo and move to it:

```
git clone https://gitlab.inria.fr/slices-ri/blueprints/post-5g/summerschool_2025
cd summerschool_2025
```

* Optional: setup SSH access instead of webshell

**Details:**

After you're enrolled, you can begin setting up your Post-5G experiment. Log in with your [Slices account](https://portal.slices-ri.eu) at the [Post-5G Blueprint Service](https://post-5g-blueprint-service-portal.slices-ri.eu) and choose the project on which you want to run the experiment, in this case, select `post5g-beta` that should appear in the project drop down menu. From there, go to the *pos Webshell* section. This will open a webshell window. The shell comes pre-installed with POS and the [SLICES CLI](https://github.com/slices-ri/slices-cli), so no software installation is required on your local machine. We will use this shell in all our experiments, so make sure to carefully configure it.

> **Note:** There is also an expert mode that uses SSH instead of the web interface as explained [here](https://gitlab.inria.fr/slices-ri/blueprints/post-5g/summerschool_2025/-/blob/main/README.md?ref_type=heads).

If you are using the `pos` shell for the first time, the Z Shell first-use wizard (`ZSh-newuser-install`) will prompt you to set up your Z Shell environment. Press `0` to select the default settings, or feel free to customize your environment as you wish.
```
pos allocation allocate $machine1 $machine2 --duration 120
```

* Provision the machines:

```
pos node bootstrap $machine1
```

```
pos node bootstrap $machine2
```

**Details:**

Because of time constraints, in this hands-on we rely on VM but baremetal machines can be used too (see https://doc.slices-ri.eu/BlueprintServices/beyond5G/my_first_xp.html).

As in any cloud service, VM are created following a flavor and in some area. The supported flavors so far are listed below.

<table><thead><tr><td>Name</td><td>vCPUs</td><td>Memory(MB)</td><td>Storage(GB)</td></tr></thead><tbody><tr><td>nano</td><td>2</td><td>4096</td><td>20</td></tr><tr><td>micro</td><td>2</td><td>8192</td><td>20</td></tr><tr><td>small</td><td>2</td><td>8192</td><td>20</td></tr><tr><td>medium</td><td>4</td><td>16384</td><td>40</td></tr><tr><td>large</td><td>4</td><td>16384</td><td>40</td></tr><tr><td>xlarge</td><td>8</td><td>32768</td><td>80</td></tr><tr><td>2xlarge</td><td>16</td><td>65536</td><td>160</td></tr><tr><td>3xlarge</td><td>32</td><td>131072</td><td>320</td></tr></tbody></table>

you can list them by running the following command in the shell:

```
pos2 flavor list
```

For this hands-on we will use the clusters available in the SophiaNode data center in Sophia Antipolis, France and that are 111, 113, 114, 115, and 116. Each area is a single node PROXMOX cluster offering 512 CPUs, 2.2TB of memory, and 3.6TB of storage. You can choose any of them.

Let's create 2 machines in the area 111.

```
area=111
```

```
machine1=$(pos2 vm create --area-id $area --flavor-name small)
```

```
machine1=$(jq -r '.hosts[0].name' <<< "${machine1//'//'}")
```

```
machine2=$(pos2 vm create --area-id $area --flavor-name small)
```

```
machine2=$(jq -r '.hosts[0].name' <<< "${machine2//'//'}")
```

**Note:** Under normal load, the creation of a VM takes about 60 seconds. Given the high number of attendees, this might get little higher.

Once the machines are created you should see them in pos, either using the command `pos nodes list`.

If they are present, you can pass them to the control of POS:
```bash
pos allocation allocate $machine1 $machine2 --duration 120
pos node bootstrap $machine1
pos node bootstrap $machine2
```

This will tell pos that you want to use pos to interact with them for the next 180 minutes. The bootstrap command ensures that SSH key and dependencies are properly setup on these machines for seamless integration with pos.

At this stage, machines are ready to be used in an experiment.

**Note:** You can list and create reservation with the GUI at https://duckburg.net.cit.tum.de/calendar.

## Step 4 - Writing the experiment script

TL;DR:

```bash
machine2_ip=$(getent ahosts ${machine2} | awk '{ print $1 }' | head -n 1)
RESULTS_FOLDER='~/results/'
cat << EOF > xp.sh
#!/usr/bin/bash
ping -c 4 ${machine2_ip} > ${RESULTS_FOLDER}ping.stdout 2> ${RESULTS_FOLDER}EOF
```

### Details:

There are no particular constraints for `xp.sh`. The script simply needs to be executable on the machine used to launch the experiment.

In this example, from `machine1` we will measure the RTT with `machine2`, using four ICMP probes with the `ping` command. The standard output (stdout) and standard error (stderr) will be stored in the `~/results/` directory.

```bash
machine2_ip=$(getent ahosts ${machine2} | awk '{ print $1 }' | head -n 1)
RESULTS_FOLDER='~/results/'
cat << EOF > xp.sh
#!/usr/bin/bash
ping -c 4 ${machine2_ip} > ${RESULTS_FOLDER}ping.stdout 2> ${RESULTS_FOLDER}EOF
```

## Step 5 - Run the measurement campaign and gather results

TL;DR:

* Sorry, you have to read the full text for this one :-)

### Details:

On each machine, we create a `~/results` directory where we expect experimental results to be stored.

Below is the code to configure our environment:

```perl
NODES=( $machine1 $machine2 )
# make sure the results directory exists on every node
for node in "${NODES[@]}"; do
    pos commands launch $node -- mkdir -p results
    pos commands launch $node -- touch results/README.md
done
```
Now that the nodes are up and running, we can launch the experiment. But we first have to install the experiment script on `machine1`.

Let assume that `xp.sh` is located in the current directory, we just have to copy it to `machine1` and then to execute it (and not to forget to make it executable before).

```bash
pos nodes copy $machine1 xp.sh
pos commands launch $machine1 -- chmod u+x xp.sh
pos commands launch $machine1 "./xp.sh" --verbose --name "xp_run"
```

At this stage the experiment is finished, now we have to retrieve the results `machine1` to save them outside of the node before it is destroyed.

```bash
cat <<EOF | pos command launch $machine1 -i -
#!/usr/bin/bash
pos_upload --force-upload -r results
EOF
```

The effect of this command is to upload the directory in the pos experiment directory, for each node.

The data and meta data of all the experiments made with pos are stored in `/srv/testbed/results/`.

For the experiment that we just ran, you can determine the subdirectory by running:

```bash
POS_RESULTS=/srv/testbed/results/
ALLOC_ID=$( pos allocations show $machine1 | jq -r .id )
XP_DIR=$POS_RESULTS/ $(pos allocations show $ALLOC_ID | jq -r .result folder)
```

In this subdirectory, you will see, among others the directories `machine1`, in which you will find the `results` directory that contains the copy of the results directory of the experiments. In `machine1` you will also find 3 files with the postfix

* `_xp_run.status`

* `_xp_run.stdout`

* `_xp_run.stderr`

that contain the output and status of the execution of `xp.sh` that we called `xp_run` for logging purpose.

## Step 6 - Results publication in the MRS

TL;DRL

* package experiment artifacts

* generate meta-data

* Publish the meta-data to the MRS

* Publish the dataset in the DMI

* Visit the MRS to check your meta data and data

### Details:

Data and meta-data are key to reproducible research. To that aim SLICES provides the *Metadata Registry System (MRS)* that offers a portal to manage and advertise data based on their metadata. SLICES also provides the *Data Management Infrastructure (DMI)* that is use to publish datasets and make the link with the MRS. Below we will publish with artifacts to the MRS/DMI.

First, we have to package our artefacts that are stored in the POS results directory.
```
tar -czf dataset.tar.gz $XP_DIR
```

We then determine the meta-data of the experiment. In this case we provide an example in `dataset.json.tpl`, adapt to your needs. How to automatically generating meta-data is still an open question.

```bash
export SIZE=$(du -bs $XP_DIR | cut -f 1)
export CREATED_AT=`date -u +"%Y-%m-%dT%H:%M:%S.$(printf '%06d' $(( $(date +%N) + $SIZE) )`
envsubst < dataset.json.tpl > dataset.json
```

We can now publish the metadata to the MRS. As our goal is to provide a dataset, we specifically ask the creation of a dataset. The MRS returns the unique ID of the dataset as well as the pre-authenticated temporary link to use to upload the dataset with the DMI.

```bash
DMI_TOKEN=$(slices auth get-for-audience https://mrs-portal.slices-staging
MRS_DATASET=$(curl --fail -X 'POST' -H 'accept: text/plain' -H "Authorization: Bearer $ACCESSibleToken" -H "Content-Type: application/json" -H "X-Dataset-URL: $(echo $MRS_DATASET | jq .uploadUrl | tr -d \")
DATASET_URL=$(echo $MRS_DATASET | jq .uploadUrl | tr -d \")
DATASET_ID=$(echo $MRS_DATASET | jq .digitalObjectId)
echo $DATASET_ID
```

Once the metadata is created, we can upload the data (dataset) with the DMI with the temporary link provided by the MRS. For that we use `machine1`. The mini-dmi is a docker compose package to help managing datasets. We thus have to install docker compose on `machine1` and install mini-dmi (it is also possible to use the DMI REST API directly).

```bash
pos commands launch $machine1 -- git clone https://gitlab.inria.fr/slices-ri
pos commands launch $machine1 -- apt update
pos commands launch $machine1 -- apt install -y docker.io docker-compose-v...
```

Now that the machine is ready, we can use it to upload the dataset. First we copy the dataset to this machine then upload the dataset with mini-dmi.

```bash
pos nodes copy --recursive --dest mini-dmi/storage-client-playground/ $mac1
cat <<EOF | pos command launch $machine1 -i -
#!/usr/bin/bash
cd mini-dmi
docker compose run storage_client curl -v --upload-file "dataset.tar.gz" "$DATASET_ID"
EOF
```

The dataset is now published and accessible via the MRS.

Go visit it at https://mrs-portal.slices-staging.slices-be.eu/app/management/digital-objects/view/{DATASET_ID} where {DATASET_ID} should be replaced by dataset ID obtained above ( $DATASET_ID ).

You can also just visit the MRS portal at https://mrs-portal.slices-staging.slices-be.eu

NOTE:

https://duckburg.net.cit.tum.de/