I looked at hooking up audited into katello, and it was pretty easy to
do. The issue was around the names which show up in the audit page. I see:
Katello/Product
Katello/Repo
which is a bit ugly. This is due to the audit class storing the type
which it asumes to be a symbol. I can not hack it up in a before_save
callback.
I can think of a few approaches to solve this.
- Add callbacks to the AuditHelper so that the audited_type method
iterates through the callbacks to clean the method name. Plugins could
then register a callback.
- Add a mapping dictionary, which is "From Type => Display Type".
Plugins could register new mappings
- Enhance the helper to only use the class names, and strip off the
module names.
Are there preferences on an approach? I think it is good for plugins to
add to the audit trail to show a unified experience.
– bk
I prefer options a) or b), with plugin registration.
The audits helper is a bit of a mess already, so in the process of
adding helpers for plugins I'd like to see the logic that exists there
moved closer to the models themselves. It would be good to use the same
helpers in both core and plugins.
e.g. instead of a single callback added by each plugin, perhaps each
model could register such a callback for themselves (a bit like the
per-model safemode Jail class) so we keep the logic local.
At the moment we add or change a model, then notice a few months later
that the audit output is poor. Plugins might see the same issue.
···
On 25/06/14 02:22, Bryan Kearney wrote:
> I looked at hooking up audited into katello, and it was pretty easy to
> do. The issue was around the names which show up in the audit page. I see:
>
> Katello/Product
> Katello/Repo
>
> which is a bit ugly. This is due to the audit class storing the type
> which it asumes to be a symbol. I can not hack it up in a before_save
> callback.
>
> I can think of a few approaches to solve this.
>
> * Add callbacks to the AuditHelper so that the audited_type method
> iterates through the callbacks to clean the method name. Plugins could
> then register a callback.
> * Add a mapping dictionary, which is "From Type => Display Type".
> Plugins could register new mappings
> * Enhance the helper to only use the class names, and strip off the
> module names.
>
> Are there preferences on an approach? I think it is good for plugins to
> add to the audit trail to show a unified experience.
–
Dominic Cleal
Red Hat Engineering
I thought Katello will be audited through Dynflow tasks. Potentially
Foreman will too in future.
The dynflow way has advantages:
- it keeps much more information
- it keeps the information unchanged on model updates
- it keeps the information after models are deleted
but I have to admit it is not well organized at the moment.
I would rather fix the dynflow tasks page to provide better auditing
capabilities (the information is already there) then adding audited to
Katello.
Petr
···
On 25.06.14 9:38, Dominic Cleal wrote:
> On 25/06/14 02:22, Bryan Kearney wrote:
>> I looked at hooking up audited into katello, and it was pretty easy to
>> do. The issue was around the names which show up in the audit page. I see:
>>
>> Katello/Product
>> Katello/Repo
>>
>> which is a bit ugly. This is due to the audit class storing the type
>> which it asumes to be a symbol. I can not hack it up in a before_save
>> callback.
>>
>> I can think of a few approaches to solve this.
>>
>> * Add callbacks to the AuditHelper so that the audited_type method
>> iterates through the callbacks to clean the method name. Plugins could
>> then register a callback.
>> * Add a mapping dictionary, which is "From Type => Display Type".
>> Plugins could register new mappings
>> * Enhance the helper to only use the class names, and strip off the
>> module names.
>>
>> Are there preferences on an approach? I think it is good for plugins to
>> add to the audit trail to show a unified experience.
>
> I prefer options a) or b), with plugin registration.
>
> The audits helper is a bit of a mess already, so in the process of
> adding helpers for plugins I'd like to see the logic that exists there
> moved closer to the models themselves. It would be good to use the same
> helpers in both core and plugins.
>
> e.g. instead of a single callback added by each plugin, perhaps each
> model could register such a callback for themselves (a bit like the
> per-model safemode Jail class) so we keep the logic local.
>
> At the moment we add or change a model, then notice a few months later
> that the audit output is poor. Plugins might see the same issue.
>
I think the goal should be a single place to see
- What changes has a user done
- What changes have been made to object X
I would assume we do not not different places per plugin.
– bk
···
On 06/26/2014 05:15 AM, Petr Chalupa wrote:
> I thought Katello will be audited through Dynflow tasks. Potentially
> Foreman will too in future.
>
> The dynflow way has advantages:
> - it keeps much more information
> - it keeps the information unchanged on model updates
> - it keeps the information after models are deleted
> but I have to admit it is not well organized at the moment.
>
> I would rather fix the dynflow tasks page to provide better auditing
> capabilities (the information is already there) then adding audited to
> Katello.
> I thought Katello will be audited through Dynflow tasks. Potentially
> Foreman will too in future.
>
> The dynflow way has advantages:
> - it keeps much more information
> - it keeps the information unchanged on model updates
> - it keeps the information after models are deleted
> but I have to admit it is not well organized at the moment.
>
> I would rather fix the dynflow tasks page to provide better auditing
> capabilities (the information is already there) then adding audited to
> Katello.
is this true for all objects or just for objects that have additional tasks
(outside of the db?)
···
On Thu, Jun 26, 2014 at 12:15 PM, Petr Chalupa wrote:
Petr
On 25.06.14 9:38, Dominic Cleal wrote:
On 25/06/14 02:22, Bryan Kearney wrote:
I looked at hooking up audited into katello, and it was pretty easy to
do. The issue was around the names which show up in the audit page. I
see:
Katello/Product
Katello/Repo
which is a bit ugly. This is due to the audit class storing the type
which it asumes to be a symbol. I can not hack it up in a before_save
callback.
I can think of a few approaches to solve this.
- Add callbacks to the AuditHelper so that the audited_type method
iterates through the callbacks to clean the method name. Plugins could
then register a callback.
- Add a mapping dictionary, which is “From Type => Display Type”.
Plugins could register new mappings
- Enhance the helper to only use the class names, and strip off the
module names.
Are there preferences on an approach? I think it is good for plugins to
add to the audit trail to show a unified experience.
I prefer options a) or b), with plugin registration.
The audits helper is a bit of a mess already, so in the process of
adding helpers for plugins I’d like to see the logic that exists there
moved closer to the models themselves. It would be good to use the same
helpers in both core and plugins.
e.g. instead of a single callback added by each plugin, perhaps each
model could register such a callback for themselves (a bit like the
per-model safemode Jail class) so we keep the logic local.
At the moment we add or change a model, then notice a few months later
that the audit output is poor. Plugins might see the same issue.
–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
> > I thought Katello will be audited through Dynflow tasks. Potentially
> > Foreman will too in future.
> >
> > The dynflow way has advantages:
> > - it keeps much more information
> > - it keeps the information unchanged on model updates
> > - it keeps the information after models are deleted
> > but I have to admit it is not well organized at the moment.
> >
> > I would rather fix the dynflow tasks page to provide better auditing
> > capabilities (the information is already there) then adding audited to
> > Katello.
>
> I think the goal should be a single place to see
>
> 1) What changes has a user done
> 2) What changes have been made to object X
I would rather say:
- What actions the user did
- What actions were performed on the object X
The issues that I always had with the audited plugin is that it's
tight tightly to the ActiveRecord and your local database.
This is not that useful in Katello, as there are many actions
that can't be directly assigned to a change in local database, such
as "synchronize repository", "install a package" or "upload a puppet module". Similarly, in Foreman,
when importing the puppet modules: right now, it shows "admin created Puppetclass motd",
while what the user actually did is importing the classes from the puppet master. When
I cancel a build of a host, I haven't updated the host, I've canceled the build:
when I list the audits for the host, I see 5 updates, but 2 times it means cancelling a build,
2 times it means triggering a build and 1 time it means I've set the puppet ca to the host
(which actually shows in details, that I've changed "Puppet ca proxy" from N/A to N/A). And there
is no record about the fact that I've hit the "Power off" button on the host.
No doubt the audited holds some interesting data and I can imagine it complementing
the informations that come from the tasks (should be not that hard to show the details
from the audited record in the task details), but I believe the Foreman Tasks has better
potential to provide the information on what happened in the system.
It's true right now there are only tasks that involve some orchestration, but it's
completely ok to have a dynflow action that has no async part at all: just a
placeholder to record what happened in the system, what resources it was related to,
what user has triggered it and how to format the information in the task details.
– Ivan
···
----- Original Message -----
> On 06/26/2014 05:15 AM, Petr Chalupa wrote:
I would assume we do not not different places per plugin.
– bk
–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Today… there appear to be 2 commits… one from the user, and later by
dynflow.
– bk
···
On 06/26/2014 06:42 AM, Ohad Levy wrote:
>
> is this true for all objects or just for objects that have additional
> tasks (outside of the db?)
>
>
>
>
> I thought Katello will be audited through Dynflow tasks. Potentially
> Foreman will too in future.
>
> The dynflow way has advantages:
> - it keeps much more information
> - it keeps the information unchanged on model updates
> - it keeps the information after models are deleted
> but I have to admit it is not well organized at the moment.
>
> I would rather fix the dynflow tasks page to provide better auditing
> capabilities (the information is already there) then adding audited
> to Katello.
>
>
> is this true for all objects or just for objects that have additional
> tasks (outside of the db?)
Our goal is to make all changes in Katello done by Dynflow, so dynflow
will track everything. But you've risen a good point, it does not track
everything yet.
···
On 26.06.14 12:42, Ohad Levy wrote:
> On Thu, Jun 26, 2014 at 12:15 PM, Petr Chalupa > wrote:
Petr
On 25.06.14 9:38, Dominic Cleal wrote:
On 25/06/14 02:22, Bryan Kearney wrote:
I looked at hooking up audited into katello, and it was
pretty easy to
do. The issue was around the names which show up in the
audit page. I see:
Katello/Product
Katello/Repo
which is a bit ugly. This is due to the audit class storing
the type
which it asumes to be a symbol. I can not hack it up in a
before_save
callback.
I can think of a few approaches to solve this.
* Add callbacks to the AuditHelper so that the audited_type
method
iterates through the callbacks to clean the method name.
Plugins could
then register a callback.
* Add a mapping dictionary, which is "From Type => Display
Type".
Plugins could register new mappings
* Enhance the helper to only use the class names, and strip
off the
module names.
Are there preferences on an approach? I think it is good for
plugins to
add to the audit trail to show a unified experience.
I prefer options a) or b), with plugin registration.
The audits helper is a bit of a mess already, so in the process of
adding helpers for plugins I'd like to see the logic that exists
there
moved closer to the models themselves. It would be good to use
the same
helpers in both core and plugins.
e.g. instead of a single callback added by each plugin, perhaps each
model could register such a callback for themselves (a bit like the
per-model safemode Jail class) so we keep the logic local.
At the moment we add or change a model, then notice a few months
later
that the audit output is poor. Plugins might see the same issue.
--
You received this message because you are subscribed to the Google
Groups "foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to foreman-dev+unsubscribe@__googlegroups.com
<mailto:foreman-dev%2Bunsubscribe@googlegroups.com>.
For more options, visit https://groups.google.com/d/__optout
<https://groups.google.com/d/optout>.
–
You received this message because you are subscribed to the Google
Groups “foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to foreman-dev+unsubscribe@googlegroups.com
mailto:foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
