Introduce resource conflict resolution strategy to PropagationPolicy

[yizhang-zen]

What would you like to be added:
/kind api-change
/kind feature

Similar to karmadactl promote function, make PropagationPolicy to be able to propagate resources to member clusters where the resources exist, by annotating work.karmada.io/conflict-resolution=overwrite

Why is this needed:
To provide the ability to overwrite resources that already exist in the member cluster instead of failure when creating PropagatePolicy.

Use case 1:
When doing Blue/Green migration, the resources that wait to be migrated may already exist in the green cluster. Using overwrite strategy to avoid potential failures and make sure the resources get updated to be consistent with resources in original blue cluster.

Use case 2:
When failover, after promoting resources from legacy clusters, Karmada will be able to propagate resources to backup clusters and overwrite resources. This will make Karmada as single source of truth, but we can get it work with clusterAffinity and clusterTolerations to decide which resources can live as they are or get overwritten in which member clusters.

[Poor12]

I think it's useful to provide some update strategies to PropagationPolicy which could reduce user focus on internal objects.

[RainbowMango]

I might need to ask a few questions to understand the use cases.

When doing Blue/Green migration, the resources that wait to be migrated may already exist in the green cluster.

I guess the Blue/Green migration means migrating resources from blue cluster to green cluster. But why do the resources already exist in the green cluster? In addition, I'm curious about the Blue/Green migration thing, why do you need to do the migration?

but we can get it work with clusterAffinity and clusterTolerations to decide which resources can live as they are or get overwritten in which member clusters.

Do you mean the workaround without the requesting feature?

[yizhang-zen]

Yes, the B/G migration means migrating all existing workload from Blue cluster to Green cluster. In our case, the blue clusters are built using some customized tools, while green clusters are EKS ones. This migration will help us get rid of the old infra and move to AWS managed k8s cluster.

But why do the resources already exist in the green cluster?

That is because our migration strategy. Some of the critical services will be dump to Green cluster before the migration and they will be the dependencies that propagates by other application.

Do you mean the workaround without the requesting feature?

well..i was trying to say after the feature in place, it will work with other pp strategies to bring more flexibility.

[RainbowMango]

Thanks. It makes sense to me.

make PropagationPolicy to be able to propagate resources to member clusters where the resources exist, by annotating work.karmada.io/conflict-resolution=overwrite

I guess we might need to extend the PropagationPolicy(and ResourceBind as well) by adding a new field to specify the behavior. Am I right? Do you have any ideas on this API change?

[yizhang-zen]

Closed in favor of #3780 🙇‍♀️