Uploaded image for project: 'Red Hat OpenStack Services on OpenShift'
  1. Red Hat OpenStack Services on OpenShift
  2. OSPRH-15589

Documention for Minor update RHEL 9.2 to RHEL 9.4 and to RHEL 9.6 after adoption

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • rhos-18.0.10 FR 3
    • documentation
    • None
    • Documention for Minor update RHEL 9.2 to RHEL 9.4 after adoption
    • False
    • Hide

      None

      Show
      None
    • False
    • ?
    • RHOSSTRAT-865 - Granular Package Update Workflow for RHOSO compute nodes during the RHOSO update process - GA
    • ?
    • rhos-ops-day1day2-upgrades
    • ?
    • 50% To Do, 0% In Progress, 50% Done
    • Release Note Not Required

      Adoption will assume a source environment of OSP17.1 RHEL 9.2. The data plane adoption procedure itself will result in an OSP18 RHEL 9.2 environment. Once complete, a minor update from RHEL 9.2. to 9.4 needs to be completed. This will be a documented step in the adoption guide, and will consist only of RPM updates (RHEL minor update procedure).

      We do need to take the OVS rpm update procedure into consideration, https://issues.redhat.com/browse/OSPRH-6141

      {}This doc epic should probably be refined based on the "Separate OpenStack update from RHEL RPMs update"{} https://issues.redhat.com/browse/OSPRH-13841 

      Detailed doc plan template for refinement:

      • Is this feature fully supported or technical preview?
        • Full support: Documentation will be published on the customer portal
        • Tech preview (TP): Documentation is not published, release note only
        • TP exception: If there is a strong customer demand for testing this feature and the writer has capacity, dev/PM can author a KB article or gdoc and if the writer has capacity they can review/edit the article.
        • A: Full support
      • Does the procedural content need to be tested by QE?
      • Does the doc epic need a release note in addition to the parent feature?
        • Yes - Writer fills in the Release Note Text and Release Note Type in the doc epic fields (not the engineering epic)
        • 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.]
        • A: After FR2 there are no release notes on epics. We need to find the right Feature to place this Epic.
      • Are there any upstream or internal resources that the writer can use for planning and drafting the content?
        • <LINKS>
        • <If there are no links available at the time of doc planning, writer creates spikes or tasks to collect this information later from the DFG>
        • A: Not right now but the engineering should provide some. Either a doc or an upstream patch.
      • Does the content require input from multiple DFGs?
        • Yes - Writer creates spikes or stories under this epic and assign them to the relevant writers for scoping
        • No - Stories are not required unless the epic needs to be divided to user stories that can be delivered separately (for personal use, consider sub-tasks instead)
        • A: No
      • 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
        • A:
          • The procedure for switching the EUS stream
          • The procedure for verifying that the EUS switch happened
          • Considerations:
            • With an EUS stream switch there must be a reboot. There will be considerations relating to that about workloads evacuation slide puzzle.
      • Does the content need to be included in any of the following guides?
        • Validated architecture (VA) guide: Is the content a part of a VA workflow, such as HCI, NFV, BGP, etc?
        • Planning guide: Are there prerequisites or planning decisions to add to the Planning guide? 
        • Deployment/Customization guide: Does the feature need to be enabled during the deployment  process, or can it be enabled post-deployment?
        • Adoption/minor updates guide: Are there any considerations or impact of this feature on adoption from pre-18 environments or from earlier 18z versions?
        • A:
          • The content goes into the minor update guide.
          • Adoption guide should mention that the EUS stream switch (upgrade from 9.2 to 9.4) is an optional post-adoption action, and link to the content in the update guide.

              kgilliga@redhat.com Katie Gilligan
              jslagle@redhat.com James Slagle
              Alan Pevec
              rhos-dfg-upgrades
              Votes:
              0 Vote for this issue
              Watchers:
              14 Start watching this issue

                Created:
                Updated: