Re: [opennms-devel] [opennms-discuss] OpenNMS pre-compiled out-of-the-box MIB eventfiles

[John Blake]

 How about just have ONMS configured with the normal mib stuff?
  (host, interface, cpu, etc) that all devices normally support.
 Then the recent vendor ready mib files would be somewhere on ONMS site to grab if wanted. Say a tarball of all, and tarballs of each vendor or let people grab the specific file if they want.
 Any update notifications to said files can be done thru mailing list.
 
 Using Davids idea of auto updating, how about having the default ONMS mib stuff have the mib II and then just the Id's of the supported mibs?
 If I get a trap from a device, onms would translate it and let me know if theres already a mib file ready for it. Then I'd go get the file. Or figure out why a device that wasnt supposed to be sending me a trap is doing it.

 

 John B



-----Cyrille Bollu <cyrille.bo...@gmail.com> wrote: -----

To: General OpenNMS Discussion <opennms-disc...@lists.sourceforge.net>, OpenNMS Code Development and Bugs <opennms-devel@lists.sourceforge.net>
From: Cyrille Bollu <cyrille.bo...@gmail.com>
Date: 01/19/2016 06:35AM
Subject: Re: [opennms-discuss] OpenNMS pre-compiled out-of-the-box MIB event files

Hi all,

Let's summarize:

I identify 3 discussions here:

       1- How to deal with new event files addition?

That's the original question.

It needs a somewhat quick solution, as atm, without solution, OpenNMS users don't benefit from new event files (ie: PR stay pending).

The simple solution to put these new files in the "/etc/opennms/example" folder is good enough for me atm.

This solution raises some concerns though:

1. OpenNMS' git repository could grow quite large with all these new event files
   => this point is discussed in the 2nd discussion below
2. How should existing (and future) users be informed that, from now on, they must look up in that folder to find new event files?
   => The catch all event is a good solution for me
   => Maybe we should add some info in the doc somewhere (maybe here: http://docs.opennms.org/opennms/releases/17.0.0/guide-admin/guide-admin.html#ga-events)?
   => I don't think this solution hinder future implementation of David's proposal of automated event file loading service. That's good
3. How do we deal with modifications to existing event files (APC event file example)?
   => We have a conflict of interest here:
   => A priori, it's easier to continue to modify existing event files than to create a new version of these files in the /etc/opennms/example folder. Doing otherwise would require to somehow inform users about the new version of event files in the /etc/opennms/example folder (so they could manually update the ones they want in the /etc/opennms/events folder).
   => Though, large modifications to existing event files are somewhat cumbersome to handle at OpenNMS upgrade time.

         2- How to deal with OpenNMS' git repository growth?

This is not the original question. Though, it's worth discussing.

Should this issue prevent us from implementing a solution to discussion 1?

If not, cool, let's go ahead and discuss this solution in another topic.

If yes, bad, let's discuss here.

Possible solutions:

1. A priori repository size management: user to issue git merge --squash (Seth's proposal)
   
2. A posteriori repository size management: OpenNMS group to squash commits directly in the develop, master,release,... branches
3. create a new git repository for openNMS event files? So that openNMS developers don't have to deal with an unnecessary  large repository
4. Others?

          3- Automated event files loading service

This is a possible solution to the original question.

It is a very cool solution but probably involves much more effort to implement and thus probably conflicts with the "urgent" character of the original question.

So, if I'm right about this conflict, and if the simple solution proposed in discussion 1 doesn't hinder the implementation of this solution I would go ahead for solution 1 and let this point open for future improvment (ie: register a new JIRA issue). Otherwise, well, I don't know.

           4- 4th discussion

What? Did you read it all till here?  :-)

There's no 4th discussion

Cheers,

Cyrille

2016-01-18 17:04 GMT+01:00 David S Hustace <da...@opennms.com>:

> On Jan 13, 2016, at 9:29 AM, ro...@opennms.org wrote:
>
> I can totally see the question about how to differentiate the trap files between: “Do we load it by default or not!”
>
> Jeff mentioned a very clever way yesterday. We could create a catch all event for each manufacturer. If a trap from the manufacturer is received by OpenNMS it can tell you something like:
>
>       “Hey I’m a “Manufacturer” trap OpenNMS doesn’t have a compiled MIB loaded but here is the place which tells you how to load and to enable pre-compiled MIBS from this manufacturer”

We should take it one step further…

If a trap is received for which there isn’t currently an eventconf in the factory, we should have a service that checks to see if a configuration is available and load it, specifically.  This way, if Trapd is running, there would be no eventconf loaded in memory until it is needed.  I would also copy the configuration from events/ to events-forceload/ so that they are automatically loaded on restart… something like that.


:David


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
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

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140

_______________________________________________
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

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/index.php/Mailing_List_FAQ

opennms-devel mailing list

To *unsubscribe* or change your subscription options, see the bottom of this 
page:
https://lists.sourceforge.net/lists/listinfo/opennms-devel