Abstract
Hyperledger Bevel is an automation framework for rapidly and consistently deploying production-ready DLT platforms. This task aims to complete a live upgrade of a Hyperledger Fabric network from version 1.4.x to 2.2.x using Hyperledger bevel and document the steps as well as make any changes needed to automate any steps possible.
Mentors
Name | Time zone | Discord ID | Email ID |
---|---|---|---|
Sownak Roy | UK/BST | Sownak#7728 | sownak.roy@accenture.com |
Jagpreet Singh Sasan | IST | Jag#2402 | jagpreet.singh.sasan@accenture.com |
Mentee
Name | Time zone | Discord ID | Email ID |
---|---|---|---|
Mohit Vaish | IST | Mohitv#9920 | mohit_vaish@hotmail.com |
Communication channel: Discord+ Github
Project repo: https://github.com/hyperledger/bevel
Deliverables
- Automation of the live upgrade from version 1.4.x to 2.2.x of Hyperledger Fabric network deployed using Hyperledger Bevel
- Relevant operational guide on the live upgrade from version 1.4.x to 2.2.x of Hyperledger Fabric network deployed using Hyperledger Bevel
- Completion of relevant issues about the same on Github
Merged PR's
- TBD
- TBD
- TBD
Final Project Presentation:
- TBD
Milestones
Eval 1:
- Manual upgrade of the platform components (orderer, peer) of the network
- Manual upgrade of the application components (channel, chaincode) parts of the network
Eval 2:
- Operation Guide on how to upgrade manually
Eval 3:
- Helm and Ansible automation for upgrade of the components
Eval 4:
- Final Operation Guide and Video on how to upgrade using Hyperledger Bevel
Timeline
Dates | Tasks/Plan | Status |
---|---|---|
June 1 - June 14 | Mentee intro with the mentor. Introduction to the concepts of Bevel | Done |
June 15 - June 28 | Manual upgrade of non-chaincode parts of the network | Done |
June 29 - July 12 | Manual upgrade of chaincode parts of the network | Done |
July 13 - July 26 | Document the approach & manual upgrade tasks performed | Ongoing |
July 27 - Aug 9 | Automate the binary upgrade process for Orderer | Done |
Aug 10 - Aug 23 | Automate the binary upgrade process for Peers and upgrade DB | Done |
Aug 24 - Sept 6 | Automate tasks for upgrade capabilities | Ongoing |
Sept 7 - Sept 20 | Automate tasks to update EndPoints and Endorsement Policies | |
Sept 21 - Oct 4 | Automate tasks to update Lifecycle and ACLs | |
Oct 5 - Oct 18 | Test final automation | |
Oct 19 - Nov 1 | Update document | |
Nov 2 - Nov 12 | Prepare final presentation and demo |
Methodology
The planned approach can be broken into following steps:
- Perform a manual upgrade for all required steps and verify the results. Steps performed can be found here
- The operator updates the JSON file 'network.yaml' for upgrade flag and upgrade version. The operator also ensures the configuration in this file reflects the current state of Hyperledger fabric deployment. Operator should also takes backup of core.yaml and orderer.yaml files, if any changes are done for existing deployment
- Once the manual upgrade is tested. The approach is to automate the same manual steps which can be broadly divided into following:
- First upgrade orderer nodes to the upgrade version. When upgrade is finished, the script waits for operator confirmation to move to next step
- This step upgrade peer nodes one by one and as earlier waits for operator confirmation
- This step upgrade ca nodes and peer cli nodes(where available) to the upgrade version
- Now script will upgrade the capabilities for orderer, channel and application group for system channel and all application channels mentioned in network.yaml file
- Next step will update the system channel consortium and all application channel orgs for endorsement policies
- This step will update all the application channels 'application group' for endorsement and lifecycle policies
- This step will ensure that OrdererEndpoints are used in system channel and all application channels
- Where ACL needs to be updated, we update it in this final automated step
- Operator should compare the new core.yaml with backup file as per step 2 and manually make the required changes
- Operator can also deploy existing chaincode using new lifecycle of 2.2.x version.