Adding write function to chaincode #1
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This is a read-only archive. Please visit https://gerrit.hyperledger.org/ for code submission |
ghost
closed this
alacambra
added a commit
to alacambra/fabric
that referenced
this pull request
Nov 28, 2017
ghost
pushed a commit
that referenced
this pull request
Jan 21, 2018
This changes the main Vagrant mount point to hyperledger to provide access to all present hyperledger repositories, including fabric-samples. This will give access to new repos as they are added without requiring a modification of the Vagrantfile every time. Patch-set #1: adds fabric-samples to the list of mounted volumes if it exists Patch-set #2: fixes commit message Patch-set #3: changes strategy, mounting the parent directory to be future proof Patch-set #4: removed unrelated changes committed by error Change-Id: If126bd9d6d8806f149a0e6bacb1d8d34875f7ba4 Signed-off-by: Arnaud J Le Hors <lehors@us.ibm.com>
ghost
pushed a commit
that referenced
this pull request
Jan 30, 2019
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>
ghost
pushed a commit
that referenced
this pull request
Mar 4, 2019
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>
ghost
pushed a commit
that referenced
this pull request
Apr 8, 2019
ghost
pushed a commit
that referenced
this pull request
Jun 6, 2019
buddingleader
added a commit
to buddingleader/fabric
that referenced
this pull request
Jul 25, 2019
Geea-fabric optimized tps from 65 to 90
eledra89
pushed a commit
to Akachain/fabric-mongo
that referenced
this pull request
Dec 4, 2020
V.2.2 mongodb
Param-S
pushed a commit
to Param-S/fabric
that referenced
this pull request
Jun 6, 2022
…ft_blockpuller Add BlockFetcher to pull blocks in a BFT setting
This pull request was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Motivation and Context
Fixes #
How Has This Been Tested?
Checklist:
Signed-off-by: