Foreman

Applied in changeset 5e7454fc1f73ebb599cf7dc96faa22836eebd11c.

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

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?

Applied in changeset 387b0b0c54a9b9c31b3727ebc1e8ec984e3d5c55.

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?

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?