Re: Discovery of deleted nodes
Shane Dawalt <[email protected]>
| Newsgroups | gmane.network.opennms.general |
|---|---|
| Message-ID | <[email protected]> |
On 05/04/2018 10:16 AM, David Hustace wrote: > >> On May 4, 2018, at 09:58, Shane Dawalt <[email protected]> wrote: >> >> Expecting this was a code change after 16.0, I waded through the OpenNMS issues database and came across HZN-572 (18.0.0). It's an IP filter put in place for the move to Camel. It prevents pinging of already discovered addresses. Prior to HZN-572, the database was used for filtering already discovered IPs. This worked well, because when a node is deleted, it's ipinterface is deleted, which allowed the IP to be rediscovered. Apparently, the new filter isn't aware of deleted IPs. > Shane, > > According to that issue, HZN-572, the issue was resolved and should behave as expected. Were you able to work around it if this is still an issue and if so, how? David, For me, the issue description reads like a statement of work, not a bug report. I interpreted it as a need to implement filtering that wasn't occurring in 18.0.0, but was occurring in earlier versions. Seth's comment of 29 Feb 2016 sounded more like a description of the method used to perform the filtering. In any case, I can be reading this wrong. The workaround I found is to wait for the node(s) to be purged from the database, then manually add the IP interface(s) causing newSuspect event(s) thus bypassing auto-discovery. Shane ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Please read the OpenNMS Mailing List FAQ: http://www.opennms.org/index.php/Mailing_List_FAQ opennms-discuss mailing list To *unsubscribe* or change your subscription options, see the bottom of this page: https://lists.sourceforge.net/lists/listinfo/opennms-discuss