usage of InventoryStatus.DELETED

John Sanda jsanda at redhat.com
Mon Mar 14 19:23:20 UTC 2011


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



More information about the rhq-devel mailing list