hyperledger/bevel

An automation framework for rapidly and consistently deploying production-ready DLT platforms

Hyperledger Bevel

• Short Description
• Scope of Project
  • Getting Started
  • Hyperledger Fabric
  • Corda Enterprise
  • Corda Opensource
  • Hyperledger Indy
  • Quorum
  • Hyperledger Besu
• Contact
• Contributing
• Initial Committers
• Sponsor

Short Description

An automation framework for rapidly and consistently deploying production-ready Distributed Ledger Technology (DLT) platforms.

Scope of Project

Hyperledger Bevel delivers an automation framework for rapidly and consistently deploying production-ready DLT platforms to cloud infrastructure.

Hyperledger Bevel is an accelerator/tool that helps developers rapidly set up and deploy secure, scalable and production-ready DLT network(s) that also allows new organizations to be easily on-boarded on the network. Bevel facilitates a safe and secure way of deploying and operating different DLT platforms.

It includes:

• Helm charts to deploy different DLT nodes and to generate the related crypto/identities.
• Helm charts for various operational features like adding new nodes, and deploying smart contracts.
• Helm charts to deploy Hyperledger Cacti connectors for Fabric, Quorum and Besu networks.
• Ansible playbooks and modular role definitions to automate the deployment of Helm charts.
• Ansible playbooks and roles to automate deployment of Hyperledger fabric using bevel-operator-fabric(Kubernetes operator for managing Hyperledger Fabric networks).
• Integrated CD using GitOps so that once the network is set up, all changes can be done via git PRs/merges.
• Configuration for Ambassador Edge Stack, HAProxy (for Hyperledger Fabric) and Isto Ingress (for Substrate) to act as Ingress Controller.

Hyperledger Bevel currently supports R3 Corda OS and Enterprise, Hyperledger Fabric, Hyperledger Indy, Hyperledger Besu, Quorum and Substrate. Other DLT platforms can easily be added.

Getting Started

To get started with the framework quickly, follow our Getting Started guidelines.

Detailed operator and developer documentation is available on our ReadTheDocs site.

The documentation can also be built locally be following instructions in the docs folder.

Hyperledger Fabric

For Hyperledger Fabric, we use the official Docker containers provided by that project. A number of different Ansible scripts will allow you to either create a new network (across clouds) or join an existing network.

Corda Enterprise

For Corda Enterprise, we build Docker containers from the Corda source with licensed jars. A number of different Ansible scripts will allow you to either create a new network (across clouds) or join an existing network.

Corda Opensource

For Corda Opensource, we build Docker containers from the Corda source. A number of different Ansible scripts will allow you to either create a new network (across clouds) or join an existing network.

Hyperledger Indy

For Hyperledger Indy, we build Docker containers from our source code. A number of different Ansible scripts will allow you to create a new network (across clouds).

Quorum

For Quorum, we use the official Docker containers provided by Quorum. A number of different Ansible scripts will allow you to either create a new network (across clouds) with choice of Consensus (between IBFT and RAFT) and a transaction Manager.

Hyperledger Besu

For Hyperledger Besu, we use the official Docker containers provided by that project. A number of different Ansible scripts will allow you to create a new network (across clouds).

Substrate

For Substrate, we use the official Docker containers provided by that project. A number of different Ansible scripts will allow you to create a new network (across clouds).

Contact

We welcome your questions & feedback on our Discord channel. Please join our Discord first.

Contributing

We welcome contributions to Hyperledger Bevel in many forms, and there’s always plenty to do!

Please review contributing guidelines to get started.

Build

If you are not using the provided Jenkins automation scripts, you can run the provisioning scripts within a docker runtime independent from your target Kubernetes cluster.

# Build provisioning image
docker build . -t ghcr.io/hyperledger/bevel-build

# Run the provisioning scripts
docker run -it -v $(pwd):/home/bevel/ ghcr.io/hyperledger/bevel-build

Initial Committers

• tkuhrt
• jonathan-m-hamilton
• sownak

Sponsor

Mark Wagner (Github: n1zyz, email: [email protected]) - TSC Member

bevel's Issues

Indy: Domain genesis config map Helm release

Create the Helm release for the Domain genesis config map Helm chart.

Indy: Pool genesis config map Helm release

Create the Helm release for the Pool genesis config map Helm chart.

Indy: Create the K8S auth job Helm chart

Create the K8S auth job Helm chart, will run using the admin Vault auth SA

