-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix test-network to work with BFT consensus. #1047
Conversation
1fb3ed2
to
c69771c
Compare
7519e1d
to
d7529ea
Compare
@@ -3,15 +3,19 @@ | |||
# imports | |||
. scripts/envVar.sh | |||
. scripts/utils.sh | |||
export PATH="${PWD}"/../../fabric/build/bin:"${ROOTDIR}"/../bin:"${PWD}"/../bin:"$PATH" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are you sure this is needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You need this in case someone will want to use old binaries.
Me and Dave had the same approach when constructing nano-bash
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most people that download the samples and try it out will not have a fabric directory. I'd suggest to remove this change.
We added it for the nano bash sample since a target user of that sample was a Fabric developer who compiles their own binaries.
d7529ea
to
63a0ef4
Compare
@denyeart let's get this PR in, shall we? |
63a0ef4
to
38fda52
Compare
@@ -3,15 +3,19 @@ | |||
# imports | |||
. scripts/envVar.sh | |||
. scripts/utils.sh | |||
export PATH="${PWD}"/../../fabric/build/bin:"${ROOTDIR}"/../bin:"${PWD}"/../bin:"$PATH" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most people that download the samples and try it out will not have a fabric directory. I'd suggest to remove this change.
We added it for the nano bash sample since a target user of that sample was a Fabric developer who compiles their own binaries.
test-network/network.sh
Outdated
@@ -18,7 +18,7 @@ | |||
# this script is actually in and infer location from there. (putting first) | |||
|
|||
ROOTDIR=$(cd "$(dirname "$0")" && pwd) | |||
export PATH=${ROOTDIR}/../bin:${PWD}/../bin:$PATH | |||
export PATH="${PWD}"/../../fabric/build/bin:"${ROOTDIR}"/../bin:"${PWD}"/../bin:"$PATH" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most people that download the samples and try it out will not have a fabric directory. I'd suggest to remove this change.
We added it for the nano bash sample since a target user of that sample was a Fabric developer who compiles their own binaries.
6c693ad
to
b8c697b
Compare
@@ -316,7 +319,8 @@ function deployCCAAS() { | |||
|
|||
# Tear down running network | |||
function networkDown() { | |||
|
|||
local temp_compose=$COMPOSE_FILE_BASE | |||
COMPOSE_FILE_BASE=compose-bft-test-net.yaml |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not following this change... won't this always force the use of compose-bft-test-net.yaml instead of the default compose-test-net.yaml?
Why is the temp_compose required here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are correct.
The compose-bft-test-net.yaml is a super set of the compose-test-net.yaml. This means that if a user launched a regular network or a bft network, during shutdown all containers will be stopped no matter what initial configuration the user chose.
This actually spares me to pass any flags to the ./network.sh down
command, and to refer to different kinds of networks.
b8c697b
to
5436366
Compare
test-network/ADD_ORDERER_TUTORIAL.md
Outdated
@@ -0,0 +1,310 @@ | |||
# Adding Orderer To An Existing Network |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be part of the official documentation, not in the samples.
Added a new option for creating channel: Running ./network.sh createChannel -bft will initiate a channel running BFT orderers. Using ./network.sh up -bft will initiate dockers for bft environment. Added option for 4 orderers. Add add_new_orderer_to_config.py which is referenced in the fabric official docs. Signed-off-by: Arkadi Piven <arkadi.piven@ibm.com> Signed-off-by: arkadipiven <arkadi7770@gmail.com>
5436366
to
14872dc
Compare
identities = config['channel_group']['groups']['Orderer']['policies']['BlockValidation']['policy']['value']['identities'] | ||
identities_before_update = copy.deepcopy(identities) | ||
new_identity = copy.deepcopy(identities[0]) | ||
new_identity['principal']['id_bytes'] = identity | ||
identities.append(new_identity) | ||
_log_update('block validation identities', identities_before_update, identities) | ||
|
||
rule = config['channel_group']['groups']['Orderer']['policies']['BlockValidation']['policy']['value'][ | ||
'rule'] | ||
rule_before_update = copy.deepcopy(rule) | ||
rule['n_out_of']['n'] = _calculate_bft_quorum(new_orderers_count) | ||
rule['n_out_of']['rules'].append({'signed_by': new_orderers_count - 1}) | ||
_log_update('block validation rules', rule_before_update, rule) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One general question and one specific question.
General question - I didn't see this file originally... is it used in this PR? Or will other instructions use it?
Specific question - I didn't see anything like these BlockValidation policies in the original configtx.yaml, like I did for the Orderer Endpoints (above) and consenter mapping (below). Can you educate me on this... why are they not in configtx.yaml? Is it in the channel config implicitly somehow originally? Is this new for BFT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't see anything like these BlockValidation policies in the original configtx.yaml, like I did for the Orderer Endpoints (above) and consenter mapping (below). Can you educate me on this... why are they not in configtx.yaml? Is it in the channel config implicitly somehow originally? Is this new for BFT?
I'll answer this one, and will let Arkadi answer the first one.
First of all, remember that the "name" of the policy in configtx.yaml is a mere pointer to a meta policy of "any orderer".
The meta policies we have, or, the policies we have in general in Fabric, are not suitable to define BFT policies, as BFT policies depend on additional input found in the channel config (the consenters...) . To add support for that, it requires invasive changes to the channel config infrastructure.
However, a signature policy is a supported policy that can always be used and it is flexible enough to fit BFT block validation.
In the spirit of making Fabric more generic and pluggable, we don't want to define policy names for every type of consensus we can imagine. Some protocols require more signatures, some require less, some require a single threshold signature, etc.
While in Raft it's easy to define a policy string ("any orderer"), for BFT it's complex to do that in the configtx.yaml, and it can also be error prone.
For BFT, the Fabric tooling (configtxgen) overrides the block validation policy that is defined in the configtx.yaml, both in order to "protect the user from a misconfiguration", and also because it was my belief that a user should not need to understand the underlying BFT protocol to configure the policy.
So, when a channel is created using configtxgen, the genesis block contains the right policy. When a channel is updated, the orderer itself checks that the policy was correctly computed via an ad-hoc verification.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the general question:
This file is used in the following tutorial:
hyperledger/fabric#4390
Please look at the add_orderer.md committed file,
Under section "Add the fifth orderer to the config" subsection 4.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The sample looks great now, let's go ahead and merge while we finish out the doc PR.
Added a new option for creating channel:
Running ./network.sh createChannel -bft will initiate a channel running BFT orderers.