Propagate an application without specify all the resources

[IonBoleac]

Is there a method for propagating an application between clusters without specifying wich resources should be propagated? For example, can an app be propagated using the namespace where it's deployed?

[XiShanYongYe-Chang]

It sounds simple for users. How does this application work (actually, we have also been thinking about how to represent the application)? The existing feature that can take effect may be the dependency propagation feature, which can propagate the resources associated with the workload to the target cluster, and this following relationship can be defined by the user through the resource interpreter.

[IonBoleac]

Transitioning a microservices application from a single-cluster to a multi-cluster environment can indeed be complex.
I make an example to explain myself easily.

I have a microservices application, like this Google app: https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/v0.3.7/release/kubernetes-manifests.yaml, which is deployed in a single-cluster system. If I want to transfer this app to a cross-cluster system I must create a PropagationPolicy for every resource. So, creating a PropagationPolicy for each resource manually is time-consuming and prone to errors. It's a little "pain".

I think that developing a new Custom Resource Definition (CRD) that simplifies the deployment process across multiple clusters is quite innovative. Such a CRD could act as a high-level abstraction, allowing users to specify the target clusters and namespaces, thereby streamlining the propagation process. This approach would not only reduce the manual overhead but also minimize the risk of configuration mistakes. It's a solution that could potentially benefit many organizations looking to scale their applications efficiently in a cross-cloud-native ecosystem.

@XiShanYongYe-Chang what do you thinks?

[XiShanYongYe-Chang]

Sorry, @IonBoleac I missed this issue.

Do you mean an abstract layer above PropagationPolicy that is responsible for generating specific PropagationPolicy without requiring users to specify resources one by one? Please correct me if I'm wrong.

I think it's a good general idea. What are the details of it, and if you want, can you describe it in detail?

Also, if you want, I'd like to know how you use Karmada? In a reproduction environment, or for research?

[IonBoleac]

Do you mean an abstract layer above PropagationPolicy that is responsible for generating specific PropagationPolicy without requiring users to specify resources one by one? Please correct me if I'm wrong.

Yes, I mean exactly this. By this, the user is provided to deploy a microservices application without further onerous settings.

I think it's a good general idea. What are the details of it, and if you want, can you describe it in detail?

In the liqo system, the application's propagation is decided by the scheduler component, even if there are two or more clusters connected. This is available because the liqo system was thought of in this way. So, can it be replicated in Karmada? Maybe using a special component that handles how to schedule the application, to take essential into account only the working namespace. It's not so easy to implement this component because there are many things to handle, like as, rescheduling, etc.
Otherwise, this component may be used to handle the initial propagation, providing and writing all the propagation policies and after that the user can modify them. In this way, the migration from a single cluster to a multicluster is more easy. What do you think? Is it a good idea/way?

Also, if you want, I'd like to know how you use Karmada. In a reproduction environment, or for research?

I used Karmada for university research.