The only reason I know of for setting a Resource DELETED (not
uninventoried) is to maintain auditing. But the whole thing seems
misguided because short of reinventorying the same resource you can't
access the audits because the Resource isn't available via the GUI. The
audits would be available for some independent reporting view although
I'm not sure we offer that report (do we?).
Also, we make no attempt that I know of to preserve auditing for
uninventoried resources. I can only guess that since this involves no
physical removal of a resource that it's less of an auditable-critical
event.
The whole idea of restoring something from a DELETED state has never
seemed intuitive to me. If it's deleted I don't think I want to have
some new instantiation be impacted in any way by the previous instance.
I think it would be quite odd to see some old resource history for
something I think I just freshly deployed. Then again, I'm not a real user.
The real downside of the DELETED status is that it creates a lot of
special case code that needs to include or exclude logic or view. I'd
like to see this status go away. It runs contrary to other directions
we're moving towards, like criteria search. This is John's initial
issue. When fetching Resources via Criteria, and requesting child
resources as optional return data, the deleted resources show up in the
children list. We were able to fix this one case but the same is true
for a ResourceType criteria find, fetching resources of the given type.
Again you could get deleted resources. The fix applied in scenario 1
does not work, in this case you'd actually have to do post-processing on
the criteria query results.
As for auditing, it seems we'd maybe be better off offering a system
audit table to capture global audit events cross-system, cross-user,
etc. Then we could track significant CRUD and other events in a single
location accessible in various ways to different users.
Thoughts on keeping or removing this status?
On 3/14/2011 11:30 AM, John Sanda wrote:
I have been investigating an issue in which a resource with an
inventory
status of DELETED was still accessible (in the CLI) with
parentResource.getChildResources(). Then I Iearned that
ResourceFactoryManagerBean.completeDeleteResourceRequest does not
uninventory the deleted resource as I thought was the case. Instead, it
just sets the inventory status of the resource to DELETED. It got me
wondering what the purpose of DELETED is. I wondered why is it that we
want to keep a deleted resource in inventory but take steps to make it
appear as though it is no longer in inventory. The best I could come up
with is that we do it for auditing purposes.
I was going to modify
ResourceFactoryManagerBean.completeDeleteResourceRequest to uninventory
the resource. One problem with that change that was pointed out to me is
that the DeleteResourceHistory audit trail would be removed as part of
the uninventory. Our audit trail would be gone because
DeleteResourceHistory is linked to Resource.
I have noticed that a number of the audit trails, including
DeleteResourceHistory, CreateResourceHistory,
ResourceConfigurationUpdate, PluginConfigurationUpdate,
BundleResourceDeploymentHistory and more, are linked to Resource. The
problem with this is that when a resource is uninventoried we lose what
could be valuable information in those audit trails. If a hard link was
not maintained between the audit trails and Resource, the audit trails
could outlive the corresponding Resource objects. And I wonder if
InventoryStatus.DELETED would then even be needed.
I wanted to get some feedback on this for a couple reasons. First, it
will help provide some better context for a bug I working on. Secondly,
if these changes are feasible, we might be able to simplify some code
where InventoryStatus.DELETED is currently used, and we will be able to
provide more robust audit trails.
Thanks
-John
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel