Open alain-ryser opened 5 years ago
This seems to be a bug, we will try to reproduce it. Likely the app delete is broken.
I created 3 local runtimes, deployed a simple calvinscript with 3 actors, migrated manually the 3 actors to one of the other runtimes. Then followed your screenshot. My result is that the actors were deleted.
$ cscontrol http://127.0.0.1:5001 actor list
[]
$ cscontrol http://127.0.0.1:5005 actor list
[]
$ cscontrol http://127.0.0.1:5003 actor list
[
"0f78e7cb-5bfd-490f-8013-08df5bdde910",
"3ea3fd2e-98c6-4df7-9a12-6d96a1bd949b",
"46ae313c-d8bd-43be-8117-3481976092df"
]
$ cscontrol http://127.0.0.1:5001 applications list
[
"12df9014-ee09-4b5a-9db3-b88ae5407fa2"
]
$ cscontrol http://127.0.0.1:5003 applications list
[]
$ cscontrol http://127.0.0.1:5005 applications list
[]
$ cscontrol http://127.0.0.1:5001 applications delete 12df9014-ee09-4b5a-9db3-b88ae5407fa2
""
$ cscontrol http://127.0.0.1:5001 actor list
[]
$ cscontrol http://127.0.0.1:5003 actor list
[]
$ cscontrol http://127.0.0.1:5005 actor list
[]
So it must be some difference in what you did before what is shown in the image. Could you share more details on which calvinscript, what migrations, etc that you did?
By the way, even if only one of the runtimes provide the application id (due to that the control interface only looks locally instead of in the registry), you should be able to delete the application from any of the nodes.
Hmm I actually did almost the same thing. The only difference is that instead of starting up the application and then migrating it manually, I used
$ cscontrol http://<ip>:5001 deploy --req depl.deployjson app.calvin
Where I used depl.deployjson and app.calvin as in the example on Application Deployment. So depl.deployjson was
{
"groups": {"firstgroup": ["src", "sum"]},
"requirements": {
"src": [{"op": "union_group",
"requirements": [{"op": "node_attr_match",
"kwargs": {"index": ["node_name", {"organization": "org.testexample", "name": "testNode1"}]}
},
{"op": "node_attr_match",
"kwargs": {"index": ["node_name", {"organization": "org.testexample", "name": "testNode2"}]}
}],
"type": "+"
},
{"op": "current_node",
"kwargs": {},
"type": "-"
}],
"sum": [{"op": "node_attr_match",
"kwargs": {"index": ["node_name", {"organization": "org.testexample", "name": "testNode2"}]},
"type": "+"
}],
"snk": [{"op": "node_attr_match",
"kwargs": {"index": ["node_name", {"organization": "org.testexample", "name": "testNode3"}]},
"type": "+"
},
{"op": "current_node",
"kwargs": {},
"type": "-"
}]
}
and app.calvin
src : std.CountTimer()
sum : std.Sum()
snk : io.StandardOut()
src.integer > sum.integer
sum.integer > snk.token
I started up the runtimes as in the example using
csruntime -n <ip-addr> -p 5000 -c 5001 -w 0 --attr '{"indexed_public": {"node_name": {"organization": "org.testexample", "name": "testNode1"}}}' &
csruntime -n <ip-addr> -p 5002 -c 5003 -w 0 --attr '{"indexed_public": {"node_name": {"organization": "org.testexample", "name": "testNode2"}}}' &
csruntime -n <ip-addr> -p 5004 -c 5005 -w 0 --attr '{"indexed_public": {"node_name": {"organization": "org.testexample", "name": "testNode3"}}}' &
Which is the only thing that is not on the screenshot.. Maybe it has to do when deploying applications using requirements?
Unrelated to the issue you have with buggy application clean-up, I'd just like to point out that the example code dealing with explicit .deployjson files dates to before we had a way of expressing deployment requirements in CalvinScript. In your case above, you could instead add something along the following lines to the .calvin file (untested):
rule node1 : node_attr_match(index=["node_name", {"organization": "org.testexample", "name": "testNode1"}])
rule node2 : node_attr_match(index=["node_name", {"organization": "org.testexample", "name": "testNode2"}])
rule node3 : node_attr_match(index=["node_name", {"organization": "org.testexample", "name": "testNode3"}])
rule node1or2 : node1 | node2
apply src : node1or2 & ~current_node()
apply sum : node2
apply snk : node3
Have a look at the files in calvin/tests/codegen, in particular test_deploy3.calvin and test_deploy3.deployjson.
While it does not solve your problem, it does make your life easier if you are going to play around with deployment requirements.
Oh wow thank you for the hint this is actually really helpful!
I recently tried the example from the deployment section in the wiki. I was then wondering if it is possible to rollback the application without shutting down the runtimes (which would be nice since the DHT wouldn't have to be rebuilt) and stumbled upon the cscontrol applications delete command. I tried it a few times but it seems that, when deleting an application, it doesn't actually stop the application in the runtime, as the actor still continue to exist within the different runtimes, as seen when running cscontrol actor list . I don't know if this is intended but if it is, I don't see how deleting an application is helpful..
Here a picture to demonstrate this. The application runs on three different nodes and was invoked from port 5001. If I use cscontrol applications list I thus only get an application ID if called from port 5001. If I delete that application the actors on other nodes still continue to run and the application therefor effectively still runs (the counter still gets printed to the stdout of the port holding the Print actor).