I'd like to do a quick analysis to see whether renaming the CPU platform service type to be CPU Core would make it a better description of whats actually being monitored. Steps required: a) Double check the current CPU resources, really do map to core not sockets. I believe after https://bugzilla.redhat.com/show_bug.cgi?id=536022 that they should do. b) Determine if we should be using the patched version of Sigar that has fixes for the issue described here: https://bugzilla.redhat.com/show_bug.cgi?id=714249. If there is too much risk in the new Sigar version, then that can be pushed. c) Determine if the are any unexpected side-effects from updating the resource type name. Maybe we should consider updating the default resource name too?
(In reply to comment #1) > c) Determine if the are any unexpected side-effects from updating the resource > type name. Maybe we should consider updating the default resource name too? this isn't as simple as "just edit rhq-plugin.xml and change "CPU" to "CPU Core". because of existing resources, we might have to play with some db-upgrade stuff. Changing type names will look as though we REMOVED the one type and ADDED the new type (we have no way of indicating "rename CPU to CPU Core". It only looks like the "CPU" type is gone and this new one called "CPU Core" now exists. This is a known limitation with plugin metadata upgrade.
We could change the resource NAME that we discover. That's easy to do in the platform plugin Java code. The resource TYPE name can still be CPU, but rather than name them "CPU 0" or "CPU 1" we can name them "CPU Core 0" or "CPU Core 1". The type name stays the same so the metadata doesn't change. Its only new resources that are discovered get new names. We coudl add db-upgrade script to change existing names like CPU 0 to CPU Core 0. UPDATE RHQ_RESOURCE SET NAME='CPU Core 0' WHERE NAME='CPU 0' UPDATE RHQ_RESOURCE SET NAME='CPU Core 1' WHERE NAME='CPU 1' ... UPDATE RHQ_RESOURCE SET NAME='CPU Core 32' WHERE NAME='CPU 32'
Add a needsinfo on luikas to comment on the resource type changes, given his experience with apache. Depending on how he responds then we could look at just doing the resource name change.
As John said, there is no easy way of renaming a resource type apart from playing games in db-upgrade. As for the renaming the names of the existing resources, there is a "hidden" feature of the ResourceUpgradeFacet that enables that. The ResourceUpgradeFacet can supply a new name of an existing resource, but on the server we don't apply it because it was deemed an unnecessary complication (what about resources that were renamed by the user?). So on the server side, there is a system setting called RESOURCE_GENERIC_PROPERTIES_UPGRADE which defaults to false (and is currently defined as read-only and not visible in the UI). If that switch is flipped to true, the server will start to accept the resource name suggestions from the resource upgrades. Of course it is perfectly possible to use db-upgrade for that as well. I just wanted to highlight the other (cleaner?) way. If that switch was visible, the user could still have an option of saying "no, i don't want my resources renamed by some stupid plugins".
See also https://bugzilla.redhat.com/show_bug.cgi?id=749121 about an issue of core counting in our Sigar version.
Deprioritized for upcoming release.