Planet OpenNMS

June 16, 2021

Order of the Green Polo: Requiescat In Pace

One of the first “group chat” technologies I was ever exposed to was Internet Relay Chat (IRC). This allowed a group of people to get together in areas called “channels” to discuss pretty much anything they felt like discussing. The service had to be hosted somewhere, and for most open source projects that was Freenode.

You might have seen that recently Freenode was taken over by new management, and the policies this new management implemented didn’t sit well with most Freenode users. In the grand open source tradition, most everyone left and went to other IRC servers, most notably Libera Chat.

In May of 2002 when I became the sole maintainer of OpenNMS, there was exactly one person who was dedicated full time to the project – me. What kept me going was the community I found on IRC, in both the #opennms channel and the local Linux users group channel, #trilug.

It was the people on IRC who supported me until I could grow the business to the point of bringing on more people. I still have strong friendships with many of them.

I was reminded of those early days as we migrated #opennms to Libera Chat. At the moment there are only 12 members logged in, and most of those are olde skoool OpenNMS people. I haven’t used IRC much since we switched to Mattermost (we host a server at chat.opennms.com) and with it a “bridge” to bring IRC conversations into the main Mattermost channel. Most people moved to use Mattermost as their primary client, but of course there were a few holdouts (Hi Alex!).

While I was reminiscing, I was also reminded of the Order of the Green Polo (OGP). When David, Matt and I started The OpenNMS Group in 2004, interest in OpenNMS was growing, and there was a core of those folks on IRC who were very active in contributing to the project. I was trying to think of someway to recognize them.

At that time, business casual, at least for men, consisted of a polo shirt and khaki slacks. Vendors often gifted polo shirts with their logos/logotypes on them to clients, and a number of open source projects sold them to raise money. We sold a white one and a black one, and I thought, hey, perhaps I can pick another color and use that to identify the special contributors to OpenNMS.

Green has always been associated with OpenNMS. In network monitoring, green symbolizes that everything is awesome. We even named one of our professional services products the “Greenlight Project“. Plus I really like green as a color.

Then the question became “what shade of green?” For some reason I thought of Tiger Woods who, by this time, late 2004, had won the prestigious Masters golf tournament three times (and would again the next spring). The winner of that tournament gets a “hunter green” jacket, and so I decided that hunter green would be the color.

Also, for some unknown reason, I saw an article about a British knighthood called “The Order of the Garter“. I combined the two and thus “The Order of the Green Polo” was born.

It was awesome.

People who had been active in contributing to OpenNMS became even more active when I recognized them with the OGP honor. They contributed code and helped us with supporting our community, as well as adding a lot to the direction of the project. We started having annual developer conferences called “Dev-Jam” and OGP members got to attend for free so we could spend some face to face time with each other. I considered these men in the OGP to be my brothers.

As OpenNMS grew, we looked to the OGP for recruitment. It was through the OGP that Alejandro came to the US from Venezuela and now leads our support and services team (if OpenNMS went away tomorrow, getting him and his spouse here would have made it all worth it). When you hired an OGP member, you were basically paying them to do something they wanted to do for free. Think of is as like eating an ice cream sundae and finding money at the bottom.

But that growth was actually something that lead to the decline of the OGP. When we hired everyone that wanted a job with us, the role of the OGP declined. Dev-Jam was open to anyone, but it was mandatory for OpenNMS employees. Not all employees were OGP even though they were full-time contributors, so there was often pressure to induct new employees into the Order. And, most importantly, as we aged many OGP members moved on to other things. Hey, it happens, and it doesn’t reflect poorly on their past contributions.

We had a special mailing list for the OGP, but instead of discussing OpenNMS governance it basically became a “happy birthday” list (speaking of which, Happy Birthday Antonio!). When OpenNMS was acquired by NantHealth, we had to merge our mail systems and in the process the OGP list was deactivated. I don’t think many people noticed.

Recently it was brought to my attention that associating OpenNMS with the Masters golf tournament through the OGP could have negative connotations. The Masters is hosted by the Augusta National Golf Club and there have been controversies around their membership policies and views on race. It was suggested that we rename the OGP to something else.

One quick solution would be to just change the shade of green to, perhaps, a “stoplight” green. But this got me to thinking that the same logic used to associate the color with racism could apply to the whole “Order of” as well, since that was based on a British knighthood which, much like Augusta, is mainly all male. Plus the British don’t have the best track record when it comes to colonialism, etc.

I think it is time for something totally new, so I’ve decided to retire the Order of the Green Polo. The members of the OGP are all male, and I’m extremely excited that as we’ve grown our company and project we have been able to greatly improve our diversity, and I would love to come up with something that can embrace everyone who has a love of OpenNMS and wants to contribute to it, be that through code, documentation, the community, &tc.

OpenNMS has changed greatly over the past two decades, and it has become harder to contribute to a project that has grown exponentially in complexity. As part of my role as the Chief Evangelist of OpenNMS, I want to change that and come up with easier ways for people to improve the OpenNMS platform, and I need to come up with a new program to recognize those who contribute (and if you want to skip that part and get right to the job thingie, we’re hiring, but don’t skip that part).

To those of you who were in the Order of the Green Polo, thank you so much for helping us make OpenNMS what it is today. I’m not sure if it would exist without you. And even without the OGP mailing list, I plan to remember your birthdays.

by Tarus at June 16, 2021 04:02 PM

June 14, 2021

OpenNMS On the Horizon – Non-Root, Docs, Dependencies, Thresholding, Persisting, Time-Series, Metadata, Nephron, Minion, UI, Helm

Since last time, we worked on running as non-root, a bunch of doc updates, dependency updates, threshold validation, collection set persisting, time-series API and metadata, Nephron, Minion health check, UI improvements, and Helm dashboards.

Github Project Updates

Internals, APIs, and Documentation
  • I continued to work on making OpenNMS run as non-root by default.
  • Marcel did some more detector documentation updates.
  • Bonnie worked on updating the development documentation introduction.
  • David Schlenk updated WMI dependencies.
  • Chandra updated threshold values to go through some basic validation at the XSD level.
  • Chandra worked on bumping our Newts dependency to the latest version.
  • I updated a few dependencies to their latest versions. (Apache Httpclient, logback-classic, thanks Dependabot!)
  • Jesse fixed an issue where collection sets with null or blank labels would throw an error, rather than just not persisting.
  • Patrick worked on an update to the time-series API to allow using regular expressions for indexing resource paths, as well as publishing some metadata to the TSDB rather than PostgreSQL.
  • I worked on publishing extra build metadata to the minion-config-schema.yml during builds.
  • Stefan did more work on Nephron testing and benchmarking.
Web, ReST, UI, and Helm
  • Jane and Chandra worked on some additional features for the Minion health check ReST service.
  • Christian updated the service web UI to show the effective (interpolated) values of metadata parameters.
  • Mark's Helm update to include a welcome dashboard was merged.
  • Mark updated the notification web UI to note that nodeid and foreignid can be referenced in notifications.
  • Bonnie updated the OpenNMS and Helm docs to note what is necessary to use the grafana-image-renderer with Helm's docker image.
  • Bonnie worked on documentation for the flow deep-dive Helm dashboard.
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • David Schlenk
  • Dustin Frisch
  • Jane Hou
  • Jesse White
  • Jian Yet Lee
  • Marcel Fuhrmann
  • Mark Mahacek
  • Patrick Schweizer
  • Stefan Wachter
  • bigbigtitus

Release Roadmap

July Releases

OpenNMS is on a monthly release schedule, with releases happening on the first Tuesday of the month.

The next OpenNMS release day is July 6th, 2021.

We currently expect at least a Horizon 28.0.1 release, plus updates for all supported Meridian releases.

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
  • start the groundwork for replacing the topology UI with a pure-javascript version
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. 😅

Disclaimer

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.

- Ben

Resolved Issues Since Last OOH

  • HELM-265: Cannot use grafana-image-renderer with Helm's Docker image
  • HELM-277: Helm Flow Dashboard updates
  • HELM-281: Create a Welcome dashboard for new Helm users
  • NMS-11764: SNMP collection failing for "interface label is null or blank"
  • NMS-12689: Add Validation for Metadata in Thresholds
  • NMS-12899: Document how collected data are stored by default
  • NMS-12900: Problems in Helm documentation
  • NMS-12997: Document RestAPI/PRIS process
  • NMS-13045: SnmpInterfacePoller
  • NMS-13097: Document missing Rest API
  • NMS-13179: Show effective values of service test parameters with meta data
  • NMS-13200: Update docs page
  • NMS-13226: Remove the opennms-docs RPM/DEB package for local installation
  • NMS-13315: Check if Docker Content Trust and Docker Registry Proxies play together nicely
  • NMS-13320: update WMI dependencies
  • NMS-13324: Persist monitor status in RRD
  • NMS-13330: Add out-of-band monitoring content to main user documentation
  • NMS-13335: Update Introduction
  • NMS-13347: Minion container v28.0.0 refuse to start
  • NMS-13348: Navbar in our new documentation can't be used on smaller screens
  • NMS-13355: Default Debian instructions don't work on a minimal install
  • NMS-13360: CVE-2020-13956: Update commons-httpclient to 4.5.13
  • NMS-13361: CVE-2017-5929: bump logback-classic version to latest
  • NMS-13365: Small visual fix for the service.jsp changes made in NMS-13179

by RangerRick at June 14, 2021 03:39 PM

June 10, 2021

New docs: Where to find them, why they’re better, and how to contribute

If you look at the OpenNMS documentation, you’ll notice a change. Yes, it has a more polished appearance thanks to our new corporate branding, but it also has improved content and functionality as a result of our recent migration from AsciiDoctor to Antora for building the documentation.

Migrating the documentation was a huge undertaking (we’ll discuss the experience and challenges in a future blog), which required a new repository structure, syntax updates to almost every file, changes to our build environment, and a lot of tweaks along the way.

Old OpenNMS documentationrebranded documentation

All the docs in one place, search functionality

We’ve consolidated all the product documentation in one place at a new URL: docs.opennms.com. From here you can access the current version (and some older ones) of the documentation for all OpenNMS components: Horizon, Meridian, Helm, Alec, PRIS, and OpenNMS.js. The documentation also contains top-level menu links to other great sources of information about the project: training videos, community discussion forums, archived documentation, and OpenNMS support.

Built-in search functionality lets you search all the documentation to easily find the answers you need. We have restructured some of the content, most notably in the Horizon/Meridian documentation:

  • Release notes are now included within the core documentation
  • Updated installation guide content now under “Deployment” menu
  • Administration Guide now under “Operation”
  • New “Reference” section with glossary and miscellaneous configuration topics

How to contribute

With the migration complete, our next steps are to improve and update the documentation. We want to remove out-of-date content and update anything that is incorrect or unclear. We want to add documentation for project features that don’t have any. Anyone can write documentation for the project, and we welcome any kind of contribution. (And if you are obsessed with documentation, please consider joining Write the Docs, our Mattermost channel devoted to all things documentation.)

Note that there are different ways to contribute documentation, each suitable for different use cases:

  • Publish tutorials and how to articles in our knowledge base. For example, you want to describe how to use the Net-SNMP agent and the OpenNMS SNMP monitor to solve a special use case with OpenNMS. This is a great way to help other OpenNMS users who might have similar questions.

  • Contribute formal technical documentation related to the source code on GitHub.

  • Fix “quickwin-docs” Jira tickets in our documentation backlog. These are issues that should not take much time to address.

Technical documentation tips

File format for documentation is AsciiDoc, with the .adoc extension. For information on syntax, see Antora’s AsciiDoc Primer or look at how the existing .adoc files work.

Technical documentation should be accurate and concise. A good way to structure your contribution is as follows:

  • Descriptive heading for new topics (for example, “Create a Minion” or “SnmpCollector”)

  • Brief description of what you are documenting. If this is a new feature, include why it is important to users (for example, “This feature lets users validate and tune their business service hierarchies until they achieve the desired status propagation.”)

  • Steps to complete the procedure, or technical content such as parameters, configuration, and examples

Minimize the use of screenshots. Include them only to illustrate a concept that may be difficult to understand or something that is not easy to locate in the UI.

Where do I contribute technical documentation?

Log in to GitHub and locate the repository for the OpenNMS component for which you want to contribute documentation (for example, opennms, opennms-helm). Navigate to the /docs directory. Within this directory, you will find the /modules directory, that contains all the technical documentation associated with the source code in that repository. The /modules directory may have more nested directories to create a hierarchy for the content (component, subcomponents).

You will find .adoc files in the /pages directory or one of the subdirectories within the /pages directory. Images go in the /assets/images directory. The following is an example of the core OpenNMS docs repository:

For more information on how to contribute to OpenNMS documentation, including formatting conventions, tips and tricks, and cheat sheets, see Develop Documentation. (Note that the introduction to the Develop Documentation topic contains outdated information. We will update it with the content from this blog for the next release.)

Happy writing and thank you for contributing to OpenNMS documentation!

by Bonnie Robinson at June 10, 2021 01:50 PM

June 07, 2021

OpenNMS On the Horizon – Documentation, Flows and Nephron, Docker Container Trust, Thresholding, Metadata, Time-Series API, Minion Health Checks

Since last time, we did a bunch more documentation updates, plus worked on a number of bug fixes and instrumentation updates to flow processing and Nephron, Docker Container Trust, thresholding, metadata, the time-series API, and Minion health checks.

Github Project Updates

Internals, APIs, and Documentation
  • Mark worked on a few documentation fixes.
  • Dustin made the flow sampling interval configurable for flows missing it in their export.
  • Bonnie updated the reference docs with a number of cleanups and also added a section on the Prometheus JMX exporter.
  • Stefan continued to work on implementing Docker Container Trust for our minion images.
  • Marcel did more updates to detector documentation.
  • Chandra added some basic validation of threshold value in the thresholding XSD. It should match either a floating-point value, or a metadata text replacement.
  • Bonnie did a bunch more documentation updates including BSM, Minion Docker, confd, and more.
  • Patrick did some more work on storing string values in the time-series API.
  • Jane worked on categorizing health checks so that a subset(s) can be queried.
  • Stefan did some more work on instrumenting Nephron for performance tuning.
Web, ReST, UI, and Helm
  • Dustin updated the availability ReST service to supply up/down status.
  • Dustin updated the metadata ReST interface read-only, since metadata is intended to only be modified through requisitions.
  • Jane added OpenAPI docs to the health-check ReST service.
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Dustin Frisch
  • Jane Hou
  • Marcel Fuhrmann
  • Mark Mahacek
  • Patrick Schweizer
  • Stefan Wachter

June Releases

In June, we released updates to all OpenNMS Meridian versions under active support, and released the first iteration of OpenNMS Horizon 28.

Horizon 28.0.0

Release 28.0.0 is the first in the Horizon 28 series, introducing a requirement of Java 11, enhancements to flow aggregation to support DSCP ToS/QoS, and more.

The codename for Horizon 28.0.0 is Jazz.

For an overview of changes in OpenNMS Horizon 28, see What's New in OpenNMS Horizon 28

Meridian Point Releases

All Meridian releases this month contained just a few small bug fixes and enhancements. As always, it is strongly recommended that you update to the latest release.

For a list of changes, see the release notes:

Release Roadmap

July Releases

OpenNMS is on a monthly release schedule, with releases happening on the first Tuesday of the month.

The next OpenNMS release day is July 6th, 2021.

We currently expect at least a Horizon 28.0.1 release.

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
  • start the groundwork for replacing the topology UI with a pure-javascript version
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. 😅

Disclaimer

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.

- Ben

Resolved Issues Since Last OOH

  • NMS-12876: Typo in Graphs: "File Descritors"
  • NMS-13238: Enhance Availability (RTC) data via REST with current service status
  • NMS-13260: Expand PageSequenceMonitor Documentation
  • NMS-13319: Provide OpenAPI doc to health-check REST API
  • NMS-13322: Backport 'NMS-13215: Fallback config for flow timeouts' to release-27.x
  • NMS-13344: Documentation Typos
  • NMS-13351: Release notes display issues

by RangerRick at June 07, 2021 03:23 PM

June 02, 2021

June 2021 Releases – Horizon 28.0.0, Meridians 2021.1.1, 2020.1.9, 2019.1.20, 2018.1.29

In June, we released updates to all OpenNMS Meridian versions under active support, and released the first iteration of OpenNMS Horizon 28.

Horizon 28.0.0

Release 28.0.0 is the first in the Horizon 28 series, introducing a requirement of Java 11, enhancements to flow aggregation to support DSCP ToS/QoS, and more.

The codename for Horizon 28.0.0 is Jazz.

For an overview of changes in OpenNMS Horizon 28, see What's New in OpenNMS Horizon 28

Meridian Point Releases

All Meridian releases this month contained just a few small bug fixes and enhancements. As always, it is strongly recommended that you update to the latest release.

For a list of changes, see the release notes:

by RangerRick at June 02, 2021 04:49 PM

June 01, 2021

OpenNMS On the Horizon – Docs, BouncyCastle SSL, Deps, Time-Series API, Minion, Nephron, Run As Non-Root, Helm, UI

Since last time, we did a ton of documentation updates, fixed the BouncyCastle SSL bug, updated some core dependencies, and made improvements in the time-series API, Minion health check, Nephron and flow processing, running as non-root, Helm, and the web UI.

Github Project Updates

Internals, APIs, and Documentation
  • Chandra and David fixed the bug with BouncyCastle causing TLS/SSL problems.
  • Patrick did more work on caching/performance improvements to the time-series API.
  • Jeff worked on some cleanups to Horizon/Meridian references in the documentation.
  • Mark made some improvements to the PSM and Prometheus collector docs.
  • Jane worked on creating a health check for checking Karaf bundle status.
  • Bonnie and Ronny did a bunch of work on improving the installation instructions.
  • Chandra continued to work on updating our Guava library to version 28.
  • Dustin worked on some additional flow debugging code.
  • Stefan did more work on tools for benchmarking flow processing performance.
  • Stefan worked on some improvements to Nephron to reduce garbage collection load.
  • I worked on changing OpenNMS to run as non-root by default.
  • Sean updated Kafka Components to 2.8.0.
  • Patrick worked on an enhancement to the time-series API to handle string properties.
  • Marcel worked on improving a bunch of detector documentation.
Web, ReST, UI, and Helm
  • Jane fixed the favicon to match the new branding.
  • Chandra and Jane worked on exposing health-check status over ReST on the Minion.
  • Mark made a "welcome" dashboard for Helm to ease getting started.
  • Christian did some CSRF improvements in a few web forms in the admin UI.
  • Mark worked on some other improvements to the flow deep dive dashboard in Helm.
  • Christian fixed a UI issue where some pages couldn't accept the alternate foreignSource:foreignId format when passing a node in.
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • David Schlenk
  • Dustin Frisch
  • Jane Hou
  • Jeff Gehlbach
  • Marcel Fuhrmann
  • Mark Mahacek
  • Patrick Schweizer
  • Ronny Trommer
  • Sean Torres
  • Stefan Wachter

Release Roadmap

June Releases

The next OpenNMS release day is July 6th, 2021.

We currently expect at least a Horizon 28.0.1 release.

Next Horizon: 29 (Q? 2021)

The next major Horizon release will be Horizon 29.

Horizon 28 has just come out, and we are still firming up what our focus is going to be for the 29 cycle.

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.

Disclaimer

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.

- Ben

Resolved Issues Since Last OOH

  • HELM-203: Documentation Improvements
  • NMS-13111: BouncyCastle breaks SSL support in OpenNMS
  • NMS-13132: Nephron: derive aggregations for hosts and applications from the conversation aggregation
  • NMS-13158: IP interface link in Response Time graph page is broken
  • NMS-13250: Proofread Basic Horizon Deployment
  • NMS-13264: Upgrade Kafka components to 2.8.0
  • NMS-13267: Doc update for PrometheusCollector parameters
  • NMS-13274: Minion: A programmatic means of obtaining health (alternate to 'opennms:health-check')
  • NMS-13277: PoC for Docker Content Trust
  • NMS-13281: Mark OIA Implementation for Timeseries as experimental
  • NMS-13287: Got Access Denied when viewing On-Call Role schedule
  • NMS-13292: Favicon of OpenAPI page need to be updated
  • NMS-13294: Meridian installation guide is incomplete
  • NMS-13308: Validate query parameters in snmpInterfaces.jsp
  • NMS-13309: Validate name parameter in DestinationWizardServlet
  • NMS-13310: Replace FlowTimestampPolicy by shipped CustomTimestampPolicyWithLimitedDelay
  • NMS-13311: Support Rest API on Minion & Enable health-check REST feature
  • NMS-13321: Docs should refer to Horizon / Meridian conditionally
  • NMS-13329: CLONE - DOC Branding: Icon in tab is still the old one
  • NMS-13333: Enumeration of DSCP values returns only 10 values
  • NMS-13336: Update conventions for text formatting

by RangerRick at June 01, 2021 06:39 PM

May 24, 2021

OpenNMS On the Horizon – Nephron, DNS, Docs, SSL, Notifications, Time-Series, Helm, Topology, UI

Since last time, we worked on Nephron, DNS requisitions, documentation, SSL bugs, test flappers, notifications, time-series, Helm, topology, and UI updates.

Github Project Updates

