+++ This bug was initially created as a clone of Bug #1660878 +++ Description of problem: Currently, querying the syspurpose status of a consumer, either by using the /consumers/{consumer_uuid}/purpose_compliance API, or by fetching the consumer with the /consumers/{consumer_uuid} API and then reading the systemPurposeStatus field on that, will show the status to be one of valid/partial/invalid. This does not fit with the original design, which is to return one of these states as a status: matched/mismatched/not specified. Version-Release number of selected component (if applicable): All current versions that support syspurpose, up to 2.5.8, 2.3.11 and master. How reproducible: 100% Steps to Reproduce: 1. Perform a GET request on the /consumers/{consumer_uuid}/purpose_compliance API and check the value of the 'status' field. Actual results: The status field has the value of either valid, invalid, or partial. Expected results: The status field should have the value of either matched, mismatched, or not specified. Additional info: An additional minor issue is that the response's 'reasons' include two reasons for each non-compliant SLA or usage, while there should be one for each. --- Additional comment from Chris Snyder on 2019-01-10 15:24:07 UTC ---
*** Bug 1654344 has been marked as a duplicate of this bug. ***