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