Internals, APIs, and Documentation
  • Stefan worked on fixing a few Nephron bugs, as well as updating it to JDK11 and Flink 1.12.
  • Christian wrapped up some work on location-aware fixes for the DNS requisition provider.
  • Mark made some documentation fixes for the Prometheus collector, PageSequenceMonitor, and syslog config.
  • Chandra fixed an issue with BouncyCastle breaking some SSL-related operations.
  • I worked on fixing some test flappers.
  • Chandra wrapped up his fixes to notifications during scheduled outages.
  • Stefan reworked Nephron's pipeline processing to use built-in Kafka APIs for delay tracking.
  • Patrick worked on some improvements to cache handling in the Time-Series API.
Web, ReST, UI, and Helm
  • I fixed an issue in Helm where entity search queries would only return the first 1000 results.
  • Antonio added some test coverage for unresolvable topologies.
  • Jeff and Christian added some parameter validation improvements to the UI.
  • I released Helm 7.1.0, which includes the DSCP QoS/ToS improvements coming in Horizon 28.
  • Mark updated his flow dashboard improvements in Helm.
  • Jane fixed the outdated favicon in the UI.
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Antonio Russo
  • Benjamin Reed
  • Chandra Gorantla
  • Christian Pape
  • Jane Hou
  • Jeff Gehlbach
  • Mark Mahacek
  • Patrick Schweizer
  • Pierre Bouffard
  • Stefan Wachter

Release Roadmap

June Releases

The next OpenNMS release day is June 1st, 2021.

Barring complications, we expect the first Horizon 28 release, plus Meridian releases for 2018 and up.

Next Horizon: 28 (Q2 2021)

The next major Horizon release will be Horizon 28.

It will be the first OpenNMS release requiring JDK 11.

It will also contain a number of other improvements, plus a new feature for flows: DSCP QoS/ToS aggregation for nodes, plus a bunch of plumbing work to improve flow aggregation in general.

Next Meridian: 2022 (Q? 2022)

With Meridian 2021 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 of Horizon 28.

Disclaimer

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.

- Ben

Resolved Issues Since Last OOH

  • HELM-253: Helm: create QoS filter dropdown to select QoS queue
  • HELM-254: Helm: create 'Total traffic by QOS tag grouped by Interface/Exporter' graph
  • HELM-255: Helm: create 'Top K applications by QOS/Interface/Exporter' graph
  • HELM-256: Helm: create 'Top K conversations by QOS/Interface/Exporter' graph
  • HELM-257: Helm: create 'Top K hosts by QOS/Interface/Exporter' graph
  • HELM-258: Helm: add filter to flow editor alowing to select a ToS
  • HELM-259: Helm: determine which information should be displayed in the ToS selection field
  • HELM-260: Allow multiple values for ToS/DSCP/ECN filters
  • HELM-274: Filter panel filter column did not return complete list
  • HELM-276: Flows and performance data source configuration is empty
  • HELM-278: Release Helm 7.1.0
  • IPL-37: Support for PostgreSQL 13
  • NMS-12357: BMP Support
  • NMS-12925: Visualize Netflow traffic by QoS
  • NMS-12947: Elastic Flow Repository: modify ReST API to support queries including QoS (aggregated and raw queries)
  • NMS-13086: Optimize flow queries in case no DSCP or ECN filter exists
  • NMS-13223: Incorrect reference to org.opennms.netmgt.syslog.cfg
  • NMS-13262: Nephron - Update Java and Flink
  • NMS-13266: Notifications received despite Schedule Outage applies
  • NMS-13272: minion-config-schema.yml java agent example as a string
  • NMS-13278: Location aware Requisitions from DNS
  • NMS-13296: Threat Modelling for DCT
  • NMS-13305: Unable to graph data from node_exporter stored in newts indexed by label

by RangerRick at May 24, 2021 04:51 PM

May 17, 2021

OpenNMS On the Horizon – Meridian 2021, DNS Requisitions, Docs, Newts, Nephron, Catheter, Smoke Tests, Minion, PRIS, Flows, Notifications, Helm

Since last time, we released Meridian 2021, plus worked on the DNS requisition handler, documentation, Newts, Nephron and Catheter, smoke tests, the Minion, PRIS, flows, notifications, and Helm.

Github Project Updates

Internals, APIs, and Documentation
  • Christian updated the DNS requisition URL handler to be location-aware.
  • Marcel did some more work on BSF detector documentation.
  • Chandra worked on bumping our guava dependency to match updated Newts.
  • Chandra and I worked on cleaning up some flapping tests.
  • Pierre worked on some updates to the Minion confd schema.
  • Bonnie did a bunch of doc updates to match newer style guides.
  • Christian updated PRIS to support setting metadata.
  • I did a bunch of small updates to Nephron and Catheter to clean up builds and release process.
  • Stefan fixed some NPE issues in missing aggregations for Elasticsearch flow queries.
  • Chandra worked on fixing notification behavior during a scheduled outage.
  • Jane worked on exposing the OpenNMS healthcheck on Minion through ReST.
Web, ReST, UI, and Helm
  • I made more preparations for the new Helm release.
  • Mark worked on some updated flow dashboards for Helm.
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Dustin Frisch
  • Jane Hou
  • Marcel Fuhrmann
  • Mark Mahacek
  • Pierre Bouffard
  • Ronny Trommer
  • Sean Torres
  • Stefan Wachter

May 2021 Releases - Horizon 27.2.0, Meridians 2021.1.0, 2020.1.8, 2019.1.19, and 2018.1.28

In May, we released updates to all OpenNMS Horizon and Meridian versions under active support, and released the first iteration of Meridian 2021.

Horizon 27.2.0

Horizon 27.2.0 is a release primarily targeting bug fixes, plus it includes our new branding refresh.

The codename for 27.2.0 is Magrathea.

For a high-level overview of what has changed in Horizon 27, see What’s New in OpenNMS Horizon 27.

For a complete list of changes in 27.2.0, see the detailed release notes.

Meridian Point Releases

Meridian 2018.1.28 was a tiny release, containing only an update to Apache Commons IO.

Meridian 2019.1.19 adds a backport of a number of browser security issues fixed the previous month in newer releases, plus a few other bug fixes.

Meridian 2020.1.8 contains all of those changes, plus a few other small bug fixes.

For a list of changes, see the release notes:

Meridian 2021

May also saw the release of Meridian 2021.1.0, the first in the 2021 series.

It is based on Horizon 27, which has proven to be one of our most solid series in quite a while. The most notable changes since Meridian 2020 (based on Horizon 26) are the removal of the legacy Remote Poller and the introduction of Application Perspective Monitoring, performing a similar set of functions using the Minion. Additionally, there are tons of bug fixes and other smaller feature improvements.

For an overview of what's changed since Meridian 2020, see the What's New section of the Meridian 2021 documentation.

Sharp readers will notice this is on our new docs.opennms.com site. We are in the process of moving projects from publishing to docs.opennms.org to the new Antora-based unified docs site.

Release Roadmap

June Releases

The next OpenNMS release day is June 1st, 2021.

Barring complications, we expect the first Horizon 28 release.

Next Horizon: 28 (Q2 2021)

The next major Horizon release will be Horizon 28.

It will be the first OpenNMS release requiring JDK 11.

It will also contain a number of other improvements, plus a new feature for flows: DSCP QoS/ToS aggregation for nodes, plus a bunch of plumbing work to improve flow aggregation in general.

Next Meridian: 2022 (Q? 2022)

With Meridian 2021 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 of Horizon 28.

Disclaimer

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.

- Ben

Resolved Issues Since Last OOH

by RangerRick at May 17, 2021 04:21 PM

May 13, 2021

May 2021 Releases – Horizon 27.2.0, Meridians 2021.1.0, 2020.1.8, 2019.1.19, and 2018.1.28

In May, we released updates to all OpenNMS Horizon and Meridian versions under active support, and released the first iteration of Meridian 2021.

Horizon 27.2.0

Horizon 27.2.0 is a release primarily targeting bug fixes, plus it includes our new branding refresh.

The codename for 27.2.0 is Magrathea.

For a high-level overview of what has changed in Horizon 27, see What’s New in OpenNMS Horizon 27.

For a complete list of changes in 27.2.0, see the detailed release notes.

Meridian Point Releases

Meridian 2018.1.28 was a tiny release, containing only an update to Apache Commons IO.

Meridian 2019.1.19 adds a backport of a number of browser security issues fixed the previous month in newer releases, plus a few other bug fixes.

Meridian 2020.1.8 contains all of those changes, plus a few other small bug fixes.

For a list of changes, see the release notes:

Meridian 2021

May also saw the release of Meridian 2021.1.0, the first in the 2021 series.

It is based on Horizon 27, which has proven to be one of our most solid series in quite a while. The most notable changes since Meridian 2020 (based on Horizon 26) are the removal of the legacy Remote Poller and the introduction of Application Perspective Monitoring, performing a similar set of functions using the Minion. Additionally, there are tons of bug fixes and other smaller feature improvements.

For an overview of what's changed since Meridian 2020, see the What's New section of the Meridian 2021 documentation.

Sharp readers will notice this is on our new docs.opennms.com site. We are in the process of moving projects from publishing to docs.opennms.org to the new Antora-based unified docs site.

by RangerRick at May 13, 2021 03:20 PM

May 12, 2021

What’s Old Is New Again

Today we launched a new look for OpenNMS, a rebranding effort that has been going on for the better part of a year. It represents a lot more than just a new logo and new colors. While OpenNMS has been around for over two decades now, it is also quite different from when it started. A tremendous amount of work has gone into the project over the past couple of years, and if you looked at using it even just a short while ago you will be surprised at what has changed.

New OpenNMS Logo

One of the best analogies I can come up with to talk about the “new” OpenNMS concerns cars. I like cars, especially Mercedes, and when I was in college I usually drove an older Mercedes sedan. I enjoyed bringing them back to their former glory (and old, somewhat beaten down cars were all I could afford), and so I might start by redoing the brake system, overhauling the engine, etc.

When I would run out of money, which was often, sometimes I’d have to sell a car. Prospective buyers would often complain that the paint wasn’t perfect or there was an issue with the interior. I’d point out that you could hop in this car right now and drive it across the country and never worry about breaking down, but they seemed focused on how it looked. Cosmetics are usually the last thing you focus on during a restoration, but it tends to be the first thing people see.

This is very much like OpenNMS. For over a decade we’ve been focused on the internals of the platform, and luckily we are now in a position to focus on how it looks.

Please don’t misunderstand: application usability is important, much more important than, say, the paint job on a car, but in order to provide the best user experience we had to start by working under the hood.

For example, from the beginning OpenNMS has contained multiple “daemons” that control various aspects of the platform. Originally this was very monolithic, and thus any small change to one of them would often require restarting the whole application.

OpenNMS is now based on a Karaf runtime which provides a modular way of managing the various features within the application. It comes with a shell that can allow even non-Java programmers access to both high and low level parts of the platform, and to make changes without restarting the whole thing. Features can be enabled and disabled on the fly, and it is easy to test the behavior of OpenNMS against a particular device without having to set up a special test environment to pore through pages of logs.

Another great aspect of OpenNMS is that much of the internal messaging can now take place through a broker such as Kafka. While this increases the stability and flexibility of the platform, users can also create custom consumers for the huge amounts of information OpenNMS is able to collect. For very large networks this creates the option to use that data outside of the platform itself, giving end users a high level of custom observablity.

The monolithic nature of OpenNMS has also been improved. The addition of “Minions” to provide monitoring at the edge of the network creates numerous monitoring solutions where there was none before. You can now reach into isolated or private networks, or monitor the performance of applications from various locations seamlessly. The “Sentinel” project allows the various processes within OpenNMS to be spread out over multiple devices with the aim to have virtually unlimited scale.

APM Example World Map

And I haven’t even started on the ability of OpenNMS to monitor tremendous amounts of telemetry data and to analyze it with tools such as “Nephron” or our foray into artificial intelligence with ALEC.

So much has changed with OpenNMS, much of it recently, that it was time for that new coat of paint. It was time for people to both notice the new look of OpenNMS at the surface, and the new OpenNMS under the covers.

One thing that hasn’t changed is that OpenNMS is still 100% open source. All of these amazing features are available to anyone under an OSI approved open source license. Plus we leverage and integrate with best-in-class open source tools such as Grafana for visualization and Cassandra (using Newts) for storing time series data.

Our new logo is a stylized gyroscope. For centuries the gyroscope has represented a way to maintain orientation in the most chaotic of situations. In much the same way, OpenNMS helps you maintain the orientation of your IT infrastructure which, let’s admit it, plays a huge role in the success of your enterprise.

Where the car analogy falls apart is that while the paint job is usually the end of a restoration, this new look for OpenNMS is just the beginning of a new chapter in the history of the project. Our goal is to create a platform where monitoring just happens. We’re not there yet, but check out the latest OpenNMS and we hope you’ll agree we are getting closer.

by Tarus at May 12, 2021 03:46 PM

Not Your Dad’s OpenNMS

OpenNMS is an “old school open source project” in many ways. We’ve been around for 20 years, spent most of that time hacking on code, and our community feels like family.

Typical of early open source projects, marketing and branding haven’t always been a top priority at OpenNMS. We’ve always had a logo (a logotype, if you want to get pedantic) and our main color was vaguely kelly green, accented with black and white. Ulf the kiwi bird was our requisite animal mascot. The logo went through various iterations over the years but kept the same basic shape.

Why change? Truthfully, we’ve always wanted to put more thought into our brand. We wanted our visual identity to represent everything we love about OpenNMS:

  • Approachable: Has a welcoming culture of helpfulness. OpenNMS is open to everyone.
  • Reliable: Designed for large enterprises and service providers, OpenNMS monitors tens of thousands of devices from a single instance.
  • Adaptable: The flexible architecture of OpenNMS can be adapted, extended, and easily integrated to meet each organization’s requirements.
  • Mature: OpenNMS has been continuously improving and setting the standard for open-source monitoring platforms for over 20 years. It continues to evolve and refine.

With the support of our new parent company, NantHealth, we were able to engage with New Kind, a “focused team of experts in strategy, positioning, messaging, and visual identity for tech brands.” New Kind has done an amazing job guiding us through this process. They asked us all the right questions and worked with us collaboratively – they've got open source roots too, so they “get it.”

Together, we created the Open Gyroscope. Just like OpenNMS, the Open Gyroscope is made of multiple pieces working in harmony to show the way and help users stay the course. We drew inspiration from existing navigational themes in the current OpenNMS brand (Horizon, Meridian, Helm, etc.).

Our new color palette was inspired by open air and sea to reflect the calm and confidence we want users to feel that comes from knowing they can rely on OpenNMS. The vibrant accent colors add fun and excitement to the palette.

Even though we have a new face, we’re still the same OpenNMS. We’re still open source, still obsessively engineering our platform, and we’re still family.

We’re so excited to continue this journey with you.

-The team at The OpenNMS Group

 

P.S.
Ulf isn’t going anywhere – he's still in charge!

by Jess at May 12, 2021 04:52 AM

May 10, 2021

OpenNMS On the Horizon – Configuration, Poller, minion, Docs, Notifications, Newts, PRIS, Karaf, Selenium, Grafana

Since last time, we worked on configuration management, poller metrics, situations on the Minion, documentation, dependencies, notifications, Newts, Tests, PRIS, Java, Karaf, Selenium monitor, OpenNMS.js and Helm, UI fixes, and a UI refresh.

Github Project Updates

Internals, APIs, and Documentation
  • Jesse did some more proof-of-concept work for configuration management
  • Jesse added some metrics to the poller
  • Stefan fixed an issue with situation feedback config on the Minion
  • Bonnie made some updates to dynamic dashboard documentation
  • I bumped our commons-io dependency to 2.8.0
  • Christian updated the notification editor to support parameters
  • Chandra bumped Newts Guava dependency to 23
  • Chandra and I worked on a number of timing fixes for tests
  • Christian worked on some metadata-related additions to PRIS
  • Ronny updated some of our base images with newer java timezone data
  • Stefan fixed an issue with reloading configuration in Karaf
  • Craig did more work on modernizing our Selenium monitor
  • Ronny continued the work to wrap up the Antora documentation update
Web, ReST, UI, and Helm
  • I released OpenNMS.js 2.1.1; it is primarily dependency updates, and some plumbing support for flow ToS
  • Stefan and I worked on wrapping up my port of Helm to TypeScript
  • Christian fixed an issue in the graph UI sidebar
  • Christian fixed an error displaying error IDs (ironically) in the web UI
  • Jane did more work refreshing the look of the login and main page
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Craig Gallen
  • Dustin Frisch
  • Jane Hou
  • Jesse White
  • Ronny Trommer
  • Sean Torres
  • Stefan Wachter

Release Roadmap

May Releases

The next OpenNMS release day is May 11th, 2021.

Currently we expect a new Horizon 27 release, as well as Meridians 2019, 2020, and 2021.

Next Horizon: 28 (Q? 2021)

The next major Horizon release will be Horizon 28.

Horizon 28 will still be coming down the pipeline soon.
Currently, we hope for it to contain the move to building with JDK 11 (and, consequently, a requirement to only run on JDK 11 or higher), QoS flow aggergation, and some other improvements in the pipeline.

Next Meridian: 2021 (Q2 2021)

Meridian 2021 is on track for a release in the 2nd quarter of 2021. It is expected to be based on the Horizon 27 codebase, which means it will contain all of the bug fixes and new features introduced in Horizon 26 and 27.

Disclaimer

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.

- Ben

Resolved Issues Since Last OOH

  • HELM-266: Filter panel can not be created
  • HELM-267: Adding a query to a performance dashboard is empty
  • NMS-8581: Not possible to define notification parameters via "Configure notifications" UI
  • NMS-12497: Migrate OpenNMS core docs to Antora
  • NMS-12728: Measurement API: Trim DS name to 19 chars when using RRD
  • NMS-12766: Race condition on ALEC's config bundle after installation
  • NMS-12767: Race condition when enabling the Situations Feedback feature
  • NMS-13235: Issue with parsing sFlow
  • NMS-13237: Cleared alarms with closed ticket state not removed when using a hybrid approach
  • NMS-13259: Sidebar navigation on the graph results page is not working
  • NMS-13263: Change Horizon to new brand icon and update navbar theme color
  • NMS-13270: Update Horizon log in page to the new design
  • NMS-13275: Fix Foundation 2019 branch building
  • NMS-13276: Time zone is handled different on Minion container image based on Ubuntu

by RangerRick at May 10, 2021 09:24 PM

OpenNMS On the Horizon – Configuration, Poller, minion, Docs, Notifications, Newts, PRIS, Karaf, Selenium, Grafana

Since last time, we worked on configuration management, poller metrics, situations on the Minion, documentation, dependencies, notifications, Newts, Tests, PRIS, Java, Karaf, Selenium monitor, OpenNMS.js and Helm, UI fixes, and a UI refresh.

Github Project Updates

Internals, APIs, and Documentation
  • Jesse did some more proof-of-concept work for configuration management
  • Jesse added some metrics to the poller
  • Stefan fixed an issue with situation feedback config on the Minion
  • Bonnie made some updates to dynamic dashboard documentation
  • I bumped our commons-io dependency to 2.8.0
  • Christian updated the notification editor to support parameters
  • Chandra bumped Newts Guava dependency to 23
  • Chandra and I worked on a number of timing fixes for tests
  • Christian worked on some metadata-related additions to PRIS
  • Ronny updated some of our base images with newer java timezone data
  • Stefan fixed an issue with reloading configuration in Karaf
  • Craig did more work on modernizing our Selenium monitor
  • Ronny continued the work to wrap up the Antora documentation update
Web, ReST, UI, and Helm
  • I released OpenNMS.js 2.1.1; it is primarily dependency updates, and some plumbing support for flow ToS
  • Stefan and I worked on wrapping up my port of Helm to TypeScript
  • Christian fixed an issue in the graph UI sidebar
  • Christian fixed an error displaying error IDs (ironically) in the web UI
  • Jane did more work refreshing the look of the login and main page
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Craig Gallen
  • Dustin Frisch
  • Jane Hou
  • Jesse White
  • Ronny Trommer
  • Sean Torres
  • Stefan Wachter

Release Roadmap

May Releases

The next OpenNMS release day is May 11th, 2021.

Currently we expect a new Horizon 27 release, as well as Meridians 2019, 2020, and 2021.

Next Horizon: 28 (Q? 2021)

The next major Horizon release will be Horizon 28.

Horizon 28 will still be coming down the pipeline soon.
Currently, we hope for it to contain the move to building with JDK 11 (and, consequently, a requirement to only run on JDK 11 or higher), QoS flow aggergation, and some other improvements in the pipeline.

Next Meridian: 2021 (Q2 2021)

Meridian 2021 is on track for a release in the 2nd quarter of 2021. It is expected to be based on the Horizon 27 codebase, which means it will contain all of the bug fixes and new features introduced in Horizon 26 and 27.

Disclaimer

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.

- Ben

Resolved Issues Since Last OOH

  • HELM-266: Filter panel can not be created
  • HELM-267: Adding a query to a performance dashboard is empty
  • NMS-8581: Not possible to define notification parameters via "Configure notifications" UI
  • NMS-12497: Migrate OpenNMS core docs to Antora
  • NMS-12728: Measurement API: Trim DS name to 19 chars when using RRD
  • NMS-12766: Race condition on ALEC's config bundle after installation
  • NMS-12767: Race condition when enabling the Situations Feedback feature
  • NMS-13235: Issue with parsing sFlow
  • NMS-13237: Cleared alarms with closed ticket state not removed when using a hybrid approach
  • NMS-13259: Sidebar navigation on the graph results page is not working
  • NMS-13263: Change Horizon to new brand icon and update navbar theme color
  • NMS-13270: Update Horizon log in page to the new design
  • NMS-13275: Fix Foundation 2019 branch building
  • NMS-13276: Time zone is handled different on Minion container image based on Ubuntu

