Goal:

• transfer the TP split update KCS to the minor update guide. 
• Remove any Tech Preview notes.

Acceptance Criteria:

• Split update chapter is republished in the minor update guide.

Mini Content Journey

• Docs
  • The two procedures are documented as separate from each other (OpenStack update, system update).
  • We should warn that customizing the package list for updating within OpenStack update can result in updates of RPMs that would require a reboot - customizations of that package list should be validated by the customer.
  • The system update procedure documentation mentions that the procedure is optional – alternatively tools like Satellite can be used to update the system. The docs should warn that the system update should happen within the EUS stream. (So that users don't go updating to RHELs we don't support.)

Reviewers:

• Technical: Jiri Stransky, Mikolaj Ciecierski
• Peer: TBD
• QE: Archana Singh?

Is this feature fully supported or technical preview?

• Full support: Documentation will be published on the customer portal
• The KCS will be transferred to the main guide, and the KCS will be retired. The 1.6 "Separate OpenStack and RHEL RPM updates" module can be removed since its only purpose was to link to the split update KCS. 

Does the procedural content need to be tested by QE?

• Yes: QE needs to create a doc testing ticket per How-to Jira with the docs team
• How will any doc changes be shared with me?

Does the documentation epic need a release note in addition to the feature?

• Yes: Writer fills in the Release Note Text and Release Note Type in the doc epic fields. This is not the engineering epic. This RN is usually reserved for documentation epics that trail behind product features or that cover functionality that doesn't have a parent feature (rare but still happens).
• No: The engineering feature or epic might still need a release note. Engineers need to follow the guidance set in[      How-to Jira with the docs team|https://spaces.redhat.com/display/RHOSPDOC/How-to-Jira+with+the+RHOS+docs+team].

What stage of the user journey are you targeting?

• Try / day 2 operations.

Who is your target persona?

• RHOSO admin

What type of information does the user need to know in order to use the feature?

• Procedures to implement or enable the feature
• Procedures to customize or configure the feature after installation
• => Procedures or considerations for upgrades, adoption, or minor updates
• Procedures to verify that the feature is enabled and is working as expected
• Procedures to operate or maintain the feature
• Concepts that need to be explained or planning decisions that must be made before the user can perform any of these procedures
• Permissions level required (RHOSO/OCP) or security considerations
• => Known issues, limitations, or troubleshooting guidance

Are there any existing upstream or internal resources that the writer can use for planning and drafting the content? Consider the situational context of the existing content. Do a Google search for any possible resources that might help.

• Link to existing KCS: https://access.redhat.com/articles/7127609 

Does the content require input from multiple DFGs?

• No

Does the content need to be included in any of the following guides?

• Minor updates guide