packetgraph icon indicating copy to clipboard operation
packetgraph copied to clipboard

core: graph operations, commit, snapshot and rollback

Open jerome-jutteau opened this issue 9 years ago • 0 comments

That's a lot in a issue title but it's just to keep the idea:

Stopping a graph, change a little thing, restart the graph may have a big cost as the "little thing" can be a part of a succession of several operations and we don't want to stop a graph at each step. We would be able to stop a graph, make all little operations and run the graph but maybe this action is done in an other thread than the graph. This may cause troubles to some brick (have to check this) and/or delay if the thread do not have the same priority.

The idea is to start a "session" on a graph, make change to it and when ready... commit change with a minimal impact on graph run. Two ideas to do this:

idea 1

  • pg_graph API overrides brick operations like pg_brick_unlink() but instead of just call the unlink function, it stacks operations.
  • pg_graph_commit() stops the graph, call all stacked operations and run the graph again.

Pro: easy to implement. Con: graph is doomed on error and graph is stopped during operations

idea 2

  • pg_graph API overrides brick operations like pg_brick_unlink() but make directly operations on an internal copy of the graph
  • If an error occurs on an operation, the original graph keeps running and stay untouched. A fresh new copy is made for future actions.
  • pg_graph_commit() stops the running graph, run the modified copy of the graph and destroy the original graph.

Pro: commit should always work, graph is not doomed on error and the commit delay is minimal. Con: need to implement copy of bricks, copy of graph: may be complicated to make.

How to copy a graph: idea 2.1

  • Add a copy operation for each brick. Each new copy have their edge pointing to original bricks.
  • Push all copies in a new graph
  • For each copy, look at each edge: get the name of the brick, get the corresponding brick copy in the new graph and replace edge so it point to the copied brick. Copying bricks is the main challenge: some bricks are easy to copy (like switch, diode, hub, print, antispoof, vtep, ...) but those depending on an external resource are more complicated to copy (vhost, nic, queue).

Idea 3

Pretty much the same solution as Idea 2 but this time, instead of really make actions on a graph copy, we create a function of each operation to test if the action is ok. Once user call commit(), all actions are performed and should go well.

Pro: prevent failing operation without touching graph Con: test if operation is possible on running easy seems easy how to check consecutive tests ? Graph is still stopped waiting for all operations to finish.

jerome-jutteau avatar Apr 21 '16 09:04 jerome-jutteau