by RangerRick at May 10, 2021 09:23 PM

May 03, 2021

OpenNMS.js v2.1.0

This release adds support for some flow APIs coming in OpenNMS Horizon 28, as well as a documentation rework and tons of dependency updates.

by RangerRick at May 03, 2021 07:28 PM

OpenNMS On the Horizon – Selenium, VMware, BSF, Documentation, Nephron, Karaf, Minion, UI, Notifications, OpenNMS.js, Helm

Since last time, we worked on Selenium monitor, VMware, BSF and other documentation, Nephron, Karaf, Minion, UI layout, notifications, opennms.js, and Helm.

Github Project Updates

Internals, APIs, and Documentation
  • Ronny did some work on creating test docker images for the Selenium monitor rework
  • Christian made some fixes for timeout handling in the VMware code
  • Marcel did some work on BSF detector documentation
  • Chandra, Craig, and Jesse continued the work on making the Selenium monitor Minion-compatible
  • Stefan fixed some dependency issues with Nephron and Catheter
  • Stefan worked on a race condition in container startup
  • Chandra fixed the default Minion flow config
Web, ReST, UI, and Helm
  • Jane worked on modernizing some of the admin help page links
  • Jane worked on some new layout stuff for the login page
  • Christian worked on an update to support setting parameters in the notification config UI
  • I converted Helm to TypeScript and the new Grafana toolkit to solve a number of initialization and related bugs
  • I added some missing types to the opennms.js convenience API, DAO, and Model exports
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Chandra Gorantla
  • Christian Pape
  • Craig Gallen
  • Dustin Frisch
  • Jane Hou
  • Jesse White
  • Marcel Fuhrmann
  • Ronny Trommer
  • Stefan Wachter

Release Roadmap

May Releases

The next OpenNMS release day is May 11th, 2021.

Currently we expect a new Horizon 27 release, as well as Meridians 2019, 2020, and 2021.

Next Horizon: 28 (Q? 2021)

The next major Horizon release will be Horizon 28.

Horizon 28 will still be coming down the pipeline soon.
Currently, we hope for it to contain the move to building with JDK 11 (and, consequently, a requirement to only run on JDK 11 or higher), QoS flow aggergation, and some other improvements in the pipeline.

Next Meridian: 2021 (Q2 2021)

Meridian 2021 is on track for a release in the 2nd quarter of 2021. It is expected to be based on the Horizon 27 codebase, which means it will contain all of the bug fixes and new features introduced in Horizon 26 and 27.

Disclaimer

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.

- Ben

Resolved Issues Since Last OOH

  • NMS-9966: nodelabel-host-name setting on HttpMonitor not applying
  • NMS-13090: Build prototype of configuration system for vacuumd config
  • NMS-13095: Replace ConfigTesterTest with something that uses the configservice
  • NMS-13096: Yang Vacuumd Configuration and Generation
  • NMS-13110: Shipped minion flow listener config does not create a working listener
  • NMS-13122: Intergate support for OSGI into configuration system
  • NMS-13225: Update Help page with doc links in the Web UI

by RangerRick at May 03, 2021 05:29 PM

OpenNMS On the Horizon – Selenium, VMware, BSF, Documentation, Nephron, Karaf, Minion, UI, Notifications, OpenNMS.js, Helm

Since last time, we worked on Selenium monitor, VMware, BSF and other documentation, Nephron, Karaf, Minion, UI layout, notifications, opennms.js, and Helm.

Github Project Updates

Internals, APIs, and Documentation
  • Ronny did some work on creating test docker images for the Selenium monitor rework
  • Christian made some fixes for timeout handling in the VMware code
  • Marcel did some work on BSF detector documentation
  • Chandra, Craig, and Jesse continued the work on making the Selenium monitor Minion-compatible
  • Stefan fixed some dependency issues with Nephron and Catheter
  • Stefan worked on a race condition in container startup
  • Chandra fixed the default Minion flow config
Web, ReST, UI, and Helm
  • Jane worked on modernizing some of the admin help page links
  • Jane worked on some new layout stuff for the login page
  • Christian worked on an update to support setting parameters in the notification config UI
  • I converted Helm to TypeScript and the new Grafana toolkit to solve a number of initialization and related bugs
  • I added some missing types to the opennms.js convenience API, DAO, and Model exports
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Chandra Gorantla
  • Christian Pape
  • Craig Gallen
  • Dustin Frisch
  • Jane Hou
  • Jesse White
  • Marcel Fuhrmann
  • Ronny Trommer
  • Stefan Wachter

Release Roadmap

May Releases

The next OpenNMS release day is May 11th, 2021.

Currently we expect a new Horizon 27 release, as well as Meridians 2019, 2020, and 2021.

Next Horizon: 28 (Q? 2021)

The next major Horizon release will be Horizon 28.

Horizon 28 will still be coming down the pipeline soon.
Currently, we hope for it to contain the move to building with JDK 11 (and, consequently, a requirement to only run on JDK 11 or higher), QoS flow aggergation, and some other improvements in the pipeline.

Next Meridian: 2021 (Q2 2021)

Meridian 2021 is on track for a release in the 2nd quarter of 2021. It is expected to be based on the Horizon 27 codebase, which means it will contain all of the bug fixes and new features introduced in Horizon 26 and 27.

Disclaimer

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.

- Ben

Resolved Issues Since Last OOH

  • NMS-9966: nodelabel-host-name setting on HttpMonitor not applying
  • NMS-13090: Build prototype of configuration system for vacuumd config
  • NMS-13095: Replace ConfigTesterTest with something that uses the configservice
  • NMS-13096: Yang Vacuumd Configuration and Generation
  • NMS-13110: Shipped minion flow listener config does not create a working listener
  • NMS-13122: Intergate support for OSGI into configuration system
  • NMS-13225: Update Help page with doc links in the Web UI

by RangerRick at May 03, 2021 05:28 PM

April 26, 2021

OpenNMS On the Horizon – Kafka, Karaf, Newts, Time-Series, Nephron, Flows, Minion, BMP, Measurements API, Selenium Monitor, ReST, UI

In the last week we did a ton more bugfixing and enhancements related to Kafka, the Karaf CLI, Newts, Time-Series Metadata, Nephron, Flows, Minion, BMP, the measurements API, the Selenium monitor, ReST, and the web UI.

Github Project Updates

Internals, APIs, and Documentation
  • Bonnie updated the Kafka documentation to note settings that should be updated when using the Kafka producer and large network devices
  • Dino fixed up the stress-metrics help output
  • Bonnie worked on Newts installation instructions
  • Jesse added some tracking of cardinality metrics in the timeseries metadata
  • Stefan made some changes to the Nephron aggregation code for backwards-compatibility
  • Dustin worked on improvements to the telemetry integration tests
  • Bonnie cleaned up the Minion confd schema descriptions
  • Chandra fixed an issue with lag in the Minion Heartbeat handling
  • Jeff did a bit more work on Cassandra-related updates to Newts
  • Chandra fixed a few timing issues with BMP
  • Dustin fixed an issue with parsing extended sFlow
  • Dustin fixed a bug in handling truncated datasource names in the measurements API
  • Stefan worked on fixing a few more Nephron tests
  • Stefan fixed a problem with confd system properties not being set properly in Minion
  • Chandra worked on making the Selenium Monitor installable on the Minion
Web, ReST, UI, and Helm
  • I worked on bumping our Vaadin framework dependency to the latest version
  • Jane fixed an issue with the LLDP ReST API
  • Christian backported some of the UI fixes made in Horizon 27 to previous branches
  • Jane updated the web UI help page to point to the new docs and OpenAPI/Swagger UI
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Dino Yancey
  • Dustin Frisch
  • Jane Hou
  • Jeff Gehlbach
  • Jesse White
  • Marcel Fuhrmann
  • Ronny Trommer
  • Stefan Wachter

Release Roadmap

May Releases

The next OpenNMS release day is May 11th, 2021.

Currently we expect a new Horizon 27 release, as well as Meridians 2019 and 2020.

Next Horizon: 28 (Q? 2021)

The next major Horizon release will be Horizon 28.

Horizon 28 will still be coming down the pipeline soon.
Currently, we hope for it to contain the move to building with JDK 11 (and, consequently, a requirement to only run on JDK 11 or higher), QoS flow aggergation, and some other improvements in the pipeline.

Next Meridian: 2021 (Q2 2021)

Meridian 2021 is on track for a release in 2nd quarter of 2021. It is expected to be based on the Horizon 27.1 codebase, which means it will contain all of the bug fixes and new features introduced in Horizon 26 and 27.

Disclaimer

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.

- Ben

Resolved Issues Since Last OOH

  • HELM-273: Drift (ES): Trying to create too many buckets.
  • NMS-12500: Develop tree structure for docs
  • NMS-12945: Nephron: add additional aggregations to support QoS filtering in Helm
  • NMS-13039: Add a warning when enabling forwarding metrics through the Kafka Producer
  • NMS-13099: Nephron: Add additional aggregations for backwards compatibilty and optimized access
  • NMS-13100: Nephron: optimize aggregation calculation
  • NMS-13101: Setting Instance ID via minon-config.yaml doesn't work
  • NMS-13160: Web ui got stuck in 2020 :)
  • NMS-13184: Re-enable Kafka RPC Single Topic By Default
  • NMS-13224: Bmp Peer Up/Down Notification Message may be missed on OpenNMS/Sentinel
  • NMS-13232: Heartbeat topic lag with a large number of minions
  • NMS-13234: vmware integration connection pool not expiring connections
  • NMS-13242: Admin Guide Newts Instructions Incomplete
  • NMS-13247: Minion - Meridian Installation Documents Incorrect
  • NMS-13255: Provide documentation for context-sensitive help in UI form
  • NMS-13258: LLDP REST api miss local port info
  • NMS-13261: Update Vaadin dependencies

by RangerRick at April 26, 2021 07:27 PM

April 20, 2021

OpenNMS On the Horizon – Performance, Selenium, Time-Series Storage, Kafka, Minion, Documentation, Flow QoS/ToS, BMP, Cassandra, Newts, UI, Helm

In the last week we worked on performance improvements, the Selenium monitor, time-series storage and instrumentation, Kafka SSL, Minion config and heartbeat, documentation, flow QoS/ToS, BMP, cloud Cassandra for Newts, UI fixes, and Helm.

Github Project Updates

Internals, APIs, and Documentation
  • Chandra made an improvement to performance when checking salted passwords
  • Craig continued his work on modernizing the Selenium monitor
  • Patrick worked on some changes to the time-series storage API tests
  • Christian added support for SSL in Nephron's Kafka implementation
  • Bonnie made some improvements to the documentation for the Minion config schema
  • Marcel worked on documentation for the BSF detector
  • Stefan did more work on the new flow QoS/ToS support
  • Chandra fixed some timing issues in the BMP code when PeerUp messages are received before router initialization
  • Jeff made some Newts improvements to support cloud-hosted Cassandra
  • Chandra fixed an issue with lagging minion heartbeats
  • Jesse added more metrics to time-series instrumentation
Web, ReST, UI, and Helm
  • Christian backported some UI fixes to older Meridian branches
  • Stefan and I worked on porting our Helm build to use Grafana's new build toolkit (including finally converting some code to TypeScript)
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Craig Gallen
  • Dustin Frisch
  • Jeff Gehlbach
  • Jesse White
  • Marcel Fuhrmann
  • Patrick Schweizer
  • Stefan Wachter

April Releases

In April, we released updates to all OpenNMS versions under active support.

Horizon 27.1.1

Release 27.1.1 contains a few enhancements, as well as a number of bug fixes including some XSS and CSRF cleanups and a Jetty DoS CVE.

The codename for 27.1.1 is Infinite Improbability Drive.

For a high-level overview of what has changed in Horizon 27, see What’s New in OpenNMS Horizon 27.

For a complete list of changes in 27.1.1, see the detailed release notes.

Meridian Releases

Meridian 2018.1.27 was a small release, with just the Jetty CVE update and a new option for tuning Minion communication with OpenNMS.

Meridian 2019.1.18 added on top of that a number of other useful bug fixes including some cosmetic UI cleanups and a fix to Kafka producer resource naming.

Meridian 2020.1.7 contains all of those changes, plus a few other bug fixes and a performance improvement in the Kafka producer.

For a list of changes, see the release notes:

Release Roadmap

May Releases

The next OpenNMS release day is May 11th, 2021.

Currently we expect a new Horizon 27 release, as well as Meridians 2019 and 2020.

Next Horizon: 28 (Q? 2021)

The next major Horizon release will be Horizon 28.

Horizon 28 will still be coming down the pipeline soon.
Currently, we hope for it to contain the move to building with JDK 11 (and, consequently, a requirement to only run on JDK 11 or higher), QoS flow aggergation, and some other improvements in the pipeline.

Next Meridian: 2021 (Q2 2021)

Meridian 2021 is on track for a release in 2nd quarter of 2021. It is expected to be based on the Horizon 27.1 codebase, which means it will contain all of the bug fixes and new features introduced in Horizon 26 and 27.

Disclaimer

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.

- Ben

Resolved Issues Since Last OOH

  • NMS-11752: "Search/Filter Resources" on "Resource Graphs" not functioning as expected
  • NMS-12946: Nephron: examine what additional compute and storage load is implied by the new QoS-based aggregations
  • NMS-13114: Drift (ES): Trying to create too many buckets.
  • NMS-13188: Page not found on topology
  • NMS-13203: Nephron should support Kafka over TLS
  • NMS-13207: Poor PasswordEncryptor performance with large number of Minions
  • NMS-13215: Flows: Fallback config for flow timeouts
  • NMS-13220: Upgrade Karaf to 4.2.11
  • NMS-13228: Stored XSS reported 2021-03-31 (update summary after disclosure)
  • NMS-13231: Backport Security Issues from Last Month

by RangerRick at April 20, 2021 02:47 PM

April 14, 2021

How to: Set up Distributed Monitoring with OpenNMS

Large, distributed networks can be difficult to reach and monitor from a central location, with challenges like firewalls, network address translation (NAT) traversal, overlapping IP address ranges, and locked-down environments. The OpenNMS Minion component extends the reach of Horizon/Meridian, so you can monitor systems and networks that would otherwise be inaccessible, for optimal visibility into every area of your network.

Minions communicate with OpenNMS via an ActiveMQ or Apache Kafka message broker. Learn how to set up a simple OpenNMS Minion environment in these articles by Alejandro Galue, Senior Manager, Services and Support at The OpenNMS Group:

by Bonnie Robinson at April 14, 2021 04:27 PM

April 07, 2021

April 2021 Releases – Horizon 27.1.1, Meridians 2018.1.27, 2019.1.18, and 2020.1.7

In April, we released updates to all OpenNMS versions under active support.

Horizon 27.1.1

Release 27.1.1 contains a few enhancements, as well as a number of bug fixes including some XSS and CSRF cleanups and a Jetty DoS CVE.

The codename for 27.1.1 is Infinite Improbability Drive.

For a high-level overview of what has changed in Horizon 27, see What’s New in OpenNMS Horizon 27.

For a complete list of changes in 27.1.1, see the detailed release notes.

Meridian Releases

Meridian 2018.1.27 was a small release, with just the Jetty CVE update and a new option for tuning Minion communication with OpenNMS.

Meridian 2019.1.18 added on top of that a number of other useful bug fixes including some cosmetic UI cleanups and a fix to Kafka producer resource naming.

Meridian 2020.1.7 contains all of those changes, plus a few other bug fixes and a performance improvement in the Kafka producer.

For a list of changes, see the release notes:

by RangerRick at April 07, 2021 06:27 PM

April 06, 2021

OpenNMS On the Horizon – Nephron, Flows, Karaf, Antora, Ticketing, Alarms, Smoke Tests, Minion, Swagger, BSM, Jetty

In the last week we worked on Nephron and flows, Karaf, Antora documentation, ticketing and alarms, smoke tests, the Minion, Swagger UI for ReST, BSM editing, and Jetty TLS configs.

Github Project Updates

Internals, APIs, and Documentation
  • Stefan did more work on Nephron and flow improvements, plus his benchmarking tools
  • Jesse worked on updating our embedded Karaf to 4.2.11
  • Bonnie and Ronny continued to work on finalizing and improving the big Antora doc update
  • Dustin fixed an issue with timeout config for flows
  • Chandra fixed the default telemetry config
  • Chandra worked on a bunch of fixes and improvements to ticketing and alarms
  • Jesse and I worked on fixing up flapping smoke tests
  • Christian fixed an issue to handle alarm reduction keys better when multiple Minions are in the same location
Web, ReST, UI, and Helm
  • Jane worked on adding Swagger UI support for our ReST API
  • Christian fixed a bug editing BSM edges
  • Jeff tightened up the TLS settings for the default Jetty config
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Dustin Frisch
  • Jane Hou
  • Jeff Gehlbach
  • Jesse White
  • Marcel Fuhrmann
  • Ronny Trommer
  • Stefan Wachter

Release Roadmap

April Releases

The next OpenNMS release day is April 6th, 2021.

Currently we expect new bug fix releases for Horizon 27 and Meridians 2019 and 2020.

Next Horizon: 28 (Q? 2021)

The next major Horizon release will be Horizon 28.

Horizon 28 will still be coming down the pipeline soon.
Currently, we hope for it to contain the move to building with JDK 11 (and, consequently, a requirement to only run on JDK 11 or higher), QoS flow aggergation, and some other improvements in the pipeline.

Next Meridian: 2021 (Q2 2021)

Meridian 2021 is on track for a release in 2nd quarter of 2021. It is expected to be based on the Horizon 27.1 codebase, which means it will contain all of the bug fixes and new features introduced in Horizon 26 and 27.

Disclaimer

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.

- Ben

Resolved Issues Since Last OOH

  • HELM-270: Grafana dependency for Helm install
  • NMS-10188: Evaluate Swagger for REST API documentation
  • NMS-10256: Change Jetty default settings to eliminate TLS 1.0 and TLS 1.1 support
  • NMS-12670: Overview chapter
  • NMS-12697: Can't edit reductionKey in BSM
  • NMS-13028: Add WebDetector documentation
  • NMS-13074: Create Win32ServiceDetector documentation
  • NMS-13075: Create WmiDetector documenation
  • NMS-13076: Create BgpSessionDetector documentation
  • NMS-13187: Investigate using openAPI&Swagger to document v2 RESTful API
  • NMS-13189: The behavior of the Ticketing API differs from older versions.
  • NMS-13196: Editing a scheduled Grafana report resets the selected Grafana dashboard
  • NMS-13210: The %dpname% breaks the alarm life-cycle when having multiple minions per location
  • NMS-13227: Change Jetty default settings to exclude vulnerable cipher suites, expose client-initiated renegotiation

by RangerRick at April 06, 2021 05:47 PM

April 01, 2021

How to: Sizing Cassandra or Scylla for Newts

When you want to store large amounts of non-aggregated data (such as performance metrics), the round robin database (RRDtool) in OpenNMS may not be enough. OpenNMS provides a time-series data store (Newts) that works with Apache Cassandra or ScyllaDB to group metrics for more efficient storage and retrieval. It removes aggregation as a bottleneck to storage, and eliminates the wasted computation caused by unused aggregate values.

Cassandra or ScyllaDB require different implementations, configuration, and maintenance, but the process to size them for use with OpenNMS is the same. In Sizing Cassandra for Newts on Discourse, Alejandro Galue, Senior Manager, Services and Support at The OpenNMS Group, describes this process, with detailed instructions and considerations on how to do the following:

  • Use the evaluation layer to determine the number of metrics collected
  • Configure the ring buffer and resource cache to manage memory use and heap size
  • Estimate the cluster and metrics sizes
  • Manage time-series data using the Time Window Compaction Strategy (TWCS)
  • Set retention values for different metrics
  • Configure OpenNMS and data collection

 

by Bonnie Robinson at April 01, 2021 05:41 PM

March 30, 2021

OpenNMS On the Horizon – Docs, Flows, Ticketing, Minion, Selenium, ReST, BSM

In the last week we continued to work on the new documentation framework, performance and bug fixes, flow handling, ticketing, monitors, ReST, and BSM.

Github Project Updates

Internals, APIs, and Documentation
  • Ronny and Bonnie continued to work on tweaking and improving the Antora doc rework.
  • Jesse made a performance improvement to event label lookups, as well as introducing parallel event processing in the Kafka producer.
  • Jeff worked on adding support to Newts for connecting to a Cassandra Datastax database.
  • Chandra did more work on fixing up some bugs in ticketing change handling.
  • I worked on improving smoke test runs.
  • I changed the Trapd minion config so that SNMPv3 config refresh time is configurable.
  • Craig continued to work on modernizing the Selenium monitor.
  • Chandra added an in-memory ticketing plugin to simplify testing the ticketing API.
  • Stefan continued to work on performance improvements to flow processing.
  • Christian added a flag to clear %dpname% in alarms, to be used in cases where people run multiple minions in a single location.
  • Marcel did more work on documenting undocumented detectors.
Web, ReST, UI, and Helm
  • Jane wrapped up her initial implementation of OpenAPI swagger support for our ReST interfaces.
  • Christian fixed an issue with changing reductionKey in the BSM editor.
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Craig Gallen
  • Dustin Frisch
  • Jane Hou
  • Jeff Gehlbach
  • Jesse White
  • Marcel Fuhrmann
  • Ronny Trommer
  • Stefan Wachter

