usage of InventoryStatus.DELETED

Andreas Dietrich adi at aspicon.de
Mon Mar 14 21:49:31 UTC 2011


Hi John,

maybe we still agree :-) ...
Some things are maybe currently too tightly coupled "under the covers",
but definitely on the user surface everything like historic data, 
auditing infos, resource management, security management or whatever one 
could think of can be nicely integrated.

 From my experience apps like RHQ are "good" in many ways when they 
concentrate on a core functionality and the sugar is loosely coupled 
around it.

Eclipse seems to be a good example. It is basically a tool for software 
development or more basically programming / Java. But a universe of 
functionality can be nicely integrated for the end users.

 From my point of view RHQ is (or wants to be*) a a) resource management 
and b) monitoring/alerting tool.
c) Auditing and d) other mentioned functionality can be an extra 
dimension or view depending on how one sees it.
I don't know if it's good for the developers in the first place (and 
maybe also users) if you try to build this functionality by coupling it 
too tightly.
I think it would be better to have a core functionality of a) or b) (I 
would see b) basically as the superior for end users) and build the 
others around it - loosely coupled.
But that's only my feeling. In the end it pretty much depends on who 
wants to pay for what and if users like it.

* it may or may not currently be, depending on ones requirements

Andreas :-)

PS: Feature requests and co.: we plan to get more active here in the future.


On 14.03.2011 22:00, John Sanda wrote:
> 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
> _______________________________________________
> 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