Skip to content

Automating the day-to-day activities related to resource management

Goal

The main goal of this use-cases stems in the idea to automate the manual activities necessary for the maintenance and synchronisation of the components used to document and manage the resources of the GP4L experimental testbed.

To reduce the manual work needed to setup monitoring and regular configuration backup of GP4L devices, the resource management automation implementation aims to automatically react to any change made in the resource source of truth by making the corresponding changes in the monitoring and configuration management components.

In the implementation the following requirements are taken into consideration:

  • device history is kept whenever possible
  • support for both IPv4 and IPv6
  • information is never permanently deleted

Components

To implement the defined use-case the following components were chosen:

  • Resources Source of Truth = NetBox
  • Monitoring = Uptime Kuma + REST API developed for Uptime Kuma
  • Configuration Management = Oxidized + Git (to store historical changes and dynamically manipulate the resources list)
  • Orchestrator = Camunda

Processes

The defined processes in Camunda reflect the following behaviour:

  • add a new device in the source of truth = add a new monitor + start making regular configuration backups
  • change device properties in the source of truth = change monitor + change backup settings
  • device taken offline (or deleted) = monitor paused + stop gathering backup

The device properties of interest for the use-case are as follows:

  • device name
  • device state = active / any other type is considered non-active
  • management IP = at least one defined (can have both IPv4 and IPv6)
  • device tags = should have at least two for configuration backup definition
    • model type in the format oxidized:model:name (oxidized:model:rare for GP4L testbed)
    • device group in the format oxidized:group:name (oxidized:group:wedge-bf100-32x, oxidized:group:nmaas-oob, oxidized:group:inband-bf2556x1t for GP4L testbed)

Two processes are implemented in Camunda so that the monitoring and configuration management component are updated according to any change of relevant parameters in the source of truth.

  1. Activate/Change device
  2. Remove/deactivate device

Both processes are activated via a webhook event defined in NetBox that is related to the device information change. It checks if the changed information is relevant and if it decides that it is then it contacts the rest of the components to create new entry or update an existing entry.

Modularity

The process implementation is done in such a way that the tasks related to specific component are implemented only if that component is configured to be actively used during the setup of the orchestrator. In other words, the use-case can be used in two different configurations:

  • Monitoring only (NetBox and Uptime Kuma)
  • Monitoring and Configuration Backup (NetBox, Uptime Kuma, and Oxidized)

How to test and/or use?

If you want to try out or use the implementation for your own environment then follow the indicated steps:

  • Step 1: Setup

    • Choose one of the available options:
      • run components instances in nmaas
      • use available containers to run the components locally

  • Step 2: Configure

    • follow the configuration guide to initialise the components

  • Step 3: Use

    • follow the user guide and enjoy the fruits of automation and orchestration