Invoking flowlessly in default mode (i.e., non-incremental) results in output being returned that the dispatchers parsing logic fails to understand because node type information is lacking.
Steps to reproduce:
Invoke the coordinator as build/engine/coordinator --logtostderr --scheduler flow --flow_scheduling_cost_model 2 --v=1 --flow_scheduling_solver=flowlessly --debug_flow_graph
Submit a job.
Submit another job.
Observe the error in the output:
I0626 16:53:01.913985 6803 solver_dispatcher.cc:191] Writing flow graph debug info into /tmp/firmament-debug/debug_1.dm
I0626 16:53:01.914111 6803 utils.cc:307] External execution of command: ext/flowlessly-git/run_fast_cost_scaling --graph_has_node_types=true --global_update=false --daemon=false
I0626 16:53:01.915642 6803 utils.cc:346] Subprocess with PID 7002 created.
E0626 16:53:01.917798 6803 solver_dispatcher.cc:562] Unknown type of row in flow graph: m 38 24
I0626 16:53:01.917911 6803 utils.cc:370] Subprocess with PID 7002 exited with status 0
I0626 16:53:01.917989 6803 flow_scheduler.cc:135] Applying 0 scheduling deltas...
Inspecting the file in question shows that it is an incremental delta:
$ cat /tmp/firmament-debug/debug-flow_1.dm
m 38 24
c EOI
... but the system isn't expecting assignment changes to be returned.
This suggests to me that we should either:
make the --only_read_assignment_changes flag implicit when --flow_solver is set to "flowlessly";
not do above, but fail if the flag is now set when --flow_solver is set to "flowlessly";
remove the special cases for flowlessly and cs2 and simply allow the user to specify a solver binary plus the appropriate combination of --incremental_flow and --only_read_assignment_changes, making it their responsibility to get it right;
shelve this until the fast delta extraction code has been back-ported into the main code base, at which point flowlessly can return the entire flow, just as cs2 does.
(3) seems painful for the user, and (4) seems inefficient to me. Maybe go for (2)?
Invoking flowlessly in default mode (i.e., non-incremental) results in output being returned that the dispatchers parsing logic fails to understand because node type information is lacking.
Steps to reproduce:
build/engine/coordinator --logtostderr --scheduler flow --flow_scheduling_cost_model 2 --v=1 --flow_scheduling_solver=flowlessly --debug_flow_graphInspecting the file in question shows that it is an incremental delta:
... but the system isn't expecting assignment changes to be returned.
This suggests to me that we should either:
--only_read_assignment_changesflag implicit when--flow_solveris set to "flowlessly";--flow_solveris set to "flowlessly";--incremental_flowand--only_read_assignment_changes, making it their responsibility to get it right;(3) seems painful for the user, and (4) seems inefficient to me. Maybe go for (2)?