Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1685898 - Need clarity on the "system purpose status" when only a layered/blank SLA subscription is attached on the system
Summary: Need clarity on the "system purpose status" when only a layered/blank SLA sub...
Keywords:
Status: NEW
Alias: None
Product: Candlepin
Classification: Community
Component: candlepin
Version: 2.3
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: candlepin-bugs
QA Contact: Katello QA List
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-06 09:16 UTC by Rehana
Modified: 2019-04-08 18:08 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)

Description Rehana 2019-03-06 09:16:03 UTC
Description of problem:
This bug has been created to have better understanding on the current implementation of "system purpose status" when the system has a layered / blank sla subscription is attached on the system 

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


How reproducible:
Always 

Steps to Reproduce:
1.Create a account with only "Layered" SLA subscription
2.Set sla to "Premium"
3.Since the layered SLA subscription was not available for 479.pem , to demonstrate the scenario 83.pem "Red Hat Enterprise Linux High Availability for x86_64" is installed on the system

[root@kvm-02-guest20 ~]# syspurpose show
{
  "service_level_agreement": "Premium"
}
Unable to send system purpose to subscription management server

# subscription-manager register --username=***** --password=** --auto-attach
Registering to: subscription.rhsm.stage.redhat.com:443/subscription
The system has been registered with ID: 322b8ff1-0491-422d-a2a8-669f5ae47caf
The registered system name is: kvm-02-guest20.rhts.eng.bos.redhat.com
Installed Product Current Status:
Product Name: Red Hat Enterprise Linux High Availability for x86_64
Status:       Subscribed

[root@kvm-02-guest20 ~]# subscription-manager list --consumed
+-------------------------------------------+
   Consumed Subscriptions
+-------------------------------------------+
Subscription Name:   High Availability for Unlimited Guests
Provides:            Red Hat Enterprise Linux High Availability for x86_64
SKU:                 RH00059
Contract:            11855476
Account:             6195180
Serial:              1350641437950457139
Pool ID:             8a99f9a6692bd0a501694d01f6b40676
Provides Management: No
Active:              True
Quantity Used:       1
Service Level:       Layered
Service Type:        L1-L3
Status Details:      Guest has not been reported on any host and is using a temporary unmapped guest subscription.
Subscription Type:   Stackable (Temporary)
Starts:              Tuesday 05 March 2019
Ends:                Wednesday 13 March 2019
System Type:         Virtual

[root@kvm-02-guest20 ~]# subscription-manager status ;syspurpose show
+-------------------------------------------+
   System Status Details
+-------------------------------------------+
Overall Status: Insufficient

High Availability for Unlimited Guests:
- Guest has not been reported on any host and is using a temporary unmapped guest subscription.

System Purpose Status: Mismatched

Actual results:
Notice the status is "Mismatched"

Expected results:
Ideally the status should be "Matched" as the Layered SLA/ Not specified are a valid match for any sla. But this bug has been created to get clarification about the current implementation which considers "Layered: SLA subscription as a mismatched case

Additional info:

Comment 1 John Sefler 2019-03-06 13:58:33 UTC
I want to change the title of this bug to....

Need clarity on the "system purpose status" when only a subscription with a "support_level_exempt":"true" is attached on the system


The point is that Red Hat subscriptions with a "Layered" SLA imply that the "support_level_exempt":"true" is also set on the pool's product attributes as shown here...

