🌱 Ensure CRS controller always add ownerReference to resources

[fabriziopandini]

What this PR does / why we need it:
While testing owner references resilience for CAPV I discovered that the CRS controller do not apply owner references to resources in case there is no connection to the workload cluster.

This PR fixes this issue.

Area example:
/area clusterresourceset

[fabriziopandini]

/test

[k8s-ci-robot]

@fabriziopandini: The /test command needs one or more targets.
The following commands are available to trigger required jobs:

• /test pull-cluster-api-build-main
• /test pull-cluster-api-e2e-blocking-main
• /test pull-cluster-api-e2e-conformance-ci-latest-main
• /test pull-cluster-api-e2e-conformance-main
• /test pull-cluster-api-e2e-main
• /test pull-cluster-api-e2e-mink8s-main
• /test pull-cluster-api-e2e-upgrade-1-30-1-31-main
• /test pull-cluster-api-test-main
• /test pull-cluster-api-test-mink8s-main
• /test pull-cluster-api-verify-main

The following commands are available to trigger optional jobs:

• /test pull-cluster-api-apidiff-main

Use /test all to run the following jobs that were automatically triggered:

• pull-cluster-api-apidiff-main
• pull-cluster-api-build-main
• pull-cluster-api-e2e-blocking-main
• pull-cluster-api-test-main
• pull-cluster-api-verify-main

In response to this:

/test

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.

[fabriziopandini]

/test pull-cluster-api-e2e-main

[sbueringer]

Thx!

/lgtm
/approve

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 45a422cfce7016b35696b1aeeb4bec857841a858

[sbueringer]

@fabriziopandini Can you please check the unit test? Wondering if we got a flake related to this PR

[fabriziopandini]

@fabriziopandini Can you please check the unit test? Wondering if we got a flake related to this PR

The flake was related to this PR and due to a race condition:

• When reconciling concurrently two CRS targeting the same cluster
• CRS1 locks briefly when acquiring a client from the cluster cache tracker
• CRS2 gets a lock error and gets requeued after a minute, while tests fail after 15s

To fix it I have expanded a little bit the scope of this PR:

• We are now applying owner references to resources before creating connection to the workload cluster (original scope)
• We are now applying owner CRSBindings before creating connection to the workload cluster (expanded scope scope)
• We creating an entry into CRSBindings for each CRS before creating connection to the workload cluster (expanded scope scope)

The last change required to fix an existing test, but this should be ok because what is important is that we do not apply resources if there is not yet a kubernetes service in the target cluster, and this is still true (see #7804)

[chrischdi]

/lgtm

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 36ca06360ded69979dc6b0b2aaa1e01a2d8b10f4

[chrischdi]

/hold

for manual merge

[sbueringer]

Thx!

/lgtm
/approve

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 1a2a4620114a1eb5ff9970a9705b4b3bda933b32

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: sbueringer

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [sbueringer]

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

[sbueringer]

/hold cancel

[jimmidyson]

/cherrypick release-1.7

[k8s-infra-cherrypick-robot]

@jimmidyson: new pull request created: #10895

In response to this:

/cherrypick release-1.7

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.