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-devel mailing list
To *unsubscribe* or change your subscription options, see the bottom of this
page:
https://lists.sourceforge.net/lists/listinfo/opennms-devel
