1. Proposed title of this feature request

Answer: "Improve Release Notes and related documentation for API response changes between Satellite major and minor releases."

2. Who is the customer behind the request?

Answer: See private comment

3. What is the nature and description of the request?

Answer: The customer recently updated from 6.13 to 6.14.  After the upgrade, certain automation tasks were failing due to API changes.  The API response change was not evident in the release notes, therefore, the customer was unprepared.  During previous versions, lifecycle_environment_name was a standalone element in the response JSON - it was also available as part of the lifecycle_environment group (sub-element name).  With the 6.14 upgrade the stand alone field was removed which caused a number of customer API calls to fail. 

Below is the entry within the 6.14 release notes that encompasses this API change.  This does not clearly convey the API change to the customer.

—

Hosts will now be assigned Content Views and lifecycle environments as a single unit

As a result of an upcoming Satellite feature, hosts will now be assigned Content Views and lifecycle environments as a single unit instead of separately. Hostgroups will be required to assign both a Content View and a lifecycle environment to a host simultaneously. This ensures that a host cannot have a lifecycle environment without an associated Content View.

Jira:SAT-19305

4. Why does the customer need this? (List the business requirements here)

Answer: The customer would like to include details of individual API response changes in future release notes and other related documentation.  This way, they can respond proactively when these types of API response changes are made and coordinate with their automation teams to prevent failures.             

5. How would the customer like to achieve this? (List the functional requirements here)

Answer: Red Hat should provide specific detail around individual API response changes in customer facing documentation and release notes.  These changes should be detailed in current and future versions.

6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.

Answer: The customer could review the documentation to verify it meets their requirements.

7. Is there already an existing RFE upstream or in Red Hat Bugzilla?

Answer: No

8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL8, RHEL9)?

Answer: As soon as possible. They are currently looking to move to 6.15, but are apprehensive due to the potential of other unforeseen changes based on their experience with the 6.14 upgrade.  They believe this creates unnecessary risk as they aren't able to appropriately prepare for changes that have not been clearly documented.

9. Is the sales team involved in this request and do they have any additional input?

Answer: Yes, the sales team is aware.  They agree that we should improve upon this as the customer's point is valid and has caused issues for the customer.

10. List any affected packages or components.

Answer: Satellite 6.x