Release Roadmap

April Releases

The next OpenNMS release day is April 6th, 2021.

Currently we expect new bug fix releases for Horizon 27 and Meridians 2019 and 2020.

Next Horizon: 28 (Q? 2021)

The next major Horizon release will be Horizon 28.

Horizon 28 will still be coming down the pipeline soon.
Currently, we hope for it to contain the move to building with JDK 11 (and, consequently, a requirement to only run on JDK 11 or higher), QoS flow aggergation, and some other improvements in the pipeline.

Next Meridian: 2021 (Q2 2021)

Meridian 2021 is on track for a release in 2nd quarter of 2021. It is expected to be based on the Horizon 27.1 codebase, which means it will contain all of the bug fixes and new features introduced in Horizon 26 and 27.

Disclaimer

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.

- Ben

Resolved Issues Since Last OOH

  • ALEC-92: Add Antora Xref validation in ALEC CI/CD
  • HELM-268: Add Antora Xref validation in HELM CI/CD
  • JS-46: OpenNMS.js: add capability and modify model to support querying flow data including QoS
  • JS-50: Add Antora Xref validation in OpenNMS.JS CI/CD
  • NMS-13091: Enhancement to Topology ReST Endpoint
  • NMS-13157: Response time query with ICMP fails for IPv6 interface
  • NMS-13165: Write documentation about the turn up of Postgres and Cassandra for more than one node
  • NMS-13197: Compile OpenNMS with JDK11 (and remove support for JDK8)
  • NMS-13198: Fix nephron/catheter build interaction
  • NMS-13205: Antora Xref validation CI/CD pipeline
  • NMS-13208: Minion: Kafka related WARN log messages (AdminClientConfig The configuration X isn't a known config)
  • NMS-13209: Add Antora Xref validation in Horizon/Meridian repository
  • NMS-13211: Improve Event forwarding performance for Kafka producer
  • NMS-13214: Backport Enlinkd ReST interface to Horizon 27
  • NMS-13217: Minion SNMPv3 trap configuration query is done every 60 seconds
  • NMS-13218: Add InMemoryTicketPlugin that can be accessed from Karaf shell

by RangerRick at March 30, 2021 03:07 PM

March 22, 2021

OpenNMS On the Horizon – Thresholding, Smoke Tests, Docs, Flows, Ticketing, Minion, Selenium, ReST, Enlinkd

In the last week we fixed a bunch of bugs including ticketing and thresholding fixes, continued to work on QoS/ToS and flow improvements, ReST additions, and documentation.

Github Project Updates

Internals, APIs, and Documentation
  • Chandra worked on fixing the handling of metadata in thresholding
  • I did a bit more work on improving our smoke test pipeline
  • Ronny and Bonnie did more work finalizing the new Antora docs
  • Stefan did more work on flow performance and processing
  • Chandra worked on fixing some alarm ticketing integration bugs
  • Chandra fixed the default config for the Minion listener
  • Stefan continued to work on QoS/ToS in flows
  • Marcel added documentation for a number of detectors
  • Craig continued to work on modernizing the Selenium monitor
Web, ReST, UI, and Helm
  • Jane wrapped up her enhancements to exposing Enlinkd data through ReST
  • Jane did more work on generating ReST API docs
  • Christian did some more work on cleaning up web UI forms
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Craig Gallen
  • Jane Hou
  • Marcel Fuhrmann
  • Ronny Trommer
  • Stefan Wachter

Release Roadmap

April Releases

The next OpenNMS release day is April 6th, 2021.

Currently we expect new bug fix releases for Horizon 27 and Meridians 2019 and 2020.

Next Horizon: 28 (Q? 2021)

The next major Horizon release will be Horizon 28.

Horizon 28 will still be coming down the pipeline soon.
Currently, we hope for it to contain the move to building with JDK 11 (and, consequently, a requirement to only run on JDK 11 or higher), QoS flow aggergation, and some other improvements in the pipeline.

Next Meridian: 2021 (Q2 2021)

Meridian 2021 is on track for a release in 2nd quarter of 2021. It is expected to be based on the Horizon 27.1 codebase, which means it will contain all of the bug fixes and new features introduced in Horizon 26 and 27.

Disclaimer

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.

- Ben

Resolved Issues Since Last OOH

  • NMS-12941: Raw Link Details via REST API
  • NMS-13072: Add out of band management capabilities
  • NMS-13120: Wrong UEI is picked when threshold alarms are generated
  • NMS-13121: Document the Event Translator
  • NMS-13149: Regular Expression field textbox greyed out for other Events except 'REGEX_FIELD' under Event notifications
  • NMS-13201: CVE-2020-27223: Jetty DoS vulnerability

by RangerRick at March 22, 2021 02:51 PM

March 15, 2021

OpenNMS On the Horizon – Configuration, Kafka, Flows, Docs, JDK11, Thresholding, Selenium, Prometheus, CircleCI, ReST, Enlinkd, UI/UX

In the last week we continued to work on documentation, UI cleanups, configuration schema work, JDK11 build updates, Prometheus exporting, CircleCI improvements, a ReST API for Enlinkd, and more.

Github Project Updates

Internals, APIs, and Documentation
  • Matt did more work on the configuration schema for the Minion
  • Chandra worked on some cleanups to the Kafka producer's node schema
  • Stefan continued his work on performance improvements to flow processing
  • Ronny did some work on doc build errors
  • Chandra worked on a fix for handling multiple related thresholds properly
  • Jesse did more fixes relating to building with JDK11
  • Dustin worked on cleaning up a build issue related to nephron and catheter
  • Craig continued to work on modernizing the Selenium monitor
  • Christian did some small updates to the WsManCollector
  • Ronny did a little mork work on his proof-of-concept Prometheus exporter
  • I did a little work on splitting up our smoke tests to be more manageable in CircleCI
Web, ReST, UI, and Helm
  • Jane did more work on providing a ReST API for raw Enlinkd data
  • I backported/released a small fix to Helm's flow code
  • I worked on a UX fix for the notification wizard UEI selection
  • Christian worked on some UI cleanups related to user display
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Chandra Gorantla
  • Christian Pape
  • Craig Gallen
  • Dustin Frisch
  • Jane Hou
  • Jesse White
  • Matthew Brooks
  • Ronny Trommer
  • Stefan Wachter

Release Roadmap

April Releases

The next OpenNMS release day is April 6th, 2021.

Currently we expect new bug fix releases for Horizon 27 and Meridians 2019 and 2020.

Next Horizon: 28 (Q? 2021)

The next major Horizon release will be Horizon 28.

Horizon 28 will still be coming down the pipeline soon.
Currently, we hope for it to contain the move to building with JDK 11 (and, consequently, a requirement to only run on JDK 11 or higher), QoS flow aggergation, and some other improvements in the pipeline.

Next Meridian: 2021 (Q2 2021)

Meridian 2021 is on track for a release in 2nd quarter of 2021. It is expected to be based on the Horizon 27.1 codebase, which means it will contain all of the bug fixes and new features introduced in Horizon 26 and 27.

Disclaimer

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.

- Ben

Resolved Issues Since Last OOH

  • NMS-12970: Topology Application Map: Outage Table: Clicking on a service should show the outages of the service
  • NMS-13131: Nephron: Use unaligned windows for different exporters
  • NMS-13134: Drift (ES): Upgrade to ES 7.10.2
  • NMS-13185: Kafka producer uses resource name instead of ifIndex as the instance for InterfaceLevelResource
  • NMS-13193: Upgrade Karaf from 4.2.6 to 4.2.10

by RangerRick at March 15, 2021 04:50 PM

March 08, 2021

OpenNMS On the Horizon – Nephron, Flows, Kafka, Tests, Enlinkd ReST, UI

In the last week we continued to work on Nephron and flows, fixed some Kafka stream related bugs, fixed up some tests, worked on an Enlinkd ReST service, and did some other UI cleanups.

Github Project Updates

Internals, APIs, and Documentation
  • Bonnie did more work on documentation updates.
  • Chandra's initial work on built-in BGP Monitoring Protocol support got merged to release-27.x.
  • Chandra worked on an issue with ifIndex not being accessible from the Kafka stream.
  • Stefan did more work on nephron, flows, and flow benchmarking.
  • Chandra fixed a problem with dropped events in the Kafka stream.
  • Craig worked on modernizing the Selenium Monitor.
  • I fixed some test flappers in linkd.
Web, ReST, UI, and Helm
  • Dustin finished cleaning up the tests I worked on cleaning up for Patrick's code to fix the application topology map. ;)
  • Christian worked on a few validation fixes in the web UI.
  • Jane worked on creating a new ReST service for accessing Enlinkd data.
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Craig Gallen
  • Dustin Frisch
  • Jane Hou
  • Matthew Brooks
  • Patrick Schweizer
  • Stefan Wachter

Release Roadmap

March Releases

In March we released updates to Horizon 27, plus all supported Meridian versions.

Horizon 27.1.0

Release 27.1.0 contains a bunch of bug fixes, as well as a number of enhancements including a refactor of our BGP Monitoring Protocol integration which adds built-in support, no longer requiring an external OpenBMP installation.

The codename for 27.1.0 is Ravenous Bugblatter Beast of Traal.

For a complete list of changes in 27.1.0, see the detailed release notes.

Meridians 2018.1.26, 2019.1.17, and 2020.1.6

Meridian 2018.1.26 had a security update for a dependency, and a fix for a Newts cache priming configuration option.
2019.1.17 and 2020.1.6 had additional bug fixes and enhancements related to the UI.
2020.1.6 also added service status to the list of information available in the /info ReST endpoint.

For a list of changes, see the release notes:

April Releases

The next OpenNMS release day is April 6th, 2021.

Currently we expect a new bug fix release for Horizon 27.

Next Horizon: 28 (Q? 2021)

The next major Horizon release will be Horizon 28.

Horizon 28 will still be coming down the pipeline soon.
Currently, we hope for it to contain the move to building with JDK 11 (and, consequently, a requirement to only run on JDK 11 or higher), QoS flow aggergation, and some other improvements in the pipeline.

Next Meridian: 2021 (Q2 2021)

Meridian 2021 is on track for a release in 2nd quarter of 2021. It is expected to be based on the Horizon 27.1 codebase, which means it will contain all of the bug fixes and new features introduced in Horizon 26 and 27.

Disclaimer

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.

- Ben

Resolved Issues Since Last OOH

  • NMS-12962: Add enhancement infrastructure for BMP updates
  • NMS-12969: Topology Map: Application: Color of app wrong for aknowledged alarm
  • NMS-13029: Actively collected metrics suddenly become unavailable through API and Web UI due to static TTL on Newts search index
  • NMS-13143: Generate Data collection throws error message "There is a group with same name, please pick another one" under MIB browser
  • NMS-13145: 'Links on interface' table was missing for interface under node list
  • NMS-13152: Query Regarding saving a filter URL with more than 255 characters in events ILP
  • NMS-13167: Kafka Producer drops samples when the sending operation timeout.
  • NMS-13174: Use perl from env
  • NMS-13178: Opennms Ui is not accessible when logged in from a read-only user

by RangerRick at March 08, 2021 04:15 PM

March 03, 2021

March 2021 Releases – Horizon 27.1.0, Meridians 2018.1.26, 2019.1.17, and 2020.1.6

For March we released point updates to all OpenNMS versions under active support.

Horizon 27.1.0

Release 27.1.0 contains a bunch of bug fixes, as well as a number of enhancements including a refactor of our BGP Monitoring Protocol integration.

The codename for 27.1.0 is Ravenous Bugblatter Beast of Traal.

For a high-level overview of what has changed in Horizon 27, see What’s New in OpenNMS Horizon 27.

For a complete list of changes in 27.1.0, see the detailed release notes.

Meridians 2018.1.26, 2019.1.17, and 2020.1.6

Meridian 2018.1.26 had a security update for a dependency, and a fix for a Newts cache priming configuration option. 2019.1.17 and 2020.1.6 had additional bug fixes and enhancements related to the UI. 2020.1.6 also added service status to the list of information available in the /info ReST endpoint.

For a list of changes, see the release notes:

by RangerRick at March 03, 2021 09:35 PM

March 01, 2021

OpenNMS On the Horizon – Newts, Kafka, BMP, Configuration, Docs, Events, Nephron, UI/UX, ReST, User Validation

In the last week we worked on Newts, Kafka queues, transitioning from OpenBMP, a configuration API, documentation, event definitions, Nephron benchmarking, UI/UX cleanups, ReST improvements, and user validation.

Github Project Updates

Internals, APIs, and Documentation
  • Dustin fixed an issue with TTL handling in Newts.
  • Dustin's fix for cache priming in Newts was backported to some of the foundation branches.
  • Chandra fixed a bug where messages could be dropped depending on how kafkaSendQueueCapacity is set.
  • Chandra did more work on wrapping up the OpenBMP migration.
  • Patrick and Jesse continued to work on creating a new configuration API.
  • Bonnie did more work on the new Antora-based documentation.
  • Marcel added definitions for applicationChanged and applicationCreated events.
  • Stefan made a tool for benchmarking Nephron flow processing.
Web, ReST, UI, and Helm
  • I added a table to the alarm details page to show related events based on UEI, node, interface, and service.
  • Jane finished her work on making sure duplicate services in requisitions are handled properly.
  • I added controls for setting the number of rows to return in the alarm, event, outage, and notification UIs.
  • Jane worked on refactoring some of the linkd model objects used in the ReST API.
  • Christian fixed an issue in handling weird characters in usernames.
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Dustin Frisch
  • Jane Hou
  • Jesse White
  • Marcel Fuhrmann
  • Patrick Schweizer
  • Stefan Wachter

Release Roadmap

March Releases

The next OpenNMS release day is March 2nd, 2021.

Currently we expect new releases for all supported Horizon and Meridian (2018, 2019, 2020) releases.

We had been planning on releasing current develop as Horizon 28 tomorrow, but since the biggest new change is the work done to pull OpenBMP's functionality into the core of the project, we have decided that it will be released as 27.1.0 instead.
This is mere semantics, and everything that was going to be in Horizon 28 will instead be in the 27.1 release.

Next Horizon: 28 (Q? 2021)

The next major Horizon release will be Horizon 28.

Horizon 28 will still be coming down the pipeline soon.
Currently, we expect it to contain a move to building with JDK 11 (and, consequently, a requirement to only run on JDK 11 or higher), plus we have some other improvements in the pipeline.

Next Meridian: 2021 (Q2 2021)

Meridian 2021 is on track for a release in 2nd quarter of 2021. It is expected to be based on the Horizon 27.1 codebase, which means it will contain all of the bug fixes and new features introduced in Horizon 26 and 27.

Disclaimer

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.

- Ben

Resolved Issues Since Last OOH

  • NMS-12739: REST API allows to import a requistion from XML with same services
  • NMS-12965: Enhance Routes with RPKI info
  • NMS-13125: XSS in user management
  • NMS-13137: No option provided to change the number of records per page in Events ILP and Events/Alarms ILP under Topology
  • NMS-13144: Response time Graphs shows empty data for all nodes listed with ICMP 100%
  • NMS-13151: Polling package shows up twice, one with irrelevant data 'cassandra-via-jmx'
  • NMS-13156: Newts Cache priming flag is inverted
  • NMS-13168: Move some model objects from opennms-webapp to opennms-web-api
  • NMS-13170: create a table to show related events in the alarm detail view

by RangerRick at March 01, 2021 07:43 PM

February 25, 2021

OpenNMS Resources

Getting started with OpenNMS can be a little daunting, so I thought I’d group together some of the best places to start.

When OpenNMS began 20+ years ago, the main communication channel was a group of mailing lists. For real time interaction we added an “#opennms” IRC channel on Freenode as well. As new technology came along we eagerly adopted it: hosting forums, creating a FAQ with FAQ-o-matic, building a wiki, writing blogs, etc.

The problem became that we had too many resources. Many weren’t updated and thus might host obsolete information, and it was hard for new users to find what they wanted. So a couple of years ago we decided to focus on just two main places for community information.

We adopted Discourse to serve as our “asynchronous” communication platform. Hosted at opennms.discourse.group the goal is to migrate all of our information that used to reside on sites like FAQs and wikis to be in one place. In as much as our community has a group memory, this is it, and we try to keep the information on this site as up to date as possible. While there is still some information left in places like our wiki, the goal is to move it all to Discourse and thus it is a great place to start.

I also want to call your attention to “OpenNMS on the Horizon (OOH)”. This is a weekly update of everything OpenNMS, and it is a good way to keep up with all the work going on with the platform since a lot of the changes being made aren’t immediately obvious.

While we’ve been happy with Discourse, sometimes you just want to interact with someone in real time. For that we created chat.opennms.com. This is an instance of Mattermost that we host to provide a Slack-like experience for our community. It basically replaces the IRC channel, but there is also a bridge between IRC and MM so that posts are shared between the two. I am “sortova” on Mattermost.

When you create an account on our Mattermost instance you will be added to a channel called “Town Square”. Every Mattermost instance has to have a default channel, and this is ours. Note that we use Town Square as a social channel. People will post things that may be of interest to anyone with an interest in OpenNMS, usually something humorous. As I write this there are over 1300 people who have signed up on Town Square.

For OpenNMS questions you will want to join the channel “OpenNMS Discussion”. This is the main place to interact with our community, and as long as you ask smart questions you are likely to get help with any OpenNMS issues you are facing. The second most popular channel is “OpenNMS Development” for those interested in working with the code directly. The Minion and Compass applications also have their own channels.

Another channel is “Write the Docs”. Many years ago we decided to make documentation a key part of OpenNMS development. While I have never read any software documentation that couldn’t be improved, I am pretty proud of the work the documentation team has put into ours. Which brings me to yet another source of OpenNMS information: the official documentation.

Hosted at docs.opennms.org, our documentation is managed just like our application code. It is written in AsciiDoc and published using Antora. The documentation is versioned just like our Horizon releases, but usually whenever I need to look something up I go directly to the development branch. The admin guide tends to have the most useful information, but there are guides for other aspects of OpenNMS as well.

The one downside of our docs is that they tend to be more reference guides than “how-to” articles. I am hoping to correct that in the future but in the meantime I did create a series of “OpenNMS 101” videos on YouTube.

They mirror some of our in-person training classes, and while they are getting out of date I plan to update them real soon (we are in the process of getting ready for a new release with lots of changes so I don’t want to do them and have to re-do them soon after). Unfortunately YouTube doesn’t allow you to version videos so I’m going to have to figure out how to name them.

Speaking of changes, we document almost everything that changes in OpenNMS in our Jira instance at issues.opennms.org. Every code change that gets submitted should have a corresponding Jira issue, and it is also a place where our users can open bug reports and feature requests. As you might expect, if you need to open a bug report please be as detailed as possible. The first thing we will try to do is recreate it, so having information such as the version of OpenNMS you are running, what operating system you are using and other steps to cause the problem are welcome.

If you would like us to add a feature, you can add a Feature Request, and if you want us to improve an existing feature you can add an Enhancement Request. Note that I think you have to have an account to access some of the public issues on the system. We are working to remove that requirement as we wish to be as transparent as possible, but I don’t think we’ve been able to get it to work just yet. I just attempted to visit a random issue and it did load but it was missing a lot of information that shows up when I go to that link while authenticated, such as the left menu and the Git Integration. You will need an account to open or comment on issues. There is no charge to open an account, of course.

Speaking of git, there is one last resource I need to bring up: the code. We host our code on Github, and we’ve separated out many of our projects to make it easier to manage. The main OpenNMS application is under “opennms” (naturally) but other projects such as our machine learning feature, ALEC, have their own branch.

While it was not my intent to delve into all things git on this post, I did want to point out than in the top level directory of the “opennms” project we have two scripts, makerpm.sh and makedeb.sh that you can use to easily build your own OpenNMS packages. I have a video queued up to go over this in detail, but to build RPMs all you’ll need is a base CentOS/RHEL install, and the packages “git” (of course), “expect”, “rpm-build” and “rsync”. You’ll also need a Java 8 JDK. While we run on Java 11, at the moment we don’t build using it (if you check out the latest OOH you’ll see we are working on it). Then you can run makerpm.sh and watch the magic happen. Note the first build takes a long time because you have to download all of the maven dependencies, but subsequent builds should be faster.

To summarize:

For normal community interaction, start with Discourse and use Mattermost for real time interaction.

For reference, check out our documentation and our YouTube channel.

For code issues, look toward our Jira instance and our Github repository.

OpenNMS is a powerful monitoring platform with a steep learning curve, but we are here to help. Our community is pretty welcoming and hope to see you there soon.

by Tarus at February 25, 2021 07:22 PM

February 24, 2021

Open Source Contributor Agreements

I noticed a recent uptick in activity on Twitter about open source Contributor License Agreements (CLAs), mostly negative.

Twitter Post About CLAs

The above comment is from a friend of mine who has been involved in open source longer than I have, and whose opinions I respect. On this issue, however, I have to disagree.

This is definitely not the first time CLAs have been in the news. The first time I remember even hearing about them concerned MySQL. The MySQL CLA required a contributor to sign over ownership of any contribution to the project, which many thought was fine when they were independent, but started to raise some concerns when they were acquired by Sun and then Oracle. I think this latest resurgence is the result of Elastic deciding to change their license from an open source one to something more “open source adjacent”. This has caused a number of people take exception to this (note: link contains strong language).

As someone who doesn’t write much code, I think deciding to sign a CLA is up to the individual and may change from project to project. What I wanted to share is a story of why we at OpenNMS have a CLA and how we decided on one to adopt, in the hopes of explaining why a CLA can be a positive thing. I don’t think it will help with the frustrations some feel when a project changes the license out from under them, but I’m hoping it will shed some light on our reasons and thought processes.

OpenNMS was started in 1999 and I didn’t get involved until 2001 when I started work at Oculan, the commercial company behind the project. Oculan built a monitoring appliance based on OpenNMS, so while OpenNMS was offered under the GPLv2, the rest of their product had a proprietary license. They were able to do this because they owned 100% of the copyright to OpenNMS. In 2002 Oculan decided to no longer work on the project, and I was able to become the maintainer. Note that this didn’t mean that I “owned” the OpenNMS copyright. Oculan still owned the copyright but due to the terms of the license I (as well as anyone else) was free to make derivative works as long as those works adhered to the license. While the project owned the copyright to all the changes made since I took it over, there was no one copyright holder for the project as a whole.

This is fine, right? It’s open source and so everything is awesome.

Fast forward several years and we became aware of a company, funded by VCs out of Silicon Valley, that was using OpenNMS in violation of the license as a base on which to build a proprietary software application.

I can’t really express how powerless we felt about this. At the time there were, I think, five people working full time on OpenNMS. The other company had millions in VC money while we were adhering to our business model of “spend less than you earn”. We had almost no money for lawyers, and without the involvement of lawyers this wasn’t going to get resolved. One thing you learn is that while those of us in the open source world care a lot about licenses, the world at large does not. And since OpenNMS was backed by a for-profit company, there was no one to help us but ourselves (there are some limited options for license enforcement available to non-profit organizations).

We did decide to retain the services of a law firm, who immediately warned us how much “discovery” could cost. Discovery is the process of obtaining evidence in a possible lawsuit. This is one way a larger firm can fend off the legal challenges of a smaller firm – simply outspend them. It made use pretty anxious.

Once our law firm contacted the other company, the reply was that if they were using OpenNMS code, they were only using the Oculan code and thus we had no standing to bring a copyright lawsuit against them.

Now we knew this wasn’t true, because the main reason we knew this company was using OpenNMS was that a disgruntled previous employee told us about it. They alleged that this company had told their engineers to follow OpenNMS commits and integrate our changes into their product. But since much of the code was still part of the original Oculan code base, it made our job much more difficult.

One option we had was to get with Oculan and jointly pursue a remedy against this company. The problem was that Oculan went out of business in 2004, and it took us awhile to find out that the intellectual property had ended up Raritan. We were able to work with Raritan once we found this out, but by this time the other company also went out of business, pretty much ending the matter.

As part of our deal with Raritan, OpenNMS was able to purchase the copyright to the OpenNMS code once owned by Oculan, granting Raritan an unlimited license to continue to use the parts of the code they had in their products. It wasn’t cheap and involved both myself and my business partner using the equity in our homes to guarantee a loan to cover the purchase, but for the first time in years most of the OpenNMS copyright was held by one organization.

This process made us think long and hard about managing copyright moving forward. While we didn’t have thousands of contributors like some projects, the number of contributors we did have was non-trivial, and we had no CLA in place. The main question was: if we were going to adopt a CLA, what should it look like? I didn’t like the idea of asking for complete ownership of contributions, as OpenNMS is a platform and while someone might want to contribute, say, a monitor to OpenNMS, they shouldn’t be prevented from contributing a similar monitor to Icinga or Zabbix.

So we asked our our community, and a person named DJ Gregor suggested we adopt the Sun (now Oracle) Contributor Agreement. This agreement introduced the idea of “dual copyright”. Basically, the contributor keeps ownership of their work but grants copyright to the project as well. This was a pretty new idea at the time but seems to be common now. If you look at CLAs for, say, Microsoft and even Elastic, you’ll see similar language, although it is more likely worded as a “copyright grant” or something other than “dual copyright”.

This idea was favorable to our community, so we adopted it as the “OpenNMS Contributor Agreement” (OCA). Now the hard work began. While most of our active contributors were able to sign the OCA, what about the inactive ones? With a project as old as OpenNMS there are a number of people who had been involved in the project but due to either other interests or changing priorities they were no longer active. I remember going through all the contributions in our code base and systematically hunting down every contributor, no matter how small, and asking them to sign the OCA. They all did, which was nice, but it wasn’t an easy task. I can remember the e-mail of one contributor bounced and I finally hunted them down in Ireland via LinkedIn.

Now a lot of the focus of CLAs is around code ownership, but there is a second, often more important part. Most CLAs ask the contributor to affirm that they actually own the changes they are contributing. This may seem trivial, but I think it is important. Sure, a contributor can lie and if it turns out they contributed something they really didn’t own the project is still responsible for dealing with that code, but there are a number of studies that have shown that simply reminding someone about a moral obligation goes a long way to reinforce ethical behavior. When someone decides to sign a CLA with such a clause it will at least make them think about it and reaffirm that their work is their own. If a project doesn’t want to ask for a copyright assignment or grant, they should at least ask for something like this.

While the initial process was pretty manual, currently managing the OCAs is pretty automated. When someone makes a pull request on our Github project, it will check to see if they have signed the OCA and if not, send them to the agreement.

The fact that the copyright was under one organization came in handy when we changed the license. One of my favorite business models for open source software is paid hosting, and I often refer to WordPress as an example. WordPress is dead simple to install, but it does require that you have your own server, understand setting up a database, etc. If you don’t want to do that, you can pay WordPress a fee and they’ll host the product for you. It’s a way to stay pure open source yet generate revenue.

But what happens if you work on an open source project and a much bigger, much better funded company just takes your project and hosts it? I believe one of the issues facing Elastic was that Amazon was monetizing their work and they didn’t like it. Open source software is governed mainly by copyright law and if you don’t distribute a “copy” then copyright doesn’t apply. Many lawyers would claim that if I give you access to open source software via a website or an API then I’m not giving you a copy.

We dealt with this at OpenNMS, and as usual we asked our community for advice. Once again I think it was DJ who suggested we change our license to the Affero GPL (AGPLv3) which specifically extends the requirement to offer access to the code even if you only offer it as a hosted service. We were able to make this change easily because the copyright was held by one entity. Can you imagine if we had to track down every contributor over 15+ years? What if a contributor dies? Does a project have to deal with their estate or do they have to remove the contribution? It’s not easy. If there is no copyright assignment, a CLA should at least include detailed contact information in case the contributor needs to be reached in the future.

Finally, remember that open source is open source. Don’t like the AGPLv3? Well you are free to fork the last OpenNMS GPLv2 release and improve it from there. Don’t like what Elastic did with their license? Feel free to fork it.

You might have detected a theme here. We relied heavily on our community in making these decisions. The OpenNMS Group, as stewards of the OpenNMS Project, takes seriously the responsibilities to preserve the open source nature of OpenNMS, and I like to think that has earned us some trust. Having a CLA in place addresses some real business needs, and while I can understand people feeling betrayed at the actions of some companies, ultimately the choice is yours as to whether or not the benefits of being involved in a particular project outweigh the requirement to sign a contributor agreement.

by Tarus at February 24, 2021 04:41 PM

February 23, 2021

The Server Room Show Podcast

A couple of weeks ago I had the pleasure to chat with Viktor Madarasz on “The Server Room Show” podcast.

The Server Room Podcast Graphic

Viktor is an IT professional with a strong interest in open source, and we had a fun and meandering conversation covering a number of topics. As usual, I talked to much so he ended up splitting our conversation across two episodes.

You can visit his website for links to the podcast from a large variety of podcast sources, or you can listen on Youtube to part one and part two.

It was fun, and I hope to be able to chat again sometime in the future.

Note: Viktor is originally from Hungary, as was my grandfather. I tried to make getting some Túró Rudi part of my appearing on the show, but unfortunately we haven’t figured out how to get it outside of Hungary, and we all know that I’d talk about open source for free pretty much any time and any place.

by Tarus at February 23, 2021 04:05 PM

February 22, 2021

OpenNMS On the Horizon – JDK11, Configuration, BMP, UI/UX, Documentation

In the last week we did more bugfixing, continued to work on JDK11-based builds, a new config API, in-core BMP support, build infrastructure updates, UI/UX cleanups, and tons of documentation tweaks.

Github Project Updates

Internals, APIs, and Documentation
  • Jesse did more work on getting everything building reliably on JDK11
  • Patrick and Jesse did more work on a new unified configuration API
  • Chandra did more work on a core BMP implementation
  • Bonnie worked on some cleanup of obsolete remote poller references in documentation, plus some other Kafka, datacollection, and event translator updates
  • Ronny worked on updating our Debian build images to Buster
  • Christian added some smoke tests for daemon reloads
  • Ronny added some deployment diagrams for documentation
  • Dustin fixed a bug in Newts cache priming
Web, ReST, UI, and Helm
  • Christian added support for searching nodes that match CDP/LLDP links
  • I fixed a bug where node/interface/service availability timelines didn't scale properly (and didn't re-scale when window size changes)
  • Jane worked on a bug in handling requisitions with duplicate services
  • Jane worked on some other UI and UX bugs
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Dustin Frisch
  • Jane Hou
  • Jesse White
  • Patrick Schweizer
  • Ronny Trommer

