Add discovered application samples by nirs · Pull Request #53 · RamenDR/ocm-ramen-samples

nirs · 2024-06-03T21:04:55Z

Introduce discovered applications
Make room for discovered applications dr resources
Add sample for deployment-rbd
Document complete DR flow for discovered application

Since this PR is big enough, I will post another PR for the kubevirt samples.

Add a section about the difference between managed and discovered applications and update the titles to make it clear that the current instructions are for OCM managed applications. Signed-off-by: Nir Soffer <nsoffer@redhat.com>

Move current dr samples to dr/managed, making rook for dr/discovered samples. Signed-off-by: Nir Soffer <nsoffer@redhat.com>

The ManagedClusterBinding belongs to the ramen-ops namespace and not to the application, so we keep it in the ramen-ops directory. The rest of the resources are in the deployment-rbd directory. I'm not sure how easy it will be to share a base kustomization with other workloads so lets start with something simple. The README was updated to describe complete DR flow for discovered application using the new resources. Signed-off-by: Nir Soffer <nsoffer@redhat.com>

ShyamsundarR · 2024-06-05T11:43:46Z

Here is what I suggest as the directory structure for discovered:

├── dr
│   ├── base
│   │   ├── drpc.yaml
│   │   └── kustomization.yaml
│   ├── discovered (new)
│   │   ├── kustomization.yaml (new)
│   │   └── placement.yaml (new)
├── ramen
│   ├── binding.yaml (new)
│   ├── dr-clusters.yaml
│   ├── dr-policy.yaml
│   ├── kustomization.yaml
│   └── ramen-ops-ns.yaml (new)

The above presents one dr enabling set of resources for any discovered application. The kustomization would hold the templates for required values that need to change, for example the protectedNS, kubeObjectProtection specification etc.

Also, the common setup for supporting discovered workloads is moved to the ramen directory, to be used as part of setup.

This PR attempts to separate this into a managed/discovered seems to lead back to creating a overlay for each type of workload that we have in the repository, which is excessive and something we want to avoid.

nirs · 2024-06-05T14:05:12Z

Here is what I suggest as the directory structure for discovered:

├── dr
│   ├── base
│   │   ├── drpc.yaml
│   │   └── kustomization.yaml
│   ├── discovered (new)
│   │   ├── kustomization.yaml (new)
│   │   └── placement.yaml (new)

Do yo suggest discovered/kustomization will customize base/ resources?

├── ramen
│ ├── binding.yaml (new)

Sure we can move binding.yaml here. It is needed only for discovered apps but we document the simple command to deploy it in the right section.

│   ├── dr-clusters.yaml
│   ├── dr-policy.yaml
│   ├── kustomization.yaml
│   └── ramen-ops-ns.yaml (new)

We don't need ramen-ops-ns - it is already created by ramen. At least we don't need to do anything in drenv for this. If we want to help users create ramen-ops with the binding we can add something like this:

ramen
  ramen-ops
    ns.yaml
    binding.yaml
    kustomization.yaml

The above presents one dr enabling set of resources for any discovered application. The kustomization would hold the templates for required values that need to change, for example the protectedNS, kubeObjectProtection specification etc.
This PR attempts to separate this into a managed/discovered seems to lead back to creating a overlay for each type of workload that we have in the repository, which is excessive and something we want to avoid.

But we need an overlay for each application (e.g deloyment, deadonset, statefulset, vm-pvc, vm-dv, vm-dvt). If we don't add it the user will have to add it manually which makes testing and experimenting too hard. This is what we have now for other workloads.

nirs · 2024-06-06T19:05:18Z

+namespace in cluster `dr1`:
+
+```
+kubectl get vrg -l app=deployment-rbd -n ramen-ops --context dr1


This does not work:

$ kubectl get vrg -l app=deployment-rbd -n ramen-ops --context dr1 No resources found in ramen-ops namespace.

Because ramen does not label the vrg with the same label of the drpc. I think this works for OCM managed apps.

nirs · 2024-06-06T19:05:48Z

+Example output:
+
+```
+$ kubectl get vrg deployment-rbd-drpc -n ramen-ops --context dr1


Command should move up, this is just the output.

nirs · 2024-06-06T19:07:12Z

+placementdecision.cluster.open-cluster-management.io/deployment-rbd-placement-decision patched (no change)
+```
+
+At this point *Ramen* take over and start protecting the application.


For completeness, we should show the drpc at this stage:

kubectl get drpc -l app=deployment-rbd -n ramen-ops --context hub

Example output:

NAME AGE PREFERREDCLUSTER FAILOVERCLUSTER DESIREDSTATE CURRENTSTATE deployment-rbd-drpc 11m dr1 Deployed

nirs · 2024-06-06T19:38:49Z

+cluster, *OCM* delete the application from the cluster and deploy it on
+the other cluster.
+
+### OCM discovered applications*


Trailing *

nirs · 2024-06-06T19:42:33Z

+The application is still running on the primary cluster:
+
+```
+$ kubectl get deploy,pod,pvc -n deployment-rbd --context dr1


Leading $ unneeded - breaks copy and paste from rendered page.

nirs · 2024-06-06T21:17:30Z

