In the Browse Resources view you used to be able to uninventory services just as you can uninventory platforms and servers. The problem was that people would use this button to stop monitoring a service, but without removing the underlying resource. They would then complain when the service was re-discovered and automatically added back to the inventory. So we removed the uninventory button from the services section, but added a work around of adding "&debug=true" to the query string to reenable the button. This approach too has flaws however, since for people that do legitimately want to remove services external to JON, they have no way of removing the corresponding JON resources without using the workaround above. Perhaps a better approach would be to be bring back the service uninventory button back, but add a warning popup when people are using it, that if the underlying service hasnt been deleted, then it will get rediscovered and added back to the inventory.
Temporarily adding the keyword "SubBug" so we can be sure we have accounted for all the bugs. keyword: new = Tracking + FutureFeature + SubBug
making sure we're not missing any bugs in rhq_triage
This seems to be related to https://bugzilla.redhat.com/show_bug.cgi?id=534750. Although we should probably re-introduce the ability to un-inventory services with some kind of notice to the user, we should also look at a method to un-inventory and ignore services. What might be ideal is on the Auto-Discovery queue page, instead of displaying what is currently being auto-discovered, include everything that has been discovered currently or in the past and give the ability to un-inventory and ignore much like we have with platforms and servers.
re: Comment 3. I think "service ignore" is out of scope for the current release
IIRC, the reason the button was removed was because we were getting a steady stream of customer support cases each week asking why uninventory didn't actually uninventory things. From the user's perspective they would say "I clicked uninventory...but then resource re-appeared a few moments later". So, from their perspective our software looked buggy. We then had to go into a long shpeal about how this feature technically isn't implemented for any resource which isn't a platform or a top-level server (so it encompasses services as well as nested servers like Tomcat) After the "pseudo-fix" of hiding the button, I recall support for this issue going way down. Over the next year or so, I can only remember a handful of times when customers asked about how to remove services, at which point we explained they technically didn't support that (i.e., fessed up to fact that we lacked that feature) but gave them a workaround with explanation. IMO, the solution as it stands today is the superior of the two. Customers will call in...want to know how to do something...we'll have to deliver the bad news (that we don't support ignoring all types of resources yet)...but we balance that with some good news by giving them a known workaround. Personally, I'd rather have users / customers thinking that we have clever, partial work-arounds for shortcomings of the product as opposed to us releasing features that are buggy and produce unexpected results.
It wouldnt be an unexpected result if we warned them before doing the action :-)
the uninventory button should be exposed in the new gwt ui. we still need to add that warning when any services are selected. see my earlier comment about the semantics of uninventorying services to help craft an appropriate warning message.
Simeon, can we put a warning in here re: services?
commit 6996576 when you uninventory any kind of resource, the old message was this: Are you sure you want to uninventory the selected resources? now when you uninventory any kind of resource, the new message is this: Are you sure you want to uninventory the selected resources? Note that if a selected resource still exists, then it will get rediscovered during its agent's next discovery scan. For us devs, this is the Message key "view_inventory_resources_uninventoryConfirm"
this feature has been added. verified during 04/29/2011 qualification cycle.
Bulk closing of old issues that are in VERIFIED state.