https://alm.accenture.com/wiki/display/BLOCKOFZ/Vault+structure

The job will:

1. Get the respective SA JWT token and CA from K8S

2. Get the admin Vault auth SA token (for himself)

3. Get the admin Vault token (for himself) and use this token for Vault communication within this job

4. Create the Vault K8S authentication

5. Create the Vault policy

6. Create the Vault role (link SA, Vault K8S auth and K8S SA)

https://www.vaultproject.io/docs/auth/kubernetes.html

Indy: Bad indy-node Docker image url

Can't reference the whole repo, we have to concat the private repo base url with the image name and version here

Indy: Add a completion check to the indy-node Ansible role

The Ansible role for creation indy-node stewards should contain a task which checks that all steward indy-node pods have successfully started before the play can continue. We can use k8s_facts Ansible module in a loop with a reasonable timeout (replays x delay).

Indy: Create a Helm Release for the indy-key-mgmt job Helm Chart

Create a Helm Release for the indy-key-mgmt job Helm Chart.

Create contributing.md

In order to make BAF a welcoming community, where clarity on contribution process & expectations are clear, we need a contributing markdown file. This document should include:

• References to documentation
• Standards / quality gates
• PR process

Indy: Dockerfile for indy-node Docker image

Create the indy-node Dockerfile, which will be used to run a HL Indy VALIDATOR node. The node IP, node port, client port, node name and network name should be as input parameters (env variables).

