Merge remote-tracking branch 'upstream/main' into develop

docs/source/guides/besu/add-new-member-org.md

@@ -27,7 +27,7 @@ This guide explains how to add a new validator node to an existing organization
 
 1. **Update network.yaml file**
 
-    Refer [this guide](../networkyaml-besu.md) for details on editing the configuration file.
+    Make sure that the genesis file is provided in base64 encoding. Also, if you are adding node to the same cluster as of another node, make sure that you add the ambassador ports of the existing node present in the cluster to the network.yaml
 
     The `network.yaml` file should contain the specific `network.organization` details along with the enode information, genesis file in base64 encoding and tessera transaction manager details
 

docs/source/guides/besu/add-new-validator-node.md

@@ -17,8 +17,25 @@ This guide explains how to add a new validator node to an existing organization
 
     To add a new node in Besu, an existing besu network should be running, enode information of all existing nodes present in the network should be available, genesis file should be available in base64 encoding and the information of transaction manager nodes and existing validator nodes should be available. The new node account should be unlocked prior adding the new node to the existing besu network. 
 
-    ---
-    **NOTE**: Addition of a new validator node has been tested on an existing network which is created by Bevel. Networks created using other methods may be suitable but this has not been tested by Bevel team.
+The `network.yaml` file should contain the specific `network.organization` details along with the tessera transaction manager node details and existing validator and member node details.
+
+---
+**NOTE**: Make sure that the genesis file is provided in base64 encoding. Also, if you are adding node to the same cluster as of another node, make sure that you add the ambassador ports of the existing node present in the cluster to the network.yaml
+
+---
+For reference, sample `network-besu-new-validatornode.yaml` file [here](https://github.com/hyperledger/bevel/blob/main/platforms/hyperledger-besu/configuration/samples/network-besu-new-validatornode.yaml)
+
+```yaml
+--8<-- "platforms/hyperledger-besu/configuration/samples/network-besu-new-validatornode.yaml:1:201"
+```
+
+Three new sections are added to the network.yaml   
+
+| Field       | Description                                              |
+|-------------|----------------------------------------------------------|
+| tm_nodes | Existing network's transaction manager nodes' public addresses with nodeport.|
+| besu_nodes | Existing network's besu nodes' public addresses with rpc port.|
+| genesis | Path to existing network's genesis.json in base64.|
 
 
 1. **Update configuration file**

docs/source/guides/besu/add-new-validator-org.md

@@ -27,7 +27,7 @@ Refer [this guide](../networkyaml-besu.md) for details on editing the configurat
 The `network.yaml` file should contain the specific `network.organization` details along with the transaction manager node details and existing validator and member node details.
 
 ---
-**NOTE**: Make sure that the genesis flie is provided in base64 encoding. Also, if you are adding node to the same cluster as of another node, make sure that you add the ambassador ports of the existing node present in the cluster to the network.yaml
+**NOTE**: Make sure that the genesis file is provided in base64 encoding. Also, if you are adding node to the same cluster as of another node, make sure that you add the ambassador ports of the existing node present in the cluster to the network.yaml
 
 ---
 For reference, sample `network-besu-new-validatororg.yaml` file [here](https://github.com/hyperledger/bevel/blob/main/platforms/hyperledger-besu/configuration/samples/network-besu-new-validatororg.yaml)

docs/source/guides/networkyaml-besu.md

@@ -39,7 +39,7 @@ Although, the file itself has comments for each key-value, here is a more detail
 The sections in the sample configuration file are  
 <a name="type"></a>
 type
-: `type` defines the platform choice like corda/fabric/indy/quorum/besu, here in the example its **besu**.
+: `type` defines the platform choice like corda/fabric/indy/quorum/besu, here in the example it's **besu**.
 
 <a name="version"></a>
 version
@@ -55,7 +55,7 @@ permissioning
 
 <a name="env"></a>
 env
-: `env` section contains the environment type and additional (other than 443) Ambassador port configuration. Vaule for proxy field under this section can be 'ambassador' as 'haproxy' has not been implemented for Besu.
+: `env` section contains the environment type and additional (other than 443) Ambassador port configuration. Value for proxy field under this section can be 'ambassador' as 'haproxy' has not been implemented for Besu.
 
 The snippet of the `env` section with example value is below
 
@@ -70,7 +70,7 @@ The fields under `env` section are
 | type       | Environment type. Can be like dev/test/prod.|
 | proxy      | Choice of the Cluster Ingress controller. Currently supports 'ambassador' only as 'haproxy' has not been implemented for Hyperledger Besu |
 | ambassadorPorts   | Any additional Ambassador ports can be given here. This is only valid if `proxy: ambassador`. These ports are enabled per cluster, so if you have multiple clusters you do not need so many ports to be opened on Ambassador. Our sample uses a single cluster, so we have to open 4 ports for each Node. These ports are again specified in the `organization` section.     |
-| loadBalancerSourceRanges | (Optional) Restrict inbound access to a single or list of IP adresses for the public Ambassador ports to enhance Bevel network security. This is only valid if `proxy: ambassador`.  |
+| loadBalancerSourceRanges | (Optional) Restrict inbound access to a single or list of IP addresses for the public Ambassador ports to enhance Bevel network security. This is only valid if `proxy: ambassador`.  |
 | retry_count       | Retry count for the checks. Use a high number if your cluster is slow. |
 |external_dns       | If the cluster has the external DNS service, this has to be set `enabled` so that the hosted zone is automatically updated. |
 | namespace         | (Optional) K8s Namespace on which proxy will be installed. Default value is `default`|
@@ -206,7 +206,7 @@ The fields under `peer` service are
 | tm_nodeport.ambassador | The tm port when exposed on ambassador service. |
 | tm_clientport.port   | Client Port used by Transaction manager `tessera`. This is the port where Besu nodes connect to their respective transaction manager. |
 
-The peer in an organization with type as `member` can be used to deploy the smarcontracts with additional field `peer.smart_contract`. The snapshot of peers service with example values is below
+The peer in an organization with type as `member` can be used to deploy the smartcontracts with additional field `peer.smart_contract`. The snapshot of peers service with example values is below
 ```yaml
         peers:
         - peer:
@@ -246,7 +246,7 @@ The additional fields under `peer` service are
 | smart_contract.contract_path | Path of the smart contract folder relative to deployjs_path  |
 | smart_contract.iterations | Number of Iteration of executions for which the gas and the code is optimised  |
 | smart_contract.entrypoint | Main entrypoint solidity file of the smart contract   |
-| smart_contract.private_for | Comma seperated string of `tessera` Public keys for the `privateFor`  |
+| smart_contract.private_for | Comma separated string of `tessera` Public keys for the `privateFor`  |
 
 Each organization with type as `validator` will have a validator service. The snippet of validator service with example values is below
 ```yaml

docs/source/guides/networkyaml-fabric.md

@@ -46,7 +46,7 @@ Use this [sample configuration file](https://github.com/hyperledger/bevel/blob/m
 
 <a name="type"></a>
 type
-: `type` defines the platform choice like corda/fabric/quorum, here in the example its **Fabric**.
+: `type` defines the platform choice like corda/fabric/quorum, here in the example it's **Fabric**.
 
 <a name="version"></a>
 version
@@ -162,7 +162,7 @@ Each `organization` field under `participants` field of the channel contains the
 |---------------------------------|------------------------------------------------------------|
 | name               | Organization name of the peer participating in the channel |
 | type               | This field can be creator/joiner of channel                |
-| org_status         | `new` (for inital setup) or `existing` (for add new org) | 
+| org_status         | `new` (for initial setup) or `existing` (for add new org) | 
 | ordererAddress     | URL of the orderer this peer connects to, including port                  |
 | peer.name          | Name of the peer                                           |
 | peer.type                          | Type can be `anchor` and `nonanchor` for Peer                                                                    |
@@ -202,15 +202,15 @@ Each `organization` under the `organizations` section has the following fields.
 | location                                    |  Location of the organization                                                                                    |
 | subject                                     | Subject format can be referred at [OpenSSL Subject](https://www.openssl.org/docs/man1.0.2/man1/openssl-req.html) |
 | external_url_suffix                         | Public url suffix of the cluster.         |
-| org_status         | `new` (for inital setup) or `existing` (for add new org) |
+| org_status         | `new` (for initial setup) or `existing` (for add new org) |
 | orderer_org        |  Ordering service provider.                              |  
 | ca_data                                     | Contains the certificate path; this has not been implemented yet |
 | cloud_provider                              | Cloud provider of the Kubernetes cluster for this organization. This field can be aws, azure, gcp or minikube |
 | aws                                         | When the organization cluster is on AWS |
 | k8s                                         | Kubernetes cluster deployment variables.|
 | vault                                       | Contains Hashicorp Vault server address and root-token in the example |
 | gitops                                      | Git Repo details which will be used by GitOps/Flux. |
-| services                                    | Contains list of services which could ca/peer/orderers/concensus based on the type of organization |
+| services                                    | Contains list of services which could ca/peer/orderers/consensus based on the type of organization |
 
 For the aws and k8s field the snapshot with sample values is below
 
@@ -273,7 +273,7 @@ The fields under `user` are
 | Field       | Description                                              |
 |-------------|----------------------------------------------------------|
 | identity          | The name of the user        |
-| attribute   | key value pair for the different attributes supported in Fabric, details about the attribues are [here](https://hyperledger-fabric-ca.readthedocs.io/en/latest/users-guide.html#attribute-based-access-control) |
+| attribute   | key value pair for the different attributes supported in Fabric, details about the attributes are [here](https://hyperledger-fabric-ca.readthedocs.io/en/latest/users-guide.html#attribute-based-access-control) |
 
 
 The services field for each organization under `organizations` section of Fabric contains list of `services` which could be ca/orderers/consensus/peers based on if the type of organization. 
@@ -341,7 +341,7 @@ The chaincodes section contains the list of chaincode for the peer, the fields u
 | image | Mandatory for external_chaincode, the container from docker registry applicable for this chaincode. For private registry, ensure password is passed in `network.docker` section |
 | crypto_mount_path | Required only when `tls: true`, the path where the crypto materials will be stored |
 
-The organization with orderer type will have concensus service. The snapshot of consensus service with example values is below
+The organization with orderer type will have consensus service. The snapshot of consensus service with example values is below
 
 ```yaml
 --8<-- "platforms/hyperledger-fabric/configuration/samples/network-fabricv2.yaml:228:229"

docs/source/guides/networkyaml-quorum.md

@@ -41,7 +41,7 @@ The sections in the sample configuration file are
 
 <a name="type"></a>
 type
-: `type` defines the platform choice like corda/fabric/indy/quorum, here in the example its **quorum**.
+: `type` defines the platform choice like corda/fabric/indy/quorum, here in the example it's **quorum**.
 
 <a name="version"></a>
 version
@@ -53,7 +53,7 @@ version
 
 <a name="env"></a>
 env
-: `env` section contains the environment type and additional (other than 443) Ambassador port configuration. Vaule for proxy field under this section can be 'ambassador' or 'haproxy'
+: `env` section contains the environment type and additional (other than 443) Ambassador port configuration. Value for proxy field under this section can be 'ambassador' or 'haproxy'
 
 The snippet of the `env` section with example value is below
 
@@ -68,7 +68,7 @@ The fields under `env` section are
 | type       | Environment type. Can be like dev/test/prod.|
 | proxy      | Choice of the Cluster Ingress controller. Currently supports 'ambassador' only as 'haproxy' has not been implemented for Quorum |
 | ambassadorPorts   | Any additional Ambassador ports can be given here. This is only valid if `proxy: ambassador`. These ports are enabled per cluster, so if you have multiple clusters you do not need so many ports to be opened on Ambassador. Our sample uses a single cluster, so we have to open 4 ports for each Node. These ports are again specified in the `organization` section.     |
-| loadBalancerSourceRanges | Restrict inbound access to a single or list of IP adresses for the public Ambassador ports to enhance Bevel network security. This is only valid if `proxy: ambassador`.  |
+| loadBalancerSourceRanges | Restrict inbound access to a single or list of IP addresses for the public Ambassador ports to enhance Bevel network security. This is only valid if `proxy: ambassador`.  |
 | retry_count       | Retry count for the checks. Use a high number if your cluster is slow. |
 |external_dns       | If the cluster has the external DNS service, this has to be set `enabled` so that the hosted zone is automatically updated. |
 
@@ -136,7 +136,7 @@ Each `organization` under the `organizations` section has the following fields.
 | k8s                                         | Kubernetes cluster deployment variables.|
 | vault                                       | Contains Hashicorp Vault server address and root-token in the example |
 | gitops                                      | Git Repo details which will be used by GitOps/Flux. |
-| services                                    | Contains list of services which could ca/peer/orderers/concensus based on the type of organization |
+| services                                    | Contains list of services which could ca/peer/orderers/consensus based on the type of organization |
 
 For the `aws` `vault` and `k8s` field the snippet with sample values is below
 ```yaml

docs/source/guides/networkyaml-substrate.md

@@ -40,7 +40,7 @@ Use this [sample configuration file](https://github.com/hyperledger/bevel/blob/m
 <a name="type"></a>
 
 ## type
-- `type` defines the platform choice like corda/fabric/indy/substrate, here in the example its **substrate**.
+- `type` defines the platform choice like corda/fabric/indy/substrate, here in the example it's **substrate**.
 
 <a name="version"></a>
 
@@ -135,7 +135,7 @@ The `organization` under the `organizations` section has the following fields.
 | k8s                  | Kubernetes cluster deployment variables.|
 | vault                | Contains Hashicorp Vault server address and root-token in the example |
 | gitops               | Git Repo details which will be used by GitOps/Flux. |
-| services             | Contains list of services which could ca/peer/orderers/concensus based on the type of organization |
+| services             | Contains list of services which could ca/peer/orderers/consensus based on the type of organization |
 
 For the `aws`, `k8s` and `vault` field the snapshot with sample values is below
 

platforms/hyperledger-besu/charts/besu-node/requirements.yaml

@@ -10,12 +10,12 @@ dependencies:
     repository: "file://../besu-tessera-node"
     tags:
       - tessera
-    version: ~1.0.0
+    version: ~1.1.0
     condition: tessera.enabled
   - name: besu-tlscert-gen
     alias: tls
     repository: "file://../besu-tlscert-gen"
     tags:
       - bevel
-    version: ~1.0.0
+    version: ~1.1.0
     condition: tls.enabled

platforms/hyperledger-indy/charts/indy-node/Chart.yaml

@@ -6,7 +6,7 @@
 apiVersion: v1
 name: indy-node
 description: Hyperledger Indy nodes for a SSI network
-version: 1.0.1
+version: 1.1.0
 appVersion: latest
 keywords:
   - bevel

platforms/substrate/charts/dscp-ipfs-node/Chart.yaml

@@ -8,7 +8,7 @@ apiVersion: v2
 name: dscp-ipfs-node
 appVersion: '2.6.1'
 description: dscp-ipfs is a component of the DSCP project that provides a distributed IPFS based storage solution for the DSCP platform.
-version: 1.0.0
+version: 1.1.0
 type: application
 annotations:
   hyperledger-bevel/platform: substrate

platforms/substrate/charts/substrate-genesis/Chart.yaml

@@ -9,7 +9,7 @@ apiVersion: v2
 name: substrate-genesis
 description: A Helm chart to generate the genesis for Substrate Nodes
 type: application
-version: 1.0.0
+version: 1.1.0
 appVersion: latest
 keywords:
   - bevel

platforms/substrate/charts/substrate-key-mgmt/Chart.yaml

@@ -7,7 +7,7 @@ apiVersion: v2
 name: substrate-key-mgmt
 appVersion: 'latest'
 description: A Helm chart to generate the keys for Substrate Nodes
-version: 1.0.0
+version: 1.1.0
 type: application
 annotations:
   hyperledger-bevel/platform: substrate

platforms/substrate/charts/substrate-node/Chart.yaml

@@ -8,7 +8,7 @@ apiVersion: v2
 name: substrate-node
 description: A Helm chart to deploy Substrate/Polkadot nodes
 type: application
-version: 1.0.0
+version: 1.1.0
 appVersion: latest
 keywords:
   - bevel