Skip to content

Automating reservation and access to network resources

Goal

The idea behind the automated reservation lab is founded in enabling the R&E community efficient access to the GP4L experimental testbed. Namely, to be able to access GP4L devices in order to conduct an experiment, a researcher needs to describe the experiment, get approval for use of a subset of devices in an agreed upon time period and then obtain ssh access to the devices via a bastion machine.

This scenario can be easily generalised to cover many similar cases when an individual or a group require to reserve the use of a group of resource for a certain period of time.

The approach to the implementation of the use case follows the generalised view of the problem embodying the defined principles of the GP4L development that enable reuse of the solution in different similar scenarios. The requirements for this implementation have been defined as follows:

  • users should self-register to a self-service portal
  • the self-service portal will provide up-to-date information on available resources at all times
  • the self-service portal will be used to create a reservation request
  • each reservation request is reviewed and approved/disapproved by an admin
  • once a reservation is approved, the ssh keys necessary for access are automatically handled
  • the solution should be seen as an extension of the automated resource management implementation

Components

For the implementation of the automated reservation management the following components have been used:

  • Resources Source of Truth = NetBox
  • Reservation System = Booked (Libre Booking)
  • Bastion host = Bastion
  • Resources Orchestration = Camunda
  • Access Orchestration = AirFlow

Processes

As NetBox is the source of truth that holds the correct information about the resources, the resources available for reservation in Booked should be managed based on NetBox.

Camunda orchestration

The synchronisation of the resource information from NetBox to Libre Booking equals to integrating one more component into the initial automated resource management lab. Thus, to implement this capability, the original Camunda processes have been extended to handle one more component: Libre Booking.

The following images depict the complete implementation of the Camunda processes that handle all three resource management components: Uptime Kuma for monitoring, Oxidized for configuration backup and Libre Booking for reservation management.

  • Process to handle add/change of active device events in NetBox

add/change device

  • Process to handle deactivate/remove device events in NetBox

remove device

In addition to these processes, Camunda also implements one more simple process that is set to run daily in the early morning. This process ensures that the information between NetBox and LibreBooking is fully synchronised, with NetBox used as the source of truth. This means that any manual changes in NetBox related resources in Libre Booking will be removed and the resource information will be reverted back to the correct values as provided by NetBox.

AirFlow orchestration

For the purposes of managing the ssh keys needed to access the resources during the active time of an approved reservation, the GP4L team has decided to use the Apache AirFlow orchestrator. Thus, this lab has also served as an experimentation playground where two different orchestrators are used in one automation scenario.

The use of AirFlow is configured in such a way that the workflow definitions are read from a Git repository, thus enabling easy dynamic change of the configuration and definition of each workflow.

The workflow implementation for the reservation use case is presented below.

airflow workflow

This process listens to a webhook defined in Libre Booking that activates the process every time a reservation has been approved by the admin. The webhook schedules the workflow to be executed at the start of the reservation time when it contacts Libre Booking to get the ssh key of the user that created the reservation and then installs the key in the Bastion providing the end time of the reservation so that the key is automatically removed after the reservation time has expired.

The implementation is done in such a way to accommodate for situations where a user might make a change to a reservation or to the ssh key after after the reservation has been approved.

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 several different configurations:

  • Reservation only (NetBox, Libre Booking, and Camunda)
  • Reservation and authorisation (NetBox, Libre Booking, Camunda, Bastion and AirFlow)
  • Reservation + Monitoring (NetBox, Uptime Kuma, Libre Booking, and Camunda)
  • Reservation and authorisation + Monitoring (NetBox, Uptime Kuma, Libre Booking, Camunda, Bastion and AirFlow)
  • Reservation + Monitoring + Configuration Backup (NetBox, Uptime Kuma, Oxidized, Libre Booking, and Camunda)
  • Reservation and authorisation + Monitoring + Configuration Backup (NetBox, Uptime Kuma, Oxidized, Libre Booking, Camunda, Bastion and AirFlow)

How to test and/or use?

If you want to run a test or maybe 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