Multi-cluster RGs Implementation

[daniel-de-vera]

E.g.:

$ signadot routegroup apply -f - <<EOF
name: hotrod-multi-cluster
spec:
  match:
    all:
    - label:
        key: app
        value: hotrod
  endpoints:
  - name: frontend
    target: http://frontend.hotrod-devmesh.svc:8080
    cluster: test
EOF


$ signadot rg get hotrod-multi-cluster
Name:             hotrod-multi-cluster
Routing Key:      kwxt78pbldssy
Cluster:          - (multi-cluster)
Created:          Fri, 29 Aug 2025 15:07:12 -03 (2 days ago)
TTL:              - (forever)
Dashboard page:   https://app.signadot.com
Status:           Ready (RoutingReady: routing is ready for all workloads in all sandboxes)

ROUTEGROUP ENDPOINT   CLUSTER   TARGET                                    URL
frontend              test      http://frontend.hotrod-devmesh.svc:8080   http://frontend--hotrod-multi-cluster.localhost.signadot.com:8086


$ signadot rg list
NAME                   ROUTING KEY     CLUSTER             CREATED        STATUS   READY SANDBOXES
hotrod-main-xrc        87p1n290yv7w4   xrc-test            9 months ago   Ready    0/0
hotrod                 jvrtrkzg1sdzg   test                7 months ago   Ready    1/1
hotrod-multi-cluster   kwxt78pbldssy   - (multi-cluster)   3 days ago     Ready    1/1

[davixcky]

I would change the - (multi-cluster and use something like clusterA, clusterB

[davixcky]

probably renaming this var?

[daniel-de-vera]

Well.. I think this is a matter of taste. I named it like that because we already had this code:

cli/internal/config/local.go

Lines 221 to 231 in 422eed0

	func (lp *LocalProxy) Validate() error {
	c := 0
	if lp.Sandbox != "" {
	c += 1
	}
	if lp.RouteGroup != "" {
	c += 1
	}
	if lp.Cluster != "" {
	c += 1
	}

And I wanted it to look consistent.

[scott-cotton]

I would just return "(multi-cluster)"

[daniel-de-vera]

Done in 40bee4d.

[scott-cotton]

LGTM

[daniel-de-vera]

I would change the - (multi-cluster and use something like clusterA, clusterB

First, we don't easily have that info (we have the list of matching sandboxes, from where we could resolve the clusters involved). But second, it feels we are mixing meanings if we do that: in one case (regular RGs) the cluster is populated based on the spec, and in the other based on the status, which looks confusing to me.