Project

General

Profile

Feature #593

split log for facts, reports and everything else

Added by Paul Kelly over 12 years ago. Updated about 6 years ago.

Status:
Needs design
Priority:
Normal
Assignee:
Paul Kelly
Category:
Rails
Target version:
-
Difficulty:
Triaged:
No
Bugzilla link:
Pull request:
Fixed in Releases:
Found in Releases:
Red Hat JIRA:

Description

The foreman log should be split into three. The continuous stream of reports and facts makes looking at the log nearly impossible.

Related issues

Has duplicate Foreman - Feature #778: log entries shuld be separated out to aid visual investigationDuplicate2011-03-23

Associated revisions

Revision 5e7454fc (diff)
Added by Paul Kelly over 11 years ago

Fixes #593 - Separate log file for facts and reports

Signed-off-by: Paul Kelly <>

Revision 387b0b0c (diff)
Added by Ohad Levy over 11 years ago

Revert "Fixes #593 - Separate log file for facts and reports"

This reverts commit 5e7454fc1f73ebb599cf7dc96faa22836eebd11c.

History

#1 Updated by Ohad Levy almost 12 years ago

  • Assignee set to Paul Kelly

#2 Updated by Paul Kelly over 11 years ago

  • Status changed from New to Ready For Testing

#3 Updated by Ohad Levy over 11 years ago

  • Target version set to 1.0

#4 Updated by Paul Kelly over 11 years ago

  • Status changed from Ready For Testing to Closed
  • % Done changed from 0 to 100

#5 Updated by Ohad Levy over 11 years ago

it would have been nice if we also included the ENC requests too ;)

#6 Updated by Ohad Levy over 11 years ago

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

#7 Updated by Ohad Levy over 11 years ago

  • 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?

#8 Updated by Ohad Levy over 11 years ago

  • Status changed from Assigned to Closed

#9 Updated by Paul Kelly over 11 years ago

  • 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.

#10 Updated by Ohad Levy over 11 years ago

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?

#11 Updated by Ohad Levy about 11 years ago

  • Status changed from Need more information to Feedback
  • Target version deleted (1.0)

Thinking on this further,

I would probably would split to:

  1. events that are generated by puppet (ENC, facts, reports).
  2. API events
  3. 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?

#12 Updated by Anonymous about 6 years ago

  • Status changed from Feedback to Needs design

Also available in: Atom PDF