Introduce docs directory

[nirs]

We want to add more workloads (stalefulset, daemonset), more storage (CephFS), and the new OCM discovered applications.

Each variant require specific instructions or example commands so it is best done using one file per variant, where you can experiment with complete disaster recovery flow for a single variant.

• Move the content we had in the main README.md to docs/initial-setup.md and docs/ocm-rbd.md
• Move the content we had in workloads/kubevirt/README.md to docs/ovm-kubevirt.md.
• Add docs/create-environment.md with short instructions how to create a testing environment for playing with the samples in this repo.
• Change README.md to a short overview linking to all other documents.

The new docs directory can be used next to create more structure documentation like https://docs.readthedocs.io.

Preview: https://github.com/nirs/ocm-ramen-samples/tree/ec49e1159dbe80e13a0c7927653f739a82973356

[nirs]

Changes in latest version:

• Rebase on master, including latest changes regarding disable dr.

[ShyamsundarR]

@nirs here is what I think the document organization should be. Current PR is more focused on providing all commands in one go in one file, which would be repeated. Also, we should write about how to protect a Deployment and not a RBD based deployment, which is where we need to work on using packageOverrides and kustomize to reduce the number of per storage class name/type overlays as discussed earlier.

---

Samples contains workload types to demonstrate what the workload author needs to consider for it to be DR protected by Ramen.

The workloads can be deployed to a OCM managed cluster via supported gitops providers (OCM Subscriptions or ArgoCD AppplicationSets), or directly onto a managed cluster.

All workloads are DR protected using their OCM Placement and orchestrating workload deployment during DR actions like Failover/Relocate, with data and k8s resources recovery. IOW, DR protection and actions usage is common across any workload, deployed in any manner (mostly) and can be documented once.

Pre-requisites

• Point to Ramen docs on Ramen install and configuration
• Point to drenv based Regional (or in the future Metro) setup docs

Preparing to use samples

• Clone/fork repo, etc.
• Create channel to point to clone
• Collect required information to use with DR protecting samples (SCs, PVC mode, cluster names, ...)
  • This start point should hence be for any setup where samples are to be used
  • Ramen policy/cluster creation should be part of Ramen configuration related documentation and not part of samples
• Choosing a deployment strategy to deploy the sample
  • This covers Subscriptions|ApplicationSet|Imperative/Discovered; these would remain common for any workload
• DR protecting a deploymed workload
  • This is/can be common, as DRPC needs a Placement and related resources. So all common DRPC creation with required data can be documented once

Experimenting with different workloads

• Deployment
  • Add documentation here regarding what we would protect and how. Add prerequsites to be considered/adhered to before DR protecting the workload.
  • IOW, if a user has another deployment this document should serve as a blueprint on how to amend the workload such that it can be reliably DR protected and what to expect during DR actions from a Workload perspective
• [STS|Daemonset|...]
• Kubevirt

[ShyamsundarR]

This should just point to https://github.com/RamenDR/ramen/blob/main/docs/user-quick-start.md so that we do not repeat content here.