Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EE deployment is not properly idempotent! #29

Open
leonardofl opened this issue May 6, 2015 · 1 comment
Open

EE deployment is not properly idempotent! #29

leonardofl opened this issue May 6, 2015 · 1 comment
Labels

Comments

@leonardofl
Copy link
Member

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.

@leonardofl leonardofl added the bug label May 6, 2015
@leonardofl
Copy link
Member Author

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant