Revision history [back]

I believe there is a misunderstanding here: the "relocation at run-time" is attempting to say that computation (ie: the act of computing something) could be relocated. Not the entity that performs it. Or at least, not the same entity.

So because of location independence and by avoiding "assumptions in nodes about where in the network it runs", it would be possible to start a node anywhere, and by bringing down one node and starting it somewhere else, the computation itself may be relocated (as in: it was at X, but is now running on host Y).

There is no support for migrating on-line nodes (ie: processes) from one machine to another.

I would also say that should probably not even be the responsibility of ROS (ie: the middleware), but of more appropriate (sub)systems of the OS and/or orchestration layer (Kubernetes supports something like this fi).

The idea describes in the tutorial you link would be similar to how stateless applications running in (Docker) containers can be easily migrated to run wherever computing resources are available: that is not the same as migrating live processes, but the in a similar sense one could state that "the computation" (ie: the functionality) is being migrated to other machines.

I believe there is a misunderstanding here: the "relocation at run-time" is attempting to say that computation (ie: the act of computing something) could be relocated. Not the entity that performs it. Or at least, not the same entity.

So because of location independence and by avoiding "assumptions in nodes about where in the network it runs", runs" (and of course also in the rest of the application/nodegraph), it would be possible to start a node anywhere, and by bringing down one node and starting it somewhere else, the computation itself may be relocated (as in: it was at X, but is now running on host Y).

There is no support for migrating on-line nodes (ie: processes) from one machine to another.

I would also say that should probably not even be the responsibility of ROS (ie: the middleware), but of more appropriate (sub)systems of the OS and/or orchestration layer (Kubernetes supports something like this fi).

The idea describes in the tutorial you link would be similar to how stateless applications running in (Docker) containers can be easily migrated to run wherever computing resources are available: that is not the same as migrating live processes, but the in a similar sense one could state that "the computation" (ie: the functionality) is being migrated to other machines.

I believe there is a misunderstanding here: the "relocation at run-time" is attempting to say that computation (ie: the act of computing something) could be relocated. Not the entity that performs it. Or at least, not the same entity.

So because of location independence and by avoiding "assumptions in nodes about where in the network it runs" (and of course also in the rest of the application/nodegraph), it would be possible to start a node anywhere, and by bringing down one node and starting it somewhere else, the computation itself may be relocated (as in: it was at X, but is now running on host Y).

There is no support for migrating on-line nodes (ie: processes) from one machine to another.

I would also say that should probably not even be the responsibility of ROS (ie: the middleware), but of more appropriate (sub)systems of the OS and/or orchestration layer (Kubernetes supports something like this fi).layer.

The idea describes in the tutorial you link would be similar to how stateless applications running in (Docker) containers can be easily migrated to run wherever computing resources are available: that is not the same as migrating live processes, but the in a similar sense one could state that "the computation" (ie: the functionality) is being migrated to other machines.

I believe there is a misunderstanding here: the "relocation at run-time" is attempting to say that computation (ie: the act of computing something) could be relocated. Not the entity that performs it. Or at least, not the same entity.

So because of location independence and by avoiding "assumptions in nodes about where in the network it runs" (and of course also in the rest of the application/nodegraph), it would be possible to start a node anywhere, and by bringing down one node and starting it somewhere else, the computation itself may be relocated (as in: it was at X, but is now running on host Y).

There is no support for migrating on-line nodes (ie: processes) from one machine to another.

I would also say that should probably not even be the responsibility of ROS (ie: the middleware), but of more appropriate (sub)systems of the OS and/or orchestration layer.

The idea describes described in the tutorial you link would be similar to how stateless applications running in (Docker) containers can be easily migrated to run wherever computing resources are available: that is not the same as migrating live processes, but the in a similar sense one could state that "the computation" (ie: the functionality) is being migrated to other machines.