MCPcopy Index your code
hub / github.com/RamenDR/ramen

github.com/RamenDR/ramen @main

Chat with this repo
repository ↗ · DeepWiki ↗ · + Follow
3,716 symbols 13,415 edges 342 files 1,251 documented · 34%
What it actually does AI analysis from the code graph — generated when you open this
loading…
README

Ramen

Ramen is an open-cluster-management (OCM) placement extension that provides Kubernetes-native Disaster Recovery for workloads and their persistent data across a pair of OCM managed clusters. Ramen orchestrates, workload protection and placement on managed clusters through:

  • Relocate: Planned migration to a peer cluster for maintenance, optimization, or failback
  • Failover: Unplanned recovery to a peer cluster after cluster loss or failure

Persistent Data Protection

Ramen supports several approaches for replicating persistent data across clusters:

Storage Vendor Assisted Replication

Ramen uses storage plugins that implement the CSI storage replication specification and csi-addons Volume[Group]Replication APIs to orchestrate volume replication and recovery across clusters.

Ceph-csi is one such plugin that implements the csi-addons APIs.

Volsync Based Replication

For storage that supports Kubernetes Volume[Group]Snapshots APIs, Ramen uses the volsync rsync plugin to transfer periodic snapshots to peer clusters.

Highly Available Storage Backends

When storage is already highly available and requires no replication, Ramen manages only workload resources. It ensures access guarantees through the csi-addon fencing specification and and csi-addons NetworkFence APIs.

NOTE: This differs from synchronously replicated storage systems, which still require replication state management and therefore would use Storage Vendor Assisted Replication.

Workload Resource Protection

Ramen supports several approaches for protecting and replicating application resources across clusters:

GitOps Based Protection (Recommended)

Applications deployed via GitOps (e.g., ArgoCD ApplicationSets) with OCM-managed Placements work directly with Ramen's placement orchestration. This is the most common deployment pattern for cloud-native applications.

Discovered Applications

Ramen can also protect applications deployed through other methods (e.g., kubectl, kustomize) by using velero to automatically identify and back up application resources.

Recipe-based Protection

Recipes define vendor-supplied workflows for capturing and recovering complex stateful applications. They specify:

  • Application-specific capture workflows
  • Recovery workflows with proper sequencing
  • Custom hooks for pre/post actions

Recipes extend discovered applications protection by enabling multi-step workflows beyond simple backup and restore.

Target Audience:

  • Software Vendors: Ship recipes with their products for out-of-the-box protection
  • Advanced Users: Write custom recipes for applications without vendor support

Getting Started

Contributing

We welcome contributions. See the contributing guide to get started, or open an issue to report bugs, suggest improvements, or request features.

Project Status

Ramen is under active development. All APIs are currently alpha with no stable releases yet.

  • Alpha: APIs may change incompatibly between releases. Recommended only for short-lived testing clusters due to potential bugs and lack of long-term support.

Licensing

Ramen is under the Apache 2.0 license.

Extension points exported contracts — how you extend this code

PodLister (Interface)
PodLister interface abstracts pod discovery based on SelectResource type. Each implementation handles a specific resourc [4 …
internal/controller/hooks/exec_pod_lister.go
Deployer (Interface)
Deployer interface has methods to deploy a workload to a cluster [3 implementers]
e2e/types/types.go
HookExecutor (Interface)
Hook interface will help in executing the hooks based on the types. Supported types are "check", "scale" and "exec". The [3 …
internal/controller/hooks/hooks_factory.go
Workload (Interface)
nolint:interfacebloat [3 implementers]
e2e/types/types.go
ObjectStoreGetter (Interface)
Example usage: func example_code() { *** setup a new s3 object store *** s3endpoint := "http://127.0.0.1:9000" s3secretn [2 …
internal/controller/s3utils.go
Context (Interface)
Context keeps the Logger, Env, Config, and Context shared by all code in the e2e package. [2 implementers]
e2e/types/types.go
ManagedClusterViewGetter (Interface)
nolint:interfacebloat [2 implementers]
internal/controller/util/mcv_util.go
TestContext (Interface)
TestContext is a more specific Context for a single test; a combination of Deployer, Workload, and namespaces. A test ha [1 …
e2e/types/types.go

Core symbols most depended-on inside this repo

Errorf
called by 940
e2e/test/testing.go
GetName
called by 592
e2e/types/types.go
Error
called by 416
internal/controller/kubeobjects/requests.go
Get
called by 407
internal/controller/kubeobjects/requests.go
Create
called by 302
internal/controller/util/predicates.go
Update
called by 215
internal/controller/hooks/scale_hook.go
GetNamespace
called by 214
e2e/types/types.go
Delete
called by 163
internal/controller/util/predicates.go

Shape

Function 1,904
Method 1,538
Struct 215
TypeAlias 28
Interface 17
Class 9
FuncType 5

Languages

Go82%
Python18%

Modules by API surface

api/v1alpha1/zz_generated.deepcopy.go149 symbols
internal/controller/drplacementcontrol.go131 symbols
internal/controller/volsync/vshandler.go127 symbols
internal/controller/vrg_volrep.go120 symbols
internal/controller/vrg_volrep_test.go117 symbols
internal/controller/drplacementcontrol_controller_test.go110 symbols
internal/controller/volumereplicationgroup_controller.go109 symbols
internal/controller/drplacementcontrol_controller.go96 symbols
test/drenv/commands_test.py75 symbols
internal/controller/drcluster_controller.go65 symbols
internal/controller/util/mcv_util.go61 symbols
internal/controller/vrg_kubeobjects.go59 symbols

For agents

$ claude mcp add ramen \
  -- python -m otcore.mcp_server <graph>

⬇ download graph artifact