Uploaded image for project: 'Fabric'
  1. Fabric
  2. FAB-14215

Raft Consensus - System Test Ideas Incubator



    • Type: Epic
    • Status: Closed
    • Priority: High
    • Resolution: Done
    • Affects Version/s: v2.0.0, v1.4.1
    • Fix Version/s: None
    • Component/s: fabric-quality
    • Labels:
    • Epic Name:
      Raft Consensus - System Test Ideas Incubator
    • SDK Impact:
    • Design Status:
      Not Required
    • Function Test Status:
      Not Required
    • Documentation Status:
      Not Required
    • Sample/Tutorial:
      Not Required
    • Design:
      (Please add high level design or a link to the design)
    • Usage:
      (Please add usage information)


      This is the proving ground to capture ideas for upcoming raft system tests areas. Once we harden these ideas and agree to create actual testcases, they should be linked instead to:


      Below is a preliminary list. (I created Jira testtasks placeholders for each of these, but they each should be reviewed carefully and expanded into multiple testcases.)

      Functional and Negative Test Areas:

      • Targeted orderer restarts during onboarding
      • kube-monkey: random restarts during traffic runs with more channels and concurrency
      • Quorum tests: stop multiple orderers(some or all) to prevent quorum, and then recover them in different sequences, with traffic
      • Migration – all tests
      • TLS cert rotation for all orderersand onboard new ordererafterwards
      • TLS cert rotation for one or more orderers, with traffic, with restarts
      • Configure OSNs in channels with only partly overlapping consenter sets (e.g. A,B,C vs B,C,D) and run traffic
      • With overlapping consenter sets, also rerun tests for restarts, onboarding, cert rotation (as needed)
      • Configure OSNsindifferentordererorganizations and run traffic
      • With OSNs in different orgs, also rerun restarts, onboarding, cert rotation (as needed)

      Scaling and Performance:

      • Performance: Raft vs Kafka
      • Scaling traffic runs on more orderers, e.g., 5, 7, 11, 15, 100
      • Higher traffic rates using HFRD
      • Higher traffic rates (orderersonly) using OTE

      Stress and Disruption:

      • Resend transactions - after timeout of single TXs when needed
      • Resend transactions - DoSscenarios
      • Flood orderersto create stress, some while restarting orderers(e.g. thundering herd)
      • Send duplicate transactions to multiple orderers(IT or SVT?)
      • Other stress and disruptive test ideas…



          Issue Links



              Unassigned Unassigned
              scottz Scott Zwierzynski
              0 Vote for this issue
              4 Start watching this issue