Goal:

• Track documentation changes for Manila adoption NFS scenario

Acceptance Criteria:

• Remove NFS known limitation
• Add "ceph cluster create" guide

Mini content journey

**

Reviewers:

• Technical: N/A
• Peer: TBD
• QE: N/A
• Partner/Field (optional): N/A

Is this feature fully supported or technical preview?

• Full support: Documentation will be published on the customer portal

**

Does the procedural content need to be tested by QE?

• No: Exemption approved by <STAKEHOLDER NAME>

**

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

•  
• 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?

• Discover: Overview, reference, blogs (Find solutions)
• Learn: Validated architectures, reference, FAQ(Gain Knowledge)

• Try: Technical Preview, quickstart (Start, try, test)
• Adopt: Adoption or Greenfield feature (Early stage customer use)
• Expand: Customizations, day 2 operations, troubleshooting, add features to control plane or data plane

**

Who is your target persona?

• RHOSO admin:  Platform Engineer
• OpenStack admin:  Cloud Administrator
• OpenStack user: SysAdmin or Developer

**

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.

• <LINKS>
• <If there are no links available at the time of doc planning, writer can create spikes or tasks to collect this information later from the DFG>

Does the content require input from multiple DFGs?

• Yes: Writer creates spikes or stories under this epic and assigns 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)

**

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

• Adoption/minor updates guide: Are there any considerations or impact of this feature on adoption from pre-18 environments or from earlier 18z versions? 
  • The Tech Preview notes need to be removed from the following procedures: 
  • https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html/adopting_a_red_hat_openstack_platform_17.1_deployment/rhoso-180-adoption-overview_assembly#creating-a-ceph-nfs-cluster_ceph-prerequisites
  • https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html/adopting_a_red_hat_openstack_platform_17.1_deployment/rhoso-180-adoption-overview_assembly#changes-to-cephFS-through-NFS_storage-requirements 

**

(Optional) Are there any additional content improvements you can also implement for the user when documenting this goal? Consider any additional actions that might also improve content. For example, restructuring content to better suit the user story.

• <Ideas and suggestions for improvements of existing content>

**

(Optional) Documentation outline If applicable, the writer can start brainstorming about the information design for the content. This is understood to only be a draft placeholder and subject to change as the content is authored and reviewed.

• Module Title (Concept)

• Overview of content required

• Module Title (Concept)

• Overview of content required

• Module Title (Procedure)

• Prerequisites

• Outline of steps

• Module Title (Procedure)

• Prerequisites

• Outline of steps

• Module Title (Reference)

• Outline of parameters/options/data to be included

• Module Title (Reference)

• Outline of parameters/options/data to be included