Feature #593
open
split log for facts, reports and everything else
Added by Paul Kelly over 14 years ago.
Updated almost 8 years ago.
Description
The foreman log should be split into three. The continuous stream of reports and facts makes looking at the log nearly impossible.
- Assignee set to Paul Kelly
- Status changed from New to Ready For Testing
- Target version set to 1.0
- Status changed from Ready For Testing to Closed
- % Done changed from 0 to 100
it would have been nice if we also included the ENC requests too ;)
on second though, why would you split ENC, facts and reports logs? its probably better to have them all in a one seperate log.
that would be something like users logs and hosts/puppet related logs
- Status changed from Closed to Assigned
Sorry, I've reverted the commit, as after playing with it, it makes little sense for facts and reports to different logs.
sometime you want to debug them, and the order etc is important.
what do you think of the suggestion above?
- Status changed from Assigned to Closed
- Status changed from Closed to Need more information
The points that you make are fine. I assume that you mean the reports, facts and enc logs going into a development-input.log and the remainder going into the development.log.
As you say it is sometime advantageous to see all the logs in one location so we should make this configurable via a setting. For day to day monitoring of large installations the split log approach would be better in my opinion.
Paul Kelly wrote:
The points that you make are fine. I assume that you mean the reports, facts and enc logs going into a development-input.log and the remainder going into the development.log.
I guess so.
As you say it is sometime advantageous to see all the logs in one location so we should make this configurable via a setting. For day to day monitoring of large installations the split log approach would be better in my opinion.
I agree, while I would argue there is a difference between a user action (such as creating a new host) vs automated actions (such as puppet reports).
Is that enough?
- Status changed from Need more information to Feedback
- Target version deleted (
1.0)
Thinking on this further,
I would probably would split to:
- events that are generated by puppet (ENC, facts, reports).
- API events
- events that are UI driven (all the rest)
What do you think? any idea on how to implement per controller action instead of per model?
- Status changed from Feedback to Needs design
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by Anonymous