Better deployment UX

[sabrinasadik]

Currently when a deployment is performed, it appears to be done "synchronously" (at least from the perspective of the user). He deploys a workload, a request is sent to the node, and at some point he gets a response which is either success, failure, or timeout after 10 minutes (which is also a failure). There is no way for the user to know what the node is doing during this timeframe (metrics.grid.tf can be checked to verify the node is doing something, but the logs of the node are not accessible to end users). To make matters worse, the lack of a distributed hub causes nodes further away (higher latency) to have long deploy times, because it takes a long time to download the disk image (in the way it is currently implemented). Ultimately these deployments will timeout for the user, but continue in the background, and the user will have to recreate the deployment some time later. This results in bad UX, and users can be lead to believe there is something wrong with the node, while it is working just fine.

A solution for this problem, which would improve the UX, would be to make this flow more "asynchronous" as follows:

• When the user sends a deployment, the node validates it and immediately answers with a result: either ok, with some form of deployment ID, or an error describing the problem
• If the deployment is ok, it starts (or is queued if needed).
• The user can perform additional calls, providing this ID, to check on the current state of the deployment. This way the user can see what the node is actually doing.
• The timeout for a deployment can either be increased significantly, or removed altogether. Ideally the system could see that progress is being made.

In this flow, UI tools can do the periodic call on deployment state to show some kind of UI progress bar indicating what the node is doing right now, e.g. downloading flist, setting up network, copy disk image, start VM, deployment is done (running), ...
It provides more insight to the user, which can show him that a long running deploy is still going, and overal makes deployments less susceptible to these kind of timeout issues.