Skip to content
This repository has been archived by the owner on May 27, 2022. It is now read-only.

[Enhancement request] Migration of application across multiple remote Clusters #18

Open
grzegorzpnk opened this issue Sep 10, 2021 · 4 comments

Comments

@grzegorzpnk
Copy link

Hello,

I'm currently working on a process of migration of applications (containers) between multiple remote Clusters. In order to provide unninterrupted communication for the MEC customers (that might be moving - user mobility) to MEC server (K8S Cluster) EMCO should have full control of an action of migration application to the new cluster.

First of all, new instance of application should be instantiated in a new cluster, and later on, once user will communicate with new application, an old instance of app in old cluster should be removed.

After analysis of current EMCO features I can assume that migration should be composed of two steps:

  1. Update Generic Placement Intent (currently only CREATE and DELETE is available, but I saw that UPDATE is ongoing, could you confirm?)
  2. Update Deployment Group - that will diffrentiate current state of EMCO DB with new values overrided by step 1 and redeploy application that contains new Placemen Intent.

In my best understanding we could utilize monitor (cluster watcher) to synchro state across new and old cluster and execute method of delete old application in old cluster sequentially after the creation of new application in new cluster will be completed.

I'd like to ask - do you see right place to implement step 2? Should it be Generic Action Controller, or we should consider implementing own custom controller for migration operation?

Currently EMCO seems to be not ready to control sequence of executing isntantiatiation/delete method -> It is executing each operations at the same time, what make service (applciation) downtime in migration process -> undesirable.

Thanks in advance for response. I'm interested in both discussion and code contribution.
Greg

@ritusood
Copy link

This is a great idea. Currently we have implemented an Update API. Using that API it is possible to move the workloads to different clusters based on updated generic placement intents. In the update API the first phase is the deletion phase and followed by modify phase. This process is described in the doc here: https://github.com/open-ness/EMCO/blob/main/docs/design/emco-design.md#update. Monitor can be used to synchronize the state between the clusters. I believe we can make it a feature in main EMCO. Let's discuss more on this topic and plan to implement it.

@grzegorzpnk
Copy link
Author

Thank you @ritusood for your feedback.
As far as I understand correctly, it is possible to move the workloads to different cluster using Update API , but without keeping service continouity (Some time between delete and create the application is down).

The idea now is to implement similar solution but to have full control over the sequence of migration process (first create new assets in new cluster and later, after complition to delete assets in old cluster). It will allow to support service-continuity for k8s applications migrated between different clusters.
The most important part seems to receive confirmation from new cluster that the deployment is completed, what allows to trigger deletion phase.

We can also meet to discuss this solution deeply.
Bests, Greg

@ritusood
Copy link

@grzegorzpnk We have moved to GitLab location https://gitlab.com/project-emco/core/emco-base. Please move the issue over there.
You are right about the confirmation from EMCO when the deployment is complete as the important part. We have a status API to provide that information but currently, the user has to poll to get the status. We have a work item to add support for providing notifications to external users/controllers on any status change.

@grzegorzpnk
Copy link
Author

Hello, thanks. I'll move this thread to gitlab.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants