 |
|
|
|
|
| Added: Wed, Mar 22nd 2000 10:06 UTC (8 years, 4 months ago) |
Updated: Thu, Jun 19th 2008 20:28 UTC (1 month, 1 day ago) |
|
|
About:
OpenNMS is the first enterprise-grade network
management platform developed using the open
source model. The three main functional areas of
OpenNMS are service polling, which monitors
services on the network and reports on their
"service level"; data collection from the remote
systems via SNMP in order to measure the
performance of the network; and a system for event
management and notifications.
Author:
Tarus Balog [contact developer]
Homepage:
http://www.opennms.org/
Tar/GZ:
http://sourceforge.net/[..]iles.php?group_id=4141&package_id=118141
RPM package:
http://sourceforge.net/project/showfiles.php?group_id=4141
Debian package:
http://sourceforge.net/project/showfiles.php?group_id=4141
CVS tree (cvsweb):
http://opennms.cvs.sourceforge.net/opennms/
Mailing list archive:
http://sourceforge.net/mail/?group_id=4141
Trove categories:
[change]
Dependencies:
[change]
No dependencies filed
|
|
» Rating:
8.18/10.00
(Rank N/A)
» Vitality: 0.98% (Rank 392)
» Popularity: 9.45% (Rank 251)
 
(click to enlarge graphs)
Record hits: 98,712
URL hits: 62,030
Subscribers: 210
|
|
Projects depending on this project:
OS-SIM
|
|
Branches
Releases
|
Version
|
Focus
|
Date
|
|
1.2.9
|
Minor bugfixes |
20-Nov-2006 18:24 |
|
1.2.8
|
Minor feature enhancements |
08-Jun-2006 16:06 |
|
1.2.7
|
Minor bugfixes |
27-Feb-2006 15:45 |
|
1.2.5
|
N/A |
11-Nov-2005 19:04 |
|
1.2.3
|
Minor feature enhancements |
27-May-2005 05:49 |
|
1.2.1
|
Minor feature enhancements |
21-Mar-2005 22:58 |
|
1.0.1
|
Minor bugfixes |
19-Aug-2002 17:07 |
|
1.0.0
|
Minor bugfixes |
30-Apr-2002 20:58 |
|
0.8.1
|
Minor bugfixes |
20-Nov-2001 22:23 |
|
0.8.0
|
Major feature enhancements |
12-Jul-2001 18:11 |
Articles referencing this project
Comments
[»]
SQL independence.
by AltGrendel - Dec 19th 2002 05:55:55
Looks good but I use MySQL. I noticed in the mail list archive that because
of some SQL procedures it would be too complicated to port over.
Are there any plans for database independence?
[reply]
[top]
[»]
Re: SQL independence.
by Deven Phillips, CISSP - Nov 10th 2004 02:27:47
> Looks good but I use MySQL. I noticed in
> the mail list archive that because of
> some SQL procedures it would be too
> complicated to port over.
>
> Are there any plans for database
> independence?
The main problem is that OpenNMS uses C based stored procedures which, as
I understand it, are not possible on MySQL. In addition, PostgreSQL
provides many enterprise features that MySQL lacks, but which are used in
OpenNMS.
[reply]
[top]
[»]
Re: SQL independence.
by Tarus Balog - Nov 10th 2004 15:11:36
> Are there any plans for database
> independence?
With 2.0, the next big development push, we are using
Hibernate (http://www.hibernate.org) to abstract the
database layer, so it might be possible to use mySQL then.
We used stored procedures for the IPLIKE function and for
the RTC daemon. The latter is going away in 2.0 and the
former is going to be written in SQL.
-T
[reply]
[top]
[»]
Re: SQL independence.
by Joaquim Homrighausen - Jun 30th 2005 07:12:52
>
> % Are there any plans for database
> % independence?
>
>
> With 2.0, the next big development push,
> we are using
> Hibernate (http://www.hibernate.org) to
> abstract the
> database layer, so it might be possible
> to use mySQL then.
What's the plan for 2.0.. release date.. roadmap.. ?
Being able to use MySQL is essential to us.
--
Appetite for construction
[reply]
[top]
[»]
Re: SQL independence.
by Tarus Balog - Jul 2nd 2005 08:26:36
>
> %
> % % Are there any plans for database
> % % independence?
> %
> %
> % With 2.0, the next big development
> push,
> % we are using
> % Hibernate (http://www.hibernate.org)
> to
> % abstract the
> % database layer, so it might be
> possible
> % to use mySQL then.
>
>
> What's the plan for 2.0.. release date..
> roadmap.. ?
>
> Being able to use MySQL is essential to
> us.
>
>
>
Unknown at the moment. We are getting ready to release 1.3.0 (before
LinuxWorld Expo in August) which adds SNMPv3 support, alarms and JMX
monitoring.
We use some stored procedures that MySQL did not support prior to 5, which
is one of the reasons the movement to MySQL would be difficult. The OpenNMS
Group (http://www.opennms.com) provides commercial support and services for
OpenNMS, and they might be able to spec a project for you to support MySQL
if the need is immediate.
-T
[reply]
[top]
[»]
Re: SQL independence.
by Joaquim Homrighausen - Jul 3rd 2005 23:53:29
> Unknown at the moment. We are getting
> ready to release 1.3.0 [..]
>
> We use some stored procedures that MySQL
> did not support prior to 5, which is one
> of the reasons the movement to MySQL
> would be difficult.
OK; it seems somewhat overkill to use stored procedures for something like
this, and it comes with the penalty of portability.
I guess we'll just have to wait or use something else, such is life in the
world of OS.
Thanks!
--
Appetite for construction
[reply]
[top]
[»]
Re: SQL independence.
by GooberToo - Sep 14th 2007 14:43:49
> OK; it seems somewhat overkill to use
> stored procedures for something like
> this, and it comes with the penalty of
> portability.
>
> I guess we'll just have to wait or use
> something else, such is life in the
> world of OS.
It's pretty obvious you don't understand databases. OpenNMS is targeting
an Enterprise Solution. Part of that need is performance. Real databases
support stored procedures because they can significantly save on both CPU
and disk bandwidth. Use of stored procedures also ensures a consistent API
is exposed to would-be developers.
Since you're mandating a request of MySQL plus insisting the use of stored
procedures should be abandoned, you should really be looking at alternate
solutions since your mandates are wholly incompatible with an Enterprise
quality solution.
[reply]
[top]
[»]
Re: SQL independence.
by GooberToo - Sep 14th 2007 14:37:13
> Being able to use MySQL is essential to
> us.
>
>
>
That's pretty funny. This is like saying we can't can't buy a car until
it explodes when you can least afford it. Only after it constantly
explodes will you consider buying the vehicle.
Hehehe...too funny. Shesh...just about any DB is going to prove more
reliable and robust than MySQL. There is a reason why real DBAs consider
MySQL to be trash...because it is. It lacks features, teaches poor SQL
coding habits, isn't reliable, scales like crap, so on and so on.
Seriously...if you consider MySQL to be a mandatory feature then you
absolutely are not looking for an Enterprise Solution. Period.
[reply]
[top]
|
|
|
