As the system stands, only deployers have the ability to change workloads. This is enforced through the smart contracts and signatures that deployers provide with their workloads.
Implementing something like this is more complex that it might seem at first. Transferring data from one node to another requires a compute workload that has access to that data. These kinds of administrative capabilities are intentionally left out of Zero OS as part of the security model.
Our goal is a self healing autonomous system without single points of failure. The Quantum Safe Storage system is one example, which is able to automatically restore the intended resilience level when a node it’s using goes offline.
In general, I think the better approach is develop solutions that provide self healing and redundant features while hiding complexity from the end user. Right now, for example, I can easily spin up a VM, but if the node goes offline it’s toast. Corporate clouds will keep backups and automatically spin up a new VM for you if something happens to one of their nodes. If someone can develop a similar service on the Grid, it would represent a great value and they can earn through sales channel fees.
At the same time, there’s nothing to stop those utilizing the Grid to coordinate with farmers to mitigate the impacts of planned service. So such a service provider could subscribe to alerts provided by farmers they work with and handle migrations on their end as needed. This could all be done without any changes to the base system, but if it turned out that some less intrusive feature could be added to facilitate such a system, I’d say we should consider it.