FAB-13264 consensus migration: kafka2raft green path #1
This is the first of four (1/4) sub-tasks that focus on the
"green" path of consensus-type migration from Kafka to Raft.
By "green" we mean that there are no failures or aborts along
the way. The flow of the green path and the changes made in
these 4 tasks are described below. The 4 sub-tasks are staged
in a way that minimizes dependencies between them.
In this sub-task we introduce changes to the
orderer/common/bootstrap package (see details below).
In essence, Just before the last config block of the system
channel (COMMIT) is written to the ledger, the bootstrap file
(a.k.a "genesis.block", do not confuse with the first block of
the ledger) is swapped with the last block of the system
channel. This sub-task extends package orderer/common/bootstrap
to support this functionality.
See respective JIRA item for further details.
The "green" path for migration is the following:
1. Start with a Kafka-based ordering service
2. Send a config update tx (START-TX) on the system channel that:
- Has ConsensusType.MigrationState=START
- This will disable the creation of new channels
- This will disable the processing of normal (standard channel) transactions
3. Wait until the START-TX is committed and get the block height H of that tx
4. Send a config update tx (CONTEXT-TX) on each of the standard channels that:
- Has ConsensusType.MigrationState=CONTEXT
- Has ConsensusType.MigrationContext=H
- Has ConsensusType.Type="etcdraft"
- Has ConsensusType.Metadata=<a marshaled etcdraft metadata: Consenters,
Options, etc>
5. Send a config update tx (COMMIT-TX) on the system channel that:
- Has ConsensusType.MigrationState=COMMIT
- Has ConsensusType.MigrationContext=H
- Has ConsensusType.Type="etcdraft"
- Has ConsensusType.Metadata=<a marshaled etcdraft metadata: Consenters,
Options, etc>
- The metadata should be the same as for the standard channels, with the same
precautions.
- If committed successfully, no further configuration will be possible
6. Restart each orderer
- The orderer will bootstrap into an etcdraft mode
- Each channel will form a cluster
- Normal transactions can resume now
7. In order to configure the channels (system or standard), make sure that
the first
config update tx (on any given channel) after migration has:
- Has ConsensusType.MigrationState=NONE
- Has ConsensusType.MigrationS=NONE
- In addition to other changes to the channel's config.
Change-Id: Iccd146bb7260bafa4e4d8c4ee457d2ac19f5a642
Signed-off-by:
Yoav Tock <tock@il.ibm.com>
Please register or sign in to comment