Bug 1655083

Summary:	subscription-manager status does not sync syspurpose data from server to client
Product:	Red Hat Enterprise Linux 8	Reporter:	Rehana <redakkan>
Component:	subscription-manager	Assignee:	candlepin-bugs
Status:	CLOSED CURRENTRELEASE	QA Contact:	Red Hat subscription-manager QE Team <rhsm-qe>
Severity:	low	Docs Contact:
Priority:	high
Version:	8.0	CC:	csnyder, jsefler, wchadwic
Target Milestone:	rc	Keywords:	Triaged
Target Release:	8.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-06-14 02:03:50 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 Rehana 2018-11-30 14:24:03 UTC

Description of problem:
As per the earlier discussion QE had an understanding that the syspurpose values modified at the server side will be synced to a registered client during any of the following operations 1) rhsmcertd check 2) auto attach 3)repos list and 4) subscription-manager status (reference : https://polarion.engineering.redhat.com/polarion/#/project/RedHatEnterpriseLinux7/workitem?id=RHEL-139045) . 

It is observed that , all except subscription-manager status is pulling the updated content from server . So this bug is to track this issue 

Version-Release number of selected component (if applicable):
# subscription-manager version
server type: Red Hat Subscription Management
subscription management server: 2.6.0-1
subscription management rules: 5.29
subscription-manager: 1.23.8-2.el8

How reproducible:
Always 

Steps to Reproduce:
1. Register system and set some syspurpose values 

Before executing subscription-manager status , check the syspurpose value on the client :
======================
# syspurpose show
{
  "usage": "Production",
  "role": "foobar",
  "service_level_agreement": "Basic",
  "addons": [
    "",
    "Smart Management"
  ]
}

2.Update syspurpose value for the consumer from server

Create a file with some values at the server side
# cat new_syspurpose
{
"role": "foobar",
"usage": "Production",
"serviceLevel": "Basic",
"addOns": ["RHEL High Availability"]
}

Let's PUT the values to consumer id 

# curl -ik -u username:password --request PUT "https://server:8443/candlepin/consumers/1217a69f-ed70-4541-b68c-2f69600b84a2" -d @./new_syspurpose  --header "Content-Type: application/json"

3.Updated addon value at server side :
===================================
# curl -k -u username:password --request GET "https://server:8443/candlepin/consumers/1217a69f-ed70-4541-b68c-2f69600b84a2?include=addOns&include=rol&include=serviceLevel&include=usage"
{
  "serviceLevel" : "Basic",
  "role" : "foobar",
  "usage" : "Production",
  "addOns" : [ "RHEL High Availability" ]
}

3.Execute subscription-manager status , 

# subscription-manager status
+-------------------------------------------+
   System Status Details
+-------------------------------------------+
Overall Status: Invalid
 
Red Hat Enterprise Linux for x86_64 High Touch Beta:
- Not supported by a valid subscription.
 
Awesome OS Server Bits:
- Not supported by a valid subscription.
 
System Purpose Status: Invalid
 
4. Check the syspurpose value on the system 

# syspurpose show
{
  "usage": "Production",
  "role": "foobar",
  "service_level_agreement": "Basic",
  "addons": [
    "",
    "Smart Management"  --> NOTICE THAT ITS STILL THE SAME VALUE
  ]
}

5.NOW LETS TRY REPO LIST
 
# subscription-manager repos --list
This system has no repositories available through subscriptions.
# syspurpose show
{
  "service_level_agreement": "Basic",
  "addons": [
    "RHEL High Availability"  --> NOTICE THAT THE VALUE IS NOW SYNC UP
  ],
  "usage": "Production",
  "role": "foobar"
}

Actual results:
Observed that the subscription-manager status does not update the latest syspurpose values from server to client

Expected results:
subscription-manager status should sync the values as per the early discussions 

Additional info:

Comment 5 Rehana 2019-01-30 10:15:03 UTC

Verifying on :
============
# subscription-manager version
server type: Red Hat Subscription Management
subscription management server: 2.6.1-1
subscription management rules: 5.31
subscription-manager: 1.23.8-15.el8

Set system purpose values on the system 
# syspurpose show
{
  "addons": [
    "bar",
    "foo"
  ],
  "role": "RHEL Server",
  "service_level_agreement": "Premium",
  "usage": "Production"
}

REgister and auto-attach subscriptions on the system
]# subscription-manager register --auto-attach
Registering to: server:8443/candlepin
Username: admin
Password: 
Organization: admin
The system has been registered with ID: f7cff39d-fd8c-4cd3-b45c-c90fcc08ed03
The registered system name is: kvm-02-guest07.rhts.eng.bos.redhat.com
Installed Product Current Status:
Product Name: Red Hat Enterprise Linux for x86_64 High Touch Beta
Status:       Not Subscribed

Product Name: Awesome OS Server Bits
Status:       Subscribed

Now update the system purpose values at the server side

# cat new_value 
{
"role": "foobar",
"usage": "Production",
"serviceLevel": "Basic",
"addOns": ["RHEL High Availability"]
}
#  curl -ik -u admin:admin --request PUT "https://server-candlepin.usersys.redhat.com:8443/candlepin/consumers/f7cff39d-fd8c-4cd3-b45c-c90fcc08ed03" -d @./new_value  --header "Content-Type: application/json"

check the values at server side now 

