You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 27, 2022. It is now read-only.
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:
Update Generic Placement Intent (currently only CREATE and DELETE is available, but I saw that UPDATE is ongoing, could you confirm?)
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
The text was updated successfully, but these errors were encountered:
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.
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
@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.
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:
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
The text was updated successfully, but these errors were encountered: