Bug 1283715

Summary: On Satellite the entitlements are not stackabl, Entitliments up to 2 socket are not appear under the physical client with 4 or more sockets
Product: Red Hat Satellite Reporter: Fotios Tsiadimos <ftsiadim>
Component: CandlepinAssignee: satellite6-bugs <satellite6-bugs>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Lai <ltran>
Severity: high Docs Contact:
Priority: high    
Version: 6.3.0CC: bcourt, bkearney, dzr0001, ftsiadim, jturel, mschibli, ojanus, redakkan, rjerrido, sreber, tomckay
Target Milestone: UnspecifiedKeywords: PrioBumpPM, Reopened, Triaged
Target Release: Unused   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-07-29 07:54:40 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Fotios Tsiadimos 2015-11-19 16:29:15 UTC
Description of problem:

On Satellite  the entitlements are not stackabl,  Entitliments up to 2 socket are not appear under the physical client with 4 or more sockets



Version-Release number of selected component (if applicable):

Satellite 6.1.3

How reproducible:

Try to attach 2 entitlements up to 2 sockets for a physical server with 4 sockets.

The entitlements are not appear in the list of the client

In the customer portal we can attach multiple entitlements to reach the sockets of the server. 



From the working:

 $ grep -i cpu dmidecode 
	Socket Designation: CPU1
	Version: Intel(R) Xeon(R) CPU           E5630  @ 2.53GHz
	Socket Designation: CPU2
	Version: Intel(R) Xeon(R) CPU           E5630  @ 2.53GHz
		CPU.Socket.1
		CPU.Socket.2



From the not working:

 $ grep -i cpu dmidecode 
	Socket Designation: CPU1
	Version:       Intel(R) Xeon(R) CPU E7-8891 v2 @ 3.20GHz
	Socket Designation: CPU2
	Version:       Intel(R) Xeon(R) CPU E7-8891 v2 @ 3.20GHz
	Socket Designation: CPU3
	Version:       Intel(R) Xeon(R) CPU E7-8891 v2 @ 3.20GHz
	Socket Designation: CPU4
	Version:       Intel(R) Xeon(R) CPU E7-8891 v2 @ 3.20GHz
		CPU.Socket.1
		CPU.Socket.2
		CPU.Socket.3
		CPU.Socket.4

From the rhsm.log

2015-11-12 05:21:10,624 [DEBUG]  @connection.py:460 - Response status: 200
2015-11-12 05:21:10,642 [INFO]  @repolib.py:158 - repos updated: 0
2015-11-12 05:21:10,659 [DEBUG]  @hwprobe.py:518 - cpu info: {'cpu.cpu(s)': 80, 'cpu.core(s)_per_socket': 10, 'cpu.thread(s)_per_core': 2, 'cpu.topology_source': 'kernel /sys cpu sibling lists', 'cpu.cpu_socket(s)': 4}
2015-11-12 05:21:10,960 [INFO]  @factlib.py:57 - Facts have not changed, skipping upload.

Comment 1 Tom McKay 2015-11-24 15:20:53 UTC
Please provide manifest as a private attachment.

Comment 3 Bryan Kearney 2016-07-26 15:25:24 UTC
Moving 6.2 bugs out to sat-backlog.

Comment 4 Bryan Kearney 2016-07-26 15:38:25 UTC
Moving 6.2 bugs out to sat-backlog.

Comment 6 Bryan Kearney 2016-10-04 20:50:53 UTC
We have been waiting on needinfo for a while. I am closing this out. If you have the additional information, please feel free to re-open.

Comment 9 Bryan Kearney 2018-09-04 17:59:29 UTC
Thank you for your interest in Satellite 6. We have evaluated this request, and we do not expect this to be implemented in the product in the foreseeable future. We are therefore closing this out as WONTFIX. If you have any concerns about this, please feel free to contact Rich Jerrido or Bryan Kearney. Thank you.

Comment 10 Markus Schibli 2018-10-05 10:21:54 UTC
(In reply to Bryan Kearney from comment #9)
> Thank you for your interest in Satellite 6. We have evaluated this request,
> and we do not expect this to be implemented in the product in the
> foreseeable future. We are therefore closing this out as WONTFIX. If you
> have any concerns about this, please feel free to contact Rich Jerrido or
> Bryan Kearney. Thank you.

Hi Brian,

I took over the TAM role from Simon for the customer Raiffeisen. 

I can't believe that Red Hat closes this case and accepts that customers do not have to pay for the services they actually consume. 

We re-open this bug and again, with Satellite 6.3 we now have socket count reported for hypervisors via `virt-who`. But we still can't attach two VDC subscriptions to a 4 socket system to correctly subscribe the system (at least not if the subscription is coming from the same contract). Without solving this issue, customer can just add 1 (!) VDC subscription to a 4 socket system. 

I don't have a 4 socket server and no manifest to reproduce that problem, but you can easily create a manifest with two VDC with the following tool: 

http://account-manager-stage.app.eng.rdu2.redhat.com/#create

Last comment, yesterday in the weekly TAM Call with the customer, the comment from customer regarding the closure of this bug was, "He can't believe that Red Hat is acting like this... that's against Red Hat's business model itself"

Would be nice if you re-think about providing a fix for that issue. Thanks.

Comment 11 Bryan Kearney 2018-11-01 14:44:42 UTC
The Satellite Team is attempting to provide an accurate backlog of bugzilla requests which we feel will be resolved in the next few releases. We do not believe this bugzilla will meet that criteria, and have plans to close it out in 1 month. This is  not a reflection on the validity of the request, but a reflection of the many priorities for the product. If you have any concerns about this, feel free to contact Rich Jerrido or Bryan Kearney or your account team. If we do not hear from you, we will close this bug out. Thank you.