Skip to content

Automated Resource Management: How to reuse

As with all GP4L developments, the automated resource 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) and Oxidized 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.

How to reuse

Access the source code repository

The Camunda source code is located in a BitBucket repo GP4L-ProcMngmt.

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

As mentioned above, this is the only source code and specific implementation done. The rest of the components are used as they are provided by the respective open source communities.

Warning

This implementation is the initial use-case that has been afterwards extended to also support resource reservation. Therefore the implementation of the processes includes additional steps which are skipped as the related components are disabled for the purposes of this solution.

Use a different monitoring/configuration backup component

If you want to replace NetBox and/or Uptime Kuma and/or Oxidized with a different component then you must edit the Camunda processes and change the places where the component APIs are invoked and their response is processed.

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.

How to maintain

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

  • NetBox v.3.7.2
  • Uptime Kuma v.1.22.0
  • Uptime Kuma API v.1.2.1
  • Oxidized v.0.29.1
  • Camunda v7.20 with Spring-Boot v.3.2.5 and Java 17

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
  • 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