OpenNMS On the Horizon – Docs, CI, Health Check, Twin API, LLDP, Config API, TLSv1.3, SNMP, Karaf, Time-Series, GeoIP, Flows, Web UI, Geomaps, ReST
Since last time, we worked on docs, CI automation, health check, the Twin API, LLDP in Enlinkd, the new config api, TLSv1.3 support, SNMP metadata handling, SNMPv3 user settings, Karaf 4.3, time-series processing, user code performance, trapoid handling, GeoIP provisioning, flow templates, web redirects, the new feather UI, geomaps, and ReST.
Github Project Updates
Internals, APIs, and Documentation
Mark continued to work on refactoring provisioning documentation.
I did a bunch of work cleaning up CircleCI stuff to use newer/recommended ubuntu images for tests.
Stefan did more work on improvements to the health-check core.
Stefan continued working on changes to optimize flow documents.
Chandra worked on optimizations in the Twin API.
Jesse worked on updating Enlinkd/topology documentation.
Antonio worked on some updates to Enlinkd LLDP handling.
Freddy continued his work on the config management backend.
Dustin updated some backend API code to use TLSv1.3.
Patrick did more work on loading existing configs into the database.
Christian did more work on refactoring and improving hardware metadata handling for SNMP.
Chandra worked on adding JMS support to the Twin API.
Dustin added a Kafka implementation for Twin IPC.
Jesse worked on supporting multiple SNMPv3 settings per user.
Yang Li wrapped up his work updating the embedded Karaf to 4.3.
Alejandro worked on some fixes to time-series processing.
Jesse fixed a locking performance issue accessing user info.
Chandra did some more work on a trapoid handling bug.
Christian worked on a GeoIP provisioning adapter.
Christian updated flow option template handling to be thread-safe.
Bonnie made some updates to the search documentation.
Web, ReST, UI, and Helm
Upendra worked on cleaning up redirect handling in some web controller code.
Mike did more work on updating the UI proof-of-concept to FeatherDS.
Tripti worked on notification support in the new UI.
Jane worked on sorting improvements in the Vue geomap.
Sagar worked on more configuration editing improvements in the new UI.
Christian fixed the V1 monitoring location ReST API sorting defaults to match V2.
Farid worked on updating the Vue geomap to use the AwesomeMarker library for map marker improvements.
Thanks to the following contributors for committing changes since last OOH:
Breaking Changes in Horizon 29
With Horizon 29 slated for next month, I wanted to take a moment to note some changes that are coming.
Along with a bunch of bug fixes and enhancements, we have a couple of things that are changing significantly that it's worth noting.
OpenNMS will run as non-root by default. However, because it is possible to have a significant number of resources
writing files into the $OPENNMS_HOME/share directory, we will not automatically
fix ownership of those files on upgrade, because it could take an indeterminate
amount of time to run chown on the entire shared data tree.
Be prepared for some downtime while upgrading.
Amazon SQS support for communicating with Minion will be removed.
RPC communication and the handling of configuration are changing significantly
enough that we would need to rewrite the SQS component and we don't believe
it to be in wide deployment, compared to using gRPC or Kafka.
OpenNMS is on a monthly release schedule, with releases happening on the second Wednesday of the month.
The next OpenNMS release day is November 10th, 2021.
We currently expect the first release in the Horizon 29 series, as well as a Meridian 2021 update.
Next Horizon: 29 (Q4 2021)
The next major Horizon release will be Horizon 29.
The current roadmap for Horizon 29 includes the following goals:
running as non-root by default
refactor the Minion's communication to get rid of out-of-band ReST calls to the OpenNMS core
add support for persistence of flows to Cortex
Next Meridian: 2022 (Q? 2022)
With Meridian 2021 recently out, we do not yet have a specific timeline for Meridian 2022.
Expect it to include -- at the very least -- the JDK11 requirement and flow aggregation improvements from Horizon 28.
Ideally it will contain work going into Horizons 29 (and probably 30) if our timeline holds.
Note that this is just based on current plans; dates, features, and releases can change or slip depending on how development goes.
The statements contained herein may contain certain forward-looking statements relating to The OpenNMS Group that are based on the beliefs of the Group’s management as well as assumptions made by and information currently available to the Group’s management. These forward-looking statements are, by their nature, subject to significant risks and uncertainties.
...We apologize for the excessive disclaimers. Those responsible have been sacked.
Mynd you, møøse bites Kan be pretti nasti...
We apologise again for the fault in the disclaimers. Those responsible for sacking the people who have just been sacked have been sacked.
Until Next Time…
If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.