Audit trails in Foreman

Support
1

Hi all,

I've been having a play with Foreman 0.3 over the last day or two, and first
of all - great work! I'm loving many of the features I've seen already, so
thanks everyone.

In particular, I've been toying with the audit trails. We have many
engineers you don't really understand Puppet, so we're using an ENC, and the
yaml data files for it are stored in Git so we can see who changed them.

By comparison, Foreman's audit trails seem to be close to that, but not
quite. I tried editing a node, both by adding a class and a parameter. The
class didn't show up in the audit tab at all. The parameter change did, but
didn't say what node the change was associated with. I'd love to move my ENC
to foreman (because it's so much shinier :P), but without the audit logs I
just can't do it.

Is this a feature which I've not configured properly? If not, I might take a
shot at extending the existing audit logging.

Many thanks,
greg

2

> Hi all,
>
> I've been having a play with Foreman 0.3 over the last day or two, and
> first of all - great work! I'm loving many of the features I've seen
> already, so thanks everyone.
>
> In particular, I've been toying with the audit trails. We have many
> engineers you don't really understand Puppet, so we're using an ENC, and the
> yaml data files for it are stored in Git so we can see who changed them.
>
> By comparison, Foreman's audit trails seem to be close to that, but not
> quite. I tried editing a node, both by adding a class and a parameter. The
> class didn't show up in the audit tab at all. The parameter change did, but
> didn't say what node the change was associated with. I'd love to move my ENC
> to foreman (because it's so much shinier :P), but without the audit logs I
> just can't do it.
>
> Is this a feature which I've not configured properly? If not, I might take
> a shot at extending the existing audit logging.
>
> Hey Greg,

You are right, there is a feature that foreman lacks at the moment, and its
already requested [1] - feel free to vote on the ticket.

main reason I've not started to work on the topic, is that we are currently
trying to redesign how parameters works in order to:

  1. support parametrized classes.
  2. replace extlookup kind of solutions
  3. provide a ui validations for parameters (like required parameters, type
    (string, numeric etc) [2]
  4. remove the 5 level restriction from the parameters hierarchy.

Cheers,
Ohad

[1] - http://theforeman.org/issues/777
[2] - http://theforeman.org/issues/322#note-4

··· On Wed, Jun 15, 2011 at 3:58 PM, Greg Sutcliffe wrote:

Many thanks,
greg

–
You received this message because you are subscribed to the Google Groups
“Foreman users” group.
To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to
foreman-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/foreman-users?hl=en.

3

Thanks for the fast reply Ohad,

I have indeed voted up that issue - and I'm fairly happy to wait
as parametrized class support would be useful to me too. Roll on 0.4 :slight_smile:

In the meantime, it's back to my Git-backed Yaml files and ugly webform
editor. Such is life :stuck_out_tongue:

Greg

··· On 15 June 2011 14:09, Ohad Levy wrote: > > Hey Greg, > > You are right, there is a feature that foreman lacks at the moment, and its > already requested [1] - feel free to vote on the ticket. > > main reason I've not started to work on the topic, is that we are currently > trying to redesign how parameters works in order to: > 1. support parametrized classes. > 2. replace extlookup kind of solutions > 3. provide a ui validations for parameters (like required parameters, type > (string, numeric etc) [2] > 4. remove the 5 level restriction from the parameters hierarchy. >