# curl -k -u admin:admin --request GET "https://server-candlepin.usersys.redhat.com:8443/candlepin/consumers/f7cff39d-fd8c-4cd3-b45c-c90fcc08ed03?include=addOns&include=serviceLevel&include=usage&include=role"
{
  "serviceLevel" : "Basic",
  "role" : "foobar",
  "usage" : "Production",
  "addOns" : [ "RHEL High Availability" ]

Check the system purpose value on the system , should still be the old value 

]# cat /etc/rhsm/syspurpose/syspurpose.json 
{
  "addons": [
    "bar",
    "foo"
  ],
  "role": "RHEL Server",
  "service_level_agreement": "Premium",
  "usage": "Production"
}

Now run `subscription-manager status` 

# subscription-manager status
+-------------------------------------------+
   System Status Details
+-------------------------------------------+
Overall Status: Invalid

Red Hat Enterprise Linux for x86_64 High Touch Beta:
- Not supported by a valid subscription.

Awesome OS with up to 4 virtual guests:
- Guest has not been reported on any host and is using a temporary unmapped guest subscription. For more information, please see https://access.redhat.com/solutions/1592573

System Purpose Status: Unknown

AND verify the system purpose values 

# syspurpose show
{
  "addons": [
    "RHEL High Availability"
  ],
  "role": "foobar",
  "service_level_agreement": "Basic",
  "usage": "Production"
}
System purpose successfully sent to subscription management server.

^^ Successfully synced data from server to client 

rhsm.log
==========

2019-01-30 05:07:04,134 [DEBUG] subscription-manager:18294:MainThread @connection.py:591 - Making request: GET /candlepin/status
2019-01-30 05:07:05,387 [INFO] subscription-manager:18294:MainThread @connection.py:638 - Response: status=200, requestUuid=237db2c5-0d81-496e-baea-b36e585a2636, request="GET /candlepin/status"
2019-01-30 05:07:05,388 [DEBUG] subscription-manager:18294:MainThread @connection.py:969 - Server has the following capabilities: ['instance_multiplier', 'derived_product', 'vcpu', 'cert_v3', 'remove_by_pool_id', 'syspurpose', 'storage_band', 'cores', 'hypervisors_async', 'org_level_content_access', 'guest_limit', 'ram', 'batch_bind']
2019-01-30 05:07:05,389 [DEBUG] subscription-manager:18294:MainThread @connection.py:543 - Loaded CA certificates from /etc/rhsm/ca/: redhat-uep.pem, candlepin-ca.pem
2019-01-30 05:07:05,389 [DEBUG] subscription-manager:18294:MainThread @connection.py:591 - Making request: GET /candlepin/consumers/7ac08f4b-f52c-4f9d-9e5d-34e4c7a9699c
2019-01-30 05:07:06,975 [INFO] subscription-manager:18294:MainThread @connection.py:638 - Response: status=200, requestUuid=a9703571-10cd-4d02-af73-278d38ca3a1e, request="GET /candlepin/consumers/7ac08f4b-f52c-4f9d-9e5d-34e4c7a9699c"
2019-01-30 05:07:06,976 [DEBUG] subscription-manager:18294:MainThread @files.py:344 - Successfully read remote syspurpose from server.
2019-01-30 05:07:06,976 [DEBUG] subscription-manager:18294:MainThread @files.py:548 - Attempting a three-way merge...
2019-01-30 05:07:06,976 [DEBUG] subscription-manager:18294:MainThread @files.py:580 - Three way merge: remote value was changed for key 'role'.
2019-01-30 05:07:06,977 [DEBUG] subscription-manager:18294:MainThread @files.py:580 - Three way merge: remote value was changed for key 'service_level_agreement'.
2019-01-30 05:07:06,977 [DEBUG] subscription-manager:18294:MainThread @files.py:580 - Three way merge: remote value was changed for key 'addons'.
2019-01-30 05:07:06,977 [DEBUG] subscription-manager:18294:MainThread @connection.py:543 - Loaded CA certificates from /etc/rhsm/ca/: redhat-uep.pem, candlepin-ca.pem
2019-01-30 05:07:06,978 [DEBUG] subscription-manager:18294:MainThread @connection.py:591 - Making request: PUT /candlepin/consumers/7ac08f4b-f52c-4f9d-9e5d-34e4c7a9699c
2019-01-30 05:07:08,256 [INFO] subscription-manager:18294:MainThread @connection.py:638 - Response: status=204, requestUuid=5c6c3992-886c-4879-a2d0-2cc37de1a909, request="PUT /candlepin/consumers/7ac08f4b-f52c-4f9d-9e5d-34e4c7a9699c"
2019-01-30 05:07:08,257 [DEBUG] subscription-manager:18294:MainThread @files.py:381 - Successfully updated remote syspurpose on the server.
2019-01-30 05:07:08,258 [DEBUG] subscription-manager:18294:MainThread @files.py:502 - Successfully updated syspurpose values at '/etc/rhsm/syspurpose/syspurpose.json'.
2019-01-30 05:07:08,258 [DEBUG] subscription-manager:18294:MainThread @files.py:502 - Successfully updated syspurpose values at '/var/lib/rhsm/cache/syspurpose.json'.
2019-01-30 05:07:08,258 [DEBUG] subscription-manager:18294:MainThread @files.py:292 - Successfully synced system purpose.