[root@jsefler-rhel7 ~]# curl --stderr /dev/null -k -u REDACTED:REDACTED  --request GET 'https://subscription.rhsm.stage.redhat.com:443/subscription/pools/8a99f9a6692bd0a501694d01f6b40676?include=productAttributes' | python -m json/tool
{
    "productAttributes": [
        {
            "name": "host_limited",
            "value": "true"
        },
        {
            "name": "product_family",
            "value": "Red Hat Enterprise Linux"
        },
        {
            "name": "enabled_consumer_types",
            "value": "SAM"
        },
        {
            "name": "ph_product_line",
            "value": "RHEL"
        },
        {
            "name": "support_level_exempt",   <====== LOOK HERE
            "value": "true"                   <====== LOOK HERE
        },
        {
            "name": "description",
            "value": "Red Hat Enterprise Linux"
        },
        {
            "name": "ph_category",
            "value": "Subscriptions"
        },
        {
            "name": "stacking_id",
            "value": "RH00059"
        },
        {
            "name": "support_level",   <====== LOOK HERE
            "value": "Layered"         <====== LOOK HERE
        },
        {
            "name": "type",
            "value": "MKT"
        },
        {
            "name": "ph_product_name",
            "value": "High Availability"
        },
        {
            "name": "service_type",
            "value": "Layered"
        },
        {
            "name": "multi-entitlement",
            "value": "yes"
        },
        {
            "name": "expires_after",
            "value": "365"
        },
        {
            "name": "subtype",
            "value": "Layered"
        },
        {
            "name": "virt_limit",
            "value": "unlimited"
        },
        {
            "name": "name",
            "value": "High Availability for Unlimited Guests"
        },
        {
            "name": "variant",
            "value": "High-Availability"
        },
        {
            "name": "arch",
            "value": "ia64,ppc,ppc64,ppc64le,x86,x86_64"
        },
        {
            "name": "sockets",
            "value": "2"
        },
        {
            "name": "support_type",
            "value": "L1-L3"
        }
    ]
}


The point of this bug is to clarify where or not an attached SKU with an "support_level_exempt":"true" should contribute to the System Purpose Status as a match to the system's "Premium" service level.   My understanding is that a SKU with an exempt service level (or a blank/empty/null/absent service-level) was not to be excluded by the old auto-attachment algorithm prior to syspurpose capabilities.  With the new syspurpose capabilities, the service-level value no longer excludes any availabile pools to the auto-attachment algorithms, instead the value is only used as a priority preference.  

In my opinion, a pool with a blank or "support_level_exempt":"true" should NOT CONTRIBUTE to the System Purpose Status.  That means...
 - when only one exempt pool is attached to a system with no sla set for system purpose, the System Purpose Status should be "Not Specified".
 - when only one exempt pool is attached to a system with a sla set for system purpose, then System Purpose Status should be "Mismatched" (even if the string value was a match)

Comment 2 John Sefler 2019-03-06 14:23:00 UTC
(In reply to John Sefler from comment #1)
> In my opinion, a pool with a blank or "support_level_exempt":"true" should
> NOT CONTRIBUTE to the System Purpose Status.  That means...
>  - when only one exempt pool is attached to a system with no sla set for
> system purpose, the System Purpose Status should be "Not Specified".
>  - when only one exempt pool is attached to a system with a sla set for
> system purpose, then System Purpose Status should be "Mismatched" (even if
> the string value was a match)

If you accept this opinion, then the case in comment 0 is correct because there is no SKU attached that matches the service-level preference.


And to follow up with one more test, let's check the System Purpose Status when SLA preference is set to "Layered" while a exempt service layer pool is attached...

[root@kvm-01-guest25 ~]# subscription-manager list --consumed
+-------------------------------------------+
   Consumed Subscriptions
+-------------------------------------------+
Subscription Name:   High Availability
Provides:            Red Hat Enterprise Linux High Availability for x86_64
SKU:                 RH00025
Contract:            11843874
Account:             6189200
Serial:              7204972771596478303
Pool ID:             8a99f9a86885be6c01689c8af47b2b41
Provides Management: No
Active:              True
Quantity Used:       1
Service Level:       Layered                     <============ LOOK HERE (from an exempt pool)
Service Type:        L1-L3
Status Details:      Subscription is current
Subscription Type:   Instance Based
Starts:              01/29/2019
Ends:                01/28/2020
System Type:         Physical

[root@kvm-01-guest25 ~]# syspurpose set-sla "Layered"
service_level_agreement set to Layered
System purpose successfully sent to subscription management server.

[root@kvm-01-guest25 ~]# subscription-manager status
+-------------------------------------------+
   System Status Details
+-------------------------------------------+
Overall Status: Invalid

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

System Purpose Status: Matched    <============= FAILED: Expected "Mismatched" because the exempt pool is not supposed to contribute to the status


Having made this argument, it would be clearly confusing to accept my opinion.  This simplest solution would be to leave the current implementation which appears to treat exempt service level subscriptions as equal contributors to the System Purpose Status.


Note You need to log in before you can comment on or make changes to this bug.