Release Roadmap

March Releases

The next OpenNMS release day is March 2nd, 2021.

Currently we expect new releases for all supported Horizon and Meridian (2018, 2019, 2020) releases.

Next Horizon: 28 (Q1 2021)

The next major Horizon release will be Horizon 28.
It is currently expected to be released during the March release cycle.

It will primarily contain enhancements to flow processing to handle ToS/QoS (DSCP) aggregation, as well as a refactor of our BGP Monitoring Protocol support to bring it in-core, rather than relying on an external OpenBMP instance.

Next Meridian: 2021 (Q2 2021)

With the recent release of Meridian 2020, plans are still tentative.
However, the current plan is that Meridian 2021 will be based on Horizon 28.

We'll know more once development plans start to firm up.

Disclaimer

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.

- Ben

Resolved Issues Since Last OOH

  • NMS-12606: Rename button on Threshold Groups screen
  • NMS-12834: Broken provisiond policy does not appear in the logs
  • NMS-12879: Remote poller: review all documentation to update RP references
  • NMS-13107: Add SNMP Data Collection example to Horizon Docs
  • NMS-13117: Create smoke test that verifies all Reload daemon are successful
  • NMS-13129: Searching node link informations
  • NMS-13135: add service status to rest /info API
  • NMS-13136: Update Kafka settings for multiple instances documentation
  • NMS-13148: The OpenNMS Web User Interface Has Experienced an Error observed when searching for a Event under Event notifications
  • NMS-13153: Node's sub-option 'Availability' exceeds table alignment and overlaps next table of 'Notifications' under Topology section
  • NMS-13161: Dependabot: Upgrade Apache POI to 3.17 (CVE-2017-12626)

by RangerRick at February 22, 2021 05:48 PM

Thoughts on Security and Open Source Software

Due to the recent supply-chain attack on Solarwinds products, I wanted to put down a few thoughts on the role of open source software and security. It is kind of a rambling post and I’ll probably lose all three of my readers by the end, but I found it interesting to think about how we got here in the first place.

I got my first computer, a TRS-80, as a Christmas present in 1978 from my parents.

Tarus and his TRS-80

As far as I know, these are the only known pictures of it, lifted from my high school yearbook.

Now, I know what you are thinking: Dude, looking that good how did you find the time off your social calendar to play with computers? Listen, if you love something, you make the time.

(grin)

Unlike today, I pretty much knew about all of the software that ran on that system. This was before “open source” (and before a lot of things) but since the most common programming language was BASIC, the main way to get software was to type in the program listing from a magazine or book. Thus it was “source available” at least, and that’s how I learned to type as well as being introduced to the “syntax error”. That cassette deck in the picture was the original way to store and retrieve programs, but if you were willing to spend about the same amount as the computer cost you could buy an external floppy drive. The very first program I bought on a floppy was from this little company called Microsoft, and it was their version of the Colossal Cave Adventure. Being Microsoft it came on a specially formatted floppy that tried to prevent access to the code or the ability to copy it.

And that was pretty much the way of the future, with huge fortunes being built on proprietary software. But still, for the most part you were aware of what was running on your particular system. You could trust the software that ran on your system as much as your could trust the company providing it.

Then along comes the Internet, the World Wide Web and browsers. At first, browsers didn’t do much dynamically. They would reach out and return static content, but then people started to want more from their browsing experience and along came Java applets, Flash and JavaScript. Now when you visit a website it can be hard to tell if you are getting tonight’s television listings or unknowingly mining Bitcoin. You are no longer in charge of the software that you run on your computer, and that can make it hard to make judgements about security.

I run a number of browsers on my computer but my default is Firefox. Firefox has a cool plugin called NoScript (and there are probably similar solutions for other browsers). NoScript is an extension that lets the user choose what JavaScript code is executed by the browser when visiting a page. A word of warning: the moment you install NoScript, you will break the Internet until you allow at least some JavaScript to run. It is rare to visit a site without JavaScript, and with NoScript I can audit what gets executed. I especially like this for visiting sensitive sites like banks or my health insurance provider.

Speaking of which, I just filed a grievance with Anthem. We recently switched health insurance companies and I noticed that when I go to the login page they are sending information to companies like Google, Microsoft (bing.com) and Facebook. Why?

Blocked JavaScript on the Anthem Website

I pretty much know the reason. Anthem didn’t build their own website, they probably hired a marketing company to do it, or at least part of it, and that’s just the way things are done, now. You send information to those sites in order to get analytics on who is visiting your site, and while I’m fine with it when I’m thinking about buying a car, I am not okay with it coming from my insurance company or my bank. There are certain laws governing such privacy, with more coming every day, and there are consequences for violating it. They are supposed to get back to me in 30 days to let me know what they are sending, and if it is personal information, even if it is just an IP Address, it could be a violation.

I bring this up in part to complain but mainly to illustrate how hard it is to be “secure” with modern software. You would think you could trust a well known insurance company to know better, but it looks like you can’t.

Which brings us back to Solarwinds.

Full disclosure: I am heavily involved in the open source network monitoring platform OpenNMS. While we don’t compete head to head with Solarwinds products (our platform is designed for people with at least a moderate amount of skill with using enterprise software while Solarwinds is more “pointy-clicky”) we have had a number of former Solarwinds users switch to our solution so we can be considered competitors in that fashion. I don’t believe we have ever lost a deal to Solarwinds, at least one in which our sales team was involved.

Now, I wouldn’t wish what happened to Solarwinds on my worst enemy, especially since the exploit impacted a large number of US Government sites and that does affect me personally. But I have to point out the irony of a company known for criticizing open source software, specifically on security, to let this happen to their product. Take this post from on of their forums. While I wasn’t able to find out if the author worked at Solarwinds or not, they compare open source to “eating from a dirty fork”.

Seriously.

But is open source really more secure? Yes, but in order to explain that I have to talk about types of security issues.

Security issues can be divided into “unintentional”, i.e. bugs, and “intentional”, someone actively trying to manipulate the software. While all software but the most simple suffers from bugs, what happened to the Solarwinds supply chain was definitely intentional.

When it comes to unintentional security issues, the main argument against open source is that since the code is available to anyone, a bad actor could exploit a security weakness and no one would know. They don’t have to tell anyone about it. There is some validity to the argument but in my experience security issues in open source code tend to be found by conscientious people who duly report them. Even with OpenNMS we have had our share of issues, and I’d like to talk about two of them.

The first comes from back in 2015, and it involved a Java serialization bug in the Apache commons library. The affected library was in use by a large number of applications, but it turns out OpenNMS was used as a reference to demonstrate the exploit. While there was nothing funny about a remote code execution vulnerability, I did find it amusing that they discovered it with OpenNMS running on Windows. Yes, you can get OpenNMS to run on Windows, but it is definitely not easy so I have to admire them for getting it to work.

I really didn’t admire them for releasing the issue without contacting us first. Sending an email to “security” at “opennms.org” gets seen by a lot of people and we take security extremely seriously. We immediately issued a work around (which was to make sure the firewall blocked the port that allowed the exploit) and implemented the upgraded library when it became available. One reason we didn’t see it previously is that most OpenNMS users tend to run it on Linux and it is just a good security practice to block all but needed ports via the firewall.

The second one is more recent. A researcher found a JEXL vulnerability in Newts, which is a time series database project we maintain. They reached out to us first, and not only did we realize that the issue was present in Newts, it was also present in OpenNMS. The development team rapidly released a fix and we did a full disclosure, giving due credit to the reporter.

In my experience that is the more common case within open source. Someone finds the issue, either through experimentation or by examining the code, they communicate it to the maintainers and it gets fixed. The issue is then communicated to the community at large. I believe that is the main reason open source is more secure than closed source.

With respect to proprietary software, it doesn’t appear that having the code hidden really helps. I was unable to find a comprehensive list of zero-day Windows exploits but there seem to be a lot of them. I don’t mean to imply that Windows is exceptionally buggy but it is a common and huge application and that complexity lends itself to bugs. Also, I’m not sure if the code is truly hidden. I’m certain that someone, somewhere, outside of Microsoft has a copy of at least some of the code. Since that code isn’t freely available, they probably have it for less than noble reasons, and one can not expect any security issues they find to be reported in order to be fixed.

There seems to be this misunderstanding that proprietary code must somehow be “better” than open source code. Trust me, in my day I’ve seen some seriously crappy code sold at high prices under the banner of proprietary enterprise software. I knew of one company that wrote up a bunch of fancy bash scripts (not that there is anything wrong with fancy bash scripts) and then distributed them encrypted. The product shipped with a compiled program that would spawn a shell, decrypt the script, execute it and then kill the shell.

Also, at OpenNMS we rely heavily on unit tests. When a feature is developed the person writing the code also creates code to “test” the feature to make sure it works. When we compile OpenNMS the tests are run to make sure the changes being made didn’t break anything that used to work. Currently we have over 8000 of these tests. I was talking to a person about this who worked for a proprietary software company and he said, “oh, we tried that, but it was too hard.”

Finally, I want to get back to that other type of security issue, the “intentional” one. To my understanding, someone was able to get access to the servers that built and distributed Solarwinds products, and they added in malware that let them compromise target networks when they upgraded their applications. Any way you look at it, it was just sloppy security, but I think the reason it went on for so long undetected is that the whole proprietary process for distributing the software was limited to so few people it was easy to miss. These kind of attacks happen in open source projects, too, they just get caught much faster.

That is the beauty of being able to see the code. You have the choice to build your own packages if you want, and you can examine code changes to your hearts content.

We host OpenNMS at Github. If you check out the code you could run something like:

git tag --list

to see a list of release tags. As I write this the latest released version of Horizon is 26.0.1. To see what changed from 26.0.0 I can run

git log --no-merges opennms-26.0.0-1 opennms-26.0.1-1

If you want, there is even a script to run a “release report” which will give you all of the Jira issues referenced between the two versions:

git-release-report opennms-26.0.0-1 opennms-26.0.1-1

While that doesn’t guarantee the lack of malicious code, it does put the control back into your hands and the hands of many others. If something did manage to slip in, I’m sure we’d catch it long before it got released to our users.

Security is not easy, and as with many hard things the burden is eased the more people who help out. In general open source software is just naturally better at this than proprietary software.

There are only a few people on this planet who have the knowledge to review every line of code on a modern computer and understand it, and that is with the most basic software installed. You have to trust someone and for my peace of mind nothing beats the open source community and the software they create.

by Tarus at February 22, 2021 02:15 PM

February 16, 2021

CVE-2021-3396: Full Security Disclosure

OpenNMS Security Issue Requires Immediate Upgrade

The OpenNMS Group recently learned about and fixed a security vulnerability that allowed local and remote code execution as an authenticated user via a custom, targeted JEXL expression.

Thank you to Artem Smotrakov for notifying us of this issue.

CVE-2021-3396 applies to the following:

  • Meridian-2016.1.0 - Meridian-2016.1.24
  • Meridian-2017.1.0 - Meridian-2017.1.26
  • Meridian-2018.1.0 - Meridian-2018.1.24
  • Meridian-2019.1.0 - Meridian-2019.1.15
  • Meridian-2020.1.0 - Meridian-2020.1.4
  • Horizon 16.0.0 - Horizon 27.0.3
  • Newts: all versions < 1.5.3

OpenNMS Meridian and Horizon users should review the CVE and upgrade to the latest OpenNMS version as soon as possible. Anyone using Meridian 2018, 2019, or 2020 should upgrade to the latest point release for their version. If you are using an earlier version, you should upgrade to the latest 2018, 2019, or 2020.

Impact
CVSS Score: 8.4 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H/E:X/RL:O/RC:C)

  • Code Execution
  • Information Disclosure

Affected components
This security vulnerability can affect the following components:

  • OpenNMS Measurements API (ReST queries and filters)
  • OpenNMS Provisiond (IP address matching)
  • OpenNMS JMX monitor
  • OpenNMS thresholding
  • opennms:stress-events Karaf command (events:stress on older releases)
  • OpenNMS database reports sub-report rendering
  • OpenNMS storage strategies: JEXL index and object name
  • Newts web API

by Jessi at February 16, 2021 09:06 PM

OpenNMS On the Horizon – CVE-2021-3396 JEXL Vulnerability, Nephron, Flows, Config API, JDK11, Docs, CDP/LLDP Search, QoS/ToS in Helm, BMP

