Skip to content
Álvaro Curto Merino edited this page Jul 15, 2024 · 7 revisions

The 6G-Library repository the includes all the necessary code and data to deploy and configure each component of a Trial Network. Each component's metadata and code are used by both the TNLCM and the Jenkins of a Site.

Every directory represents an available component in the 6G Sandbox project, except the .global/, which includes general information to all components such as:

  • cac/: Ansible task files importable from any component
  • iac/: Terraform provider and backend files.
  • json_templates/: JSON templates to perform a callback to the TNLCM after each deployment
  • pac/: The Jenkinsfiles defining the pipelines available from the Jenkins

How a component is deployed

Prior to the development of a component, is crucial to understand how the basic workflow of a Trial Network deployment works:

image

1. TNCLM sends request to Jenkins

When a TN descriptor is registered in the TNLCM, it begins making a succession of requests to the Jenkins, to start the deployment of each component one at a time. Each request contains the parameters required by the TN_DEPLOY pipeline, including the corresponding input file. This file includes the input variables listed in the TNLCM's TN descriptor. You can find an example of a usable input file for each component in this repo as {component_type}/sample_input_file.yaml.

Most inputs just serve to overwrite a private value, but others (mainly mandatory ones) serve to define dependencies between componentes. The available inputs for each component are described at {component_type}/.tnlcm/public.yaml

2. Jenkins starts the corresponding Ansible playbook

The TN_DEPLOY pipeline first writes its parameters and the component's inputs as variable files loadable by Ansible, then clones the 6G-Sandbox-Sites repository and finally launches the playbook {COMPONENT_TYPE}/code/component_playbook.yaml.

3. Ansible playbook

Ansible executes the playbook {component_type}/code/component_playbook.yaml which will load the necessary inputs, deploy the component (using terraform or Helm Charts), and generate a list of outputs. A Trial Network uses terraform as a way to achieve Infrastructure as Code (IaC), and as such, component's manifests along with the .tfstate file are uploaded to the chosen S3 storage backend (currently only MinIO). The steps on how to structure a component_playbook.yaml are described in the Playbook Development Guide

4. TNLCM Callback

As the last step of the Ansible playbook, a final callback to the TNLCM is sent using the format of the files in .global/json_templates/ with the execution result and the generated outputs. The outputs expected by the TNLCM are described at {component_type}/.tnlcm/public.yaml

EXTRA

Expanding step 3 and prior to the Playbook Development Guide, it must be noted that there are multiple sources of variables available for a playbook.

The first and most important one is the .global/cac/load_variables.yaml task file, which loads the following variable files in order, overwriting the previous ones:

  • 6G-Sandbox-Sites/{{ deployment_site }}/core.yaml": Variables unique to each site loaded from repository 6G-Sandbox-Sites
  • {{ component_type }}/variables/{{ site_hypervisor }}/private.yaml: Default variables unique to each component.
  • {{ component_type }}/variables/input_file.yaml: Component inputs. File created during the Jenkins pipeline. Most of them simply overwrite some of the private variables.
  • {{ component_type }}/variables/pipeline_parameters.yaml: Jenkins parameters. File created during the Jenkins pipeline.

Environment variables aren't a reliable source of information, but some of them can also be used inside pipelines. Useful environment variables include the instanced Jenkins credentials (as seen in the environment field in TN_DEPLOY. The WORKSPACE does not need to be referenced as an environmental variable, as is passed as an argument when the playbook is launched.

However, to address the problem of variable dependencies between components, we can use another source of variables: terraform outputs. In the same way we generate a list of outputs for the TNLCM callback, we can also write them as as terraform outputs and apply them to be available from any deployment.