Skip to content

Automated Reservation Management: How to reuse

As with all GP4L developments, the automated reservation management solution has been made with reuse in mind.

In addition to the flexibility of using a subset of components, using nmaas or local containers to run it, and the fully parametrised configurable environment you can also try to reuse the code and adapt it to your own needs.

Note

NetBox, Uptime Kuma (and API), Oxidized, AirFlow and Bastion are used as they are without any special changes in their source code or native container images. All of the customisation necessary to implement the orchestration is done by configurations of the components and the development of the orchestration processes in Camunda and AirFlow.

Warning

The GP4L team has identified a bug in Libre Booking that had to be fixed in order to obtain the necessary functionality for the implementation of the reservation use-case. The release of Libre Booking with the implemented fix is currently pending. If you want to reuse Libre Booking please use the container provided in the installation guide.

How to reuse

Access the source code repository

The Camunda source code is located at ADD LINK TO REPO HERE.

The AirFlow source code is available https://github.com/sonjafiliposka/test-AF (this is the Git repository that you need to use during the configuration phase).

The provided code for the implemented processes can serve as a starting point for your own custom development.

As mentioned above, these are the only source codes and specific implementations done. The rest of the components are used as they are provided by the respective open source communities.

Use a different component

If you want to replace a specific component with a different implementation then you must edit the Camunda processes and change the places where the component APIs are invoked and their response is processed. The same applies in case you want to change Libre Booking and/or Bastion with some other implementation. In this case you will also need to make changes to the AirFlow workflow.

Each component has its own specific API, so the change to another component means switching to a completely different API with a completely different data model. Depending on the difference in the API, this change might require significant adjustments in the code.

Make changes to the processes

To make changes to the Camunda processes one must understand the workings of Camunda and the process development using Spring Boot. Using the provided source code repository you can download the process definitions and implementation and then edit them and make anu changes you want.

To make change to the ssh keys authorisation process implemented in AirFlow you need to understand the nature of the AirFlow scheduler and the definition of workflows and tasks. The process can then be adapted by making changes in the provided Python code.

How to maintain

The current version of the implementation (as of May 2024) uses the following versions of the components:

  • NetBox v3.7.2
  • Uptime Kuma v1.22.0
  • Uptime Kuma API v1.2.1
  • Oxidized v0.29.1
  • Camunda v7.20 with Spring-Boot v3.2.5 and Java 17
  • Libre Booking v2.8.6 + custom fix
  • AirFlow v2.7.1
  • Bastion v20.04-v2

Note

Please note that using an Uptime Kuma version above the specified is not possible as the Uptime Kuma API does not support it and therefore does not work correctly with it.

As long as the GP4L team is actively working it will continue to monitor the new releases of each component and update the implementation so that it is based on the latest versions as much as possible.

If you are looking to implement your own maintenance please consider the following problems that have been encountered in previous solution upgrades:

  • changes to component APIs with new update releases
    • if the component has an API change as part of its release then careful testing must be made to check if these changes require changes in the Camunda processes implementation
  • changes to event notification
    • in the most recent version NetBox has changed the way webhooks are defined, if this happens again then the webhook configuration should be suitably adapted to the new changes
  • changes in implementation
    • in the newest version Oxidized no longer supports an empty list of devices which has been handled with the addition of the dummy entry during initialisation

Tips & Tricks

As NetBox is the source of truth of all device information, the data stored in Uptime Kuma and Oxidized needs to be checked and synchronised with the data in NetBox. For these purposes it is essential that one can recognise which entry in the other component corresponds to which entry in NetBox (especially in events of device updates such as renaming or IP address change).

For these purposes where possible the NetBox unique id is stored in the other components.

  • this is the case with
    • Uptime Kuma where part of the probe name is the netbox id
    • Libre Booking where a custom resource attribute holds the netbox id
  • as this implementation is not possible for Oxidized, in this case existing entry is identified by cross comparing the new and old information from NetBox

While working on the implementation, the GP4L team has found bugs in the implementation of the NetBox API (that have been fixed in the subsequent release of a new version) as well as in the implementation of Libre Booking. The new release of Libre Booking with the fix provided by the GP4L team is still pending.