zos3: support update of some of workloads

[muhamadazmy]

The provision engine need to handle the failure to update differently than an install update. The problem is a failed update does not mean that the reservation is gone.

For example, increase a disk size can fail, but doesn't mean the disk is gone so the disk state should still be okay but we need to report back that the operation of the resize has failed. This is currently is not possible, because a workload can only hold ONE error message that is associated with the workload state.

I suggest that a workload can have instead (State) which is basically the current disk state. And also a List of (states) that are associated with operations.

For example

Disk Workload {
   State: Ok,
   Result: {
       Size: "current disk size",
    } 
   Operations {
      {State: Error, Operatino: update, Time: Timestamp, message: "failed to increase disk size, no enough space"}
      {State: Ok, Operation: install, Time: Timestamp, message: ""}
   }
} 

• Deployment storage rewrite to support transactions
• Disk resize
• ZDB resize
• Monitoring should use transaction data to correctly calculate usage

[muhamadazmy]

Requirements

Was thinking about the cleanest way to implement this without sacrifice correctness of the operation. Came across this set of requirements

• A deployment is a container of some workloads that can interact together
• A change on the workload can be to create, update or delete
• Not all workload types can execute an update
• An update on the workload need to change the state if the update was successful, otherwise a failure to update need to reflect that the transaction has failed, BUT the state is not (the state also include workload data)

This all pushes toward a different persisted workload storage (currently deployments are stored as single files). Instead the abstract structure of storage need to reflect "transactions" where transactions can itself container 'data', 'state' and error. and the final state of the object is computed by scanning the transactions and compute the final state/data of the workload.

deployment {
   ...
   workload: <name> {
     type: <type>
     transactions: [
        {op: install, data: {...}, state: ok, error: none}
        {op: update, data: {...}, state: not-changed: error}
     ]
   }
}

for example the previous workload state will still be ok, but with the data provided on install.
If we push another update call that passes, then it will has {op: update, data: {..}, state: ok} and then the final state of the workload will be ok, and the associated data is data from last update operations

WORK IN PRGRESS

[muhamadazmy]

Get Deployment operation need to be backward compatible. A Get operation need to return the same data (current state) of the deployment.
A new call should return history of operations with data, and errors.