In the last week we disclosed a JEXL vulnerability, did more bug fixing, updated Nephron and flow handling, worked on a new configuration API, did more JDK 11 updates, more documentation fixups, CDP/LLDP searching, QoS/ToS improvements, OpenBMP migration, and more.

Github Project Updates

Internals, APIs, and Documentation
  • Newts got a new release with some small changes to JEXL expression handling.
  • Jane did some more fixes to Vacuumd.
  • Chandra backported his SNMPv3 encryption feature to foundation-2020.
  • Stefan made some fixes in Nephron's tests.
  • Patrick continued his work on a more modern API for configuration handling.
  • Jesse did more work on getting OpenNMS building under JDK 11, including working on migrating our old Mina code to Netty.
  • Bonnie did some more work on documentation updates for the Antora transition.
  • Chandra continued his work on migrating our OpenBMP integration to an in-core feature.
  • Christian made some test improvements for daemon reloading.
Web, ReST, UI, and Helm
  • I added support for viewing currently running services in the /info ReST API, as well as displaying them in the web UI sysconfig page.
  • I fixed a bug editing existing scheduled reports where the timezone could revert back to the default (browser) zone.
  • Stefan did more work on QoS/ToS support in Helm.
  • Christian added support for searching nodes by CDP/LLDP info.
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Dustin Frisch
  • Jane Hou
  • Jesse White
  • Matthew Brooks
  • Patrick Schweizer
  • Ronny Trommer
  • Stefan Wachter

CVE-2021-3396: JEXL Security Vulnerability

A potential local and remote code execution vulnerability has been discovered in OpenNMS and Newts relating to JEXL expression handling in a number of subsystems.

If you have not already upgraded to the latest Horizon or Meridian 2018/2019/2020 release, we recommend doing so immediately.

The following subsystems are affected:

  • OpenNMS Measurements API (ReST Queries and Filters)
  • OpenNMS Provisiond (IP address matching)
  • OpenNMS JMX Monitor
  • OpenNMS Thresholding
  • opennms:stress-events Karaf command (events:stress on older releases)
  • OpenNMS Database Reports sub-report rendering
  • OpenNMS Storage strategies: JEXL Index and Object Name
  • Newts web API

The full disclosure is available on our website and has been submitted to the Mitre CVE database at CVE-2021-3396 and should be updating soon. Thanks go to Artem Smotrakov for tipping us off on this JEXL vulnerability.

Off-Schedule Release: Horizon 27.0.5

A bug was found in metadata handling in Provisiond that was introduced in 27.0.4 which could cause re-scans of existing nodes to fail. It was determined to be high-enough impact that we went ahead and made an off-schedule Horizon release.

27.0.5 contained only the fix for the metadata-handling, and a fix for hostname lookups when in the flow API.

Release Roadmap

March Releases

The next OpenNMS release day is March 2nd, 2021.

Currently we expect a new Horizon release.

Next Horizon: 28 (Q1 2021)

The next major Horizon release will be Horizon 28.
It is currently expected to be released during the March release cycle.

It will primarily contain enhancements to flow processing to handle ToS/QoS (DSCP) aggregation, as well as a refactor of our BGP Monitoring Protocol support to bring it in-core, rather than relying on an external OpenBMP instance.

Next Meridian: 2021 (Q2 2021)

With the recent release of Meridian 2020, plans are still tentative.
However, the current plan is that Meridian 2021 will be based on Horizon 28.

We'll know more once development plans start to firm up.

Disclaimer

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.

- Ben

Resolved Issues Since Last OOH

  • HELM-264: Selected time range is not considered when determining some variable options
  • NMS-12884: Vacuumd throws NullPointer Exception on startup
  • NMS-12953: Get dashboards from OpenBMP working
  • NMS-13064: Timezone and Grafana Dashboard fields not preserved when editing a scheduled report
  • NMS-13098: Fix NPE in Vaccumd
  • NMS-13109: Vmware-importer requisition meta-data lost at import
  • NMS-13118: unable to add node/interface meta-data through requisition ui
  • NMS-13128: Provisioning stopped working after upgrade to 27.0.4

by RangerRick at February 16, 2021 03:00 PM

February 10, 2021

CVE-2021-3396: OpenNMS Security Vulnerability (Please Update)

We recently learned about a security issue with OpenNMS. Please refer to CVE-2021-3396 for more information.

To protect everyone using OpenNMS from an exploitation of this vulnerability, the CVE will not provide full details of the vulnerability until Tuesday, February 16, 2021. This should provide time to upgrade your system before full public disclosure.

This issue affects Horizon 16.0.0–Horizon 27.0.3 and all supported Meridian versions:

  • Meridian-2016.1.0–Meridian-2016.1.24
  • Meridian-2017.1.0–Meridian-2017.1.26
  • Meridian-2018.1.0–Meridian-2018.1.24
  • Meridian-2019.1.0–Meridian-2019.1.15
  • Meridian-2020.1.0–Meridian-2020.1.4

We recommend that you make the time to upgrade to the latest version of Horizon or Meridian as soon as possible. These versions fix the issue.

Anyone using Meridian 2018, 2019, or 2020 should upgrade to the latest point release. If you are using an earlier version, you should upgrade to 2018, 2019, or 2020.

by Jessi at February 10, 2021 04:25 PM

February 08, 2021

OpenNMS On the Horizon – Flows, QoS/ToS, JMX, Telemetryd, Vacuumd, Minion, Confd, OpenBMP, Prometheus, Metadata, UI

In the last week we worked on flow improvements including QoS/ToS aggregation, the JMX monitor, Telemetryd and Vacuumd bugs, Minion confd, OpenBMP, JMX Prometheus publishing, JEXL, config managment, node metadata import, and UI fixes.

Github Project Updates

Internals, APIs, and Documentation
  • Stefan continued his work on QoS/ToS aggregate flow support in OpenNMS (and Helm)
  • I fixed an issue with the JMX Monitor and string comparisons in JEXL test code
  • Chandra fixed an issue with reloading Telemetryd
  • Jane fixed an NPE in Vacuumd
  • Dustin did some work on flow sequence tracking
  • Chandra fixed an issue with the default Minion confd flow configuration
  • Chandra continued his work on the OpenBMP migration
  • Ronny did some more work on pushing JMX metrics to Prometheus
  • Christian did more work on cleaning up some JEXL implementation stuff
  • Patrick continued to work on speccing out a new configuration management API
  • Christian did some work on a bug in importing node metadata
Web, ReST, UI, and Helm
  • I did more work on fixing an issue editing scheduled Grafana reports
  • Jane worked on some UI quick fixes and cleanups
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Chandra Gorantla
  • Christian Pape
  • Dustin Frisch
  • Jane Hou
  • Jesse White
  • Matthew Brooks
  • Patrick Schweizer
  • Ronny Trommer
  • Stefan Wachter

February Releases: Horizon 27, and Meridians 2018 through 2020

For February we released point updates to all OpenNMS versions under active support.

Horizon 27.0.4

Release 27.0.4 contains a number of bug fixes relating to WMI, the Minion, flows, reports, JEXL processing, and more, as well as a few small enhancements.

The codename for 27.0.4 is Towel.

For a high-level overview of what has changed in Horizon 27, see What’s New in OpenNMS Horizon 27.

For a complete list of changes in 27.0.4, see the detailed release notes.

Meridians 2018.1.25, 2019.1.16, and 2020.1.5

Meridian 2020.1.5 had a few bug fixes including a timezone fix for Grafana reports and an SFlow fix. Meridians 2019 and 2018 had smaller releases with just a couple of bug fixes.

For a list of changes, see the release notes:

Release Roadmap

March Releases

The next OpenNMS release day is March 2nd, 2021.

Currently we expect a new Horizon release.

Next Horizon: 28 (Q1 2021)

The next major Horizon release will be Horizon 28.
It is currently expected to be released during the March release cycle.

It will primarily contain enhancements to flow processing to handle ToS/QoS (DSCP) aggregation, as well as a refactor of our BGP Monitoring Protocol support to bring it in-core, rather than relying on an external OpenBMP instance.

Next Meridian: 2021 (Q2 2021)

With the recent release of Meridian 2020, plans are still tentative.
However, the current plan is that Meridian 2021 will be based on Horizon 28.

We'll know more once development plans start to firm up.

Disclaimer

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.

- Ben

Resolved Issues Since Last OOH

  • NMS-8184: Notification link in Admin menu goes to start page
  • NMS-8770: Change password does not go to Change password page
  • NMS-8854: Cloning of Foreign Source Definition
  • NMS-8977: Wrong label in event search menu
  • NMS-9139: Footer in Alarm view is broken
  • NMS-9308: Clarify clone detectors and policies
  • NMS-12517: Searching for event context that contains single quotes is not possible
  • NMS-12963: Enhance Routes with ASN info
  • NMS-12964: Enhance Routes with WhoIs info
  • NMS-13061: Move Stats handling to TimeScaleDB
  • NMS-13070: Timezone and date range inconsistencies when scheduling database reports associated with Grafana dashboards.
  • NMS-13103: JEXL expression handling updates
  • NMS-13106: Make sequence number trackin thread-save and patient about out-of-order
  • NMS-13112: Telemetryd: Reload daemon always fails and stops Temetryd
  • NMS-13115: Nephron: Replace JacksonJsonCoder for FlowSummaries
  • NMS-13116: Nephron: fix rounding errors in flow sampling
  • ORG-74: Smartmon Blog

by RangerRick at February 08, 2021 09:14 PM

February 03, 2021

February 2021 Releases – Horizon 27.0.4, Meridians 2018.1.25, 2019.1.16, and 2020.1.5

For February we released point updates to all OpenNMS versions under active support.

Horizon 27.0.4

Release 27.0.4 contains a number of bug fixes relating to WMI, the Minion, flows, reports, JEXL processing, and more, as well as a few small enhancements.

The codename for 27.0.4 is Towel.

For a high-level overview of what has changed in Horizon 27, see What’s New in OpenNMS Horizon 27.

For a complete list of changes in 27.0.4, see the detailed release notes.

Meridians 2018.1.25, 2019.1.16, and 2020.1.5

Meridian 2020.1.5 had a few bug fixes including a timezone fix for Grafana reports and an SFlow fix. Meridians 2019 and 2018 had smaller releases with just a couple of bug fixes.

For a list of changes, see the release notes:

by RangerRick at February 03, 2021 07:14 PM

February 01, 2021

OpenNMS On the Horizon – Flows, ToS/QoS, OpenBMP, JDK 11, Minion, Prometheus

In the last week we did more work on flow aggregation (including ToS and QoS), continued to work on the OpenBMP migration, JDK 11 builds, JEXL cleanups, time zone handling, Minion metrics in Prometheus, and more.

Github Project Updates

Internals, APIs, and Documentation
  • Dustin wrapped up his work on clock skew detection in flow processing
  • Chandra continued his work on moving OpenBMP to the OpenNMS core
  • Chandra updated the develop branch (future Horizon 28) to enable single-topic Kafka RPC by default
  • Jesse worked on integration test updates related to the JDK11 transition
  • Bonnie did some more work on the new Antora-based documentation
  • Christian and Jesse did some work on cleaning up our JEXL handling
  • Stefan continued his work on QoS/ToS support in flow aggregation
  • Ronny added support for exporting some Minion metrics to Prometheus
  • I fixed an issue with timezone handling in the Grafana report backend
Web, ReST, UI, and Helm
  • I did more work on fixing up topology map tests.
  • Christian worked on fixing event search to allow events with single quotes in them
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Dustin Frisch
  • Jesse White
  • Matthew Brooks
  • Ronny Trommer
  • Stefan Wachter

Release Roadmap

February Releases

The next OpenNMS release day is February 2nd, 2021.

Currently we expect a point release for Horizon and all active Meridians.

Next Horizon: 28 (March 2021)

The next major Horizon release will be Horizon 28.
It is currently expected to be released during the March release cycle.

It will primarily contain enhancements to flow processing to handle ToS/QoS (DSCP) aggregation, as well as a refactor of our BGP Monitoring Protocol support to bring it in-core, rather than relying on an external OpenBMP instance.

Next Meridian: 2021 (Q2 2021)

With the recent release of Meridian 2020, plans are still tentative.
However, the current plan is that Meridian 2021 will be based on Horizon 28.

We'll know more once development plans start to firm up.

Disclaimer

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.

- Ben

Resolved Issues Since Last OOH

  • NMS-12967: Discrepancy between Flows "top N" and SNMP for same interface
  • NMS-13104: Enable Single topic by default for Kafka RPC

by RangerRick at February 01, 2021 02:50 PM

January 25, 2021

OpenNMS On the Horizon – JDK11, OpenBMP, ToS/QoS, Flows, Documentation

In the last week we continued our work on JDK11 migration, moving OpenBMP functionality into OpenNMS, ToS/QoS flow aggregation, Antora documentation, a new configuration API/implementation, and plenty of bug fixes.

Github Project Updates

Internals, APIs, and Documentation
  • Jesse continued to work on JDK11 builds.
  • Dustin and Stefan did some more fixes to hostname resolution in flow aggregation.
  • Chandra worked on some a fix for some Karaf poller commands not working when Telemetryd is disabled.
  • Stefan continued his work on ToS/QoS flow aggregation.
  • Christian fixed a bug where a dbonly provisiond scan would not preserve node metadata.
  • Patrick and Jerry did more work on a prototype configuration system using Vacuumd.
  • Chandra continued his work on the OpenBMP core migration.
  • Matt made some fixes to the flow parser schema.
  • Bonnie did some wrapup work on the Antora documentation migration.
  • Christian made some improvements to his fix for running the WMI collector on Minion.
  • Ronny filled in some of the missing descriptions in the new Minion config schema definition.
  • Jesse worked on bumping our embedded Karaf to 4.2.10.
Web, ReST, UI, and Helm
  • I worked on more fixes to time zone handling in the schedule report UI.
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Dustin Frisch
  • Jerry Beuree
  • Jesse White
  • Matthew Brooks
  • Patrick Schweizer
  • Ronny Trommer
  • Stefan Wachter

Release Roadmap

February Releases

The next OpenNMS release day is February 2nd, 2021.

Currently we expect a Horizon 27 point release.

Next Horizon: 28 (March 2021)

The next major Horizon release will be Horizon 28.
It is currently expected to be released during the March release cycle.

It will primarily contain enhancements to flow processing to handle ToS/QoS (DSCP) aggregation, as well as a refactor of our BGP Monitoring Protocol support to bring it in-core, rather than relying on an external OpenBMP instance.

Next Meridian: 2021 (Q2 2021)

With the recent release of Meridian 2020, plans are still tentative.
However, the current plan is that Meridian 2021 will be based on Horizon 28.

We'll know more once development plans start to firm up.

Disclaimer

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.

- Ben

Resolved Issues Since Last OOH

  • NMS-12944: WmiCollector does not work on Minion
  • NMS-13083: Update opennms.spec to take advantage of maven smart builder plugin
  • NMS-13094: Karaf Poller commands won't work if Telemetryd is disabled

by RangerRick at January 25, 2021 10:21 PM

January 19, 2021

OpenNMS On the Horizon – Flows, JDK 11, Kafka, Antora, VMware, OpenBMP, Vacuumd, JICMP/JRRD, WMI, Minion, Topology

In the last week we did more work on JDK 11 transition, QoS/ToS flow aggregation, Antora documentation, configuration APIs, OpenBMP, and more.

Github Project Updates

Internals, APIs, and Documentation
  • Sean did some more work picking up old projects to improve healthcheck functionality
  • Dustin, Christian, and Stefan continued the work on adding QoS/ToS aggregate processing to flows
  • Ronny worked on updating PRIS to use/support JDK 11
  • Sean continued to work on updating our Kafka component dependencies
  • Bonnie finished the first pass at moving OpenNMS documentation to Antora
  • Christian fixed an issue with running the VMware config builder script in JDK 11
  • Chandra worked on stat aggregations in the OpenBMP migration
  • Patrick and Jerry worked on configuration handling for Vacuumd
  • Zoë added support for silencing some log warnings in the case of purposefully-unused JICMP/JRRD native code
  • Dino fixed a silly bug in sflow hostname enrichment
  • Dustin did more hostname-resolution optimizations for Elasticsearch flow aggregation
  • Dustin updated flow processing to more gracefully handle invalid flows
  • Christian updated the WMI collector to work on Minion
  • Jesse continued the work on getting OpenNMS to build and run tests on JDK 11
Web, ReST, UI, and Helm
  • I did more work on fixing smoke tests for the topology UI application provider
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Dino Yancey
  • Dustin Frisch
  • Jerry Beuree
  • Jesse White
  • Patrick Schweizer
  • Ronny Trommer
  • Sean Torres
  • Stefan Wachter
  • Zoë Knox

Release Roadmap

February Releases

The next OpenNMS release day is February 2nd, 2021.

Currently we expect a Horizon 27 point release.

Next Horizon: 28 (Q1 2021)

The next major Horizon release will be Horizon 28.

We're still in the development cycle for it, but at a high level it is expected to contained our finished work moving OpenBMP's functionality into OpenNMS, as well as enhancements to handle ToS/QoS in flows.

Next Meridian: 2021 (Q2 2021)

With the recent release of Meridian 2020, plans are still tentative.
However, the current plan is that Meridian 2021 will be based on Horizon 28.

We'll know more once development plans start to firm up.

Disclaimer

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.

- Ben

Resolved Issues Since Last OOH

  • NMS-12704: Upgrade Kafka components to 2.7.0
  • NMS-12990: requisition meta data are deleted if node meta data defined with "db only" synchronize
  • NMS-13065: Flow Rest API: Name lookup is happening per bucket and not per interval (Aggregation Only)
  • NMS-13081: Optionally silence file not found warnings for JICMP, JRRD when properties are not set
  • NMS-13082: Exception messages during node import (log noise)
  • NMS-13088: Keep and adjust flows with negative duration
  • NMS-13093: SFlow enhancment is not functional
  • PRIS-154: PRIS is not working with JDK greater version 8

by RangerRick at January 19, 2021 05:16 PM

January 11, 2021

OpenNMS On the Horizon – Kafka, OpenBMP, Haveged, Documentation, CircleCI, SNMP, ToS/QoS, PRIS

In the last week we worked on the OpenBMP migration, documentation, builds, ToS aggregate flow support, moving to JDK 11, and more.

Github Project Updates

Internals, APIs, and Documentation
  • Sean did some more work on updating our Kafka components to a newer release
  • Chandra continued his work on moving our OpenBMP integration to core code
  • I updated our packaging to soft-depend on haveged for better SSL performance
  • Bonnie did more work on the migration of docs to Antora
  • Ronny worked on updating our CircleCI build images to a newer JDK (and OS updates)
  • Zoë updated the snmpifdescr column to be arbitrarily-sized
  • Stefan did more work on ToS/QoS support
  • Ronny updated PRIS to build with JDK 11

Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Ronny Trommer
  • Sean Torres
  • Stefan Wachter
  • Zoë Knox

January Horizon and Meridian Releases

In January we released point updates for Horizon 27 and Meridians 2019 and 2020.

Horizon 27.0.3

Horizon 27.0.3 is a minor release with a number of mostly esoteric bug fixes, and a few small enhancements.

The codename for 27.0.3 is Dolphins.

For a complete list of changes in 27.0.3, see the release notes.

Meridians 2019.1.15 and 2020.1.4

Both Meridian releases had just a few small changes, including a new soft dependency on Haveged.

For a list of changes, see the release notes:

Release Roadmap

February Releases

The next OpenNMS release day is February 2nd, 2021.

Currently we expect a Horizon 27 point release.

Next Horizon: 28 (Q1 2021)

The next major Horizon release will be Horizon 28.

We're still in the development cycle for it, but at a high level it is expected to contained our finished work moving OpenBMP's functionality into OpenNMS, as well as enhancements to handle ToS/QoS in flows.

Next Meridian: 2021 (Q2 2021)

With the recent release of Meridian 2020, plans are still tentative.
However, the current plan is that Meridian 2021 will be based on Horizon 28.

We'll know more once development plans start to firm up.

Disclaimer

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.

- Ben

Resolved Issues Since Last OOH

  • NMS-2013: Added Admin group members to magic-users.properties automatically
  • NMS-12801: Notifications Not Auto-Acking
  • NMS-12976: Increase length of snmpinterfaces.snmpifdescr
  • NMS-13012: Migrate Admin Guide
  • NMS-13067: Inconsistent breadcrumbs on Locations/Minions
  • NMS-13069: The makerpm.sh script requires the mingw32-nsis package
  • NMS-13071: Upgrade Container base images
  • NMS-13079: Make OpenNMS compile on Apple Silicon
  • NMS-13084: Fix vmwareconfigbuilder script to run with JDK9+

by RangerRick at January 11, 2021 07:13 PM

January 05, 2021

January 2021 Releases – Horizon 27.0.3, Meridians 2020.1.4 and 2019.1.15

For January we released point updates to Horizon 27, Meridian 2020, and Meridian 2019.

Horizon 27.0.3

Horizon 27.0.3 is a minor release with a number of mostly esoteric bug fixes, and a few small enhancements.

The codename for 27.0.3 is Dolphins.

For a high-level overview of what has changed in Horizon 27, see What’s New in OpenNMS Horizon 27.

For a complete list of changes in 27.0.3, see the detailed release notes.

Meridians 2019.1.15 and 2020.1.4

Both Meridian releases had just a few small changes, including a new soft dependency on Haveged.
This has been a recommendation of our support crew for quite a while to speed up launch times and SSL processing, but it had not previously been included as an actual dependency in our packages.

