Skip to content
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

Migration from RAFT to BFT: IT: check mixed orderer #4643

Open
Tracked by #3773
tock-ibm opened this issue Jan 30, 2024 · 2 comments
Open
Tracked by #3773

Migration from RAFT to BFT: IT: check mixed orderer #4643

tock-ibm opened this issue Jan 30, 2024 · 2 comments
Assignees

Comments

@tock-ibm
Copy link
Contributor

tock-ibm commented Jan 30, 2024

Check what happens to a Raft-based orderering service that has two channels, A & B.
Channel A is migrated to BFT but B does not.
If the ordering service exits maintenance mode, do both channels continue to function properly?
We do not plan to support this scenario in production, but we would like to experiment and see what happens.

@dviejokfs
Copy link

@tock-ibm
Copy link
Contributor Author

tock-ibm commented Mar 5, 2024

Tested it at the end of this online meetup about deploying Hyperledger Fabric 3.0 using the bevel-operator-fabric

@dviejokfs Thanks! Could you summarize here what exactly you tested and how, and what were the results?

Our decision right now is to not officially support mixed orderers, i.e. an orderer with channels in both etcdraft & BFT. This does not mean it will not work, we just do not want to commit to it working and devote testing and development resource to it. However it would be interesting and important to know what actually happens in this case.

PS did you have the chance to check a mixed peer? #4642

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants