Deployments updates

[muhamadazmy]

• ZOS has always supported updating a deployment. It works by updating the deployment hash on the chain then send a new deployment to the node (where the deployment hash is validated against the one on the chain)
• Before the node reported how much capacity is used by a deployment so if a user updated his deployment with a new hash but never updated the deployment on the node, there is no harm done.
• Now after the new capacity planning changes, the user actually request the needed capacity on the chain, for capacity planning purposes.
• A user then can create a deployment with lets say capacity 100.
• A user send a deployment to a node the node validate that the deployment required capacity is indeed <= 100.
• Node runs the deployment
• The user then updates his deployment and make it smaller (say 50, or even 0)
• The user never update his deployment on the node.
• User gets free capacity.

The problem is it's hard to tell if an update node operation is malicious or good. A user can do the same operation and then update his deployment on the node. Hence the node shouldn't take any aggressive action on a deployment if it's updated but not have the user request yet.

A better temporary solution is that a deployment update should never reduce the used capacity but only bring it up (or change the hash). this should apply also for capacity reservation

[muhamadazmy]

Conclusion:

• You can increase and decrease capacity reservation
• For deployment you can only
  • Change it's hash
  • Increase it's capacity reservation
  • Delete

This means a user can only (properly) decrease a capacity reservation size if he deleted a deployment. You can update your deployment as much as you want this can be either only change of the hash (no change in capacity) or increase the capacity. but never shrinking it

[muhamadazmy]

@brandonpille ?

[brandonpille]

I'm on it.