Detecting ramen resources per application

[nirs]

Current system does not have uniform way to find all the relevant ramen resources for specific application.

The system makes it very hard to locate all the resources without known the resource kind (e.g. kubectl get all -n namespace return only some kinds).

Use cases

One application per namespace - subscriptions/rbd

hub:
  app-namespace:
    drpc:
      name: app-name-placement-1-drpc
cluster1:
  app-namespace:
    vrg:
      name: app-name-placement-1-drpc
    vrs:
    - name: pvc-name
cluster1:
  app-namespace:

One application per namespace - applicationset/rbd

hub:
  openshift-gitops:
    drpc:
      name: app-name-placement-drpc
cluster1:
  app-namespace:
    vrg:
      name: app-name-placement-drpc
    vrs:
    - name: pvc-name
cluster1:
  app-namespace:

One application per namespace - applicationset/cephfs

hub:
  openshift-gitops:
    drpc:
      name: app-name-placement-drpc
cluster1:
  app-namespace:
    vrg:
      name: app-name-placement-drpc
    replicationsources:
    - name: pvc-name?
cluster1:
  app-namespace:
    vrg:
      name: app-name-placement-drpc
    replicationdestinations:
    - name: pvc-name?```

Multiple application per namespace

When creating an app we can use the same application namespace (subscription) or the same remote namespace (application sets).

hub:
  openshift-gitops:
    drpc:
      name: app1-name-placement-drpc
      name: app2-name-placement-drpc
cluster1:
  shared-apps-namespace:
    vrgs:
      - name: app1-name-placement-drpc
      - name: app2-name-placement-drpc
    vrs:
    - name: pvc1-name?
    - name: pvc2-name? 
cluster1:
  shared-apps-namespace:

Looks like this is hard to get right for users - deployment name and pvc names will conflict. Seems impossible with ocm-ramen-samples.

One application, multiple namespaces

(Not sure how this will look, @hatfieldbrian may add more info on this)

Locating stuff

• drpc
  • Depends on application implementation (subscription/application sets)
  • Depend on undocumented drpc name format that may change in future versions
• vrg
  • Depend on drpc name format, again implementation detail that can change in future versions
• vr/replicaiton{source,destination}
  • Depend on the pvc name, need to know the specific deployment

Suggested solution

When users create applications in ACM, they must create an application name and use it to locate the application and perform actions.

Users also create an application namespace, not sure if we can use the same namespace to have multiple applications in the same namespace.

When the application is create from the UI, all resources related to the application can have the same label common label:

labels:
  app.kubernetes.io/name: mysql

This can be applied to:

• subscription
• placement
• applicationset
• drpc
• vrg (ramen can propagate the label from the drpc)
• vr (ramen can propagate the label from the vrg)
• replication{source,destination}? (ramen can propagate the label from drpc/vrg)
• manifestwork?
• namespaces?
• application resources?

With this tools (like ramen kubectl plugin) can identify an application using:

kubectl ramen status --namespace xxx --app-name yyy

Or using kubectl:

kubectl get --selector app.kubernetes.io/name=yyy

Tools can deal with the difference between subscriptions and applications sets by looking the application namespace and gitops namespace on the hub.

Current ocm-samples-ramen yamls already contain similar label:

$ grep -r -A1 labels: subscription/
subscription/placementrule.yaml:  labels:
subscription/placementrule.yaml-    app: busybox-sample
--
subscription/subscription.yaml:  labels:
subscription/subscription.yaml-    app: busybox-sample

But we don't have this in openshift. We need a uniform configuration in upstream and downstream so tools can work in the same way.

Issues

• subscription/placement/applicationset label - depends on OCM/ACM?
• maybe we can add the label when assigning drpolicy to an application?

See also

• ancient issue for vrg: #14
• https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/

[nirs]

@BenamarMk @ShyamsundarR what do you think?

[nirs]

Looks like this already mostly implemented - these resources already have app: app-name:

• subscription
• placementrule (minikube)
• placement (openshift)
• drpc
• vrg

Can be nice to have the same label on the vrs and replccation{source,destination} and maybe other but we can start using the current labels instead of depending on drpc/vrg/vr name.

[nirs]

Does not work for discovered apps:

The drpc has app= label added by the samples:

$ kubectl get drpc -l app=deployment-rbd -n ramen-ops --context hub
NAME                  AGE   PREFERREDCLUSTER   FAILOVERCLUSTER   DESIREDSTATE   CURRENTSTATE
deployment-rbd-drpc   18m   dr1                                                 Deployed

But the label is not propagated to the vrg and vrs:

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

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

@raghavendra-talur do you know why the vrg and vr are missing the label from the drpc?