usage of InventoryStatus.DELETED

John Mazzitelli mazz at redhat.com
Mon Mar 14 19:42:04 UTC 2011


ahhh ok.. that's right. DELETED is for when you delete WARs and things.

OK, then would another purpose of DELETED be so we don't auto-discovery 
the same thing again??? I guess if we deleted something it would not get 
auto-discovered so maybe not.

On 03/14/2011 03:23 PM, 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


More information about the rhq-devel mailing list