bug: SyncAgent does not detect relatedResource changes

[BergCyrill]

Describe the bug

When having a publishedResource and a related resource with source in kcp a change of the related resource (e.g. ConfigMap) will not be synced by the API-SyncAgent. This sync does only happen when:

• the related resource gets deleted in the service provider cluster
• the api-syncagent is restarted

Steps To Reproduce

1. Consume a CR with a related resource of type ConfigMap
2. Validate this ConfigMap is synced into the service provider cluster
3. Make changes to the ConfigMap in kcp
4. Review the ConfigMap in the service provider cluster and api-syncagent logs - there will be no errors in the logs but also no changes to the ConfigMap

Expected Behaviour

I would expect the api-syncagent to sync related resources with source kcp in the service provider cluster whenever changes occur.

Additional Context

No response

[xrstf]

Hi,

that is absolutely correct, the syncagent doesn't even try to watch for changes to related resources. That was left out for the reasons below for now, and because the bold assumption was made that if an operator produces/updates a related object, then it would most likely also touch a condition or something on the primar object, thereby triggering the full resync.

---

The biggest question that blocks this is how this can be done efficiently. The entire architecture of the syncagent's syncer is built around

1. get primary object
2. sync primarty object
3. calculate based on the primary object all related objects
4. sync those

This means the agent is pretty good at telling you which Secret belongs to a Certificate, but it cannot answer which Certificate belongs to a Secret.

If the agent were, for example, to watch Secrets, then whenever a Secret changes, it would have to get all primary objects that it ever synced, and for each single object calculate the set of possible related objects, and then check if the Secret is among them. Clearly that's not a workable approach.

---

However the need to react to changes in related resources is of course real and we need to implement it.

My current thought is that watching related resources is something you as the service provider have to explicitly configure. And in that configuration you also tell the agent how to find the primary object for the watched object. If for example ownerRefs would be used, it could look something like

spec:
  # ....

  related:
    - id: connection-details
      resource: secrets
      version: v1
      object:
        reference:
          path: metadata.name
      watch:
        # for every Secret, look at the OwnerRef of the
        # given kind, and when such a ref exists, it
        # points to the primary object
        byOwner:
          kind: OwningObject
       
        # for every Secret "foo", find the primary object that
        # has a "secret-name=foo" label
        byLabel:
          secret-name: {{ .watchObject.name }}

[BergCyrill]

I think the byLabel logic could help here, not so sure about the byOwner one. I am thinking about having resource A creating a configMap A and this configMap is used as a related resource for n different other resources (or maybe I have got your idea wrong here).
Wouldn't the (really helpful) enhancement in kcp 0.29.0 to have matcher in the permission claims help to reduce the amount of e.g. configMaps that should be watched and acted on? Maybe in combination with the label matcher on the PR could be a feasible solution.