Since RPM added support for Recommmends: and Suggests: like Debian packages, we revisited this and added it as an optional dependency.

For a list of changes, see the release notes:

by RangerRick at January 05, 2021 10:31 PM

January 04, 2021

OpenNMS On the Horizon – New Year, New OOH

In the last few weeks we did very little, as The OpenNMS Group is officially on holiday from Christmas to the New Year. However, a few small changes made it in before everyone disappeared for a while.

No matter what you celebrate, I hope y'all had a good holiday while we were radio silent, and have a better 2021 than you did 2020.

Github Project Updates

Internals, APIs, and Documentation
  • Stefan did more work on time-window and aggregation logic in Nephron
  • Ronny worked on some Minion documentation updates
  • Matt continued to work on tweaking his Minion confd improvements
  • Ronny updated a bunch of build environment Docker configs to newer versions (Ubuntu, JDK, etc.)

Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Matthew Brooks
  • Ronny Trommer
  • Stefan Wachter

Release Roadmap

January Releases

The next OpenNMS release day is January 5th, 2020.

The current expectation is that there will be Meridian 2019 and 2020 bug fix releases, as well as a Horizon 27.0.3 release with bug fixes.

Next Horizon: 28 (Q1 2021)

The next major Horizon release will be Horizon 28.

We're still deep in the development cycle for it, but at a high level it is expected to contained our finished work moving OpenBMP's functionality into OpenNMS, as well as enhancements to handle ToS/QoS in flows.

Next Meridian: 2021 (Q2 2021)

With the recent release of Meridian 2020, plans are still tentative.
However, the current plan is that Meridian 2021 will be based on Horizon 28.

We'll know more once development plans start to firm up.

Disclaimer

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.

- Ben

Resolved Issues Since Last OOH

  • NMS-13040: Updating UI to clarify rescan process
  • NMS-13049: Update PostgreSQL JDBC drivers
  • NMS-13055: Karaf command 'snmp-fit' not functional
  • NMS-13060: Long datasource names are truncated and are not accessable on read

by RangerRick at January 04, 2021 03:47 PM

December 21, 2020

OpenNMS On the Horizon – Nephron, Flows, Minion, Packaging, Confd, UI

In the last week we continued to work on bug fixing and improvements related to Nephron and flows, Minion, packaging and configuration, and the web UI.

Also, this is your reminder that The OpenNMS Group shuts down offices from Christmas Eve through the new year. A number of us will probably stay randomly active on chat, but you won't see a new OOH until January.

Whether you celebrate Christmas, or something else, or nothing at all, I hope you have a good holiday season and I'll see you on the other side of 2020!

Github Project Updates

Internals, APIs, and Documentation
  • Chandra fixed an issue in timeouts in a few custom SNMP-related Karaf commands
  • Dustin continued to work on fixing flow timestamp issues
  • Jesse, Christian, and Dustin worked on some test tools for analyzing flow captures
  • Marcel updated the PostgreSQL JDBC driver to handle newer auth protocols
  • Zoë worked on a fix to JRobin handling that could cause failures in special cases
  • Matt created a schema for our confd Minion configuration
  • I added a weak dependency on haveged to our OpenNMS packages
  • Stefan made some date-related fixes to Nephron
Web, ReST, UI, and Helm
  • Stefan continued his work on enhancing the flow deep dive dashboard with QoS/ToS data
  • Chandra and Bonnie made more UI tweaks to the provisioning scan UI
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Dino Yancey
  • Dustin Frisch
  • Jesse White
  • Marcel Fuhrmann
  • Matthew Brooks
  • Stefan Wachter
  • Zoë Knox

Release Roadmap

January Releases

The next OpenNMS release day is January 5th, 2020.

The current expectation is that there will be a Horizon 27.0.3 release with bug fixes.

Next Horizon: 28 (Q1 2021)

The next major Horizon release will be Horizon 28.

We're still early in the development cycle for it, but at a high level it is expected to contained our finished work moving OpenBMP's functionality into OpenNMS, as well as enhancements to handle ToS/QoS in flows.

Next Meridian: 2021 (Q2 2021)

With the recent release of Meridian 2020, plans are still tentative.
However, the current plan is that Meridian 2021 will be based on Horizon 28.

We'll know more once development plans start to firm up.

Disclaimer

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.

- Ben

Resolved Issues Since Last OOH

  • NMS-13040: Updating UI to clarify rescan process
  • NMS-13049: Update PostgreSQL JDBC drivers
  • NMS-13055: Karaf command 'snmp-fit' not functional
  • NMS-13060: Long datasource names are truncated and are not accessable on read

by RangerRick at December 21, 2020 04:52 PM

December 14, 2020

OpenNMS On the Horizon – Elasticsearch, SNMP, CircleCI, Documentation, OpenBMP, Nephron, Minion, Flows, Helm

In the last week we worked on Elasticsearch indexing, malformed SNMP, CircleCI, documentation, OpenBMP migration, Nephron, Minion configuration, flow aggregation, and Helm.

Github Project Updates

Internals, APIs, and Documentation
  • Chandra backported his fix to elasticsearch indexing to foundation-2020
  • Chandra did some additional work on handling malformed SNMP responses
  • I updated some of our CircleCI projects to cache NPM differently
  • Bonnie continued her work on moving our documentation to Antora
  • Chandra continued his work on migrating our BMP support from OpenBMP to in-core
  • Dustin and Christian did more work on expanding our Nephron testing
  • Matt did more work on making Minion confd configuration more robust
  • Stefan has continued his work on supporting ToS/QoS in flow aggregation
Web, ReST, UI, and Helm
  • I fixed a Grafana compatibility issue in Helm flow datasource
  • Stefan worked on adding TypeScript support to Helm's build
  • Stefan added a "host" panel to the flow deep dive dashboard in Helm
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Dustin Frisch
  • Matthew Brooks
  • Stefan Wachter

Release Roadmap

January Releases

The next OpenNMS release day is January 5th, 2020.

The current expectation is that there will be a Horizon 27.0.3 release with bug fixes.

Next Horizon: 28 (Q1 2021)

The next major Horizon release will be Horizon 28.

We're still early in the development cycle for it, but at a high level it is expected to contained our finished work moving OpenBMP's functionality into OpenNMS, as well as enhancements to handle ToS/QoS in flows.

Next Meridian: 2021 (Q2 2021)

With the recent release of Meridian 2020, plans are still tentative.
However, the current plan is that Meridian 2021 will be based on Horizon 28.

We'll know more once development plans start to firm up.

Disclaimer

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 Week…

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.

- Ben

Resolved Issues Since Last OOH

  • HELM-261: The transformation withGroupByInterval from the Flow DS is not working
  • NMS-11043: MailTransportMonitor
  • NMS-12818: ArrayIndexOutOfBoundsException thrown by the SNMP Interface Poller
  • NMS-13001: bad repository settings?
  • NMS-13030: When using a custom prefix, the Elasticsearch Forwarder for events and situation-feedback creates a wrong template.
  • NMS-13042: ArrayIndexOutOfBoundsException thrown by the SNMP Interface Poller

by RangerRick at December 14, 2020 08:29 PM

December 07, 2020

OpenNMS On the Horizon – Bugs, Nephron, OpenBMP, Geohashes, Prometheus, Minion, ToS/QoS

In the last week we released new Meridian and Horizon versions, and worked on a bunch of bugs, Nephron flow processing, moving BMP support in-core, node geohashes, the Prometheus collector, Minion configuration, ToS/QoS aggregation, and much more.

Github Project Updates

Internals, APIs, and Documentation
  • Dustin and Christian continued to work on improvements to Nephron flow processing and clock skew handling
  • Bonnie and Ronny did more work on the migration of the admin guide to Antora
  • Chandra worked on a fix for the elasticsearch forwarder when using custom prefixes
  • Marcel made confd templates for the Mattermost notification strategy
  • Dino fixed an issue with non-integer counters in the Prometheus collector
  • Chandra continued to work on moving our OpenBMP integration to the OpenNMS core
  • Jesse added support for geohashes to the node metadata
  • I fixed a serialization bug I introduced when fixing timezones in Grafana reports
  • Dustin worked on some flink test infrastructure
  • Pierre fixed an issue with custom server certificates in the Minion
  • Dustin made a fix to initializing telemetryd when multiple metrics have the same name
  • Stefan added a CLI option to opennms to start paused waiting for a debugger
  • Chandra worked on an SNMP poller exception bug
Web, ReST, UI, and Helm
  • Stefan worked on updates to the flow ReST API and OpenNMS.js to handle raw ToS queries
  • Patrick continued his work on handling topology map issues with applications
  • Bonnie and Chandra worked on clarifying the Provisioning UI scan prompt
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Dino Yancey
  • Dustin Frisch
  • Jesse White
  • Marcel Fuhrmann
  • Matthew Brooks
  • Patrick Schweizer
  • Pierre Bouffard
  • Ronny Trommer
  • Stefan Wachter

November Releases

In November we released updates to all supported Meridians as well as Horizon 27.

You might have noticed that Horizon 27 and Meridian 2020 jump by 2 releases in this announcement compared to last month. This brings us to the report serialization regression.

Report Serialization Regression

A fix for timezone handling in Grafana reports that went into Horizon 27.0.1 and Meridian 2020.1.2 turned out to trigger a bug in loading existing reports, because of changes to the underlying Java objects that get stored in the database.

The regression was released, so we did an off-schedule release of updated Horizon 27 and Meridian 2020 packages to minimize the impact.

If you created new scheduled reports with Horizon 27.0.1 or Meridian 2020.1.2, you will need to recreate them.

Horizon 27

On Tuesday, we released Horizon 27.0.1, followed by Horizon 27.0.2 yesterday.

  • Horizon 27.0.1 _(Pan-Galactic Gargle Blaster)_ contains a number of bugfixes including a critical CVE fix for Jetty, as well as a few other smaller changes and improvements.
  • Horizon 27.0.2 _(Deep Thought)_ adds to that a fix for the report serialization bug, a fix for JCIFS support, and an update to node metadata to support geohashes.
Meridian 2020

Like Horizon 27, Meridian 2020 had two releases: 2020.1.2 on Tuesday, and 2020.1.3, yesterday.

Meridians 2019.1.14 and 2018.1.24

As is common in maintenance releases, the older Meridians got just a couple of bug fixes -- the Jetty CVE fix, and a fix to RRD file creation in certain cases when provisioning new nodes.

For more details, see the release notes:

Release Roadmap

January Releases

The next OpenNMS release day is January 5th, 2020.

The current expectation is that there will be a Horizon 27.0.3 release with bug fixes.

Next Horizon: 28 (Q1 2021)

The next major Horizon release will be Horizon 28.

We're still early in the development cycle for it, but at a high level it is expected to contained our finished work moving OpenBMP's functionality into OpenNMS, as well as enhancements to handle ToS/QoS in flows.

Next Meridian: 2021 (Q2 2021)

With the recent release of Meridian 2020, plans are still tentative.
However, the current plan is that Meridian 2021 will be based on Horizon 28.

We'll know more once development plans start to firm up.

Disclaimer

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 Week…

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.

- Ben

Resolved Issues Since Last OOH

  • NMS-12700: Add support for custom.system.properties on Sentinel
  • NMS-12949: Persist basic BMP messages in OpenNMS
  • NMS-12952: Handle stats for BMP
  • NMS-12982: Create confd templates to handle Slack properties
  • NMS-12989: Change installation guide to run as non-root user
  • NMS-13004: Create confd templates to handle Mattermost properties
  • NMS-13007: Prometheus Collector attempting to persist non-integer values to counters
  • NMS-13017: When using a custom prefix, the Elasticsearch Forwarder for events and situation-feedback creates a wrong template.
  • NMS-13034: OpenNMS fails to start, when more than one active listener is referencing the same parser
  • NMS-13035: Bouncycastle JAR version 1.67 breaks CIFS Monitor
  • NMS-13036: Add "geohash" support to the meta-data DSL
  • NMS-13037: report timezone changes break reading pre-existing reports from Quartz

by RangerRick at December 07, 2020 05:17 PM

December 04, 2020

November 2020 Releases: Horizon 27.0.2, Meridians 2018.1.24, 2019.1.14, and 2020.1.3

In November we released updates to all supported Meridians as well as Horizon 27.

You might have noticed that Horizon 27 and Meridian 2020 jump by 2 releases in this announcement compared to last month. Read on for details.

Report Serialization Regression

A fix for timezone handling in Grafana reports that went into Horizon 27.0.1 and Meridian 2020.1.2 turned out to trigger a bug in loading existing reports, because of changes to the underlying Java objects that get stored in the database.

The regression was released, so we did an off-schedule release of updated Horizon 27 and Meridian 2020 packages to minimize the impact.

If you created new scheduled reports with Horizon 27.0.1 or Meridian 2020.1.2, you will need to recreate them.

Horizon 27

On Tuesday, we released Horizon 27.0.1, followed by Horizon 27.0.2 yesterday.

Horizon 27.0.1 (Pan-Galactic Gargle Blaster) contains a number of bugfixes including a critical CVE fix for Jetty, as well as a few other smaller changes and improvements.

Horizon 27.0.2 (Deep Thought) adds to that a fix for the report serialization bug, a fix for JCIFS support, and an update to node metadata to support geohashes.

Meridian 2020

Like Horizon 27, Meridian 2020 had two releases: 2020.1.2 on Tuesday, and 2020.1.3, yesterday.

Meridian 2020.1.2 (Skerry) contained many of the same fixes as Horizon 27, most notably the Jetty CVE fix.

Meridian 2020.1.3 (Fjord) is identical to 2020.1.2, but contains the fix for the report serialization bug.

Meridians 2019.1.14 and 2018.1.24

As is common in maintenance releases, the older Meridians got just a couple of bug fixes -- the Jetty CVE fix, and a fix to RRD file creation in certain cases when provisioning new nodes.

For more details, see the release notes:

by RangerRick at December 04, 2020 08:08 PM

November 30, 2020

OpenNMS On the Horizon – Documentation, Elasticsearch, Netflow, Traps, Tests, Topology

In the last week we did more documentation migration, Elasticsearch flow storage and queries, Netflow, traps, tests, and topology maps.

Github Project Updates

Internals, APIs, and Documentation
  • Bonnie continued her work on migrating the admin and installation guides to Antora
  • Chandra worked on a fix to Elasticsearch templates when using prefixes
  • Ronny did more work on updating Minion documentation
  • I worked on documentation for JICMP
  • Christian worked on Netflow v9 updates for flowStartMilliseconds and flowEndMilliseconds
  • Marcel did some work on the Slack notification strategy
  • Chandra fixed a bug that could occur when receiving traps on Minion
  • Dustin did some work on flink test infrastructure
Web, ReST, UI, and Helm
  • Stefan worked on updating the flow Elasticsearch and ReST APIs to support querying raw ToS/QoS
  • Patrick continued his work on fixing up topology map application support
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Dustin Frisch
  • Marcel Fuhrmann
  • Matthew Brooks
  • Patrick Schweizer
  • Ronny Trommer
  • Stefan Wachter

Release Roadmap

November Releases

The next OpenNMS release day is December 1st, 2020.

The current expectation is that there will be updates to Horizon 27.0.1 and Meridians 2018 through 2020.

Next Horizon: 28 (Q1 2021)

The next major Horizon release will be Horizon 28.

We're still early in the development cycle for it, but at a high level it is expected to contained our finished work moving OpenBMP's functionality into OpenNMS, as well as enhancements to handle ToS/QoS in flows.

Next Meridian: 2021 (Q2 2021)

With the recent release of Meridian 2020, plans are still tentative.
However, the current plan is that Meridian 2021 will be based on Horizon 28.

We'll know more once development plans start to firm up.

Disclaimer

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 Week…

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.

- Ben

Resolved Issues Since Last OOH

  • NMS-12733: No support for TLS v1.3 in MailTransportMonitor
  • NMS-13006: flowStartMilliseconds/flowEndMilliseconds for NetFlow v9
  • NMS-13014: Cortex plugin shows only data for counters in a window > 3 hours
  • NMS-13015: Null pointer exception whe minion receives traps
  • NMS-13023: Add clock skew correction mechanism
  • NMS-13024: Check flow sequence numbers to detect missing packets

by RangerRick at November 30, 2020 03:41 PM

November 23, 2020

OpenNMS On the Horizon – Nephron, Provisiond, OpenBMP, sFlow, Netflow, TLS, CIFS, OpenNMS.js, Grafana, Topology

In the last week we did a bunch of work on nephron and flows, fixed a bunch of bugs including provisioning imports and CIFS, fixed timezone support in the Grafana database reports, and more.

Github Project Updates

Internals, APIs, and Documentation
  • Dustin did more work on handling clock skew and other issues in Nephron
  • Ronny did more work on Docker documentation
  • I updated our embedded Jetty to the latest version
  • Bonnie did more work on provisiond and other admin documentation
  • Chandra continued his work on persisting data in the OpenBMP migration
  • Dino fixed an issue with handling ingress/egress with sFlow
  • Christian worked on an issue with DNS hostname enhancement in flows
  • Stefan added support for enabling TLS1.3 on JDKs that support it
  • I fixed an issue with resource leaks in CIFS protocol handling
  • Chandra fixed a provisioning issue with import scanning when new nodes are added
  • Sean made some Nephron updates for Java 11 support
  • David Schlenk made an update to the SNMP interface poller to handle all known ifOperStatus values
  • Christian added flowStartMilliseconds/flowEndMilliseconds support to netflow 9 handling
Web, ReST, UI, and Helm
  • I worked on moving the documentation for OpenNMS.js to Antora
  • I fixed an issue with timezone handling in the report ReST API
  • I updated the Grafana report UI to handle timezones properly
  • Patrick continued his work on fixing Topology Maps and APM
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • David Schlenk
  • Dino Yancey
  • Dustin Frisch
  • Jesse White
  • Patrick Schweizer
  • Ronny Trommer
  • Sean Torres
  • Stefan Wachter

Release Roadmap

November Releases

The next OpenNMS release day is December 1st, 2020.

The current expectation is that there will be updates to Horizon 27.0.1 and Meridians 2018 through 2020.

Next Horizon: 28 (Q1 2021)

The next major Horizon release will be Horizon 28.

We're still early in the development cycle for it, but at a high level it is expected to contained our finished work moving OpenBMP's functionality into OpenNMS, as well as enhancements to handle ToS/QoS in flows.

Next Meridian: 2021 (Q2 2021)

With the recent release of Meridian 2020, plans are still tentative.
However, the current plan is that Meridian 2021 will be based on Horizon 28.

We'll know more once development plans start to firm up.

Disclaimer

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 Week…

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.

- Ben

Resolved Issues Since Last OOH

  • JS-47: Create Antora documentation for OpenNMS.js
  • NMS-12930: Timezone inconsistency when generating PDF reports from Grafana dashboards
  • NMS-12938: TSS: Cortex Plugin: Use REST API for reading timeseries
  • NMS-12955: sFlow Ingress / Egress
  • NMS-12974: RRD files for SNMP data are not created until a Service Restart
  • NMS-12980: Handle all possible values of ifOperStatus in the SNMP Interface Poller
  • NMS-12994: Provisioning introduction
  • NMS-12995: Document Configure Discovery process
  • NMS-12996: Document requisition process
  • NMS-13011: JCifs leaks memory after upgrade

by RangerRick at November 23, 2020 09:25 PM

November 16, 2020

OpenNMS On the Horizon – Nephron, Flows, Docs, VMware, Minion, BMP, Grafana, Topology Maps

In the last week we worked on Nephron and flows, documentation, VMware updates, Minion certificate handling, OpenBMP migration, Grafana reports, and the topology map.

Github Project Updates

Internals, APIs, and Documentation
  • Dustin did more work on fixing flow data handling in Nephron
  • Bonnie worked on documentation updates for BMP and Provisiond
  • Christian worked on some fixups to VMware asset migration
  • Ronnie worked on Docker, Minion, Sentinel, and flow documentation changes
  • Dustin added some instrumentation to the flow receiver and processor
  • Stefan backported his work to support Minion server certificates to Horizon 27
  • Chandra did more work on migrating OpenBMP's functionality into the OpenNMS core
  • Jesse worked on some Nephron changes to provide near-real-time estimates
Web, ReST, UI, and Helm
  • I worked on fixing time zone handling in Grafana database reports
  • Patrick did more work on fixing topology application map alarm handling
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Dustin Frisch
  • Jesse White
  • Patrick Schweizer
  • Ronny Trommer
  • Stefan Wachter

Release Roadmap

November Releases

The next OpenNMS release day is December 1st, 2020.

The current expectation is that there will be updates to Horizon 27.0.2 and Meridian 2020.

Next Horizon: 28 (Q1 2021)

The next major Horizon release will be Horizon 28.

We're still early in the development cycle for it, but at a high level it is expected to contained our finished work moving OpenBMP's functionality into OpenNMS, as well as enhancements to handle ToS/QoS in flows.

Next Meridian: 2021 (Q2 2021)

With the recent release of Meridian 2020, plans are still tentative.
However, the current plan is that Meridian 2021 will be based on Horizon 28.

We'll know more once development plans start to firm up.

Disclaimer

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 Week…

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.

- Ben

Resolved Issues Since Last OOH

  • NMS-12928: Text for start page
  • NMS-12985: Upgrade script does not migrate VMware metadata
  • NMS-12998: Unable to enable Jaeger tracing in Sentinel
  • NMS-13000: backport Minion certificate management to Horizon 27
  • NMS-13002: Update typo in BMP docs

