Created
September 30, 2015 16:22
-
-
Save rgrwkmn/7ee23c5887e73b65d424 to your computer and use it in GitHub Desktop.
Potential VM Deployment Process Actions
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| First there would be optimistic update actions when posting the data to the backend service. These would be linked together by some process ID in meta data. | |
| ``` | |
| { type: VM_POST, payload: vmDataOnClient } | |
| { type: VM_POST_ERROR, payload: someError } | |
| { type: VM_POST_SUCCESS, payload: vmDataFromServer } | |
| ``` | |
| Then streaming data would come from the web server with progress of the VM deployment on the hypervisor. These would be linked together by the VM ID, since the VM is the thing they have in common. | |
| ``` | |
| { type: VM_DEPLOY_START, payload: vmId } // VM added to deployment progress store | |
| { type: VM_DEPLOY_PROGRESS, payload: somePercent } // deployment progress store updated | |
| { type: VM_DEPLOY_ERROR, payload: someError } // deployment progress store updated | |
| { type: VM_DEPLOY_COMPLETE, payload: deploySummaryData? } // deployment progress store updated | |
| ``` | |
| `VM_DEPLOY_ERROR` needs to exist because errors don't necessarily stop the process, so one can't simply make the payload of `VM_DEPLOY_COMPLETE` an error and cover all possible errors. The completion payload would probably have some summary data that could contain multiple errors. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment