yes, I think that a system should at least be able to report on itself
for security events and things like that. So, user/role modifications,
things like that. And in this case it might be nice to capture that a
physical resource deletion took place (like a WAR file disappearing). Or
other actions that perform physical inventory changes. But I agree
that RHQ does not need to go overboard.
And specifically to this case, I don't think we should complicate the
code bending over backwards to keep some nominally important audit. I
do think the simple addition of a global audit table would be useful
going forward and could relieve us of some pain points.
On 3/14/2011 5:00 PM, John Sanda wrote:
Hi Andreas,
Thanks for the input. I tend to think (and this is just my own opinion)
that auditing is/should be a vital part of the platform. I agree that
the auditing system is too tightly coupled to the resource inventory.
You make some good points around that, and I encourage you to submit a
feature request in bugzilla. There is one point on which I slightly
disagree. I do think that the historic data should be part of RHQ, that
does not mean though it needs to live in the same database as resource
inventory.
- John
On 3/14/11 4:17 PM, Andreas Dietrich wrote:
> Hi,
>
> (we have several customers where we monitor their machines, networks,
> servers etc. and create quarterly, monthly, weekly, ... reports for them).
> Thus auditing is an important issue for us.
>
> But since RHQ in this respect isn't too good at it (and from my point of
> view should not be)*,
> we anyways use some data warehouse (DWH) where we replicate data to
> generate the reports from.
>
> So from a production point of view I would keep RHQ (especially the
> "core" code and the "core" db schema) simple and providing
primarily
> "monitoring and alerting" functionality.
> I would keep other secondary needs like auditing, resource management
> and alike separate (in a modular way) so the core is only loosely
> coupled to those secondary tasks.
>
> ____________________________________________________________
> * One existing example I could give and don't think it should be
> implemented in the "core" RHQ schema is the following:
>
> We use resource group definitions for customer relationship management.
> There are two tables in RHQ that store resource-group relationships
> (implicit and explicit memberships).
>
> It (rarely) happens that we have to rediscover or delete/uninventory
> resources/groups/group definitions/ resource-group-memberships, ....
> A) Thus we can't rely on ids on resources, groups, etc. but rather their
> names, when we want to generate such a report (where the report time
> frame may contain (e.g. id and membership) changes like the above).
> B) We have to consider the lifespan(s) of a resource, group,
> resource-group-membership when we generate the report.
> ...
>
> All this has an - at least significant - influence on the "almost
> duplicated" DWH-RHQ schema:
> 1) some primary keys have to be removed/modified to work with this
> historic data, e.g. the primary key on (resource_id, group_id) for a
> membership mapping must be at least extended to (resource_id, group_id,
> valid_from_date, valid_to_date).
> 2) resources, groups, ... also have to be extended with this
> (valid_from_date, valid_to_date) to be correctly reportable
> 3) We don't think it makes much sense to slow down app/db performance,
> size etc. by keeping this historic data in RHQ.
> ...
> ____________________________________________________________
>
>
> Kind regards
> Andreas :-)
>
>
> On 14.03.2011 20:23, John Sanda wrote:
>> Uninventory does not set the status to DELETED. It sets the status to
>> UNINVENTORIED. The async job looks for resources where Resource.agent is
>> null to determine which resources to purge. When
>> ResourceFactoryManagerBean completes the resource deletion, it set the
>> resource's inventory status to DELETED, but it does not set
>> Resource.agent to null. Other than for auditing purposes, I don't
>> understand the reason for having the DELETED status. If we have audit
>> trails that are independent of the resources to which they are
>> associated, then I believe we can altogether do away with DELETED. By
>> independent, I mean no explicit FK. And since the audit trail could
>> outlive the associated resource, we'd probably want to store something
>> more that the resource id in each audit trail row.
>>
>> On 3/14/11 2:36 PM, John Mazzitelli wrote:
>>> DELETED was also so we can uninventory very fast.
>>>
>>> Before DELETED, if you would uninventory a platform, the UI was
>>> extremely slow and many times would timeout.
>>>
>>> Uninventory now just does a bulk update to flip the status to DELETED
>>> and *poof* resources no longer show up in the UI and it is very fast.
>>>
>>> Note that there is an async job that is supposed to actually delete
>>> resources (these jobs can take long to complete and Joe wrote it so it
>>> wouldn't tx timeout, knowing that this stuff can take a while).
>>>
>>> the flag for this async delete job is a null agent.
>>>
>>> come to think of it, I thought whenever a resource is flagged as DELETE
>>> status, the agent is also nulled out. Thus, now that I think about it,
>>> these resources should be removed at some point (losing audit, yes).
>>> _______________________________________________
>>> rhq-devel mailing list
>>> rhq-devel(a)lists.fedorahosted.org
>>>
https://fedorahosted.org/mailman/listinfo/rhq-devel
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel(a)lists.fedorahosted.org
>>
https://fedorahosted.org/mailman/listinfo/rhq-devel
> _______________________________________________
> rhq-devel mailing list
> rhq-devel(a)lists.fedorahosted.org
>
https://fedorahosted.org/mailman/listinfo/rhq-devel
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel