Add unique labels to deployments that are replicated via MWRS and Placement Policy

[ramaraochavali]

We plan to use MWRS and Placement Policy to copy deployments to mutiple clusters. We need a unique label on the pods of each of these deployments so that we can uniquely identify them and apply routing rules (like Envoy/Istio) to each of these deployments based on incoming request.

Is it possible to achieve this currently? If it is not possible, can we enhance MWRS and have templatized label support in the podspec and OCM updates the label when it is executed?

[qiujian16]

Thanks for asking this. Would you like to explain more on how would you like the label to be set or some examples?
We discussed before an enhancment on mwrs to add a field that overrides or patches the field defined in the default manifests, but it will be by placement. I wonder if what you need is to customize some fields in mwrs per cluster?

[ramaraochavali]

Sure.
Yes, first step is to create a "unique" label customizable per placement(cluster).

What we are eventually looking for is to have a copy of deployments (even inside a single cluster - we call them "cells"). So what we need to customize some fields (including deployment name so that we can create multiples in single cluster and pod label) - so possibly some templated values that OCM can replace it with or preprocessed before creating them?

What is the best way to solve this?

[ramaraochavali]

@qiujian16 any thoughts on both use cases?

[qiujian16]

Sorry for the late reply. I think it is more like you want to deploy different manifests in different clusters. MWRS is for same or similar set of manifests to deploy across multiple clusters. I am not sure in your case, how common those manifests would be among different clusters. For example, would it be good enough if in MWRS, we have

manifestOverride:
- resource:
     name: deploy1
     namespace: ns1
     resources: deployments
     group: apps
     version: v1
   placement:
      name: placement1 // a list of clusters to have this resource override
    override:
       type: patch // the type could also be replace
       patch: // you can patch the label or name with a json path

With this it can override some field in a resource, but it cannot add additional manifest.

[ramaraochavali]

Thank you for the reply. I think this can help. Does it already exist or needs to be built?

[qiujian16]

it needs to be built.