First, this ticket should not be a defect.
The log level of the ccb commit messages is intentional, the motive being to have a record of if and when a CCB was committed.
Second, having a record o configuration changes at hte OpensAF level is normally necesssary
for analyzing a reproted problem involving OpenSAF. Many problems are triggered by a
configuration change. Having a persistent record of such configuration changes is crucial for
understanding or debugging unexpected events or problems, in a system.
Such troubleshooting does not just cover troubleshooting of OpenSAF, but also troubleshooting
of application level behavior when the configuration of such an application is changed.
Log level NOtice is the lowest log level that is pushed to the syslog by default in OpenSAF.
This ticket in fact goes further than just lowering the log level to INfo (which is normally
not logged but can be toggled on), it argues for lowering it to trace!
So you could end up in a scenario where there is a serious incident on a system, but no way
to see from OpensAF logs if there was any configuration change involved in triggering the
problem. You would need to reproduce the problem to get trace or INfo log level enabled.
The problem with trace is that the volumes are so large that it somtimes impacts the bhavior
of the system, simetimes making it difficult to reproduce the problem.
CCB traffic is very low during normal operation. Only during SMF campaigns,
or manual reconfigurations of the system would there be CCB traffic of any significance.
So log messages of committed CCBs can hardly be a big issue in teerms of volume, in general.
In summary:
I argue that this ticket is not motivated and it is by definition not a defect since the current behavior
is intentional and well motivated.
The motive behind this ticket should be analyzed better and explained better in the ticket.
Or the ticket may just be closed.
A slightly better alternative is to introduce a new configuration parameter to specify if CCB commits
are to be logged. The default of that configuration parameter must of course be OFF (currrent
behavior the default).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I suggest to close this ticket.
When ticket #2306 is implemented and support logging to /var/log/opensaf/xxxxxx log, then we can create a new ticket, and redirect these logs to the new log file.
Thanks,
Zoran
-----Original Message-----
From: Anders Bjornerstedt [mailto:andersbj@users.sf.net]
Sent: den 16 mars 2017 11:30
To: [opensaf:tickets]2382@tickets.opensaf.p.re.sf.net
Subject: [opensaf:tickets] #2382 imm: reducing log level for ccb-committed messages
First, this ticket should not be a defect.
The log level of the ccb commit messages is intentional, the motive being to have a record of if and when a CCB was committed.
Second, having a record o configuration changes at hte OpensAF level is normally necesssary for analyzing a reproted problem involving OpenSAF. Many problems are triggered by a configuration change. Having a persistent record of such configuration changes is crucial for understanding or debugging unexpected events or problems, in a system.
Such troubleshooting does not just cover troubleshooting of OpenSAF, but also troubleshooting of application level behavior when the configuration of such an application is changed.
Log level NOtice is the lowest log level that is pushed to the syslog by default in OpenSAF.
This ticket in fact goes further than just lowering the log level to INfo (which is normally not logged but can be toggled on), it argues for lowering it to trace!
So you could end up in a scenario where there is a serious incident on a system, but no way to see from OpensAF logs if there was any configuration change involved in triggering the problem. You would need to reproduce the problem to get trace or INfo log level enabled.
The problem with trace is that the volumes are so large that it somtimes impacts the bhavior of the system, simetimes making it difficult to reproduce the problem.
CCB traffic is very low during normal operation. Only during SMF campaigns, or manual reconfigurations of the system would there be CCB traffic of any significance.
So log messages of committed CCBs can hardly be a big issue in teerms of volume, in general.
In summary:
I argue that this ticket is not motivated and it is by definition not a defect since the current behavior is intentional and well motivated.
The motive behind this ticket should be analyzed better and explained better in the ticket.
Or the ticket may just be closed.
A slightly better alternative is to introduce a new configuration parameter to specify if CCB commits are to be logged. The default of that configuration parameter must of course be OFF (currrent behavior the default).
** [tickets:#2382] imm: reducing log level for ccb-committed messages**
Status: review Milestone: 5.0.2 Created: Thu Mar 16, 2017 09:26 AM UTC by Neelakanta Reddy Last Updated: Thu Mar 16, 2017 09:47 AM UTC Owner: Neelakanta Reddy
First, this ticket should not be a defect.
The log level of the ccb commit messages is intentional, the motive being to have a record of if and when a CCB was committed.
Second, having a record o configuration changes at hte OpensAF level is normally necesssary
for analyzing a reproted problem involving OpenSAF. Many problems are triggered by a
configuration change. Having a persistent record of such configuration changes is crucial for
understanding or debugging unexpected events or problems, in a system.
Such troubleshooting does not just cover troubleshooting of OpenSAF, but also troubleshooting
of application level behavior when the configuration of such an application is changed.
Log level NOtice is the lowest log level that is pushed to the syslog by default in OpenSAF.
This ticket in fact goes further than just lowering the log level to INfo (which is normally
not logged but can be toggled on), it argues for lowering it to trace!
So you could end up in a scenario where there is a serious incident on a system, but no way
to see from OpensAF logs if there was any configuration change involved in triggering the
problem. You would need to reproduce the problem to get trace or INfo log level enabled.
The problem with trace is that the volumes are so large that it somtimes impacts the bhavior
of the system, simetimes making it difficult to reproduce the problem.
CCB traffic is very low during normal operation. Only during SMF campaigns,
or manual reconfigurations of the system would there be CCB traffic of any significance.
So log messages of committed CCBs can hardly be a big issue in teerms of volume, in general.
In summary:
I argue that this ticket is not motivated and it is by definition not a defect since the current behavior
is intentional and well motivated.
The motive behind this ticket should be analyzed better and explained better in the ticket.
Or the ticket may just be closed.
A slightly better alternative is to introduce a new configuration parameter to specify if CCB commits
are to be logged. The default of that configuration parameter must of course be OFF (currrent
behavior the default).
Hi,
I fully agree with Anders.
I suggest to close this ticket.
When ticket #2306 is implemented and support logging to /var/log/opensaf/xxxxxx log, then we can create a new ticket, and redirect these logs to the new log file.
Thanks,
Zoran
-----Original Message-----
From: Anders Bjornerstedt [mailto:andersbj@users.sf.net]
Sent: den 16 mars 2017 11:30
To: [opensaf:tickets] 2382@tickets.opensaf.p.re.sf.net
Subject: [opensaf:tickets] #2382 imm: reducing log level for ccb-committed messages
First, this ticket should not be a defect.
The log level of the ccb commit messages is intentional, the motive being to have a record of if and when a CCB was committed.
Second, having a record o configuration changes at hte OpensAF level is normally necesssary for analyzing a reproted problem involving OpenSAF. Many problems are triggered by a configuration change. Having a persistent record of such configuration changes is crucial for understanding or debugging unexpected events or problems, in a system.
Such troubleshooting does not just cover troubleshooting of OpenSAF, but also troubleshooting of application level behavior when the configuration of such an application is changed.
Log level NOtice is the lowest log level that is pushed to the syslog by default in OpenSAF.
This ticket in fact goes further than just lowering the log level to INfo (which is normally not logged but can be toggled on), it argues for lowering it to trace!
So you could end up in a scenario where there is a serious incident on a system, but no way to see from OpensAF logs if there was any configuration change involved in triggering the problem. You would need to reproduce the problem to get trace or INfo log level enabled.
The problem with trace is that the volumes are so large that it somtimes impacts the bhavior of the system, simetimes making it difficult to reproduce the problem.
CCB traffic is very low during normal operation. Only during SMF campaigns, or manual reconfigurations of the system would there be CCB traffic of any significance.
So log messages of committed CCBs can hardly be a big issue in teerms of volume, in general.
In summary:
I argue that this ticket is not motivated and it is by definition not a defect since the current behavior is intentional and well motivated.
The motive behind this ticket should be analyzed better and explained better in the ticket.
Or the ticket may just be closed.
A slightly better alternative is to introduce a new configuration parameter to specify if CCB commits are to be logged. The default of that configuration parameter must of course be OFF (currrent behavior the default).
** [tickets:#2382] imm: reducing log level for ccb-committed messages**
Status: review
Milestone: 5.0.2
Created: Thu Mar 16, 2017 09:26 AM UTC by Neelakanta Reddy Last Updated: Thu Mar 16, 2017 09:47 AM UTC
Owner: Neelakanta Reddy
if(i != sOwnerVector.end()) {
LOG_NO("Ccb %u COMMITTED (%s)", ccb->mId, (*i)->mAdminOwnerName.c_str());
} else {
LOG_NO("Ccb %u COMMITTED (%s)", ccb->mId, "<released>");
}</released>
Reduce the LOG_NO to TRACE
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/opensaf/tickets/2382/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
The fix for the problem wil be a part of Enhancement #2306