You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If a deployment process is properly completed and then triggered again, new service ids will be dynamically generated, and new instances will be deployed. So both the old and new versions will coexist. This happens because at the second deployment, we still have the previous cookbooks listed on node.json.
However, it is not a trivial issue, since we cannot just clear the node.json service list, once the second deployment may be not related to the first.
The text was updated successfully, but these errors were encountered:
Ok, it is not a real bug...
If I reenact the SAME choreography, the deployment is idempotent.
By the SAME choreography I mean the choreography with the same ID that lives on EE memory.
If I deploy a second choreography, does not matter that it is EQUIVALENT to the first one: new services must be deployed indeed.
And if I shut down EE all the choreographies are lost (what I did to raise this issue). Since no previous choreographies exist, the second deployment (after restart) is a completely new choreography deployment.
The gotcha: since EE does not stores their choreographies to avoid crash problems, maybe the right thing to do would be: the EE must clear some files to start in a clean state (i.e. clear the node.json file).
If a deployment process is properly completed and then triggered again, new service ids will be dynamically generated, and new instances will be deployed. So both the old and new versions will coexist. This happens because at the second deployment, we still have the previous cookbooks listed on node.json.
However, it is not a trivial issue, since we cannot just clear the node.json service list, once the second deployment may be not related to the first.
The text was updated successfully, but these errors were encountered: