Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • The first thing first, make all hypervisors use the same resource base for Virtual Router.
  • Introduce a new capability interface to network elements, named "aggregated executionAggregatedCommandExecutor"
    1. If the network element has this capabilityis an "AggregatedCommandExecutor", "prepareAggregatedExecution(Network)" would be called when developer want all the following commands to be aggregated executed.
      1. The designed scenario is VR rebooting or re-create.
    2. After the aggregated period past, "completeAggregatedExecution(Network)" would be called, then network element would start to execute the all commands in it's queue
      1. The queue would be formed into one command in VR's case, then give to VirtualRoutingResource for execution.
    3. prepareAggregatedExecution and completeAggregatedExecution() must be called in pair.
      1. Another function abortAggregatedExecution(Network) should be called if completeAggregatedExecution() cannot be called(e.g. some commands failed to generated during the process), to clean up the queue and fail the task.
      2. Call prepareAggregatedExecution() alone would result in all the following commands failed to executed and blocked forever.
  • Virtual Router implemenation:
    1. All the following executed commands would be put in a queue(per VR) in the mgmt server, waiting to be executed
      1. Currently we would still return true for each commands for backward compatibility
      2. But the result of "aggregated command" is the real result.
    2. The aggregated commands would form a new command
    3. VirtualRouting would execute the aggregated command in following sequence:
      1. Get all the preparation done.
        1. e.g. Plug in nics or find nic no, dependence on the hypervisors
      2. Generate a configuration file represent all the commands in the aggregated command
        1. Some commands are a little different, e.g. configure load balancer, which would require copy files to VR, which may need extra process since the file would be overrided in the VR by other configure load balancer command later.
      3. Send the configuration to VR to execute
      4. Get the clean up done.
  • Mind the gap!
    • Order is extremely important!
      • Every commands called in original order should happen in the exactly same order in aggregated execution.
        • We don't want to program firewall before ipassoc.
      • No other command should be executed before VR complete the aggregated execution
        • It can be guaranteed if the aggregated command has been executed earlier in VR, because it would hold the VR lock inside.
    • Reboot of VR should clean the queue.
    • If the failure happened in the execution process, it should provide enough debug information
      • e.g. which command failed with what's parameter, and what's the error message.
    • No other concurrent operation should happen to the same VR
    • Currently only support two state of execution result: Success, or Fail.
      • The result and debug info can be get, but partial success won't be supported.

...