Uploaded image for project: 'RHEL Documentation'
  1. RHEL Documentation
  2. RHELDOCS-18195

[Scoping]Modify RHEL Storage documentation to better match RHEL use cases

XMLWordPrintable

    • Adding better Storage use cases
    • sst_logical_storage, sst_storage_io
    • False

      Feature Overview

      Linux has a broad set of storage capabilities, a subset of which are included in RHEL.  The best capabilities supported in RHEL support to the most common use cases for RHEL servers in corporate data centers. Because storage protocols and technologies are deployed in many different scanrios - depending on their context in the customer's infrastructure - it's important for Red Hat documentation to describe each technology in the correct context. This was one of the key goals when the documentation teams restructured the RHEL documentation for the RHEL 8 release. Here is the universe of storage technologies most used in RHEL.

      This Jira feature is included under the market problem that define how customers require simplified storage consumption options. Those simplifications are sometimes built into newer and better user interface designs. but they can also be supported by documentation that instead of generically explaining a feature or function, describes the best practices most often used when deploying storage with RHEL. 

      The key element to document:  How do customers consume storage when they are using RHEL as their server operating system?

      While we are constantly researching better answers to this question (which we'll capture in this set of features and stories), we have a general sense of the major ways storage is consumed, and should modify our documentation to better capture these known scenarios.

      The most common uses for RHEL storage capabilities are: 

      • Setting up a root device.  This is generally during the installation process, and includes disk partitioning, basic volume setup, and setting up a local file system layout using one of the supported local file systems (XFS [the default] and ext4)
      • Setting up a server to consume external storage (setting up storage initiators using Fibre Channel, iSCSI or NVMe, deploying multipathing, attaching to a network file system)
      • Presenting storage services to other devices (less common).  The most common deployment is using the RHEL host as an NFS server.

      Additionally, we must document the best ways to enhance a customer's storage experience:

      • Describe approaches to simplified local storage feature consumption (Stratis smart feature integration, storage system roles, web console features, Anaconda/installation considerations)
      • Add documentation for integrated, enhanced local storage capabilities as they exist and as they emerge (integrated event management, pooled storage, snaps, encryption, data reduction, data protection, etc

      Goals

      The goal of restructuring our capabilities to better suit RHEL use cases is to orient the user toward the steps they need in common RHEL use cases. Some users will be knowledgeable storage use cases, but many, including those most likely to consume our documentation, will simply be looking for the right way to optimally configure a system for tit's intended use

      Requirements

      The following use cases scenarios should be documented

      requirement Notes isMvp?
      Disk, volume, and file system setup during installation.   Y
      Attaching to external block storage (iSCSI initiator, FC initiator, dm multipath)   Y
      Using RHEL storage features to manage local and remote attached storage (LVM, VDO, mdraid)   Y
      Sharing storage from a RHEL host (NFS server, iSCSI target, clustered file access)   Y

       

      (Optional) Use Cases

      Disk setup during installation

      Local storage management

      Remote storage connections

      Out of Scope

       

      Background, and strategic fit

      < What does the person writing code, testing, documenting need to know? >

      Assumptions

      We always assume that man pages are suitable for less common use cases.  We also assume that 

       

      Customer Considerations

      < Are there specific customer environments that need to be considered (such as working with existing h/w and software)?>

      <Are there Upgrade considerations that customers need to account for, or that the Feature should address on behalf of the customer?>

      <Does the Feature introduce data that could be gathered and used for Insights purposes?>

       

      Documentation Considerations

      The reader of this document should not need to understand storage technologies.

      <What does success look like?>

      < Does this feature have doc impact?  Possible values are: New Content, Updates to existing content,  Release Note, or No Doc Impact>

       <If unsure and no Technical Writer is available, please contact Content Strategy. If yes, complete the following.>

      • <What concepts do customers need to understand to be successful in [action]?>
      • <How do we expect customers will use the feature? For what purpose(s)?>
      • <What reference material might a customer want/need to complete [action]?>
      • <Is there source material that can be used as reference for the Technical Writer in writing the content? If yes, please link if available. >
      • <What is the doc impact (New Content, Updates to existing content, or Release Note)?>

       

      Interoperability Considerations

      < Which other products and versions in our portfolio does this feature impact? >

      <If other products will be impacted set the ‘LP_Interop’ label on the Feature>

      < What interoperability test scenarios should be factored by the layered product(s)? >

       

      Questions

      Question Outcome
         

       

            abhide@redhat.com Apurva Bhide
            tharpayanthi Tharpayanthi V
            Apurva Bhide Apurva Bhide
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: