Re: [Engine-devel] Task cancelation feature

----- Original Message ----- You can have clean task only when there is a clear owner for a task. This is not the case because it has been decided VDSM can be used by more then one client. I know that people kind of like how convenient it is but it's problematic from the same reason that the unix method is problematic. - If you die you can no longer track the task. - If the kid dies and restarts itself you no longer can track the task. - If the task is started by another process you can no longer track it. - If you happen to die and not restart all your tasks stay there until someone clears them and it's impossible to know for sure when that is safe. We already have issues because this semantic, doesn't hold up for a lot of the error cases. It doesn't hold up at all when there are more then one task instigators. Because in TCP and and AMQP you are guaranteed to get the result message as long as you are connected to the bus you will always know the result unless you or VDSM crashed. When you restart, you have to write code to sync up in case something happen while you where down anyway. When VDSM restart\errors you need to write code to check how the task ended anyway because even "failed" tasks can finish successfully. Also, in the new storage, VDSM restarts usually don't fail big operations and the can continue even on another host. (We send the commit write and the storage fails just after the request was sent but we didn't get the write ack. The task is committed but it failed on timeout.) As I said, everything *is* asynchronous. It's impossible to have synchronous calls because you can't have synchronous calls on AMQP\TCP. Because the engine is responsible for generating the ID there is no need for the silly 2 step approach we have now. Yes, If you convince everyone to move away from message based communication and multiplexing requests on the same TCP connection (or go back to only HTTP) you can get synchronous tasks back. If you can find a way to make "clean task" make sense and work then you can have that back too. I think that after thinking about it you'll realize that considering all the possible error flows, sync-up on failure is the most robust and flexible way to go. Further more, I doubt you can find a system where you never need to sync-up on the state of VDSM so might as well make that the only flow.