[arfevrier]

Summary

Related resources currently synchronize their .status only in the same direction as their spec (with MR #175).

This prevents using related resources when their desired state is produced on one side and their observed state is produced on the other. This PR allows the authoritative side for the status to be configured independently from the resource origin.

The following four configurations are supported:

origin	syncStatus	Spec direction	Status direction
kcp	kcp	kcp → service	kcp → service
kcp	service	kcp → service	service → kcp
service	service	service → kcp	service → kcp
service	kcp	service → kcp	kcp → service

When syncStatus is omitted, .status synchronization remains disabled.

Use Case

The diagram shows two providers collaborating through a customer workspace. APIExports and
APIBindings are intentionally omitted to keep the overview clear.

1. Provider A creates a related resource in its service cluster and synchronizes its spec to kcp.
2. Provider B reconciles the resource and publishes the result in its status.
3. Provider A synchronizes that status from kcp back to its service cluster.

The spec and status therefore flow in opposite directions without requiring direct connectivity
between the providers' service clusters. And the Database is owned by the customer.

Current Limitations and Possible Improvements

• The current validation permits origin: kcp with syncStatus: kcp without watch. In that case, the status present during a primary reconciliation is synchronized, but later status changes do not trigger reconciliation by themselves. Configuring watch is therefore still necessary when continuous event-driven status synchronization is expected. (I keep the same behavior as before, but perhaps that doesn’t make much sense any more.)

• Related resources are not watched automatically. Without a watch configuration, related resources are read and synchronized only when another event causes their primary resource to be reconciled. byOwner can target one primary, but owner references are cluster-local and are not copied between clusters, while bySelector may reconcile several primaries. A future improvement could use the provenance annotations already present on generated copies to identify the
  exact primary?

Changes

• Allow syncStatus to select either kcp or service as the authoritative status source.
• Synchronize the status independently from the related resource spec.
• Watch both sides when spec and status flow in opposite directions.
• Keep status synchronization disabled when syncStatus is omitted.
• Update API validation, generated resources, documentation, and tests.

@iakmc, what do you think of the changes ? As it directly impacts your MR !175.

Testing

Lint:

make lint
0 issues.

Focused status synchronization scenarios:

--- PASS: TestSyncRelatedObjectStatusFromKcp
--- PASS: TestSyncRelatedObjectStatusBackToKcp
--- PASS: TestSyncRelatedObjectStatusFromService
--- PASS: TestSyncRelatedObjectStatusNotSyncedByDefault
--- PASS: TestSyncRelatedObjectStatusFromKcpWithServiceOrigin

Full build and e2e suite:

make clean build test-e2e
PASS

All e2e packages and scenarios pass, including the related-resource synchronization and cleanup
tests.

What Type of PR Is This?

/kind feature
/kind api-change

Related Issue(s)

Fixes #193

Release Notes

Related resource status synchronization can now use kcp or the service cluster as its authoritative
source independently from the resource origin.

[kcp-ci-bot]

Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[kcp-ci-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign embik for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[kcp-ci-bot]

Hi @arfevrier. Thanks for your PR.

I'm waiting for a kcp-dev member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[mjudeikis]

/ok-to-test

[arfevrier]

/retest-required