by RangerRick at November 16, 2020 07:14 PM

November 09, 2020

OpenNMS On the Horizon – Horizon 27, Documentation, OpenConfig gNMI, CircleCI, Nephron

In the last week we released Horizon 27, did more documentation migration work, finished up the OpenConfig gNMI merge, fixed some Horizon 27 bugs (🙃), made some CircleCI improvements, and worked on Nephron performance.

Github Project Updates

Internals, APIs, and Documentation
  • Bonnie and Ronny did more work on migrating our documentation infrastructure to Antora
  • Chandra wrapped up merging his branch to support gNMI OpenConfig
  • I did some work on trying to speed up the tarball assembly portion of the CircleCI build
  • Christian made some fixes to the recent VMware asset changes
  • Sean and Dustin did some work on stabilizing Nephron under heavy load

Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Ronny Trommer
  • Sean Torres

November Releases - Meridian 2019, Meridian 2020, Horizon 27

November saw bugfix releases from Meridians 2019 and 2020, but most notably saw the (soft) launch of Horizon 27.

Horizon 27 includes a ton of fixes and improvements, but the largest change is the removal of the Remote Poller in favor of a new Minion-based polling mechanism we're calling Application Perspective Monitoring.

Please note that it also includes some changes to VMware metadata handling that we found issues in after releasing. If you use the VMware integration, please hold off on upgrading until 27.0.1 comes out (as soon as we've confirmed the fixes).

Release Roadmap

November Releases

The next OpenNMS release day is December 1st, 2020.

The current expectation is that there will be updates to Horizon 27.0.2 and Meridian 2020.

Next Horizon: 28 (Q1 2021)

The next major Horizon release will be Horizon 28.

We're still early in the development cycle for it, but at a high level it is expected to contained our finished work moving OpenBMP's functionality into OpenNMS, as well as enhancements to handle ToS/QoS in flows.

Next Meridian: 2021 (Q2 2021)

With the recent release of Meridian 2020, plans are still tentative.
However, the current plan is that Meridian 2021 will be based on Horizon 28.

We'll know more once development plans start to firm up.

Disclaimer

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 Week…

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.

- Ben

Resolved Issues Since Last OOH

  • HELM-213: Migrate documentation to Antora
  • HELM-252: Helm Plugin on Grafana.com Out of Date
  • NMS-12915: Add gNMI support for OpenConfig
  • NMS-12959: Event Translator debug logging is incorrect
  • NMS-12968: Display the alarm status correctly in topology map for applications
  • NMS-12971: Identify message broker strategies in web "about" page
  • NMS-12975: Nephron Stability Issues at Scale
  • NMS-12979: Alarm (v1 & v2) ReST Service PUT Can't PUT Multiple Things
  • NMS-12986: VMware datacollection failed

by RangerRick at November 09, 2020 08:22 PM

November 02, 2020

OpenNMS On the Horizon – ToS, SSL, gNMI OpenConfig, Docs, Karaf, Web UI, ReST

In the last week we worked on ToS in flows, SSL certificates, gNMI OpenConfig, documentation, Karaf updates, web UI improvements, and ReST.

Github Project Updates

Internals, APIs, and Documentation
  • Christian and Dustin did more work on adding support for ToS handling in flows
  • Stefan worked on a change to support importing server certs into the Minion trust store
  • Bonnie did more work on Provisiond documentation updates
  • Chandra did some final wrap-up of the branch to add gNMI OpenConfig support
  • David did some work on better error-code handling in the SSLCertMonitor
  • Sean worked on updating our embedded Karaf to 4.2.10
Web, ReST, UI, and Helm
  • Jeff made an update to the "About" page to show configured message broker strategies
  • Christian added support for querying the new ToS flow information in Helm
  • Patrick made some fixes to outage handling in the Application Topology View
  • I made a fix to the alarm ReST (v1 & v2) APIs to handle applying multiple values in one PUT request
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • David Schlenk
  • Dino Yancey
  • Dustin Frisch
  • Jeff Gehlbach
  • Patrick Schweizer
  • Sean Torres
  • Stefan Wachter

Release Roadmap

November Releases

The next OpenNMS release day is November 3rd, 2020.

The current plan is to release Horizon 27 as well as Meridians 2019 and 2020.

Next Horizon: 27 (Q4 2020)

The next major Horizon release will be Horizon 27.
It's going to contain a bunch of great stuff:

  • improvements to node caching for flow processing
  • VMware meta-data has been moved from assets to the new node meta-data
  • Minion improvements, including configuration enhancements and an overhaul to RPC thread-handling
  • a new handy global search bar in the web UI
  • improved SNMPv3 auth configuration
  • a major rework of remote poller functionality, now integrated with the Minion (we're calling it Application Perspective Monitoring)
Next Meridian: 2021 (Q2 2021)

With the recent release of Meridian 2020, plans are still tentative.
However, the current expectation is that Meridian 2021 will be based on Horizon 28, which is expected to build on Horizon 27 with additional flow and metadata improvements.

We'll know more once development plans start to firm up.

Disclaimer

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 Week…

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.

- Ben

Resolved Issues Since Last OOH

  • NMS-8484: Add custom string attributes based on indirect and complex SNMP Indices
  • NMS-12897: Filter outages table in Application Topology View
  • NMS-12948: SSLCertMonitor should include more details about the expir(ing|ed) certificate in reason codes
  • NMS-12958: Update Maximum PostgreSQL to allow PostgreSQL 13
  • NMS-12961: Create Horizon 27 Release Notes
  • NMS-12970: Topology Application Map: Outage Table: Clicking on a service should show the outages of the service
  • NMS-12971: Identify message broker strategies in web "about" page
  • NMS-12979: Alarm (v1 & v2) ReST Service PUT Can't PUT Multiple Things

by RangerRick at November 02, 2020 04:33 PM

October 26, 2020

OpenNMS On the Horizon – OpenBMP, Flow ToS, OpenNMS.js, PostgreSQL 13, Outages

In the last week we worked on OpenBMP refactoring, ToS handling in flows, OpenNMS.js updates, documentation, PostgreSQL 13, filtering outages in the application topology view, and bug fixes.

Github Project Updates

Internals, APIs, and Documentation
  • Chandra continued his work on removing OpenBMP as an external dependency
  • Christian worked on adding support for ToS handling in flows
  • I worked on modernizing a bunch of build and runtime dependencies in OpenNMS.js
  • I worked on moving OpenNMS.js documentation to Antora
  • Bonnie worked on installation, minion, and provisioning documentation
  • I updated our PostgreSQL support to include 13
  • David Schlenk made a fix for the opennms startup script not knowing its PID in some cases
Web, ReST, UI, and Helm
  • Patrick worked on updating the application topology view to support filtering outages
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • David Schlenk
  • Dustin Frisch
  • Patrick Schweizer

Release Roadmap

November Releases

The next OpenNMS release day is November 3rd, 2020.

The current plan is to release Horizon 27 as well as Meridians 2019 and 2020.

Next Horizon: 27 (Q4 2020)

The next major Horizon release will be Horizon 27.
It's going to contain a bunch of great stuff:

  • improvements to node caching for flow processing
  • VMware meta-data has been moved from assets to the new node meta-data
  • Minion improvements, including configuration enhancements and an overhaul to RPC thread-handling
  • a new handy global search bar in the web UI
  • improved SNMPv3 auth configuration
  • a major rework of remote poller functionality, now integrated with the Minion (we're calling it Application Perspective Monitoring)
Next Meridian: 2021 (Q2 2021)

With the recent release of Meridian 2020, plans are still tentative.
However, the current expectation is that Meridian 2021 will be based on Horizon 28, which is expected to build on Horizon 27 with additional flow and metadata improvements.

We'll know more once development plans start to firm up.

Disclaimer

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 Week…

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.

- Ben

Resolved Issues Since Last OOH

  • NMS-5879: Debian init.d script wrong postgres dependency
  • NMS-12917: Update Minion installation documentation
  • NMS-12966: service starts / restarts work but spit out an error if configured to wait for startup

by RangerRick at October 26, 2020 05:47 PM

October 19, 2020

OpenNMS On the Horizon – Kafka, BGP/BMP, Sentinel, Vcenter, Time-Series, Helm, and ElasticSearch

In the last week we worked on some Kafka test infrastructure updates, the BMP integration, Vcenter CIM polling, time-series plugins, Helm, and ElasticSearch QoS querying.

Github Project Updates

Internals, APIs, and Documentation
  • Sean worked on bumping Kafka components to 2.6.0
  • Chandra did more work on reworking our BMP integration to not rely on external OpenBMP
  • Alejandro's system property update for Sentinel got updated and merged
  • Christian worked on a fix for Vcenter CIM polling
  • Patrick worked on some fixes for incomplete data in the Cortex time-series plugin
Web, ReST, UI, and Helm
  • I wrapped up the Helm 6 release
  • Christian worked on making the ElasticSearch ReST API support raw and aggregated QoS queries
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Alejandro Galue
  • Benjamin Reed
  • Chandra Gorantla
  • Christian Pape
  • Patrick Schweizer
  • Sean Torres

Release Roadmap

November Releases

The next OpenNMS release day is November 3rd, 2020.

The current plan is to release Horizon 27 as well as Meridians 2019 and 2020.

Next Horizon: 27 (Q4 2020)

The next major Horizon release will be Horizon 27.
It's going to contain a bunch of great stuff:

  • improvements to node caching for flow processing
  • VMware meta-data has been moved from assets to the new node meta-data
  • Minion improvements, including configuration enhancements and an overhaul to RPC thread-handling
  • a new handy global search bar in the web UI
  • improved SNMPv3 auth configuration
  • a major rework of remote poller functionality, now integrated with the Minion (we're calling it Application Perspective Monitoring)
Next Meridian: 2021 (Q2 2021)

With the recent release of Meridian 2020, plans are still tentative.
However, the current expectation is that Meridian 2021 will be based on Horizon 28, which is expected to build on Horizon 27 with additional flow and metadata improvements.

We'll know more once development plans start to firm up.

Disclaimer

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 Week…

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.

- Ben

Resolved Issues Since Last OOH

  • NMS-12919: Unable to poll Vcenter CIM - Calling something in OpenJDK11 that has been removed.

by RangerRick at October 19, 2020 06:40 PM

October 12, 2020

OpenNMS On the Horizon – Docs, CI, Detectors and Pollers, Flows, Meta-Data, Helm, Resource Graphs

Apologies for the skipped OOH, I was on vacation last week.

In the last two weeks we worked on documentation, CI, a number of detectors and pollers, flows, meta-data, Helm, and custom resource graphs.

Github Project Updates

Internals, APIs, and Documentation
  • I worked on updating our CI builds to use Cloudsmith for assets
  • I updated the HTTP detector to work with servers that do not send a response reason phrase
  • Christian did more work adding support for setting meta-data in requisitions
  • Dustin worked on improved support for DNS hostname resolution in flow data
  • Bonnie and Ronnie worked on migrating documentation to Antora
  • Alejandro added support for custom.system.properties in the Sentinel Docker image
  • Jeff worked on being able to handle indirect and complex SNMP indices
  • David Schlenk updated some of our WMI bits to support NTLMv2/SMBv2
  • Christian added a fix to handle invalid flow data from some vendor devices
  • Christian fixed VCenter CIM handling on OpenJDK 11
Web, ReST, UI, and Helm
  • I changed the custom resource list to be sorted
  • I did more work on fixing Helm in Grafana 7
  • Chandra made the custom resource graph handle being unable to "graph all" more gracefully
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Alejandro Galue
  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • David Schlenk
  • Dustin Frisch
  • Jeff Gehlbach
  • Ronny Trommer

October Releases - Horizon 26.2.2, Meridians 2018.1.23, 2019.1.12, and 2020.1.0

Last week we released Horizon 26.2.2, as well as the latest Meridian 2018, 2019, and 2020.

For a complete rundown of the releases, see the October release announcement.

Release Roadmap

November Releases

The next OpenNMS release day is November 3rd, 2020.

The current plan is to release Horizon 27 as well as Meridians 2019 and 2020.

Next Horizon: 27 (Q4 2020)

The next major Horizon release will be Horizon 27.
It's going to contain a bunch of great stuff:

  • improvements to node caching for flow processing
  • VMware meta-data has been moved from assets to the new node meta-data
  • Minion improvements, including configuration enhancements and an overhaul to RPC thread-handling
  • a new handy global search bar in the web UI
  • improved SNMPv3 auth configuration
  • a major rework of remote poller functionality, now integrated with the Minion (we're calling it Application Perspective Monitoring)
Next Meridian: 2021 (Q2 2021)

With the recent release of Meridian 2020, plans are still tentative.
However, the current expectation is that Meridian 2021 will be based on Horizon 28, which is expected to build on Horizon 27 with additional flow and metadata improvements.

We'll know more once development plans start to firm up.

Disclaimer

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 Week…

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.

- Ben

Resolved Issues Since Last OOH

  • HELM-247: fix alarm table in Grafana 7
  • NMS-10351: HTTP Detector does not accept a response without a reason as valid
  • NMS-12692: Support hostnames resolution when using aggregated flows
  • NMS-12788: Use newer protocol versions for remote DCOM WMI
  • NMS-12800: Netflow timestamps incorrectly calculated on interfaces with MPLS
  • NMS-12805: Wildcard certificate rejected after upgrade from OpenNMS version 26.1.1 to 26.1.2
  • NMS-12813: Include XML schema for wsman-datacollection-config.xml in assemblies
  • NMS-12918: Allow setting meta data in a requisition
  • NMS-12922: Create a report that matches Horizon 27.0.0 Jira issues with merged pull requests in GitHub
  • NMS-12929: Improvements to Timescale Plugin
  • NMS-12931: sort custom reports
  • NMS-12932: TSS: TimescalePlugin: Create KAR
  • NMS-12933: Update Copyright notice for 2020
  • NMS-12939: Custom Resource Performance Reports returns Missing Parameter: resourceId

by RangerRick at October 12, 2020 07:28 PM

October Releases: Horizon 26.2.2, Meridians 2018.1.23, 2019.1.12, and 2020.1.0

In October we released a Horizon 26 bug fix release, as well as Meridian maintenance releases on the 2018 and 2019 branches. The biggest news, however, is the release of Meridian 2020.

Meridian 2020

Meridian 2020 is the latest in the Meridian series, based on Horizon 26.1.3 plus a number of bug fixes that have gone into the 26 series since its release.

This marks the end of official support for Meridian 2017, although we will continue to make critical updates to the 2017 branch for Powered By OpenNMS customers.

For a high-level overview of what's changed since Meridian 2019, see the Meridian 2020 landing page. The complete release notes are available on meridian.opennms.com.

Meridians 2018.1.23 and 2019.1.12

Meridian 2018.1.23 contained just a small fix for using the correct (location-specific) SNMP config in the SNMP Interface Poller.

Meridian 2019.1.12 includes a number of bug fixes and a few small enhancements.

Horizon 26.2.2

Horizon 26.2.2 contains a number of bug fixes and enhancements, including documentation improvements, time series updates, and a fix for UEI processing.

by RangerRick at October 12, 2020 07:08 PM

September 28, 2020

OpenNMS On the Horizon – Documentation, Thresholding and Requisition Metadata Support, gNMI OpenConfig, Helm

In the last week we did more documentation improvements, worked on metadata support for thresholding and requisitions, added gNMI support to the OpenConfig integration, made Helm impromevements, and did lots of other bug fixing.

Github Project Updates

Internals, APIs, and Documentation
  • Bonnie worked on improving installation documentation for Minion
  • Chandra did more work on adding metadata support for thresholds
  • Ronny and Bonnie worked on moving our documentation rendering to Antora
  • Christian updated the nodeDeleted event to support more log message fields
  • Chandra worked on adding gNMI support to the OpenConfig integration
  • Dustin made improvements to hostname resolution handling in flow queries
  • Mike fixed a bug in the OIA where alarm type was not being set
  • I worked on trying to fix up CircleCI builds to rely less on hitting (flapping) upstream package archives
  • Ronny worked on a new PRIS release using the new documentation workflow
  • Christian worked on adding support for setting metadata in requisitions
  • Jeff worked on an ancient request to add custom string attributes when collecting on complex SNMP indexes
Web, ReST, UI, and Helm
  • I worked on fixing Helm in Grafana 7
  • Jeff updated the Helm nodeResources() function to allow showing the resource label or name, as well as being able to specify a resource type
  • Patrick fixed an issue in flow ReST queries when no data is available
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Dustin Frisch
  • Jeff Gehlbach
  • Mark Mahacek
  • Mike Kelly
  • Patrick Schweizer
  • Ronny Trommer

Release Roadmap

Note that this is just based on current plans; dates, features, and releases can change or slip depending on how development goes.

October Releases

The next OpenNMS release day is October 6th, 2020.

The current plan is to release Horizon 26.2.2 as well as Meridians 2018, 2019, and 2020.

Next Horizon: 27 (Q4 2020)

The next major Horizon release will be Horizon 27.
It's going to contain a bunch of great stuff:

  • improvements to node caching for flow processing
  • VMware meta-data has been moved from assets to the new node meta-data
  • Minion improvements, including configuration enhancements and an overhaul to RPC thread-handling
  • a new handy global search bar in the web UI
  • improved SNMPv3 auth configuration
  • a major rework of remote poller functionality, now integrated with the Minion (we're calling it Application Perspective Monitoring)
Next Meridian: 2020 (Q4 2020)

Meridian 2020 will be based on Horizon 26.1, and should have roughly the same featureset as Horizon 26.1.3 plus a few bugfixes we've made since then.

Until Next Week…

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.

- Ben

Resolved Issues Since Last OOH

  • HELM-95: Expose Resource Label attribute to Grafana variables
  • NMS-10554: nodeDeleted event should contain more information
  • NMS-12498: Determine migration process
  • NMS-12794: Add support for meta-data on single-DS threshold definitions
  • NMS-12814: Interfaces incorrectly marked as having flows resulting in no data via Helm
  • NMS-12914: Nullpointer in Time Series Integration Layer when query leads to no data.
  • NMS-12917: Update Minion installation documentation
  • NMS-12921: Application link on start page redirects to start page
  • NMS-12923: Integration API: Alarm.type is unset

by RangerRick at September 28, 2020 05:59 PM

September 21, 2020

OpenNMS On the Horizon – Events, Meta-Data, Time Series, SNMP, Helm, Documentation, Perspective Monitoring

In the last week we fixed a bunch of bugs relating to events, meta-data, time series, SNMP, and Helm, updated documentation, and continued to make small perspective monitoring tweaks in preparation for Horizon 27.

Github Project Updates

Internals, APIs, and Documentation
  • Ronny added a log category for the perspective poller
  • Jesse fixed a bug in event matching when a UEI matched across multiple sources
  • Chandra did more work on adding meta-data support to thresholding
  • Patrick fixed some NPE issues in the time series API
  • Chandra made some more fixes for handling broken agents that return the wrong number of OIDs
  • Patrick created some documentation for writing time series plugins
  • Christian enhanced nodeDeleted events to contain additional parameters
  • Chandra fixed the SNMP poller to handle location when looking up config
  • Patrick fixed some queries that Helm uses to determine whether flow data is available
  • Bonnie reworked the documentation on setting up Minion
  • Bonnie worked on providing documentation updates to handle RHEL7-specific requirements
  • I build ARM64 JICMP/JICMP6/JRRD/JRRD2 binaries for RHEL7, RHEL8, and Debian/Ubuntu
Web, ReST, UI, and Helm
  • Ronny updated the application page to direct link to nodes, interfaces, services, and IPs
  • Jeff worked on a fix to show resource labels in Grafana/Helm variables
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • David Schlenk
  • Dino
  • Jeff Gehlbach
  • Jesse White
  • Patrick Schweizer
  • Ronny Trommer

Release Roadmap

Note that this is just based on current plans; dates, features, and releases can change or slip depending on how development goes.

October Releases

The next OpenNMS release day is October 6th, 2020.

The current plan is to release Horizon 26.2.2 as well as Meridian 2019 and 2020.

Next Horizon: 27 (Q4 2020)

The next major Horizon release will be Horizon 27.
It's going to contain a bunch of great stuff:

  • improvements to node caching for flow processing
  • VMware meta-data has been moved from assets to the new node meta-data
  • Minion improvements, including configuration enhancements and an overhaul to RPC thread-handling
  • a new handy global search bar in the web UI
  • improved SNMPv3 auth configuration
  • a major rework of remote poller functionality, now integrated with the Minion (we're calling it Application Perspective Monitoring)
Next Meridian: 2020 (Q4 2020)

Meridian 2020 will be based on Horizon 26.1, and should have roughly the same featureset as Horizon 26.1.3 plus a few bugfixes we've made since then.

Until Next Week…

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.

- Ben

Resolved Issues Since Last OOH

  • JICMP-25: Build for aarch64
  • NMS-12755: Eventconf with same UEI but differing masks does not follow first-found-wins rule when some events have alarm-data elements and some do not
  • NMS-12818: ArrayIndexOutOfBoundsException thrown by the SNMP Interface Poller
  • NMS-12891: Install guide RHEL instructions are invalid on RHEL 7
  • NMS-12892: Document the MailTransportMonitor
  • NMS-12902: Snmp Interface Poller is not using location specific SNMP Config
  • NMS-12912: Update link to In Memory TS DB
  • NMS-12913: Allow to navigate to monitored items in application status view
  • OIA-32: Create howto for writing tss plugins

by RangerRick at September 21, 2020 04:05 PM