+++ This bug was initially created as a clone of Bug #596917 +++
2) Nature Of Problem:
While Satellite 5.3.0 now has the ability to get the number of CPUs via
API call, the customer would also like to grab the number of sockets from
the registered systems.
4) Functional Requirements That Are Not Presently Possible:
be able to get the number of physical cpus (sockets) in a managed system
from satellite via API call
5) What Will Success Look Like:
API call at returns the number of sockets. something added to getCPU
--- Additional comment from Issue Tracker on 2010-05-27 14:50:55 EDT ---
Event posted on 05-19-2010 01:46pm EDT by kbaxley
resubmitting this RFE...previously there was a request open to have the
ability to extract the number of CPU's from a system via API call. We
implemented this for Satellite 5.3, but, the customer would like to take
this a step further and has asked for an RFE to have an API call that will
pull out the number of physical CPUs (sockets) that a system has.
They've also asked that this be done via spackewalk-reports, but, I
don't believe it has much of a chance. This particular RFE will probably
have the same for the same reasons as below, but, the customer would prefer
to use the API:
https://bugzilla.redhat.com/show_bug.cgi?id=593584
This event sent from IssueTracker by cww [SEG - Feature Request]
issue 289757
--- Additional comment from Clifford Perry on 2010-06-02 14:59:45 EDT ---
So the scope of the change requires:
1) Client changes to capture and send up more detailed information of CPU cores and sockets.
2) Server side schema changes to store new data, (plus backend to insert it correctly as part of hardware profiles)
3) WebUI for system details & hardware pages to display information
4) System Search changes to expose this data in searches
5) spacewalk-reports to report this new data
6) new/enhanced API calls to provide the data
The biggest initial hurdle, if this is accepted is to clone RFE to RHEL 4, 5 and 6 RHN Clients to propose and track for next releases of each OS version and then also make all Satellite changes (2 -> 6).
Cliff
--- Additional comment from Stephen Herr on 2013-04-04 11:21:54 EDT ---
I have split this request into two bugs since there really are two logical steps in making this functionality available.
1) The RHEL client tools must be updated to pass socket information to Satellite
2) Satellite must be updated to store / display socket information
I have created bug 948326 to track the development / release of #1, the client tools updates. This bug will continue to track the development / release of #2, the Satellite update. Both will be necessary for this functionality to work.
We will likely not do #4 in Cliff's list: making socket information searchable. Everything else should currently be available in Spacewalk master through these commits:
7ccda3c0bc634e96a572c4530d6839c4b7e00505
69016b8a4d4a07d2869d92e35ea90e939a291b96
36c64513d68cad3a3973d76de91529f473afdd15
53257058ba0b52b56948fc90798d5c599e535172
29c95600f79f2a9aa9e699f47e8253d0ab69bf69
65b8c9413c7ef714296233003a2b58c18b069a91
ef063db763e503e89ee3e376b2d98c2f0ced69f8
Also:
cfaee23bfef0a7be8d9f755b8b3932560c1ddfd9
Satellites that are installed with spacewalk-schema-1.10.42-1 or later will not default to setting the number cpu sockets to 1 in the database. Instead we will simply leave that field null if we don't know.