KEP: Split Detector and Add PropagationPolicy Controller

[pigletfly]

…Policy Controller

What type of PR is this?
/kind design

What this PR does / why we need it:

Which issue(s) this PR fixes:
Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

     NONE

[karmada-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please assign rainbowmango after the PR has been reviewed.
You can assign the PR to them by writing /assign @rainbowmango in a comment when ready.

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

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

[Garrybest]

/assign

[Garrybest]

Wow, this proposal is really good to me. Actually this proposal helps us to clean up the dector. Now the dector contributes to building RB and aggregating RB status, it is a little ambiguous. We could do a seperation to make all controller keep their duties.

1. After aggregating status from work, we could calculate the summary status and update to original object at once. There is no need to do another reconcile again.
2. The policy controller helps us looking a matched policy and create the respective RB. The architecture is OK and more policy details could be disscussed in this controller.

Generally, I do like this enhancement which makes the controller more distinct.

Hey guys, you may take a look.
/cc @RainbowMango @mrlihanbo @XiShanYongYe-Chang @GitHubxsy

[RainbowMango]

Yes, we discussed this at the last community meeting. (Haven't look at the update yet)
Moving controllers from the detector look good to me.

[pigletfly]

Yes, we discussed this at the last community meeting. (Haven't look at the update yet) Moving controllers from the detector look good to me.

updated our case in production.As the ResourceBinding part, have sent a PR #1366.

[pigletfly]

@RainbowMango any further comments ?

[pigletfly]

and with this KEP, we don't need SkippedPropagatingAPIs flag any more.

[RainbowMango]

I'm trying to figure out which PR/Issue should be included in the coming v1.7 release which is planned at the end of this month.
I guess we don't have enough time for this feature, so I'm moving this to v1.8.

[RainbowMango]

This PR has been delayed for more than 2 years, part of the work has been done(like, #1366), but I think it still lacks of enough benefits for us to do that(split detector) for now, but I can imagine that we will do that until we are going to introduce status(.status) to the PropagationPolicy.

So, I'm going to close this PR for now, and maybe revisit it in the future.
/close

[karmada-bot]

@RainbowMango: Closed this PR.

In response to this:

This PR has been delayed for more than 2 years, part of the work has been done(like, #1366), but I think it still lacks of enough benefits for us to do that(split detector) for now, but I can imagine that we will do that until we are going to introduce status(.status) to the PropagationPolicy.

So, I'm going to close this PR for now, and maybe revisit it in the future.
/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.