The orchestrator should know which devices have which jobs, even if the jobs move around
Because of this, it'd be better if instead of having to connect to devices directly (which has been the case i.e. opening up http://localhost:5000/request-history to see what the device in port 5000 has done) the orchestrator would query their execution history
Could be fired from a timer or ad hoc requests
Such an interface could then later be extended to show resource/task-manager -type view on each device (CPU, memory etc.)
In addition, the current execution-tab can be removed moving more towards autonomic devices, that the orchestrator just keeps track of and acts as a connection database
TODO:
[ ] Once a deployment is activated (i.e. deployed), start querying their history and dump into database
[ ] Add a ReST endpoint for inspecting these histories
The orchestrator should know which devices have which jobs, even if the jobs move around
Because of this, it'd be better if instead of having to connect to devices directly (which has been the case i.e. opening up
http://localhost:5000/request-historyto see what the device in port 5000 has done) the orchestrator would query their execution historySuch an interface could then later be extended to show resource/task-manager -type view on each device (CPU, memory etc.)
In addition, the current execution-tab can be removed moving more towards autonomic devices, that the orchestrator just keeps track of and acts as a connection database
TODO: