diff --git a/doc/deployment_guide/configure_your_machine/configure_your_machine.md b/doc/deployment_guide/configure_your_machine/configure_your_machine.md
deleted file mode 100644
index 81bb9422a61cfd57de0427142a6887be1bf6b4ca..0000000000000000000000000000000000000000
--- a/doc/deployment_guide/configure_your_machine/configure_your_machine.md
+++ /dev/null
@@ -1,12 +0,0 @@
-In this section, we describe how to configure a machine (physical or virtual) to be used as the deployment, execution, and development environment for the ETSI TeraFlowSDN controller. Choose your preferred environment below and follow the instructions provided.
-
-**NOTE**: If you already have a remote physical server fitting the requirements specified in this section feel free to use it instead of deploying a local VM. Check [1.1.1. Physical Server](./1.1.-Configure-your-Machine/1.1.1.-Physical-Server) for further details.
-
-Virtualization platforms tested are:
- - [1.1.1. Physical Server](./1.1.-Configure-your-Machine/1.1.1.-Physical-Server)
- - [1.1.2. Oracle Virtual Box](./1.1.-Configure-your-Machine/1.1.2.-Oracle-Virtual-Box)
- - [1.1.3. VMWare Fusion](./1.1.-Configure-your-Machine/1.1.3.-VMWare-Fusion)
- - [1.1.4. OpenStack](./1.1.-Configure-your-Machine/1.1.4.-OpenStack)
- - [1.1.5. Vagrant Box](./1.1.-Configure-your-Machine/1.1.5.-Vagrant-Box)
-
-Other virtualization environments might be used; in that case, you will need to adapt these instructions to your particular case. If you want to contribute with details on how you used other hypervisors or platforms, [contact](https://labs.etsi.org/rep/tfs/controller/-/wikis/home#contact) the TFS team through Slack.
diff --git a/doc/deployment_guide/configure_your_machine/openstack.md b/doc/deployment_guide/configure_your_machine/openstack.md
deleted file mode 100644
index aa47dd67a785fb1ba5214faa9e643b7ccee2ef96..0000000000000000000000000000000000000000
--- a/doc/deployment_guide/configure_your_machine/openstack.md
+++ /dev/null
@@ -1,62 +0,0 @@
-
-This page describes how to configure a VM for running ETSI TeraFlowSDN(TFS) controller using [OpenStack](https://www.openstack.org/). It has been tested with OpenStack Kolla up to Yoga version.
-
-# Create a Security Group in OpenStack
-In OpenStack, go to Project - Network - Security Groups - Create Security Group with name TFS
-
-Add the following rules:
-
-|Direction |Ether Type |IP Protocol |Port Range | Remote IP Prefix|
-|-----------|-----------|------------|-----------|-----------------|
-|Ingress |IPv4 |TCP |22 (SSH) |0.0.0.0/0|
-|Ingress |IPv4 |TCP |2200 |0.0.0.0/0|
-|Ingress |IPv4 |TCP |8080 |0.0.0.0/0|
-|Ingress |IPv4 |TCP |80 |0.0.0.0/0|
-|Egress |IPv4 |Any |Any |0.0.0.0/0|
-|Egress |IPv6 |Any |Any |::/0|
-
-__Note__: The IP address will be assigned depending on the network you have configured inside OpenStack. This IP will have to be modified in TeraFlow configuration files which by default use IP 10.0.2.10
-
-# Create a flavour
-
-## From dashboard (Horizon)
-
-Go to Admin - Compute - Flavors and press Create Flavor
-
-- Name: TFS
-- VCPUs: 4
-- RAM (MB): 8192
-- Root Disk (GB): 60
-
-## From CLI
-```
- openstack flavor create TFS --id auto --ram 8192 --disk 60 --vcpus 8
-```
-# Create an instance in OpenStack:
-
-- Instance name: TFS-VM
-- Origin: [Ubuntu-22.04 cloud image] (https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64.img)
-- Create new volume: No
-- Flavor: TFS
-- Networks: extnet
-- Security Groups: TFS
-- Configuration: Include the following cloud-config
-
-```
-#cloud-config
-# Modifies the password for the VM instance
-username: ubuntu
-password: <your-password>
-chpasswd: { expire: False }
-ssh_pwauth: True
-```
-
-
-## Upgrade the Ubuntu distribution
-```bash
-sudo apt-get update -y
-sudo apt-get dist-upgrade -y
-```
-- If asked to restart services, restart the default ones proposed.
-- Restart the VM when the installation is completed.
-
diff --git a/doc/deployment_guide/configure_your_machine/oracle_virtual_box.md b/doc/deployment_guide/configure_your_machine/oracle_virtual_box.md
deleted file mode 100644
index ef0197c5b7b54c2dd08525a23bdc804e315f9f48..0000000000000000000000000000000000000000
--- a/doc/deployment_guide/configure_your_machine/oracle_virtual_box.md
+++ /dev/null
@@ -1,96 +0,0 @@
-This page describes how to configure a VM for running ETSI TeraFlowSDN(TFS) controller using [Oracle VirtualBox](https://www.virtualbox.org/). It has been tested with VirtualBox up to version 6.1.40 r154048.
-
-# Create a NAT Network in VirtualBox
-In "Oracle VM VirtualBox Manager", Menu "File > Preferences... > Network", create a NAT
-network with the following specifications:
-
-|Name |CIDR |DHCP |IPv6 |
-|-----------|-----------|--------|--------|
-|TFS-NAT-Net|10.0.2.0/24|Disabled|Disabled|
-
-Within the newly created "TFS-NAT-Net" NAT network, configure the following IPv4
-forwarding rules:
-
-|Name|Protocol|Host IP |Host Port|Guest IP |Guest Port|
-|----|--------|---------|---------|---------|----------|
-|SSH |TCP |127.0.0.1|2200 |10.0.2.10|22 |
-|HTTP|TCP |127.0.0.1|8080 |10.0.2.10|80 |
-
-__Note__: IP address 10.0.2.10 is the one that will be assigned to the VM.
-
-# Create VM in VirtualBox:
-
-- Name: TFS-VM
-- Type/Version: Linux / Ubuntu (64-bit)
-- CPU (*): 4 vCPUs @ 100% execution capacity
-- RAM: 8 GB
-- Disk: 60 GB, Virtual Disk Image (VDI), Dynamically allocated
-- Optical Drive ISO Image: "ubuntu-22.04.X-live-server-amd64.iso"
- - Download the latest Long Term Support (LTS) version of the *Ubuntu Server* image from [Ubuntu 22.04 LTS](https://releases.ubuntu.com/22.04/), e.g., "ubuntu-22.04.X-live-server-amd64.iso".
- - __Note__: use Ubuntu Server image instead of Ubuntu Desktop to create a lightweight VM.
-- Network Adapter 1 (*): enabled, attached to NAT Network "TFS-NAT-Net"
-- Minor adjustments (*):
- - Audio: disabled
- - Boot order: disable "Floppy"
-
-__Note__: (*) settings to be editing after the VM is created.
-
-# Install Ubuntu 22.04 LTS Operating System
-In "Oracle VM VirtualBox Manager", start the VM in normal mode, and follow the
-installation procedure.
-Below we provide some installation guidelines:
-- Installation Language: English
-- Autodetect your keyboard
-- If asked, select "Ubuntu Server" (do not select "Ubuntu Server (minimized)").
-- Configure static network specifications:
-
-|Interface|IPv4 Method|Subnet |Address |Gateway |Name servers |Search domains|
-|---------|-----------|-----------|---------|--------|---------------|--------------|
-|enp0s3 |Manual |10.0.2.0/24|10.0.2.10|10.0.2.1|8.8.8.8,8.8.4.4|<empty> |
-
-- Leave proxy and mirror addresses as they are
-- Let the installer self-upgrade (if asked).
-- Use an entire disk for the installation
- - Disable setup of the disk as LVM group
- - Double check that NO swap space is allocated in the partition table. Kubernetes does not work properly with SWAP.
-- Configure your user and system names:
- - User name: TeraFlowSDN
- - Server's name: tfs-vm
- - Username: tfs
- - Password: tfs123
-- Install Open SSH Server
- - Import SSH keys, if any.
-- Featured Server Snaps
- - Do not install featured server snaps. It will be done manually later to illustrate how to uninstall and reinstall them in case of trouble with.
-- Let the system install and upgrade the packages.
- - This operation might take some minutes depending on how old is the Optical Drive ISO image you use and your Internet connection speed.
-- Restart the VM when the installation is completed.
-
-## Upgrade the Ubuntu distribution
-```bash
-sudo apt-get update -y
-sudo apt-get dist-upgrade -y
-```
-- If asked to restart services, restart the default ones proposed.
-- Restart the VM when the installation is completed.
-
-
-## Install VirtualBox Guest Additions
-On VirtualBox Manager, open the VM main screen. If you are running the VM in headless
-mode, right click over the VM in the VirtualBox Manager window and click "Show".
-If a dialog informing about how to leave the interface of the VM is shown, confirm
-pressing "Switch" button. The interface of the VM should appear.
-
-Click menu "Device > Insert Guest Additions CD image..."
-
-On the VM terminal, type:
-```bash
-sudo apt-get install -y linux-headers-$(uname -r) build-essential dkms
- # This command might take some minutes depending on your VM specs and your Internet access speed.
-sudo mount /dev/cdrom /mnt/
-cd /mnt/
-sudo ./VBoxLinuxAdditions.run
- # This command might take some minutes depending on your VM specs.
-sudo reboot
-```
-
diff --git a/doc/deployment_guide/configure_your_machine/physical_server.md b/doc/deployment_guide/configure_your_machine/physical_server.md
deleted file mode 100644
index 907027fab71f7e1313881c609c71e97d9d1745a4..0000000000000000000000000000000000000000
--- a/doc/deployment_guide/configure_your_machine/physical_server.md
+++ /dev/null
@@ -1,88 +0,0 @@
-This page describes how to configure a physical server for running ETSI TeraFlowSDN(TFS) controller.
-
-# Server Specifications
-
-#### Minimum Server Specifications for development and basic deployment
-- CPU: 4 cores
-- RAM: 8 GB
-- Disk: 60 GB
-- 1 GbE NIC
-
-#### Recommended Server Specifications for development and basic deployment
-- CPU: 6 cores
-- RAM: 12 GB
-- Disk: 80 GB
-- 1 GbE NIC
-
-#### Server Specifications for best development and deployment experience
-- CPU: 8 cores
-- RAM: 32 GB
-- Disk: 120 GB
-- 1 GbE NIC
-
-**NOTE**: the specifications listed above are provided as a reference. They depend also on the CPU clock frequency, the RAM memory, the disk technology and speed, etc.
-
-For development purposes, it is recommended to run the VSCode IDE (or the IDE of your choice) in a more powerful server, for instance, the recommended server specifications for development and basic deployment.
-
-Given that TeraFlowSDN follows a micro-services architecture, for the deployment, it might be better to use many clusterized servers with many slower cores than a single server with few highly performant cores.
-
-
-# Clusterized Deployment
-You might consider creating a cluster of machines each featuring, at least, the minimum server specifications. That solution brings you scalability in the future.
-
-
-# Networking
-No explicit indications are given in terms of networking besides that servers need access to the Internet for downloading dependencies, binaries, and packages while building and deploying the TeraFlowSDN components.
-
-Besides that, the network requirements are essentially the same than that required for running a classical Kubernetes environment. To facilitate the deployment, we extensively use [MicroK8s](https://microk8s.io/), thus the network requirements are, essentially, the same demanded by MicroK8s, especially, if you consider creating a Kubernetes cluster.
-
-As a reference, the other deployment solutions based on VMs assume the VM is connected to a virtual network configured with the IP range `10.0.2.0/24` and have the gateway at IP `10.0.2.1`. The VMs have the IP address `10.0.2.10`.
-
-The minimum required ports to be accessible are:
-- 22/SSH : for management purposes
-- 80/HTTP : for the TeraFlowSDN WebUI and Grafana dashboard
-- 8081/HTTPS : for the CockroachDB WebUI
-
-Other ports might be required if you consider to deploy addons such as Kubernetes observability, etc. The details on these ports are left appart given they might vary depending on the Kubernetes environment you use.
-
-
-# Operating System
-
-The recommended Operating System for deploying TeraFlowSDN is [Ubuntu Server 22.04 LTS](https://releases.ubuntu.com/jammy/) or [Ubuntu Server 20.04 LTS](https://releases.ubuntu.com/focal/). Other version might work, but we have not tested them. We strongly recommend using Long Term Support (LTS) versions as they provide better stability.
-
-Below we provide some installation guidelines:
-- Installation Language: English
-- Autodetect your keyboard
-- If asked, select "Ubuntu Server" (do not select "Ubuntu Server (minimized)").
-- Configure static network specifications (adapt them based on your particular setup):
-
-|Interface|IPv4 Method|Subnet |Address |Gateway |Name servers |Search domains|
-|---------|-----------|-----------|---------|--------|---------------|--------------|
-|enp0s3 |Manual |10.0.2.0/24|10.0.2.10|10.0.2.1|8.8.8.8,8.8.4.4|<empty> |
-
-- Leave proxy and mirror addresses as they are
-- Let the installer self-upgrade (if asked).
-- Use an entire disk for the installation
- - Disable setup of the disk as LVM group
- - Double check that NO swap space is allocated in the partition table. Kubernetes does not work properly with SWAP.
-- Configure your user and system names:
- - User name: `TeraFlowSDN`
- - Server's name: `tfs-vm`
- - Username: `tfs`
- - Password: `tfs123`
-- Install Open SSH Server
- - Import SSH keys, if any.
-- Featured Server Snaps
- - Do not install featured server snaps. It will be done manually later to illustrate how to uninstall and reinstall them in case of trouble with.
-- Let the system install and upgrade the packages.
- - This operation might take some minutes depending on how old is the Optical Drive ISO image you use and your Internet connection speed.
-- Restart the VM when the installation is completed.
-
-## Upgrade the Ubuntu distribution
-```bash
-sudo apt-get update -y
-sudo apt-get dist-upgrade -y
-```
-- If asked to restart services, restart the default ones proposed.
-- Restart the VM when the installation is completed.
-
diff --git a/doc/deployment_guide/configure_your_machine/vagrant_box.md b/doc/deployment_guide/configure_your_machine/vagrant_box.md
deleted file mode 100644
index 075e9cdea262e659f77bf8c6b928a747e7deb2a9..0000000000000000000000000000000000000000
--- a/doc/deployment_guide/configure_your_machine/vagrant_box.md
+++ /dev/null
@@ -1,255 +0,0 @@
-This page describes how to create a Vagrant Box, using the base virtual machine configured in [Oracle Virtual Box](./1.1.2.-Oracle-Virtual-Box).
-
-# Virtual Machine specifications
-Most of the specifications can be as specified in the [Oracle Virtual Box](./1.1.2.-Oracle-Virtual-Box) page, however, there are a few particularities to Vagrant that must be accommodated, such as:
-- Virtual Hard Disk
- - Size: 60GB (at least)
- - **Type**: VMDK
-
-
-
-Also, before initiating the VM and installing the OS, we'll need to:
-- Disable Floppy in the 'Boot Order'
-- Disable audio
-- Disable USB
-- Ensure Network Adapter 1 is set to NAT
-
-# Network configurations
-At Network Adapt 1, the following port-forwarding rule must be set.
-
-| Name | Protocol | Host IP | Host Port | Guest IP | Guest Port |
-| - | - | - | - | - | - |
-| SSH | TCP | | **2222** | | 22 |
-
-
-
-# Installing the OS
-
-For a Vagrant Box, it is generally suggested that the ISO's server version is used, as it is intended to be used via SSH, and any web GUI is expected to be forwarded to the host.
-
-
-
-
-
-
-
-Make sure the disk is not configured as an LVM group!
-
-
-
-## Vagrant ser
-Vagrant expects by default, that in the box's OS exists the user `vagrant` with the password also being `vagrant`.
-
-
-
-## SSH
-
-Vagrant uses SSH to connect to the boxes, so installing it now will save the hassle of doing it later.
-
-
-
-## Features server snaps
-
-Do not install featured server snaps. It will be done manually [later](./1.-Deployment-Guide/1.2.-Install-Microk8s) to illustrate how to uninstall and reinstall them in case of trouble with.
-
-## Updates
-
-Let the system install and upgrade the packages. This operation might take some minutes depending on how old is the Optical Drive ISO image you use and your Internet connection speed.
-
-## Upgrade the Ubuntu distribution
-```bash
-sudo apt-get update -y
-sudo apt-get dist-upgrade -y
-```
-- If asked to restart services, restart the default ones proposed.
-- Restart the VM when the installation is completed.
-
-### Install VirtualBox Guest Additions
-On VirtualBox Manager, open the VM main screen. If you are running the VM in headless
-mode, right-click over the VM in the VirtualBox Manager window, and click "Show".
-If a dialog informing about how to leave the interface of the VM is shown, confirm
-by pressing the "Switch" button. The interface of the VM should appear.
-
-Click the menu "Device > Insert Guest Additions CD image..."
-
-On the VM terminal, type:
-```bash
-sudo apt-get install -y linux-headers-$(uname -r) build-essential dkms
- # This command might take some minutes depending on your VM specs and your Internet access speed.
-sudo mount /dev/cdrom /mnt/
-cd /mnt/
-sudo ./VBoxLinuxAdditions.run
- # This command might take some minutes depending on your VM specs.
-sudo reboot
-```
-
-# ETSI TFS Installation
-After this, proceed to [1.2. Install Microk8s](./1.-Deployment-Guide/1.2.-Install-Microk8s), after which, return to this wiki to finish the Vagrant Box creation.
-
-# Box configuration and creation
-Make sure the ETSI TFS controller is correctly configured. **You will not be able to change it after!**
-
-It is advisable to do the next configurations from a host's terminal, via a SSH connection.
-```bash
-ssh -p 2222 vagrant@127.0.0.1
-```
-
-## Set root password
-Set the root password to `vagrant`.
-```bash
-sudo passwd root
-```
-
-## Set the superuser
-Set up the Vagrant user so that it’s able to use sudo without being prompted for a password.
-Anything in the `/etc/sudoers.d/*` directory is included in the sudoers privileges when created by the root user.
-Create a new sudo file.
-```bash
-sudo visudo -f /etc/sudoers.d/vagrant
-```
-and add the following lines
-```text
-# add vagrant user
-vagrant ALL=(ALL) NOPASSWD:ALL
-```
-You can now test that it works by running a simple command.
-```bash
-sudo pwd
-```
-Issuing this command should result in an immediate response without a request for a password.
-
-## Install the Vagrant key
-Vagrant uses a default set of SSH keys for you to directly connect to boxes via the CLI command `vagrant ssh`, after which it creates a new set of SSH keys for your new box. Because of this, we need to load the default key to be able to access the box after created.
-```bash
-chmod 0700 /home/vagrant/.ssh
-wget --no-check-certificate https://raw.github.com/mitchellh/vagrant/master/keys/vagrant.pub -O /home/vagrant/.ssh/authorized_keys
-chmod 0600 /home/vagrant/.ssh/authorized_keys
-chown -R vagrant /home/vagrant/.ssh
-```
-
-## Configure the OpenSSH Server
-Edit the `/etc/ssh/sshd_config` file:
-```bash
-sudo vim /etc/ssh/sshd_config
-```
-And uncomment the following line:
-```bash
-AuthorizedKeysFile %h/.ssh/authorized_keys
-```
-Then restart SSH.
-```bash
-sudo service ssh restart
-```
-
-## Package the box
-Before you package the box, if you intend to make your box public, it is best to clean your bash history with:
-```bash
-history -c
-```
-Exit the SSH connection, and **at you're host machine**, package the VM:
-```bash
-vagrant package --base teraflowsdncontroller --output teraflowsdncontroller.box
-```
-
-## Test run the box
-Add the base box to you local Vagrant box list:
-```bash
-vagrant box add --name teraflowsdncontroller ./teraflowsdncontroller.box
-```
-Now you should try to run it, for that you'll need to create a **Vagrantfile**. For a simple run, this is the minimal required code for this box:
-```ruby
-# -*- mode: ruby -*-
-# vi: set ft=ruby :
-
-Vagrant.configure("2") do |config|
- config.vm.box = "teraflowsdncontroller"
- config.vm.box_version = "1.1.0"
- config.vm.network :forwarded_port, host: 8080 ,guest: 80
-end
-```
-Now you'll be able to spin up the virtual machine by issuing the command:
-```bash
-vagrant up
-```
-And connect to the machine using:
-```bash
-vagrant ssh
-```
-
-# Pre-configured boxes
-If you do not wish to create your own Vagrant Box, you can use one of the existing ones created by TFS contributors.
-- [davidjosearaujo/teraflowsdncontroller](https://app.vagrantup.com/davidjosearaujo/boxes/teraflowsdncontroller)
-- ... <!-- Should create and host one at ETSI!! -->
-
-To use them, you simply have to create a Vagrantfile and run `vagrant up controller` in the same directory. The following example Vagrantfile already allows you to do just that, with the bonus of exposing the multiple management GUIs to your `localhost`.
-```ruby
-Vagrant.configure("2") do |config|
-
- config.vm.define "controller" do |controller|
- controller.vm.box = "davidjosearaujo/teraflowsdncontroller"
- controller.vm.network "forwarded_port", guest: 80, host: 8080 # WebUI
- controller.vm.network "forwarded_port", guest: 8084, host: 50750 # Linkerd Viz Dashboard
- controller.vm.network "forwarded_port", guest: 8081, host: 8081 # CockroachDB Dashboard
- controller.vm.network "forwarded_port", guest: 8222, host: 8222 # NATS Dashboard
- controller.vm.network "forwarded_port", guest: 9000, host: 9000 # QuestDB Dashboard
- controller.vm.network "forwarded_port", guest: 9090, host: 9090 # Prometheus Dashboard
-
- # Setup Linkerd Viz reverse proxy
- ## Copy config file
- controller.vm.provision "file" do |f|
- f.source = "./reverse-proxy-linkerdviz.sh"
- f.destination = "./reverse-proxy-linkerdviz.sh"
- end
- ## Execute configuration file
- controller.vm.provision "shell" do |s|
- s.inline = "chmod +x ./reverse-proxy-linkerdviz.sh && ./reverse-proxy-linkerdviz.sh"
- end
-
- # Update controller source code to the desired branch
- if ENV['BRANCH'] != nil
- controller.vm.provision "shell" do |s|
- s.inline = "cd ./tfs-ctrl && git pull && git switch " + ENV['BRANCH']
- end
- end
-
- end
-end
-```
-This Vagrantfile also allows for **optional repository updates** on startup by running the command with a specified environment variable `BRANCH`
-```bash
-BRANCH=develop vagrant up controller
-```
-
-## Linkerd DNS rebinding bypass
-Because of Linkerd's security measures against DNS rebinding, a reverse proxy, that modifies the request's header `Host` field, is needed to expose the GUI to the host. The previous Vagrantfile already deploys such configurations, for that, all you need to do is create the `reverse-proxy-linkerdviz.sh` file in the same directory. The content of this file is displayed below.
-```bash
-# Install NGINX
-sudo apt update && sudo apt install nginx -y
-
-# NGINX reverse proxy configuration
-echo 'server {
- listen 8084;
-
- location / {
- proxy_pass http://127.0.0.1:50750;
- proxy_set_header Host localhost;
- proxy_set_header X-Real-IP $remote_addr;
- proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
- proxy_set_header X-Forwarded-Proto $scheme;
- }
-}' > /home/vagrant/expose-linkerd
-
-# Create symlink of the NGINX configuration file
-sudo ln -s /home/vagrant/expose-linkerd /etc/nginx/sites-enabled/
-
-# Commit the reverse proxy configurations
-sudo systemctl restart nginx
-
-# Enable start on login
-echo "linkerd viz dashboard &" >> .profile
-
-# Start dashboard
-linkerd viz dashboard &
-
-echo "Linkerd Viz dashboard running!"
-```
diff --git a/doc/deployment_guide/configure_your_machine/vm_ware_fusion.md b/doc/deployment_guide/configure_your_machine/vm_ware_fusion.md
deleted file mode 100644
index 9e4c20de7d52126673f24dcd70ea267de3e8d836..0000000000000000000000000000000000000000
--- a/doc/deployment_guide/configure_your_machine/vm_ware_fusion.md
+++ /dev/null
@@ -1,54 +0,0 @@
-This page describes how to configure a VM for running ETSI TeraFlowSDN(TFS) controller using [VMWare Fusion](https://www.vmware.com/products/fusion.html). It has been tested with VMWare Fusion version 12 and 13.
-
-# Create VM in VMWare Fusion:
-
-In "VMWare Fusion" manager, create a new network from the "Settings/Network" menu.
-
-- Unlock to make changes
-- Press the + icon and create a new network
-- Change the name to TFS-NAT-Net
-- Check "Allow virtual machines on this network to connect to external network (NAT)"
-- Do not check "Enable IPv6"
-- Add port forwarding for HTTP and SSH
-- Uncheck "Provide address on this network via DHCP"
-
-Create a new VM an Ubuntu 22.04.1 ISO:
-
-- Display Name: TeraFlowSDN
-- Username: tfs
-- Password: tfs123
-
-On the next screen press "Customize Settings", save the VM and in "Settings" change:
-- Change to use 4 CPUs
-- Change to access 8 GB of RAM
-- Change disk to size 60 GB
-- Change the network interface to use the previously created TFS-NAT-Net
-
-Run the VM to start the installation.
-
-# Install Ubuntu 22.04.1 LTS Operating System
-
-The installation will be automatic, without any configuration required.
-
-- Configure the guest IP, gateway and DNS:
-
- Using the Network Settings for the wired connection, set the IP to 10.0.2.10,
- the mask to 255.255.255.0, the gateway to 10.0.2.2 and the DNS to 10.0.2.2.
-
-- Disable and remove swap file:
-
- $ sudo swapoff -a
- $ sudo rm /swapfile
-
- Then you can remove or comment the /swapfile entry in /etc/fstab
-
-- Install Open SSH Server
- - Import SSH keys, if any.
-
-- Restart the VM when the installation is completed.
-
-# Upgrade the Ubuntu distribution
-```bash
-sudo apt-get update -y
-sudo apt-get dist-upgrade -y
-```
diff --git a/doc/deployment_guide/deploy_TeraFlowSDN/deploy_TeraFlowSDN.md b/doc/deployment_guide/deploy_TeraFlowSDN/deploy_TeraFlowSDN.md
deleted file mode 100644
index 05638ea48c41284518a1b41906f3a27fb5ccf04b..0000000000000000000000000000000000000000
--- a/doc/deployment_guide/deploy_TeraFlowSDN/deploy_TeraFlowSDN.md
+++ /dev/null
@@ -1,159 +0,0 @@
-This section describes how to deploy TeraFlowSDN controller on top of MicroK8s using the
-environment configured in the previous sections.
-
-
-## Install prerequisites
-```bash
-sudo apt-get install -y git curl jq
-```
-
-
-## Clone the Git repository of the TeraFlowSDN controller
-Clone from ETSI-hosted GitLab code repository:
-```bash
-mkdir ~/tfs-ctrl
-git clone https://labs.etsi.org/rep/tfs/controller.git ~/tfs-ctrl
-```
-
-__Important__: The original H2020-TeraFlow project hosted on GitLab.com has been
-archieved and will not receive further contributions/updates.
-Please, clone from [ETSI-hosted GitLab code repository](https://labs.etsi.org/rep/tfs/controller).
-
-
-## Checkout the appropriate Git branch
-TeraFlowSDN controller versions can be found in the appropriate release tags and/or branches as described in [Home > Versions](/Home#versions).
-
-By default the branch *master* is checked out and points to the latest stable version of the TeraFlowSDN controller, while branch *develop* contains the latest developments and contributions under test and validation.
-
-To switch to the appropriate branch run the following command, changing `develop` by the name of the branch you want to deploy:
-```bash
-cd ~/tfs-ctrl
-git checkout develop
-```
-
-
-## Prepare a deployment script with the deployment settings
-Create a new deployment script, e.g., `my_deploy.sh`, adding the appropriate settings as
-follows.
-This section provides just an overview of the available settings. An example [`my_deploy.sh`](https://labs.etsi.org/rep/tfs/controller/-/blob/master/my_deploy.sh) script is provided in the root folder of the project for your convenience with full description of all the settings.
-
-__Note__: The example `my_deploy.sh` script provides reasonable settings for deploying a functional and complete enough TeraFlowSDN controller, and a brief description of their meaning. To see extended descriptions, check scripts in the `deploy` folder.
-
-```bash
-cd ~/tfs-ctrl
-tee my_deploy.sh >/dev/null << EOF
-# ----- TeraFlowSDN ------------------------------------------------------------
-export TFS_REGISTRY_IMAGES="http://localhost:32000/tfs/"
-export TFS_COMPONENTS="context device ztp monitoring pathcomp service slice nbi webui load_generator"
-export TFS_IMAGE_TAG="dev"
-export TFS_K8S_NAMESPACE="tfs"
-export TFS_EXTRA_MANIFESTS="manifests/nginx_ingress_http.yaml"
-export TFS_GRAFANA_PASSWORD="admin123+"
-export TFS_SKIP_BUILD=""
-
-# ----- CockroachDB ------------------------------------------------------------
-export CRDB_NAMESPACE="crdb"
-export CRDB_EXT_PORT_SQL="26257"
-export CRDB_EXT_PORT_HTTP="8081"
-export CRDB_USERNAME="tfs"
-export CRDB_PASSWORD="tfs123"
-export CRDB_DATABASE="tfs"
-export CRDB_DEPLOY_MODE="single"
-export CRDB_DROP_DATABASE_IF_EXISTS="YES"
-export CRDB_REDEPLOY=""
-
-# ----- NATS -------------------------------------------------------------------
-export NATS_NAMESPACE="nats"
-export NATS_EXT_PORT_CLIENT="4222"
-export NATS_EXT_PORT_HTTP="8222"
-export NATS_REDEPLOY=""
-
-# ----- QuestDB ----------------------------------------------------------------
-export QDB_NAMESPACE="qdb"
-export QDB_EXT_PORT_SQL="8812"
-export QDB_EXT_PORT_ILP="9009"
-export QDB_EXT_PORT_HTTP="9000"
-export QDB_USERNAME="admin"
-export QDB_PASSWORD="quest"
-export QDB_TABLE_MONITORING_KPIS="tfs_monitoring_kpis"
-export QDB_TABLE_SLICE_GROUPS="tfs_slice_groups"
-export QDB_DROP_TABLES_IF_EXIST="YES"
-export QDB_REDEPLOY=""
-
-EOF
-```
-
-The settings are organized in 4 sections:
-- Section `TeraFlowSDN`:
- - `TFS_REGISTRY_IMAGE` enables to specify the private Docker registry to be used, by default, we assume to use the Docker respository enabled in MicroK8s.
- - `TFS_COMPONENTS` specifies the components their Docker image will be rebuilt, uploaded to the private Docker registry, and deployed in Kubernetes.
- - `TFS_IMAGE_TAG` defines the tag to be used for Docker images being rebuilt and uploaded to the private Docker registry.
- - `TFS_K8S_NAMESPACE` specifies the name of the Kubernetes namespace to be used for deploying the TFS components.
- - `TFS_EXTRA_MANIFESTS` enables to provide additional manifests to be applied into the Kubernetes environment during the deployment. Typical use case is to deploy ingress controllers, service monitors for Prometheus, etc.
- - `TFS_GRAFANA_PASSWORD` lets you specify the password you want to use for the `admin` user of the Grafana instance being deployed and linked to the Monitoring component.
- - `TFS_SKIP_BUILD`, if set to `YES`, prevents rebuilding the Docker images. That means, the deploy script will redeploy existing Docker images without rebuilding/updating them.
-
-- Section `CockroachDB`: enables to configure the deployment of the backend [CockroachDB](https://www.cockroachlabs.com/) database.
- - Check example script [`my_deploy.sh`](https://labs.etsi.org/rep/tfs/controller/-/blob/master/my_deploy.sh) for further details.
-
-- Section `NATS`: enables to configure the deployment of the backend [NATS](https://nats.io/) message broker.
- - Check example script [`my_deploy.sh`](https://labs.etsi.org/rep/tfs/controller/-/blob/master/my_deploy.sh) for further details.
-
-- Section `QuestDB`: enables to configure the deployment of the backend [QuestDB](https://questdb.io/) timeseries database.
- - Check example script [`my_deploy.sh`](https://labs.etsi.org/rep/tfs/controller/-/blob/master/my_deploy.sh) for further details.
-
-
-## Confirm that MicroK8s is running
-
-Run the following command:
-```bash
-microk8s status
-```
-
-If it is reported `microk8s is not running, try microk8s start`, run the following command to start MicroK8s:
-```bash
-microk8s start
-```
-
-Confirm everything is up and running:
-
-1. Periodically [Check the status of Kubernetes](/1.-Deployment-Guide/1.2.-Install-MicroK8s#check-status-of-kubernetes-and-addons) until you see the addons \[dns, ha-cluster, helm3, hostpath-storage, ingress, registry, storage\] in the enabled block.
-2. Periodically [Check Kubernetes resources](/1.-Deployment-Guide/1.2.-Install-MicroK8s#check-all-resources-in-kubernetes) until all pods are **Ready** and **Running**.
-
-
-## Deploy TFS controller
-First, source the deployment settings defined in the previous section.
-This way, you do not need to specify the environment variables in each and every command you execute to operate the TFS controller.
-Be aware to re-source the file if you open new terminal sessions.
-Then, run the following command to deploy TeraFlowSDN controller on top of the MicroK8s Kubernetes platform.
-
-```bash
-cd ~/tfs-ctrl
-source my_deploy.sh
-./deploy/all.sh
-```
-
-The script performs the following steps:
-- Executes script `./deploy/crdb.sh` to automate deployment of CockroachDB database used by Context component.
- - The script automatically checks if CockroachDB is already deployed.
- - If there are settings instructing to drop the database and/or redeploy CockroachDB, it does the appropriate actions to honor them as defined in previous section.
-- Executes script `./deploy/nats.sh` to automate deployment of NATS message broker used by Context component.
- - The script automatically checks if NATS is already deployed.
- - If there are settings instructing to redeploy the message broker, it does the appropriate actions to honor them as defined in previous section.
-- Executes script `./deploy/qdb.sh` to automate deployment of QuestDB timeseries database used by Monitoring component.
- - The script automatically checks if QuestDB is already deployed.
- - If there are settings instructing to redeploy the timeseries database, it does the appropriate actions to honor them as defined in previous section.
-- Executes script `./deploy/tfs.sh` to automate deployment of TeraFlowSDN.
- - Creates the namespace defined in `TFS_K8S_NAMESPACE`
- - Creates secrets for CockroachDB, NATS, and QuestDB to be used by Context and Monitoring components.
- - Builds the Docker images for the components defined in `TFS_COMPONENTS`
- - Tags the Docker images with the value of `TFS_IMAGE_TAG`
- - Pushes the Docker images to the repository defined in `TFS_REGISTRY_IMAGE`
- - Deploys the components defined in `TFS_COMPONENTS`
- - Creates the file `tfs_runtime_env_vars.sh` with the environment variables for the components defined in `TFS_COMPONENTS` defining their local host addresses and their port numbers.
- - Applies extra manifests defined in `TFS_EXTRA_MANIFESTS` such as:
- - Creating an ingress controller listening at port 80 for HTTP connections to enable external access to the TeraFlowSDN WebUI, Grafana Dashboards, and Compute NBI interfaces.
- - Deploying service monitors to enable monitoring the performance of the components, device drivers and service handlers.
- - Initialize and configure the Grafana dashboards (if Monitoring component is deployed)
-- Report a summary of the deployment
- - See [Show Deployment and Logs](./1.5.-Show-Deployment-and-Logs)
diff --git a/doc/deployment_guide/install_micro_k8s/install_micro_k8s.md b/doc/deployment_guide/install_micro_k8s/install_micro_k8s.md
deleted file mode 100644
index 207395f37eff08c9cd8411a4df34ad095a359656..0000000000000000000000000000000000000000
--- a/doc/deployment_guide/install_micro_k8s/install_micro_k8s.md
+++ /dev/null
@@ -1,217 +0,0 @@
-This section describes how to deploy the MicroK8s Kubernetes platform and configure it
-to be used with ETSI TeraFlowSDN controller.
-Besides, Docker is installed to build docker images for the ETSI TeraFlowSDN controller.
-
-The steps described in this section might take some minutes depending on your internet
-connection speed and the resources assigned to your VM, or the specifications of your
-physical server.
-
-To facilitate work, these steps are easier to be executed through an SSH connection, for instance using tools like [PuTTY](https://www.putty.org/) or [MobaXterm](https://mobaxterm.mobatek.net/).
-
-
-## Upgrade the Ubuntu distribution
-Skip this step if you already did it during the creation of the VM.
-```bash
-sudo apt-get update -y
-sudo apt-get dist-upgrade -y
-```
-
-
-## Install prerequisites
-```bash
-sudo apt-get install -y ca-certificates curl gnupg lsb-release snapd jq
-```
-
-
-## Install Docker CE
-Install Docker CE and Docker BuildX plugin
-```bash
-sudo apt-get install -y docker.io docker-buildx
-```
-
-**NOTE**: Starting from Docker v23, [Build architecture](https://docs.docker.com/build/architecture/) has been updated and `docker build` command entered into deprecation process in favor of the new `docker buildx build` command. Package `docker-buildx` provides the new `docker buildx build` command.
-
-Add key "insecure-registries" with the private repository to the daemon configuration. It is done in two commands since
-sometimes read from and write to same file might cause trouble.
-
-```bash
-if [ -s /etc/docker/daemon.json ]; then cat /etc/docker/daemon.json; else echo '{}'; fi \
- | jq 'if has("insecure-registries") then . else .+ {"insecure-registries": []} end' -- \
- | jq '."insecure-registries" |= (.+ ["localhost:32000"] | unique)' -- \
- | tee tmp.daemon.json
-sudo mv tmp.daemon.json /etc/docker/daemon.json
-sudo chown root:root /etc/docker/daemon.json
-sudo chmod 600 /etc/docker/daemon.json
-```
-
-Restart the Docker daemon
-```bash
-sudo systemctl restart docker
-```
-
-
-## Install MicroK8s
-
-**Important**: Some TeraFlowSDN dependencies need to be executed on top of MicroK8s/Kubernetes v1.24. It is not guaranteed (by now) to run on newer versions.
-
-```bash
-# Install MicroK8s
-sudo snap install microk8s --classic --channel=1.24/stable
-
-# Create alias for command "microk8s.kubectl" to be usable as "kubectl"
-sudo snap alias microk8s.kubectl kubectl
-```
-
-It is important to make sure that `ufw` will not interfere with the internal pod-to-pod
-and pod-to-Internet traffic.
-To do so, first check the status.
-If `ufw` is active, use the following command to enable the communication.
-
-```bash
-
-# Verify status of ufw firewall
-sudo ufw status
-
-# If ufw is active, install following rules to enable access pod-to-pod and pod-to-internet
-sudo ufw allow in on cni0 && sudo ufw allow out on cni0
-sudo ufw default allow routed
-```
-
-**NOTE**: MicroK8s can be used to compose a Highly Available Kubernetes cluster enabling you to construct an environment combining the CPU, RAM and storage resources of multiple machines. If you are interested in this procedure, review the official instructions in [How to build a highly available Kubernetes cluster with MicroK8s](https://ubuntu.com/tutorials/getting-started-with-kubernetes-ha), in particular, the step [Create a MicroK8s multi-node cluster](https://ubuntu.com/tutorials/getting-started-with-kubernetes-ha#4-create-a-microk8s-multinode-cluster).
-
-#### References:
-- [The lightweight Kubernetes > Install MicroK8s](https://microk8s.io/#install-microk8s)
-- [Install a local Kubernetes with MicroK8s](https://ubuntu.com/tutorials/install-a-local-kubernetes-with-microk8s)
-- [How to build a highly available Kubernetes cluster with MicroK8s](https://ubuntu.com/tutorials/getting-started-with-kubernetes-ha)
-
-
-## Add user to the docker and microk8s groups
-
-It is important that your user has the permission to run `docker` and `microk8s` in the
-terminal.
-To allow this, you need to add your user to the `docker` and `microk8s` groups with the
-following commands:
-
-```bash
-sudo usermod -a -G docker $USER
-sudo usermod -a -G microk8s $USER
-sudo chown -f -R $USER $HOME/.kube
-sudo reboot
-```
-
-In case that you get trouble executing the following commands, might due to the .kube folder is not automatically provisioned into your home folder, you may follow the steps below:
-
-```bash
-mkdir -p $HOME/.kube
-sudo chown -f -R $USER $HOME/.kube
-microk8s config > $HOME/.kube/config
-sudo reboot
-```
-
-## Check status of Kubernetes and addons
-To retrieve the status of Kubernetes __once__, run the following command:
-```bash
-microk8s.status --wait-ready
-```
-
-To retrieve the status of Kubernetes __periodically__ (e.g., every 1 second), run the
-following command:
-```bash
-watch -n 1 microk8s.status --wait-ready
-```
-
-## Check all resources in Kubernetes
-To retrieve the status of the Kubernetes resources __once__, run the following command:
-```bash
-kubectl get all --all-namespaces
-```
-
-To retrieve the status of the Kubernetes resources __periodically__ (e.g., every 1
-second), run the following command:
-```bash
-watch -n 1 kubectl get all --all-namespaces
-```
-
-## Enable addons
-
-First, we need to enable the community plugins (maintained by third parties):
-
-```bash
-microk8s.enable community
-```
-
-The Addons to be enabled are:
-- `dns`: enables resolving the pods and services by name
-- `helm3`: required to install NATS
-- `hostpath-storage`: enables providing storage for the pods (required by `registry`)
-- `ingress`: deploys an ingress controller to expose the microservices outside Kubernetes
-- `registry`: deploys a private registry for the TFS controller images
-- `linkerd`: deploys the [linkerd service mesh](https://linkerd.io) used for load balancing among replicas
-- `prometheus`: set of tools that enable TFS observability through per-component instrumentation
-- `metrics-server`: deploys the [Kubernetes metrics server](https://github.com/kubernetes-sigs/metrics-server) for API access to service metrics
-
-```bash
-microk8s.enable dns helm3 hostpath-storage ingress registry prometheus metrics-server linkerd
-```
-
-__Important__: Enabling some of the addons might take few minutes.
-Do not proceed with next steps until the addons are ready.
-Otherwise, the deployment might fail.
-To confirm everything is up and running:
-1. Periodically
- [Check the status of Kubernetes](./1.2.-Install-MicroK8s#check-status-of-kubernetes-and-addons)
- until you see the addons [dns, ha-cluster, helm3, hostpath-storage, ingress, linkerd, metrics-server, prometheus, registry, storage] in the enabled block.
-2. Periodically
- [Check Kubernetes resources](./1.2.-Install-MicroK8s#check-all-resources-in-kubernetes)
- until all pods are __Ready__ and __Running__.
-3. If it takes too long for the Pods to be ready, __we observed that rebooting the machine may help__.
-
-Then, create aliases to make the commands easier to access:
-
-```bash
-sudo snap alias microk8s.helm3 helm3
-sudo snap alias microk8s.linkerd linkerd
-```
-
-To validate that `linkerd` is working correctly, run:
-
-```bash
-linkerd check
-```
-
-To validate that the `metrics-server` is working correctly, run:
-```bash
-kubectl top pods --all-namespaces
-```
-and you should see a screen similar to the `top` command in Linux, showing the columns *namespace*, *pod name*, *CPU (cores)*, and *MEMORY (bytes)*.
-
-In case pods are not starting, check information from pods logs. For example, linkerd is sensitive for proper /etc/resolv.conf syntax.
-```bash
-kubectl logs <podname> --namespace <namespace>
-```
-If the command shows an error message, also restarting the machine might help.
-
-## Stop, Restart, and Redeploy
-Find below some additional commands you might need while you work with MicroK8s:
-```bash
-microk8s.stop # stop MicroK8s cluster (for instance, before power off your computer)
-microk8s.start # start MicroK8s cluster
-microk8s.reset # reset infrastructure to a clean state
-```
-
-If the following commands does not work to recover the MicroK8s cluster, you can redeploy it.
-
-If you want to keep MicroK8s configuration, use:
-```bash
-sudo snap remove microk8s
-```
-
-If you need to completely drop MicroK8s and its complete configuration, use:
-```bash
-sudo snap remove microk8s --purge
-sudo apt-get remove --purge docker.io docker-buildx
-```
-
-**IMPORTANT**: After uninstalling MicroK8s, it is convenient to reboot the computer (the VM if you work on a VM, or the physical computer if you use a physical computer). Otherwise, there are system configurations that are not correctly cleaned. Especially in what port forwarding and firewall rules matters.
-
-After the reboot, redeploy as it is described in this section.
diff --git a/doc/deployment_guide/show_deployment_and_logs/show_deployment_and_logs.md b/doc/deployment_guide/show_deployment_and_logs/show_deployment_and_logs.md
deleted file mode 100644
index 96d6147463db79c8430887f673b8e424cec355c3..0000000000000000000000000000000000000000
--- a/doc/deployment_guide/show_deployment_and_logs/show_deployment_and_logs.md
+++ /dev/null
@@ -1,33 +0,0 @@
-This section presents some helper scripts to inspect the status of the deployment and
-the logs of the components.
-These scripts are particularly helpful for troubleshooting during execution of
-experiments, development, and debugging.
-
-
-## Report the deployment of the TFS controller
-
-The summary report given at the end of the [Deploy TFS controller](./1.3.-Deploy-TeraFlowSDN#deploy-tfs-controller)
-procedure can be generated manually at any time by running the following command.
-You can avoid sourcing `my_deploy.sh` if it has been already done.
-```bash
-cd ~/tfs-ctrl
-source my_deploy.sh
-./deploy/show.sh
-```
-
-Use this script to validate that all the pods, deployments, replica sets, ingress
-controller, etc. are ready and have the appropriate state, e.g., *running* for Pods, and
-the services are deployed and have appropriate IP addresses and port numbers.
-
-
-## Report the log of a specific TFS controller component
-
-A number of scripts are pre-created in the `scripts` folder to facilitate the inspection
-of the component logs.
-For instance, to dump the log of the Context component, run the following command.
-You can avoid sourcing `my_deploy.sh` if it has been already done.
-
-```bash
-source my_deploy.sh
-./scripts/show_logs_context.sh
-```
diff --git a/doc/deployment_guide/webUI_and_grafana_dashboards/webUI_and_grafana_dashboards.md b/doc/deployment_guide/webUI_and_grafana_dashboards/webUI_and_grafana_dashboards.md
deleted file mode 100644
index 1bd9ec0f3e2a7dfa2430eef79bb65495c164cb3f..0000000000000000000000000000000000000000
--- a/doc/deployment_guide/webUI_and_grafana_dashboards/webUI_and_grafana_dashboards.md
+++ /dev/null
@@ -1,14 +0,0 @@
-This section describes how to get access to the TeraFlowSDN controller WebUI and the monitoring Grafana dashboards.
-
-## Access the TeraFlowSDN WebUI
-If you followed the installation steps based on MicroK8s, you got an ingress controller installed that exposes on TCP port 80.
-
-Besides, the ingress controller defines the following reverse proxy paths (on your local machine):
-- `http://127.0.0.1/webui`: points to the WebUI of TeraFlowSDN.
-- `http://127.0.0.1/grafana`: points to the Grafana dashboards.
- This endpoint brings access to the monitoring dashboards of TeraFlowSDN.
- The credentials for the `admin`user are those defined in the `my_deploy.sh` script, in the `TFS_GRAFANA_PASSWORD` variable.
-- `http://127.0.0.1/restconf`: points to the Compute component NBI based on RestCONF.
- This endpoint enables connecting external software, such as ETSI OpenSourceMANO NFV Orchestrator, to TeraFlowSDN.
-
-**Note**: In the creation of the VM, a forward from host TCP port 8080 to VM's TCP port 80 is configured, so the WebUIs and REST APIs of TeraFlowSDN should be exposed on the endpoint `127.0.0.1:8080` of your local machine instead of `127.0.0.1:80`.
\ No newline at end of file
diff --git a/doc/development_guide/configure_environment/configure_environment.md b/doc/development_guide/configure_environment/configure_environment.md
deleted file mode 100644
index 3610c9e590fde6a01d6ac39578891bf01259c7ec..0000000000000000000000000000000000000000
--- a/doc/development_guide/configure_environment/configure_environment.md
+++ /dev/null
@@ -1,6 +0,0 @@
-- [2.1.1. Python](./2.1.-Configure-Environment/2.1.1.-Python)
-- [2.1.2. Java (Quarkus)](./2.1.-Configure-Environment/2.1.2.-Java-(Quarkus))
-- [2.1.3. Java (Maven)](./2.1.-Configure-Environment/2.1.3.-Java-(Maven))
-- [2.1.4. Rust](./2.1.-Configure-Environment/2.1.4.-Rust)
-- [2.1.5. Erlang](./2.1.-Configure-Environment/2.1.5.-Erlang)
-- [2.1.6. Kotlin](./2.1.-Configure-Environment/2.1.6.-Kotlin)
diff --git a/doc/development_guide/configure_environment/java_quarkus.md b/doc/development_guide/configure_environment/java_quarkus.md
deleted file mode 100644
index 36bfad1fb4eb7812a38841662966f8d6875b301a..0000000000000000000000000000000000000000
--- a/doc/development_guide/configure_environment/java_quarkus.md
+++ /dev/null
@@ -1,64 +0,0 @@
-This section describe the steps needed to create a development environment for TFS components implemented in Java. Currently, ZTP and Policy components have been developed in Java (version 11) and use the [Quarkus](https://quarkus.io/) framework, which enables kubernetes-native development.
-
-## Install JDK
-To begin, make sure that you have java installed and in the correct version
-```
-java --version
-```
-
-If you don't have java installed you will get an error like the following:
-```
-Command 'java' not found, but can be installed with:
-
-sudo apt install default-jre # version 2:1.11-72build1, or
-sudo apt install openjdk-11-jre-headless # version 11.0.14+9-0ubuntu2
-sudo apt install openjdk-17-jre-headless # version 17.0.2+8-1
-sudo apt install openjdk-18-jre-headless # version 18~36ea-1
-sudo apt install openjdk-8-jre-headless # version 8u312-b07-0ubuntu1
-```
-
-In which case you should use the following command to install the correct version:
-```
-sudo apt install openjdk-11-jre-headless
-```
-
-Else you should get something like the following:
-```
-openjdk 11.0.18 2023-01-17
-OpenJDK Runtime Environment (build 11.0.18+10-post-Ubuntu-0ubuntu120.04.1)
-OpenJDK 64-Bit Server VM (build 11.0.18+10-post-Ubuntu-0ubuntu120.04.1, mixed mode, sharing)
-```
-
-## Compiling and testing existing components
-In the root directory of the existing Java components you will find an executable maven wrapper named `mvnw`. You could use this executable, which is already configured in pair with the components, instead of your local maven installation. So for example if you want to compile the project you would run the following:
-```
-./mvnw compile
-```
-
-## VS Code Quarkus plugin
-In case you are using [VS Code](https://code.visualstudio.com/) for development, we suggest to install the [official Quarkus extension](https://marketplace.visualstudio.com/items?itemName=redhat.vscode-quarkus).
-The extension should be able to automatically find the current open project and integrate with the above `mvnw` maven wrapper, making it easier to control the [maven lifecycle](https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html).
-Make sure that you open the specific component directory (i.e., `src/ztp` or `src/policy`) and not the general controller one (i.e., `src`.
-
-## New Java TFS component
-
-### Sample Project
-
-If you want to create a new TFS component written in Java you could generate a new Quarkus project based on the following project:
-
-[TFS Sample Quarkus Project](https://code.quarkus.io/?e=grpc&e=kubernetes&e=container-image-jib&e=kubernetes-service-binding&e=smallrye-health&e=resteasy-reactive)
-
-In that way, you should have most of the libraries you would need to integrate with the rest of the TFS Components. Feel free however to add or remove libraries depending on your needs.
-
-### Initial setup
-
-If you used the sample project above, you should have a project with a basic structure. However there are some steps that you should take before starting development.
-
-First make sure that you copy the protobuff files, that are found in the root directory of the TFS SDN controller, to the `new-component/src/main/proto` directory.
-
-Next you should create the following files:
-* `new-component/.gitlab-ci.yml`
-* `new-component/Dockerfile`
-* `new-component/src/resources/application.yaml`
-
-We suggest to copy the respective files from existing components (Automation and Policy) and change them according to your needs.
\ No newline at end of file
diff --git a/doc/development_guide/configure_environment/python.md b/doc/development_guide/configure_environment/python.md
deleted file mode 100644
index 80d6874423672354cb3a9aeb669f6cd684a53169..0000000000000000000000000000000000000000
--- a/doc/development_guide/configure_environment/python.md
+++ /dev/null
@@ -1,149 +0,0 @@
-This section describes how to configure the Python environment to run experiments and
-develop code for the ETSI TeraFlowSDN controller.
-In particular, we use [PyEnv](https://github.com/pyenv/pyenv) to install the appropriate
-version of Python and manage the virtual environments.
-
-
-## Upgrade the Ubuntu distribution
-Skip this step if you already did it during the installation of your machine.
-```bash
-sudo apt-get update -y
-sudo apt-get dist-upgrade -y
-```
-
-
-## Install PyEnv dependencies
-```bash
-sudo apt-get install -y make build-essential libssl-dev zlib1g-dev libbz2-dev libreadline-dev libsqlite3-dev wget \
- curl llvm git libncursesw5-dev xz-utils tk-dev libxml2-dev libxmlsec1-dev libffi-dev liblzma-dev
-```
-
-
-## Install PyEnv
-
-We recommend installing PyEnv through
-[PyEnv Installer](https://github.com/pyenv/pyenv-installer).
-Below you can find the instructions, but we refer you to the link for updated
-instructions.
-
-```bash
-curl https://pyenv.run | bash
-# When finished, edit ~/.bash_profile // ~/.profile // ~/.bashrc as the installer proposes.
-# In general, it means to append the following lines to ~/.bashrc:
-export PYENV_ROOT="$HOME/.pyenv"
-command -v pyenv >/dev/null || export PATH="$PYENV_ROOT/bin:$PATH"
-eval "$(pyenv init -)"
-eval "$(pyenv virtualenv-init -)"
-```
-
-In case .bashrc is not linked properly to your profile, you may need to append the
-following line into your local .profile file:
-
-```bash
-# Open ~/.profile and append this line:
-+source "$HOME"/.bashrc
-```
-
-
-## Restart the machine
-Restart the machine for all the changes to take effect.
-```bash
-sudo reboot
-```
-
-
-## Install Python 3.9 over PyEnv
-
-ETSI TeraFlowSDN uses Python 3.9 by default.
-You should install the latest stable update of Python 3.9, i.e., avoid "-dev" versions.
-To find the latest version available in PyEnv, you can run the following command:
-
-```bash
-pyenv install --list | grep " 3.9"
-```
-
-At the time of writing, this command will output the following list:
-
-```
- 3.9.0
- 3.9-dev
- 3.9.1
- 3.9.2
- 3.9.4
- 3.9.5
- 3.9.6
- 3.9.7
- 3.9.8
- 3.9.9
- 3.9.10
- 3.9.11
- 3.9.12
- 3.9.13
- 3.9.14
- 3.9.15
- 3.9.16 ** always select the latest version **
-```
-
-Therefore, the latest stable version is Python 3.9.16.
-To install this version, you should run:
-
-```bash
-pyenv install 3.9.16
- # This command might take some minutes depending on your Internet connection speed
- # and the performance of your machine.
-```
-
-
-## Create the Virtual Environment for TeraFlowSDN
-The following commands create a virtual environment named as `tfs` using Python 3.9 and
-associate that environment with the current folder, i.e., `~/tfs-ctrl`.
-That way, when you are in that folder, the associated virtual environment will be used,
-thus inheriting the Python interpreter, i.e., Python 3.9, and the Python packages
-installed on it.
-
-```bash
-cd ~/tfs-ctrl
-pyenv virtualenv 3.9.16 tfs
-pyenv local 3.9.16/envs/tfs
-```
-
-After completing these commands, you should see in your prompt that now you're within
-the virtual environment `3.9.16/envs/tfs` on folder `~/tfs-ctrl`:
-
-```
-(3.9.16/envs/tfs) tfs@tfs-vm:~/tfs-ctrl$
-```
-
-In case that the correct pyenv does not get automatically activated when you change to
-the tfs-ctrl/ folder, then execute the following command:
-
-```bash
-cd ~/tfs-ctrl
-pyenv activate 3.9.16/envs/tfs
-```
-
-
-
-## Install the basic Python packages within the virtual environment
-From within the `3.9.16/envs/tfs` environment on folder `~/tfs-ctrl`, run the following
-commands to install the basic Python packages required to work with TeraFlowSDN.
-```bash
-cd ~/tfs-ctrl
-./install_requirements.sh
-```
-
-Some dependencies require to re-load the session, so log-out and log-in again.
-
-
-## Generate the Python code from the gRPC Proto messages and services
-
-The components, e.g., microservices, of the TeraFlowSDN controller, in general, use a gRPC-based open API to interoperate.
-All the protocol definitions can be found in sub-folder `proto` within the root project folder.
-For additional details on gRPC, visit the official web-page [gRPC](https://grpc.io/).
-
-In order to interact with the components, (re-)generate the Python code from gRPC definitions running the following command:
-
-```bash
-cd ~/tfs-ctrl
-proto/generate_code_python.sh
-```
diff --git a/doc/images/architecture/CAPIF Core Function.png b/doc/images/architecture/CAPIF Core Function.png
deleted file mode 100644
index cc790ca60cb40a631a0fcc83d3530f62e51b28e3..0000000000000000000000000000000000000000
Binary files a/doc/images/architecture/CAPIF Core Function.png and /dev/null differ
diff --git a/doc/images/architecture/CAPIF_Core_Function.png b/doc/images/architecture/CAPIF_Core_Function.png
deleted file mode 100644
index cc790ca60cb40a631a0fcc83d3530f62e51b28e3..0000000000000000000000000000000000000000
Binary files a/doc/images/architecture/CAPIF_Core_Function.png and /dev/null differ
diff --git a/doc/images/architecture/New_Architecture.png b/doc/images/architecture/New_Architecture.png
deleted file mode 100644
index 6ef7755c59136332a25d9c4ac735fa0784d24442..0000000000000000000000000000000000000000
Binary files a/doc/images/architecture/New_Architecture.png and /dev/null differ
diff --git a/doc/images/architecture/msg_flow.png b/doc/images/architecture/msg_flow.png
deleted file mode 100644
index 7163f87ea381ab5e63169d8722fea4c259c10a42..0000000000000000000000000000000000000000
Binary files a/doc/images/architecture/msg_flow.png and /dev/null differ
diff --git a/doc/images/flows/01_Login_Admin.png b/doc/images/flows/01_Login_Admin.png
deleted file mode 100644
index 5913c96c3bcb4a1c18b22ff13547604a1c8e9df9..0000000000000000000000000000000000000000
Binary files a/doc/images/flows/01_Login_Admin.png and /dev/null differ
diff --git a/doc/images/flows/02_Creation_of_user.png b/doc/images/flows/02_Creation_of_user.png
deleted file mode 100644
index 2024dfff4eca11ecdf5930060ec635d6d06482c6..0000000000000000000000000000000000000000
Binary files a/doc/images/flows/02_Creation_of_user.png and /dev/null differ
diff --git a/doc/images/flows/03_Register_of_AEF_GetAuth.png b/doc/images/flows/03_Register_of_AEF_GetAuth.png
deleted file mode 100644
index f200f9fe444a9a06c8a6e59b31d241d1ea3fdb35..0000000000000000000000000000000000000000
Binary files a/doc/images/flows/03_Register_of_AEF_GetAuth.png and /dev/null differ
diff --git a/doc/images/flows/04_AEF_API_Provider_registration.png b/doc/images/flows/04_AEF_API_Provider_registration.png
deleted file mode 100644
index 091f4901bb64c6755747758d6add38e5d4773561..0000000000000000000000000000000000000000
Binary files a/doc/images/flows/04_AEF_API_Provider_registration.png and /dev/null differ
diff --git a/doc/images/flows/05_AEF_Publish.png b/doc/images/flows/05_AEF_Publish.png
deleted file mode 100644
index 1bfb90e51198c72f338fcb65986d546d9e96ba03..0000000000000000000000000000000000000000
Binary files a/doc/images/flows/05_AEF_Publish.png and /dev/null differ
diff --git a/doc/images/flows/06_Invoker_Register_GetAuth.png b/doc/images/flows/06_Invoker_Register_GetAuth.png
deleted file mode 100644
index f200f9fe444a9a06c8a6e59b31d241d1ea3fdb35..0000000000000000000000000000000000000000
Binary files a/doc/images/flows/06_Invoker_Register_GetAuth.png and /dev/null differ
diff --git a/doc/images/flows/07_Invoker_Onboarding.png b/doc/images/flows/07_Invoker_Onboarding.png
deleted file mode 100644
index 9cd4b2d9fc99daa0f285a0f9e5cf77d9c51ea17c..0000000000000000000000000000000000000000
Binary files a/doc/images/flows/07_Invoker_Onboarding.png and /dev/null differ
diff --git a/doc/images/flows/08_Invoker_Discover_AEF.png b/doc/images/flows/08_Invoker_Discover_AEF.png
deleted file mode 100644
index 20b2f04f94444833bbea04832620434593f89bc0..0000000000000000000000000000000000000000
Binary files a/doc/images/flows/08_Invoker_Discover_AEF.png and /dev/null differ
diff --git a/doc/images/flows/09_Invoker_Create_Security_Context.png b/doc/images/flows/09_Invoker_Create_Security_Context.png
deleted file mode 100644
index bb655e0e38e8394b3aaa024ada0f13c2f21c2b4c..0000000000000000000000000000000000000000
Binary files a/doc/images/flows/09_Invoker_Create_Security_Context.png and /dev/null differ
diff --git a/doc/images/flows/10_Invoker_Get_Token.png b/doc/images/flows/10_Invoker_Get_Token.png
deleted file mode 100644
index 2e39f52a3d12efa8c19ea3032957e9f48d890d0e..0000000000000000000000000000000000000000
Binary files a/doc/images/flows/10_Invoker_Get_Token.png and /dev/null differ
diff --git a/doc/images/flows/11_Invoker_Send_Request_to_AEF_Service_API.png b/doc/images/flows/11_Invoker_Send_Request_to_AEF_Service_API.png
deleted file mode 100644
index 1e4a87c54b04d2d6524da2617fa615dab7318dc7..0000000000000000000000000000000000000000
Binary files a/doc/images/flows/11_Invoker_Send_Request_to_AEF_Service_API.png and /dev/null differ
diff --git a/doc/images/logos/Open CAPIF Logo Screen_B_W Slogan NEG.png b/doc/images/logos/Open CAPIF Logo Screen_B_W Slogan NEG.png
deleted file mode 100644
index d0061b6f859094be2b4c4d9e73047ebbe2524e98..0000000000000000000000000000000000000000
Binary files a/doc/images/logos/Open CAPIF Logo Screen_B_W Slogan NEG.png and /dev/null differ
diff --git a/doc/images/logos/Open CAPIF Logo Screen_Colour Slogan NEG@3x.png b/doc/images/logos/Open CAPIF Logo Screen_Colour Slogan NEG@3x.png
deleted file mode 100644
index 06f34e564036a3bff31f3e85311ca144d2346d2b..0000000000000000000000000000000000000000
Binary files a/doc/images/logos/Open CAPIF Logo Screen_Colour Slogan NEG@3x.png and /dev/null differ
diff --git a/doc/images/logos/OpenCAPIF.png b/doc/images/logos/OpenCAPIF.png
deleted file mode 100644
index 57562abe95af2699d7dbb34fe43ecc686d3c910e..0000000000000000000000000000000000000000
Binary files a/doc/images/logos/OpenCAPIF.png and /dev/null differ
diff --git a/doc/images/logos/OpenCAPIF.webp b/doc/images/logos/OpenCAPIF.webp
deleted file mode 100644
index 8ae5c10e186e12481f1e65f36b69ac722f057775..0000000000000000000000000000000000000000
Binary files a/doc/images/logos/OpenCAPIF.webp and /dev/null differ
diff --git a/doc/images/logos/OpenCAPIF_Small.png b/doc/images/logos/OpenCAPIF_Small.png
deleted file mode 100644
index 8e904bbabca310de26524d8159f80f874e84ce09..0000000000000000000000000000000000000000
Binary files a/doc/images/logos/OpenCAPIF_Small.png and /dev/null differ
diff --git a/doc/images/logos/OpenCAPIF_Square.png b/doc/images/logos/OpenCAPIF_Square.png
deleted file mode 100644
index 7b558faff76fcbcd6887cd39d867b75805a522d0..0000000000000000000000000000000000000000
Binary files a/doc/images/logos/OpenCAPIF_Square.png and /dev/null differ
diff --git a/doc/images/logos/OpenCAPIF_Square.webp b/doc/images/logos/OpenCAPIF_Square.webp
deleted file mode 100644
index f3535f6dadd6d625469c06b256d2aa7405b719d2..0000000000000000000000000000000000000000
Binary files a/doc/images/logos/OpenCAPIF_Square.webp and /dev/null differ
diff --git a/mkdocs.yml b/mkdocs.yml
index a90b07a81f0ea6adf37cb7a36f52a7da8a6ef534..d015c5d26ceb87b2ed1d7ea1f246b8f4498893b0 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -78,9 +78,3 @@ extra:
nav:
- 1. Deployment Guide: ./deployment_guide/deployment_guide.md
- 2. Development Guide: ./development_guide/development_guide.md
-
-# - Testing:
-# - Test Plan: ./testing/testplan/README.md
-# - Robot Framework: ./testing/robotframework/README.md
-# - Postman: ./testing/postman/README.md
-# - FAQ: ./FAQ.md