usage of InventoryStatus.DELETED

John Sanda jsanda at redhat.com
Mon Mar 14 21:00:57 UTC 2011


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 at lists.fedorahosted.org
>>> https://fedorahosted.org/mailman/listinfo/rhq-devel
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel at lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/rhq-devel
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel



More information about the rhq-devel mailing list