Extend federated type config status umbrella issue

[RainbowMango]

Background

If a target type in a FederatedTypeConfig not present in one or more member clusters, that will cause the sync controller totally not working because the federated informer hanging in sync.
For more details discussion and reproduce, you can get from here.

Solutions

The community has discussed this issue years ago and proposed a solution at here. The solution looks pretty good, so the main solution will follow this solution.

This umbrella issue tries to split the solution to some small pieces of iteration items. So that we can keep each PRs small and easy to review.
Any comments are welcome and feel free to take tasks you are interested in(just send a comment to this issue).

Iteration Items/tasks

• API extension on board. (@RainbowMango)
  This is the first PR that focus on API extension and deal with relative auto-generated things.

• SyncController maintaining the new fields of status

• The sync controller will determine the status of the target type in each FederatedCluster in the namespace - present or not

• The overall status is driven off the status in each cluster - if the target type is not present in one or more clusters, the overall status is NotPresentInAllClusters

Maybe prevent not present cluster from federated informer too?

• SyncController use the new fields in reconciliation loop
  Not sync to and not delete from the not present clusters.

• Add/Update E2E test

New iteration items could be added in the future, and it is certain that each item could not break the current functionalities.

/kind feature
/help

[k8s-ci-robot]

@RainbowMango:
This request has been marked as needing help from a contributor.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

Background

If a target type in a FederatedTypeConfig not present in one or more member clusters, that will cause the sync controller totally not working because the federated informer hanging in sync.
For more details discussion and reproduce, you can get from here.

Solutions

The community has discussed this issue years ago and proposed a solution at here. The solution looks pretty good, so the main solution will follow this solution.

This umbrella issue tries to split the solution to some small pieces of iteration items. So that we can keep each PRs small and easy to review.
Any comments are welcome and feel free to take tasks you are interested in(just send a comment to this issue).

Iteration Items/tasks

• API extension on board. (@RainbowMango)
  This is the first PR that focus on API extension and deal with relative auto-generated things.

• SyncController maintaining the new fields of status

• The sync controller will determine the status of the target type in each FederatedCluster in the namespace - present or not

• The overall status is driven off the status in each cluster - if the target type is not present in one or more clusters, the overall status is NotPresentInAllClusters

Maybe prevent not present cluster from federated informer too?

• SyncController use the new fields in reconciliation loop
  Not sync to and not delete from the not present clusters.

• Add/Update E2E test

New iteration items could be added in the future, and it is certain that each item could not break the current functionalities.

/kind feature
/help

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/test-infra repository.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

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/test-infra repository.