[https://github.com/hyperledger/indy-node/tree/master/environment/docker/pool]

 

Indy: Jenkinsfile for indy-node Dockerfile image

Create a Jenkinsfile to build the indy-node Docker image.

Update Helm charts for peers, orderers and ca to take Ambassador annotations from values.yaml

Update the Helm charts for orderer, peer and ca fabric components so that the services include the Ambassador annotations. The annotation values should be read from values file.

As part of Jira BLOCKOFZ-950 we have updated the Helm charts to consider Ambassador annotation. The implementation picks up the entire block of annotation for ambassador from the values file. The Jira has been added in case the Helm charts need to be updated to only take the minimum required information from the user and accordingly creating the necessary Ambassador annotation

Indy: Jenkinsfile for indy-cli Dockerfile image

Create a Jenkinsfile to build the indy-cli Docker image.

Implement Linuxkit images for Corda Doorman

Follow instructions to create doorman image

[https://innersource.accenture.com/projects/BLOI/repos/platform-kubernetes-corda/|https://innersource.accenture.com/projects/BLOI/repos/platform-kubernetes-corda/browse/charts/doorman/templates/deployment.yaml)]

From ambassador branch

Acceptance Criteria:

Create and upload image into docker registry. 

Update readme/readthedocs for building image.

Test that a fully functional corda network 4.0 works the same way when upgraded to 4.1 via BAF

Test the complete corda network functionality once both the nodes and apps upgraded to v4.1 to ensure all the functionality works as same as v4.0

Implement RAFT Consensus for Fabric

As a user I want to use RAFT Consensus for my Fabric network so that I have a choice of consensus mechanisms.

This is a stretch goal if Fabric 1.4.1 is implemented.

Acceptance Criteria:

1. Add RAFT as another consensus mechanism
2. Provide choice of consensus mechanism in network configuration.
3. Create or update charts as necessary.
4. Test deployment on cluster using GitOps.

Indy: Ansible role for Vault auth K8S service accounts

Prepare an Ansible role which creates all organizations' service accounts by using a K8S component role - needs the creation of the K8S service account component template. Has to follow the pre-defined Vault policies in

https://alm.accenture.com/wiki/display/BLOCKOFZ/Vault+structure

that means

1. one service account per identity <identity-name>-vault-auth
2. one admin service account per org <org-name>-admin-vault-auth
3. one public crypto read only service account per org for the BAF AC <org-name>-baf-ac-vault-auth

Add the new role to the main deploy_network.yaml Indy playbook.

Indy: Jenkinsfile for indy-key-mgmt Dockerfile image

Create a Jenkinsfile to build the indy-key-mgmt Docker image.

Indy: Add Platform Indy to Fulcrum Automation Matrix

Add HL Indy to the Fulcrum Automation Matrix

[https://alm.accenture.com/wiki/display/BLOCKOFZ/Fulcrum+Automation+Matrix]

Indy: Create the Identity crypto generation Ansible role

Loop over all identities from the network.yaml and prepare values for Helm Releases for every identity (committed and pushed to Git and then executed by Flux). Wait for success criteria (e.g. public DID for every identity can be pulled from the respective Vault).

Upgrade Fabric Platform code to 1.4.4

Description

As a user I want to use Fabric version 1.4.4 in BAF so that the latest features are available.

Acceptance Criteria:

1. All Fabric images are upgraded to 1.4.4
2. Ensure backward compatibility of the network in BAF i.e. both 1.4.0 and 1.4.4 should be able to be installed using BAF.

Indy: Create Namespace Ansible role

Prepare an Ansible role which creates all organizations' namespaces by using a K8S component role - needs the creation of the K8S namespace component template. Add the new role to the main deploy_network.yaml Indy playbook.

Have a look at 

[https://innersource.accenture.com/projects/BLOCKOFZ/repos/blockchain-automation-framework/browse/platforms/hyperledger-fabric/configuration/roles/k8_component/tasks/main.yaml]

[https://innersource.accenture.com/projects/BLOCKOFZ/repos/blockchain-automation-framework/browse/platforms/hyperledger-fabric/configuration/roles/k8_component/templates/namespace_component.tpl]

Store and retrieve Vault token from Ansible secrets

As a user I want to store the Hashicorp Vault root token in Ansible Vault so that the token is not available as plaintext when the ansible script is executed.

Test Supplychain chaincode with Fabric 1.4.4 version

Description

As a developer I want to test BAF Supplychain app chaincode with Fabric 1.4.3 so that I can deploy the Supplychain app on a Fabric 1.4.3 network.

The Supplychain chaincode(s) can be found at examples\supplychain-app\fabric\chaincode_rest_server\chaincode
This sample is built for Fabric 1.4.0, this task is to test the chaincode for Fabric 1.4.4 and make any changes if necessary.

Acceptance Criteria

1. Test Supplychain chaincode withe Fabric 1.4.4
2. Change the chaincode if required to support Fabric 1.4.4

Indy: Ansible role for Pool genesis

Create an Ansible role, which retrieves the DIDs, verification keys, BLS public and proof-of-possession keys for all stewards on the genesis network, assembles the Pool genesis transaction file, creates the Pool genesis config map values (Helm release) for all organizations and pushes them to the respective Git locations. The node names, IPs and ports should be taken from the network.yaml file. Also, please add this role to the Indy deploy-network playbook.

Indy: Pool genesis config map Helm chart

Create the Indy Pool genesis config map Helm chart.

Implement solo consensus in Fabric for dev environments

Indy: Vault structure has to reflect public and private crypto clearly

All crypto in Vault has to be clearly divided into public and private.

Indy: Create and run the first Indy deploy-network.yaml

Create the first deploy-network.yaml with the indy-node Ansible role and run it on the UDISP DEV environment.

Indy: Update HL Indy to 1.11.0

Indy 1.10.0 has been released

[https://github.com/hyperledger/indy-node/blob/master/CHANGELOG.md#1100]

Indy: Ansible role for Domain genesis

Create an Ansible role, which retrieves the DIDs and verification keys for all trustees and stewards on the genesis network, assembles the Domain genesis transaction file, creates the Domain genesis config map values (Helm release) for all organizations and pushes them to the respective Git locations. Also, please add this role to the Indy deploy-network playbook.

Indy: Change trustees and stewards to a list

Change the network.yaml and Vault structure to a list of trustees and stewards.

Example:

      services:
        trustees:
        - trustee:
          name: authority-trustee

Indy: Create the admin K8S auth Ansible role

The admin K8S auth in Vault should be created from the AC to avoid the Vault root token to be distributed to a K8S job. If the Vault token isn't present assume that the K8S auth was already created and skip the execution of the role in the deploy-network playbook.

If the Vault root token is present in the network.yaml, then execute an Ansible role, which will:

1. Get the respective SA JWT token and CA from K8S for the admin admin vault auth SA
2. Create the Vault K8S authentication for the admin vault auth SA
3. Create the Vault policy
4. Create the Vault role (link SA, Vault K8S auth and K8S SA)

https://alm.accenture.com/wiki/display/BLOCKOFZ/Vault+structure

Indy: Add baremetal K8S support to the shared environment-setup.yaml playbook

The current BAF supports just AWS EKS, we should add the ability to connect to any K8S cluster by providing the kubeconfig as an input parameter, because now it's being always obtained via AWS Authenticator.

Indy: Bad indy-key-mgmt Docker image link

The image won't be on Docker Hub, we have to point to a private repo (configured in network.yaml) and add to it just the image name and version here

Originally posted by @juraj-durech in #57

Indy: Add Ansible role to retrieve the AC Vault token

Add an Ansible role, which retrieves the K8S service account token and uses it to retrieve the Vault token for the Ansible controller. The token should be stored for later use in the deploy-network Indy Ansible playbook. Add this role to the deploy-network Indy playbook.

Indy: Create the K8S auth job Ansible role

The Ansible role will create:

1. Helm releases for all identity K8S auths (each identity has its read-only role)
2. Helm release for the organizations' admins K8S auth (read-write role)
3. Helm release for the BAF AC K8S auth (public crypto read-only)

Has to be aligned with Vault policies https://alm.accenture.com/wiki/display/BLOCKOFZ/Vault+structure

Indy: Add a network.yaml HL Indy validator Ansible role

Validate e.g.

1. At least 4 genesis stewards
2. Max 1 trustee per org
3. Max 1 endorser per org
4. At least one trustee per network.yaml
   ...

Indy: Update the DLT Network Schema with Indy

Update the Canonical DLT Network Configuration Schema

[https://alm.accenture.com/wiki/display/BLOCKOFZ/Canonical+DLT+Network+Configuration+Schema]

with HL Indy.

Indy: Implement the Indy cleanup playbook

Create the HL Indy cleanup playbook, which should:

1. Use the Vault root token to cleanup all organizations' Vault Indy crypto
2. Cleanup the Flux release folder in Git for all organizations
3. Delete all organizations' namespaces with all K8S resources (including PVCs and PVs)
4. Delete the Flux Helm release from all organizations' K8S clusters (including the Git secret)
5. Delete Tiller from all organizations' K8S clusters
6. Rollback all changes done on the Ansible controller (Vault client, Helm client, Kubectl, AWS cli ...)

Indy: Ansible role to get EIP metadata from AWS

Prepare an Ansible role which retrieves the EIP allocation IDs for all steward public IPs found in the network.yaml and stores them in an Ansible fact / variable to be used later. The role should also check that the same public IP is specified for all stewards within one organization.

Indy: Create the Helm Chart for indy-key-mgmt Identity generation job

Prepare a job Helm Chart using the indy-key-mgmt Docker image which will obtain a vault token using a K8S service account token and then will generate Identity crypto (run the script in the idy-key-mgmt Docker image).

Create Code of Conduct

In order to make BAF a welcoming community, where expectations are clear, we need a code of conduct document. This is largely expected to borrow from / reference the Hyperledger code of conduct, but should still have a reference within this repository.

Update Fabric network to support Policies

The current Fabric network on Kubernetes runs on default policies. This should be upgraded so that custom policies can be applied to the network.
Steps:

1. Explore how the NodeOUs can be configured manually i.e. not using cryptogen
2. Update the generate-crypto.sh and generate-user-crypto.sh to create the config.yaml for NodeOUs
3. Update the root configtx.yaml to include the policies from the fabric-network/configtx.yaml
4. Add the policy to the chaincode

Acceptance Criteria

1. No default Policies in the configtx.yaml when generating the genesis block

Indy: Domain genesis config map Helm chart

Create the Indy Domain genesis config map Helm chart.

Indy: Update the shared site.yaml playbook with Indy

Add the Indy main deploy network playbook to the shared site.yaml playbook.

Indy: Store identity crypto in Vault without bootstrap

Remove the bootstrap suffixes from Indy crypto in Vault, which affects:

1. Identity crypto generation in indy-key-mgmt (probably Vault upload)

2. Getting the crypto in indy-node init container (the from Vault path is without bootstrap but the filename should still have bootstrap)

Indy: Create StorageClass Ansible role

Prepare an Ansible role which creates all organizations' storage classes by using a K8S component role - needs the creation of the K8S storage class component template. Add the new role to the main deploy_network.yaml Indy playbook.

Indy: K8S Auth job Helm release

Create the Helm release for the K8S Auth job Helm chart.

POST /api/v1/container failing

With current installation of the chaincode, the post method is failing with following error on peer

Same/similar error with POST /api/v1/product

2019-09-23 09:38:04.928 UTC [endorser] callChaincode -> INFO 16d [allchannel][ac409e93] Exit chaincode: name:"supplychain" (30000ms)
2019-09-23 09:38:04.929 UTC [endorser] SimulateProposal -> ERRO 16e [allchannel][ac409e93] failed to invoke chaincode name:"supplychain" , error: timeout expired while executing transaction
github.com/hyperledger/fabric/core/chaincode.(*Handler).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:1225
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:312
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Invoke
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:301
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:238
github.com/hyperledger/fabric/core/endorser.(*SupportImpl).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/support.go:147
github.com/hyperledger/fabric/core/endorser.(*Endorser).callChaincode
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:142
github.com/hyperledger/fabric/core/endorser.(*Endorser).SimulateProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:237
github.com/hyperledger/fabric/core/endorser.(*Endorser).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:456
github.com/hyperledger/fabric/core/handlers/auth/filter.(*expirationCheckFilter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/expiration.go:61
github.com/hyperledger/fabric/core/handlers/auth/filter.(*filter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/filter.go:32
github.com/hyperledger/fabric/protos/peer._Endorser_ProcessProposal_Handler.func1
/opt/gopath/src/github.com/hyperledger/fabric/protos/peer/peer.pb.go:169
github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware.ChainUnaryServer.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware/chain.go:31
github.com/hyperledger/fabric/common/grpclogging.UnaryServerInterceptor.func1
/opt/gopath/src/github.com/hyperledger/fabric/common/grpclogging/server.go:91
github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware.ChainUnaryServer.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware/chain.go:34
github.com/hyperledger/fabric/common/grpcmetrics.UnaryServerInterceptor.func1
/opt/gopath/src/github.com/hyperledger/fabric/common/grpcmetrics/interceptor.go:30
github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware.ChainUnaryServer.func1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware/chain.go:39
github.com/hyperledger/fabric/protos/peer._Endorser_ProcessProposal_Handler
/opt/gopath/src/github.com/hyperledger/fabric/protos/peer/peer.pb.go:171
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).processUnaryRPC
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:982
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).handleStream
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:1208
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:686
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:1333
error sending
failed to execute transaction ac409e93d00be001a0732905c4e50ad7fe21daf61fea47026f42ad312a5d877a
github.com/hyperledger/fabric/core/chaincode.processChaincodeExecutionResult
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:244
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:239
github.com/hyperledger/fabric/core/endorser.(*SupportImpl).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/support.go:147
github.com/hyperledger/fabric/core/endorser.(*Endorser).callChaincode
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:142
github.com/hyperledger/fabric/core/endorser.(*Endorser).SimulateProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:237
github.com/hyperledger/fabric/core/endorser.(*Endorser).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:456
github.com/hyperledger/fabric/core/handlers/auth/filter.(*expirationCheckFilter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/expiration.go:61
github.com/hyperledger/fabric/core/handlers/auth/filter.(*filter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/filter.go:32
github.com/hyperledger/fabric/protos/peer._Endorser_ProcessProposal_Handler.func1
/opt/gopath/src/github.com/hyperledger/fabric/protos/peer/peer.pb.go:169
github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware.ChainUnaryServer.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware/chain.go:31
github.com/hyperledger/fabric/common/grpclogging.UnaryServerInterceptor.func1
/opt/gopath/src/github.com/hyperledger/fabric/common/grpclogging/server.go:91
github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware.ChainUnaryServer.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware/chain.go:34
github.com/hyperledger/fabric/common/grpcmetrics.UnaryServerInterceptor.func1
/opt/gopath/src/github.com/hyperledger/fabric/common/grpcmetrics/interceptor.go:30
github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware.ChainUnaryServer.func1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware/chain.go:39
github.com/hyperledger/fabric/protos/peer._Endorser_ProcessProposal_Handler
/opt/gopath/src/github.com/hyperledger/fabric/protos/peer/peer.pb.go:171
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).processUnaryRPC
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:982
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).handleStream
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:1208
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:686
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:1333

Ansible role to initialize and unseal Vault

Create Ansible role to automatically initialize and unseal Vault.

Doorman changes to implement TLS based doorman chart.

1)Changes in doorman.tpl ,doorman chart and implement them to get doorman up and running using the latest BLOI doorman chart (available in BLOI feature/ambassador branch - [https://innersource.accenture.com/projects/BLOI/repos/platform-kubernetes-corda/browse/charts/doorman)|https://innersource.accenture.com/projects/BLOI/repos/platform-kubernetes-corda/browse/charts/doorman/templates/deployment.yaml)] . 

 

2. certificate creation for ssl communication with mongodb database.

Acceptance criteria

1. Corda network should run with backward compatibility
2. Documentation to reflect the changes made