@@ -0,0 +1,6 @@
+apiVersion: cluster.open-cluster-management.io/v1beta1


Ramen already has code to create a placement decision with the right decision set:
https://github.com/RamenDR/ramen/blob/d475bc759f4cb84b0fd823b9eea2b0b54b7c0364/controllers/drplacementcontrol_controller.go#L2116

So this file should not be needed.

nirs · 2024-06-06T21:34:15Z

+    --type merge \
+    --namespace ramen-ops \
+    --context hub
+```


This step should not be needed if we remove the placemnt-decision.yaml - ramen will create a new configured resource automatically.
https://github.com/RamenDR/ramen/blob/d475bc759f4cb84b0fd823b9eea2b0b54b7c0364/controllers/drplacementcontrol_controller.go#L2116

raghavendra-talur · 2024-06-07T04:26:49Z

+### OCM managed applications
+
+Deployed and undeployed by *OCM*, using either *Subsription* or
+*ApplciationSet* resources. *Ramen* take ownership of the application


s/take/takes

raghavendra-talur · 2024-06-07T04:27:02Z

+
+Deployed and undeployed by *OCM*, using either *Subsription* or
+*ApplciationSet* resources. *Ramen* take ownership of the application
+when enabling DR, and return ownership to OCM when disabling DR. When DR


s/return/returns

raghavendra-talur · 2024-06-07T04:27:27Z

+Deployed and undeployed by *OCM*, using either *Subsription* or
+*ApplciationSet* resources. *Ramen* take ownership of the application
+when enabling DR, and return ownership to OCM when disabling DR. When DR
+is enabled, *Ramen* control the placement of the application and backup


s/control/controls

raghavendra-talur · 2024-06-07T04:28:03Z

+and restore the application PVCs.
+
+When failing over or relocating an *OCM managed application* to another
+cluster, *OCM* delete the application from the cluster and deploy it on


s/delete/deletes and s/deploy/deploys

raghavendra-talur · 2024-06-07T04:29:10Z

+repository using kubectl. Another example is creating a virtual machine
+using KubeVirt console.
+
+*Ramen* take ownership of the application when enabling DR and return


plural changes in this and next paragraph too

raghavendra-talur · 2024-06-07T08:07:05Z

@@ -0,0 +1,8 @@
+---


If ACM is never to look at the placement and placementdecision, then we don't need the managedClusterSetBinding.

akalenyu · 2024-06-09T14:25:07Z

+imperative means. An example is deploying one of the workloads in this
+repository using kubectl. Another example is creating a virtual machine


Suggested change

imperative means. An example is deploying one of the workloads in this

repository using kubectl. Another example is creating a virtual machine

imperative means. An example is directly supplying one of the workload definitions in this

repository (Deployment, for example) to `kubectl apply`. Another example is creating a virtual machine

nirs requested review from ShyamsundarR, netzzer and raghavendra-talur June 3, 2024 21:05

nirs commented Jun 4, 2024

View reviewed changes

Comment thread dr/discovered/deployment-rbd/drpc.yaml

Comment thread dr/discovered/deployment-rbd/placement-decision.yaml Outdated

nirs commented Jun 4, 2024

View reviewed changes

Comment thread dr/discovered/deployment-rbd/drpc.yaml Outdated

nirs commented Jun 4, 2024

View reviewed changes

Comment thread dr/discovered/deployment-rbd/placement.yaml Outdated

nirs force-pushed the discovered-apps branch from 3921bef to 28e09bc Compare June 4, 2024 17:13

nirs added 2 commits June 4, 2024 21:37

Introduce discovered applications

3d14b7c

Add a section about the difference between managed and discovered applications and update the titles to make it clear that the current instructions are for OCM managed applications. Signed-off-by: Nir Soffer <nsoffer@redhat.com>

Make room for discovered applications dr

e97d598

Move current dr samples to dr/managed, making rook for dr/discovered samples. Signed-off-by: Nir Soffer <nsoffer@redhat.com>

nirs force-pushed the discovered-apps branch 2 times, most recently from 043ea92 to 97df338 Compare June 4, 2024 19:38

nirs force-pushed the discovered-apps branch from 97df338 to 6bc74a5 Compare June 4, 2024 19:49

nirs marked this pull request as ready for review June 4, 2024 19:51

nirs mentioned this pull request Jun 5, 2024

Document failover and relocate flows #42

Open

nirs commented Jun 6, 2024

View reviewed changes

nirs marked this pull request as draft June 6, 2024 21:56

raghavendra-talur reviewed Jun 7, 2024

View reviewed changes

akalenyu reviewed Jun 9, 2024

View reviewed changes

		@@ -0,0 +1,6 @@
		apiVersion: cluster.open-cluster-management.io/v1beta1

		imperative means. An example is deploying one of the workloads in this
		repository using kubectl. Another example is creating a virtual machine

Uh oh!

Conversation

nirs commented Jun 3, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ShyamsundarR commented Jun 5, 2024

Uh oh!

nirs commented Jun 5, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nirs Jun 6, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

nirs commented Jun 3, 2024 •

edited

Loading

nirs commented Jun 5, 2024 •

edited

Loading

nirs Jun 6, 2024 •

edited

Loading