Automated Reservation Management User Guide

Once you have setup and configured all components you are ready to start using the automated reservation management orchestration solution.

How to use

The general user guide is quite simple:

Resources that can be reserved

1. Any changes to devices in NetBox will be automatically picked up by Camunda and then reflected in Libre Booking, Uptime Kuma (if enabled) and Oxidized (if enabled).

Note

If you are using nmaas please note that any change that need to be reflected in Oxidized will be made via the Git repo. All changes to the Git repo trigger a restart of the Oxidized instance, and it might take a little bit of time for it to be reloaded properly. Be patient if the Oxidized URL report a "503 Service Temporarily Unavailable" error.

The information related to devices stored in NetBox and relevant for the implementation of this orchestration scenario is presented in the figure below.

Any manual changes of NetBox devices in LibreBooking will be overriden and reverted back to reflect NetBox after the daily sync.

To ensure correct synchronisation the custom resource attribute netbox id is automatically defined in Libre Booking.

In addition, there is another custom resource attribute "type" that is used to provide the capability of making reservations for several types of resources using Libre Booking. The default type is "GP4L device".

Making reservations

1. To use the self-reservation capabilities a user first needs to register in Libre Booking
   • go to the main Libre Booking URL
   • choose First Time User? Register
   • in the form fill out the required data
     • username, email, password, confirm password, first and last name, organisation and position
     • in the bastion info field provide the ssh key that will be used to get access to the devices via the Bastion
   • once you successfully activate the account you are ready to make reservations
2. To make a new reservation a user needs to login to Libre Booking and choose to reserve a resource from the dashboard
   • define the start and end time of the reservation
   • choose multiple resources if needed (only available resources in the chosen time period are eligible)
   • provide title and description of the reservation
   • provide information if multiple people are going to use the reservation
   • create the reservation
3. The Libre Booking admin gets an email notification about the newly made reservation and needs to decide if it is going to be approved or no
4. If the reservation is approved then the user can use the resources in the specified time period
5. If a user makes a change to an already approved reservation, the reservation changes need to be approved by the admin
6. If a reserved resource becomes unavailable the users that have reservations that include the resource will be notified via email. They can choose to modify the reservation or leave it as it is (with the resource in question being unavailable).

Authorising the use of the reserved resources

1. When the reservation time starts, the user should
   • check-in in Libre Booking
   • connect to Bastion via ssh and then connect to the reserved resources
2. At the end of the experiment (or end of reservation time), the user should
   • check-out in Libre Booking
   • the ssh key will be removed from the Bastion and the ssh access will be terminated

Important Information:

• For a resource to be added and synced with Libre Booking the defined reservation tag must be added to the device in NetBox
  • devices without this tag will not be considered as eligible for reservation
  • the default tag that is used in nmaas for these purposes is "rarereservation"
• Do not delete or change the custom attributes and user groups added automatically in Libre Booking. These include
  • user group with auto membership
    • by default "GP4L users"
  • custom resource attributes
    • netbox id
    • resource type
  • custom user attribute
    • bastion info
• If you are using Oxidized, you must add the tags for model and group when creating a device
  • if a device does not have a model and group then Oxidized will not be informed about any device related events
• For a resource to be added (and a monitoring probe created and a configuration backup defined) a device must
  • be in the state active
  • have at least one interface
  • have at least one primary IP address
  • if any of these are not met, the device is considered non-active

Note

In Uptime Kuma the monitoring probe is named as device_name[netbox_id]. Additional IPv6 string is added to the name if the primary IP address is of that type.

Note

In Oxidized there always will be a DUMMY entry in the list as the software does not support the case when there are no active devices at a certain moment.

Video demonstration

The following video describes the use of the automated reservation management scenario