hyperledger
Many issues when deploy a fabric 2.5.4 network using the playbooks in minikube
Describe the bug When trying to deploy a Fabric 2.5.4 network I found a series of bugs and inconsistencies.
- The first bug happens at the fabric-genesis stage: https://github.com/hyperledger-bevel/bevel/blob/35d5589254c4edcef8ce9c00140f674d7c4b96db/platforms/hyperledger-fabric/configuration/roles/create/genesis/tasks/valuefile.yaml#L2-L10 https://github.com/hyperledger-bevel/bevel/blob/35d5589254c4edcef8ce9c00140f674d7c4b96db/platforms/shared/configuration/roles/create/job_component/vars/main.yaml#L21-L21 ... https://github.com/hyperledger-bevel/bevel/blob/35d5589254c4edcef8ce9c00140f674d7c4b96db/platforms/shared/configuration/roles/create/job_component/vars/main.yaml#L30-L31 https://github.com/hyperledger-bevel/bevel/blob/35d5589254c4edcef8ce9c00140f674d7c4b96db/platforms/shared/configuration/roles/create/job_component/templates/fabric_genesis.tpl#L21-L22
This issue is fixed with:
image:
alpineUtils: {{ docker_url }}/bevel-alpine:{{ charts.bevel_alpine_version }}
fabricTools: {{ docker_url }}/{{ charts.fabric_tools_image }}
- The fabric-genesis operation tries to update a helm repo. However, no repo is added by default: https://github.com/hyperledger-bevel/bevel/blob/35d5589254c4edcef8ce9c00140f674d7c4b96db/platforms/shared/configuration/roles/create/job_component/tasks/main.yaml#L48-L48
So, I tried to add the bevel chart repo extensively mentioned in the documentation. It did not work
helm repo add bevel https://hyperledger.github.io/bevel
Error: looks like "https://hyperledger.github.io/bevel" is not a valid chart repository or cannot be reached: failed to fetch https://hyperl
edger.github.io/bevel/index.yaml : 404 Not Found
So I commented and it worked. I have finally executed the ./platforms/shared/configuration/site.yaml playbook.
# update_repo_cache: true
- Now, I use the playbook
platforms/hyperledger-fabric/configuration/add-new-channel.yamlto add a new channel. The bevel_alpine_version and fabric_tools_image appeared again, so I applied the same prior fix: https://github.com/hyperledger-bevel/bevel/blob/35d5589254c4edcef8ce9c00140f674d7c4b96db/platforms/shared/configuration/roles/create/job_component/templates/osn_create_channel_job.tpl#L21-L22
I could successfully create the channel.
- I also tried to create a channel using the
./platforms/hyperledger-fabric/configuration/create-join-channel.yaml. However, this playbook seems to be outdated, considering the changes introduced by https://github.com/hyperledger-bevel/bevel/pull/1712 https://github.com/hyperledger-bevel/bevel/blob/35d5589254c4edcef8ce9c00140f674d7c4b96db/platforms/hyperledger-fabric/configuration/create-join-channel.yaml#L21-L21 https://github.com/hyperledger-bevel/bevel/blob/35d5589254c4edcef8ce9c00140f674d7c4b96db/platforms/hyperledger-fabric/configuration/create-join-channel.yaml#L36-L36
After commenting this nonexistent playbooks, there it was the problem related to the bevel_alpine_version and fabric_tools_image again: https://github.com/hyperledger-bevel/bevel/blob/35d5589254c4edcef8ce9c00140f674d7c4b96db/platforms/shared/configuration/roles/create/job_component/templates/create_channel_job.tpl#L21-L22 https://github.com/hyperledger-bevel/bevel/blob/35d5589254c4edcef8ce9c00140f674d7c4b96db/platforms/shared/configuration/roles/create/job_component/templates/join_channel_job.tpl#L21-L22
To Reproduce Steps to reproduce the behavior:
- Build the bevel container
- Create a fabric 2.5.4 network file with gitops, vault, no proxy. Containing 2 orgs.
- Run the bevel container and execute:
mkdir build
# cp ./platforms/hyperledger-fabric/configuration/samples/network-fabricv2.yaml build/network.yaml
cp ~/.kube/config build/config
# setup vault
docker run --network=host -p 8200:8200 --name vault hashicorp/vault:1.13.1
export VAULT_ADDR='http://192.168.25.5:8200'
export VAULT_TOKEN="hvs.vkv1OoBqgXgVDAIMmo2TskCB"
vault secrets enable -version=2 -path=secretsv2 kv
docker build -t hyperledger/bevel:johann .
docker run -it --rm --network=host -v $(pwd):/home/bevel \
-w /home/bevel --name bevel hyperledger/bevel:johann /bin/bash
# EDIT the network.yaml file to set the correct values for your environment
# COMMANDS INSIDE THE CONTAINER
git config --global --add safe.directory /home/bevel
export PATH=/root/bin:$PATH
export KUBECONFIG=/home/bevel/build/config
export VAULT_ADDR='http://192.168.25.5:8200'
ajv validate -s ./platforms/network-schema.json -d ./build/network.yaml
# GENERATES ISSUES 1 and 2:
ansible-playbook -vv ./platforms/shared/configuration/site.yaml \
--inventory-file=./platforms/shared/inventory/ \
-e "@./build/network.yaml" \
-e 'ansible_python_interpreter=/usr/bin/python3'
# GENERATES ISSUE 3
ansible-playbook -vv ./platforms/hyperledger-fabric/configuration/add-new-channel.yaml \
--inventory-file=./platforms/shared/inventory/ \
-e "@./build/network.yaml" \
-e 'ansible_python_interpreter=/usr/bin/python3'
# GENERATES ISSUE 4
ansible-playbook -vv ./platforms/hyperledger-fabric/configuration/create-join-channel.yaml \
--inventory-file=./platforms/shared/inventory/ \
-e "@./build/network.yaml" \
-e 'ansible_python_interpreter=/usr/bin/python3'
Expected behavior Fabric 2.5.4 network is created, before channel is created and successfully joined.
Screenshots Issues:
Environment (please complete the following information):
- arch linux
- 6.12.21-1-lts
My network.yaml
##############################################################################################
# Copyright Accenture. All Rights Reserved.
#
# SPDX-License-Identifier: Apache-2.0
##############################################################################################
---
# yaml-language-server: $schema=../platforms/network-schema.json
# This is a sample configuration file for setting up initial Fabric network with 1 RAFT Orderer and 5 Nodes.
network:
# Network level configuration specifies the attributes required for each organization
type: fabric
version: "2.5.4"
# version: "2.2.2"
upgrade: false # true : To upgrading Hyperledger Fabric version from 1.4.x to 2.2.x
frontend: enabled #Flag for frontend to enabled for nodes/peers
#Environment section for Kubernetes setup
env:
type: "dev" # tag for the environment. Important to run multiple flux on single cluster
proxy: none # values can be 'haproxy' or 'none'
retry_count: 20 # Retry count for the checks
external_dns: enabled # Should be enabled if using external-dns for automatic route configuration
labels:
service:
example1: example2
deployment: {}
pvc: {}
# For providing Custom Templates to generate configtx.yaml
configtx:
custom: false # true : when custom tpl(s) are to be provided | false : when the default tpl(s) are to be used
folder_path: /home/bevel/build/configtx_tpl/ # path to folder where the tpl(s) are placed e.g. /home/bevel/build/configtx_tpl/
# Docker registry details where images are stored. This will be used to create k8s secrets
# Please ensure all required images are built and stored in this registry.
# Do not check-in docker_password.
docker:
url: "ghcr.io/hyperledger"
# username: "docker_username"
# password: "docker_password"
# Remote connection information for orderer (will be blank or removed for orderer hosting organization)
# For RAFT consensus, have odd number (2n+1) of orderers for consensus agreement to have a majority.
consensus:
name: raft
orderers:
- orderer:
type: orderer
name: orderer1
org_name: supplychain #org_name should match one organization definition below in organizations: key
uri: orderer1.supplychain-net:7050 # Must include port, Can be external or internal URI for orderer which should be reachable by all peers
- orderer:
type: orderer
name: orderer2
org_name: supplychain #org_name should match one organization definition below in organizations: key
uri: orderer2.supplychain-net:7050 # Must include port, Can be external or internal URI for orderer which should be reachable by all peers
- orderer:
type: orderer
name: orderer3
org_name: supplychain #org_name should match one organization definition below in organizations: key
uri: orderer3.supplychain-net:7050 # Must include port, Can be external or internal URI for orderer which should be reachable by all peers
# The channels defined for a network with participating peers in each channel
channels:
- channel:
consortium: SupplyChainConsortium
channel_name: AllChannel
channel_status: new
osn_creator_org: # Organization name, whose orderers will create the channel. This field is only used with version 2.5
name: supplychain
chaincodes:
- "chaincode_name"
orderers:
- supplychain
participants:
- organization:
name: supplychain
type: joiner
org_status: new
peers:
- peer:
name: peer0
type: anchor
gossipAddress: peer1.supplychain-net:7051
peerAddress: peer0.supplychain-net:7051
- peer:
name: peer1
type: nonanchor
gossipAddress: peer0.supplychain-net:7051
peerAddress: peer1.supplychain-net:7051
ordererAddress: orderer1.supplychain-net:7050
- organization:
name: manufacturer
type: joiner
org_status: new
peers:
- peer:
name: peer0
type: anchor
gossipAddress: peer0.manufacturer-net:7051
peerAddress: peer0.manufacturer-net:7051 # Must include port, External URI of the peer
ordererAddress: orderer1.supplychain-net:7050
endorsers:
# Only one peer per org required for endorsement
- organization:
name: manufacturer
peers:
- peer:
name: peer0
corepeerAddress: peer0.manufacturer-net:7051
certificate: "/path/manufacturer/server.crt" # certificate path for peer
# Allows specification of one or many organizations that will be connecting to a network.
# If an organization is also hosting the root of the network (e.g. doorman, membership service, etc),
# then these services should be listed in this section as well.
organizations:
# Specification for the 1st organization. Each organization maps to a VPC and a separate k8s cluster
- organization:
name: supplychain
country: UK
state: London
location: London
subject: "O=Orderer,OU=Orderer,L=51.50/-0.13/London,C=GB"
external_url_suffix: ""
org_status: new
fabric_console: enabled # To deploy Fabric console for this organization
orderer_org: supplychain # Name of the organization that provides the ordering service
ca_data:
certificate: /path/supplychain/server.crt # Path where ca public cert will be stored (if new) or read from (if existing ca)
cloud_provider: minikube # Options: aws, azure, gcp, digitalocean, minikube
aws:
access_key: "aws_access_key" # AWS Access key, only used when cloud_provider=aws
secret_key: "aws_secret_key" # AWS Secret key, only used when cloud_provider=aws
# Kubernetes cluster deployment variables. The config file path and name has to be provided in case
# the cluster has already been created.
k8s:
context: "minikube"
config_file: "/home/bevel/build/config"
# Hashicorp Vault server address and root-token. Vault should be unsealed.
# Do not check-in root_token
vault:
url: "http://192.168.25.5:8200"
root_token: "hvs.T4o9M0QGLdLLnYxlHz252HPu"
secret_path: "secretsv2"
# Git Repo details which will be used by GitOps/Flux.
# Do not check-in git_access_token
gitops:
git_protocol: "https" # Option for git over https or ssh
git_url: "https://github.com/johannww/bevel.git" # Gitops https or ssh url for flux value files
branch: "deploy" # Git branch where release is being made
release_dir: "platforms/hyperledger-fabric/releases/dev" # Relative Path in the Git repo for flux sync per environment.
component_dir: "platforms/hyperledger-fabric/releases/k8sComponent" # Relative path where values files are stored.
chart_source: "platforms/hyperledger-fabric/charts" # Relative Path where the Helm charts are stored in Git repo
git_repo: "github.com/johannww/bevel.git" # Gitops git repository URL for git push (without https://)
username: "johannww" # Git Service user who has rights to check-in in all branches
password: "" # Git Server user password/token (Optional for ssh; Required for https)
email: "[email protected]" # Email to use in git config
private_key: "path_to_private_key" # Path to private key file which has write-access to the git repo (Optional for https; Required for ssh)
# Services maps to the pods that will be deployed on the k8s cluster
# This sample is an orderer service and includes a raft consensus
services:
ca:
name: ca
subject: "/C=GB/ST=London/L=London/O=Orderer"
type: ca
grpc:
port: 7054
consensus:
name: raft
orderers:
# This sample has multiple orderers as an example.
# You can use a single orderer for most production implementations.
# For RAFT consensus, have odd number (2n+1) of orderers for consensus agreement to have a majority.
- orderer:
name: orderer1
type: orderer
consensus: raft
grpc:
port: 7050
ordererAddress: orderer1.supplychain-net:7050
- orderer:
name: orderer2
type: orderer
consensus: raft
grpc:
port: 7050
ordererAddress: orderer2.supplychain-net:7050
- orderer:
name: orderer3
type: orderer
consensus: raft
grpc:
port: 7050
ordererAddress: orderer3.supplychain-net:7050
peers:
- peer:
name: peer0
type: anchor # This can be anchor/nonanchor. Atleast one peer should be anchor peer.
gossippeeraddress: peer1.supplychain-net:7051 # Internal Address of the other peer in same Org for gossip, same peer if there is only one peer
peerAddress: peer0.supplychain-net:7051 # External URI of the peer
cli: enabled # Creates a peer cli pod depending upon the (enabled/disabled) tag.
grpc:
port: 7051
events:
port: 7053
couchdb:
port: 5984
restserver:
targetPort: 20001
port: 20001
expressapi:
targetPort: 3000
port: 3000
- peer:
name: peer1
type: nonanchor # This can be anchor/nonanchor. Atleast one peer should be anchor peer.
gossippeeraddress: peer0.supplychain-net:7051 # External address of the existing anchor peer
peerAddress: peer1.supplychain-net:7051 # External URI of the peer
cli: enabled # Creates a peer cli pod depending upon the (enabled/disabled) tag.
grpc:
port: 7051
events:
port: 7053
couchdb:
port: 5984
restserver:
targetPort: 20001
port: 20001
expressapi:
targetPort: 3000
port: 3000
# Specification for the 2nd organization. Each organization maps to a VPC and a separate k8s cluster
- organization:
name: manufacturer
country: CH
state: Zurich
location: Zurich
subject: "O=Manufacturer,OU=Manufacturer,L=47.38/8.54/Zurich,C=CH"
external_url_suffix: ""
org_status: new
orderer_org: supplychain # Name of the organization that provides the ordering service
fabric_console: enabled # To deploy Fabric console for this organization
ca_data:
certificate: /path/manufacturer/server.crt
cloud_provider: minikube # Options: aws, azure, gcp, digitalocean, minikube
aws:
access_key: "aws_access_key" # AWS Access key, only used when cloud_provider=aws
secret_key: "aws_secret_key" # AWS Secret key, only used when cloud_provider=aws
# Kubernetes cluster deployment variables. The config file path and name has to be provided in case
# the cluster has already been created.
k8s:
context: "minikube"
config_file: "/home/bevel/build/config"
# Hashicorp Vault server address and root-token. Vault should be unsealed.
# Do not check-in root_token
vault:
url: "http://192.168.25.5:8200"
root_token: "hvs.T4o9M0QGLdLLnYxlHz252HPu"
secret_path: "secretsv2"
# Git Repo details which will be used by GitOps/Flux.
# Do not check-in git_access_token
gitops:
git_protocol: "https" # Option for git over https or ssh
git_url: "https://github.com/johannww/bevel.git" # Gitops https or ssh url for flux value files
branch: "deploy" # Git branch where release is being made
release_dir: "platforms/hyperledger-fabric/releases/dev" # Relative Path in the Git repo for flux sync per environment.
component_dir: "platforms/hyperledger-fabric/releases/k8sComponent" # Relative path where values files are stored.
chart_source: "platforms/hyperledger-fabric/charts" # Relative Path where the Helm charts are stored in Git repo
git_repo: "github.com/johannww/bevel.git" # Gitops git repository URL for git push (without https://)
username: "johannww" # Git Service user who has rights to check-in in all branches
password: "" # Git Server user password/token (Optional for ssh; Required for https)
email: "[email protected]" # Email to use in git config
private_key: "path_to_private_key" # Path to private key file which has write-access to the git repo (Optional for https; Required for ssh)
# Generating User Certificates with custom attributes using Fabric CA in Bevel for Peer Organizations
users:
- user:
identity: user1
attributes:
- key: "hf.Revoker"
value: "true"
# The participating nodes are peers
# This organization hosts it's own CA server
services:
ca:
name: ca
subject: "/C=CH/ST=Zurich/L=Zurich/O=Manufacturer"
type: ca
grpc:
port: 7054
peers:
- peer:
name: peer0
type: anchor # This can be anchor/nonanchor. Atleast one peer should be anchor peer.
gossippeeraddress: peer0.manufacturer-net:7051 # Internal Address of the other peer in same Org for gossip, same peer if there is only one peer
peerAddress: peer0.manufacturer-net:7051 # Must include port, External URI of the peer
cli: disabled # Creates a peer cli pod depending upon the (enabled/disabled) tag.
cactus_connector: disabled # set to enabled to create a cactus connector for Fabric
grpc:
port: 7051
events:
port: 7053
couchdb:
port: 5984
restserver: # This is for the rest-api server
targetPort: 20001
port: 20001
expressapi: # This is for the express api server
targetPort: 3000
port: 3000
chaincodes:
- name: "chaincode_name" #This has to be replaced with the name of the chaincode
version: "1" #This has to be replaced with the version of the chaincode
sequence: "1" #sequence of the chaincode, update this only for chaincode upgrade
maindirectory: "chaincode_main" #The main directory where chaincode is needed to be placed
lang: "golang" # The language in which the chaincode is written ( golang/java/node )
repository:
username: "johannww" # Git Service user who has rights to check-in in all branches
password: ""
url: "github.com/<username>/bevel-samples.git"
branch: main
path: "chaincode_src" #The path to the chaincode
arguments: 'chaincode_args' #Arguments to be passed along with the chaincode parameters
endorsements: "" #Endorsements (if any) provided along with the chaincode
This is my first bevel deploy, so I do not want to assume I have not made any mistake. However, I think this repository may benefit from regularly executing the fabric workflow in the .github/workflows folder.
Another inconsistent variable naming when installing the chaincode: https://github.com/hyperledger-bevel/bevel/blob/35d5589254c4edcef8ce9c00140f674d7c4b96db/platforms/hyperledger-fabric/configuration/roles/helm_component/templates/install_chaincode_job.tpl#L25-L26 https://github.com/hyperledger-bevel/bevel/blob/35d5589254c4edcef8ce9c00140f674d7c4b96db/platforms/hyperledger-fabric/configuration/roles/helm_component/vars/main.yaml#L32-L33
When trying to install the chaincode:
HelmRelease.helm.toolkit.fluxcd.io \"chaincode-install-supplychain-peer0-asset-transfer-basic-1\" is invalid:
[spec.releaseName: Too long: may not be more than 53 bytes...........
I had to get in the flux pods' logs to discover this, which could be detected when running the playbook. Perhaps changing "chaincode" to "cc" would free bytes for the chaincode name.
Also, this secret path prevents the k8s service account vault token from accessing the git_password secret:
https://github.com/hyperledger-bevel/bevel/blob/35d5589254c4edcef8ce9c00140f674d7c4b96db/platforms/hyperledger-fabric/configuration/roles/create/chaincode/install/tasks/valuefile.yaml#L24-L24
Because the vault token created for the service account:
https://github.com/hyperledger-bevel/bevel/blob/35d5589254c4edcef8ce9c00140f674d7c4b96db/platforms/shared/charts/bevel-vault-mgmt/templates/job.yaml#L174-L186
only has access to:
https://github.com/hyperledger-bevel/bevel/blob/35d5589254c4edcef8ce9c00140f674d7c4b96db/platforms/shared/charts/bevel-vault-mgmt/templates/configmap.yaml#L23-L23
Since the ca-server is the one requiring the bevel-vault-mgmt chart, the secretPrefix is:
https://github.com/hyperledger-bevel/bevel/blob/35d5589254c4edcef8ce9c00140f674d7c4b96db/platforms/hyperledger-fabric/configuration/roles/helm_component/templates/ca-server.tpl#L32
This is a possible fix:
- name: Write the git credentials to Vault
shell: |
vault kv put {{ vault.secret_path | default('secretsv2') }}/{{ network.env.type }}{{ org.name | lower }}/credentials/{{ namespace }}/git git_password="{{ chaincode.repository.password }}"
dep is depracated but working:
https://github.com/hyperledger-bevel/bevel/blob/35d5589254c4edcef8ce9c00140f674d7c4b96db/platforms/hyperledger-fabric/charts/fabric-chaincode-install/templates/install_chaincode.yaml#L186-L186
Same image and secrets naming problem for chaincode approval: https://github.com/hyperledger-bevel/bevel/blob/35d5589254c4edcef8ce9c00140f674d7c4b96db/platforms/hyperledger-fabric/configuration/roles/helm_component/templates/approve_chaincode_job.tpl#L23-L24 https://github.com/hyperledger-bevel/bevel/blob/35d5589254c4edcef8ce9c00140f674d7c4b96db/platforms/hyperledger-fabric/configuration/roles/helm_component/vars/main.yaml#L32-L33 https://github.com/hyperledger-bevel/bevel/blob/35d5589254c4edcef8ce9c00140f674d7c4b96db/platforms/hyperledger-fabric/configuration/roles/helm_component/templates/approve_chaincode_job.tpl#L36-L37
For the orderer ca certificate, I think it's better to fetch from the "orderer-tls-cacert", because it is created for all namespaces. Meanwhile, only the orderers' organizations vaults store the orderer ca certificate, which makes it hard for non-orderer organizations to access it.
For the admin secrets, a simple fix is possible:
env_type: "{{ network.env.type }}"
adminsecretprefix: {{ vault.secret_path | default('secretsv2') }}/data/{{ env_type }}{{ org.name | lower }}/users/admin
The Commit chaincode chart uses a secret deleted by commit a955703408f9aa2:
https://github.com/hyperledger-bevel/bevel/blob/35d5589254c4edcef8ce9c00140f674d7c4b96db/platforms/hyperledger-fabric/charts/fabric-chaincode-commit/templates/commit_chaincode.yaml#L86-L90
I could approve a chaincode, but could not commit it. I will leave a branch here that registers my necessary modifications: https://github.com/johannww/bevel/tree/fabric-fixes
EDIT: Now the commit is working on the my fabric-fixes branch.
I would like to use bevel to deploy my research network, mainly with the cacti connector, however its current state does not seem stable.
Am I missing something here? Shoud I use previous releases? Bevel Fabric Operator seems to be an option. It even supports Fabric v3.0.
After committing a regular chaincode, I am trying to install an external one. First thing: the whole platforms/hyperledger-fabric/configuration/external-chaincode-ops.yaml playbook is outdated. Its conditionals tests for nonexistent organization variables, such as type: https://github.com/hyperledger-bevel/bevel/blob/35d5589254c4edcef8ce9c00140f674d7c4b96db/platforms/hyperledger-fabric/configuration/external-chaincode-ops.yaml#L36-L37 https://github.com/hyperledger-bevel/bevel/blob/35d5589254c4edcef8ce9c00140f674d7c4b96db/platforms/hyperledger-fabric/configuration/external-chaincode-ops.yaml#L56-L57 https://github.com/hyperledger-bevel/bevel/blob/35d5589254c4edcef8ce9c00140f674d7c4b96db/platforms/hyperledger-fabric/configuration/external-chaincode-ops.yaml#L76-L77
Also, the fabric ca-tools cli no longer seems to be deployed but the playbook tries to use it for generating the crypto material for the external chaincode: https://github.com/hyperledger-bevel/bevel/blob/35d5589254c4edcef8ce9c00140f674d7c4b96db/platforms/hyperledger-fabric/configuration/external-chaincode-ops.yaml#L61-L61
I am still testing and improving.
I see there is a goal to make the helm charts standalone: https://github.com/hyperledger-bevel/bevel/issues/2557. However, the external chaincode installation chart still depends on the artifacts generated by the playbook: https://github.com/hyperledger-bevel/bevel/blob/35d5589254c4edcef8ce9c00140f674d7c4b96db/platforms/hyperledger-fabric/configuration/roles/create/chaincode/install_ext/tasks/create_package.yaml#L55-L62
I could launch a chaincode as a service without tls successfully: https://github.com/johannww/bevel/tree/7c648f7c234ccf68e7ef11debe96f9aeac1e99da
Another observation, I don't think that the regular chaincode can be launched by the peer, as there are no DinD containers. A tcp socket is also possible.
UPDATE: I have managed to make external chaincode (mTLS or not) to work and have enhanced the decoupling from the ansible playbooks---started by #1887.
Right now I am trying to update the documentation for the charts I changed.
@alvaropicazo, can you point to me how the READMEs for the charts were generated? helm-docs?
@johannww The root README file was written manually, @sownak what about the README for each chart? Same or did we use a tool for that?
To some extent, I already have: https://github.com/johannww/bevel/tree/fabric-fixes
I managed to get a network working network with chaincodes as a service (with and without tls). I continued the work on decoupling from ansible playbooks, etc. However, I renamed/deleted/created some new variables on the charts and that is why I asked about the documentation.
@alvaropicazo I am currently focused on other technologies while implementing my research project. I will probably get back to it in a near future. For now, I cannot continue the contributions.