search

hyperledger-bevel / bevel

An automation framework for rapidly and consistently deploying production-ready DLT platforms
https://hyperledger-bevel.readthedocs.io/en/latest/
Apache License 2.0
346 stars 719 forks source link

Unable to add a new organization to the network in feature/fabric220 #1199

Closed sivaramsk closed 3 years ago

sivaramsk commented 3 years ago

Describe the bug Adding a new organization fails in feature/fabric220 branch

To Reproduce Steps to reproduce the behavior:

  1. Create a fabric network with 2.2.0 version from the fabric220 branch
  2. Modify the network.yaml to add a new organization.
  3. Run the add-new-organization.yaml script.

Expected behavior The new organization should be added to the network.

Screenshots The script fails with the below error 

"\u001b[36m2020-11-26 10:10:29.463 UTC [msp] Validate -> DEBU 01c\u001b[0m MSP org1MSP validating identity", "\u001b[36m2020-11-26 10:10:29.464 UTC [msp] GetDefaultSigningIdentity -> DEBU 01d\u001b[0m Obtaining default signing identity", "\u001b[34m2020-11-26 10:10:29.464 UTC [channelCmd] InitCmdFactory -> INFO 01e\u001b[0m Endorser and orderer connections initialized", "\u001b[36m2020-11-26 10:10:29.465 UTC [msp.identity] Sign -> DEBU 01f\u001b[0m Sign: plaintext: 0AA6080A076F7267314D5350129A082D...72697465727312002A0641646D696E73 ", "\u001b[36m2020-11-26 10:10:29.465 UTC [msp.identity] Sign -> DEBU 020\u001b[0m Sign: digest: CDEEE8E2587E2AC5B72B86FF9D904610A55A712325050E9AF69C3E4CDAF474D3 ", "\u001b[36m2020-11-26 10:10:29.466 UTC [msp.identity] Sign -> DEBU 021\u001b[0m Sign: plaintext: 0ADE080A1608021A060895FEFDFD0522...CEDA82A20F2F52B0F3E36B3D887946E4 ", "\u001b[36m2020-11-26 10:10:29.466 UTC [msp.identity] Sign -> DEBU 022\u001b[0m Sign: digest: 1F313A659A3D64C0E28B86186AD771790DD702AFBA9B85DE749BDC73A9C45050 ", "\u001b[36m2020-11-26 10:10:29.467 UTC [grpc] WithKeepaliveParams -> DEBU 023\u001b[0m Adjusting keepalive ping interval to minimum period of 10s", "\u001b[36m2020-11-26 10:10:29.467 UTC [grpc] Infof -> DEBU 024\u001b[0m parsed scheme: \"\"", "\u001b[36m2020-11-26 10:10:29.467 UTC [grpc] Infof -> DEBU 025\u001b[0m scheme \"\" not registered, fallback to default scheme", "\u001b[36m2020-11-26 10:10:29.467 UTC [grpc] Infof -> DEBU 026\u001b[0m ccResolverWrapper: sending update to cc: {[{orderer1.ordorg-net:7050  <nil> 0 <nil>}] <nil> <nil>}", "\u001b[36m2020-11-26 10:10:29.467 UTC [grpc] Infof -> DEBU 027\u001b[0m ClientConn switching balancer to \"pick_first\"", "\u001b[36m2020-11-26 10:10:29.467 UTC [grpc] Infof -> DEBU 028\u001b[0m Channel switches to new LB policy \"pick_first\"", "\u001b[36m2020-11-26 10:10:29.467 UTC [grpc] Infof -> DEBU 029\u001b[0m Subchannel Connectivity change to CONNECTING", "\u001b[36m2020-11-26 10:10:29.467 UTC [grpc] Infof -> DEBU 02a\u001b[0m Subchannel picks a new address \"orderer1.ordorg-net:7050\" to connect", "\u001b[36m2020-11-26 10:10:29.468 UTC [grpc] UpdateSubConnState -> DEBU 02b\u001b[0m pickfirstBalancer: HandleSubConnStateChange: 0xc00041bb10, {CONNECTING <nil>}", "\u001b[36m2020-11-26 10:10:29.468 UTC [grpc] Infof -> DEBU 02c\u001b[0m Channel Connectivity change to CONNECTING", "\u001b[36m2020-11-26 10:10:29.475 UTC [grpc] Infof -> DEBU 02d\u001b[0m Subchannel Connectivity change to READY", "\u001b[36m2020-11-26 10:10:29.475 UTC [grpc] UpdateSubConnState -> DEBU 02e\u001b[0m pickfirstBalancer: HandleSubConnStateChange: 0xc00041bb10, {READY <nil>}", "\u001b[36m2020-11-26 10:10:29.475 UTC [grpc] Infof -> DEBU 02f\u001b[0m Channel Connectivity change to READY", "Error: got unexpected status: BAD_REQUEST -- error applying config update to existing channel 'allchannel': error authorizing update: error validating DeltaSet: invalid mod_policy for element [Group]  /Channel/Application/org3MSP: mod_policy not set", "command terminated with exit code 1"], "stdout": "", "stdout_lines": []}

Environment (please complete the following information):

Additional context Comparing the script with this document - https://developer.ibm.com/technologies/blockchain/tutorials/cl-add-an-organization-to-your-hyperledger-fabric-blockchain/. If you look at the update_config.json, it has all the orgs added to the Application.groups, where as the add-new-organization.yaml script has only the org that is being added as part of the Application.group.

sivaramsk commented 3 years ago 
# This is a sample configuration file for SupplyChain App which has 5 nodes.
network:
  # Network level configuration specifies the attributes required for each organization
  # to join an existing network.
  type: fabric
  version: 2.2.0                 # currently tested 1.4.0 and 1.4.4

  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: haproxy                  # values can be 'haproxy' or 'ambassador'
    ambassadorPorts: 15010,15020    # Any additional Ambassador ports can be given here, must be comma-separated without spaces, this is valid only if proxy='ambassador'
    retry_count: 20                 # Retry count for the checks
    external_dns: disabled           # Should be enabled if using external-dns for automatic route configuration

  # 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: "index.docker.io/hyperledgerlabs"
    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.
  orderers:
    - orderer:
      type: orderer
      name: orderer1
      org_name: ordorg               #org_name should match one organization definition below in organizations: key
      uri: orderer1.ordorg-net:7050   # Can be external or internal URI for orderer which should be reachable by all peers
      certificate: /home/blockchain-automation-framework/build/orderer1.crt           # Ensure that the directory exists

  # The channels defined for a network with participating peers in each channel
  channels:
  - channel:
    consortium: MyConsortium
    channel_name: AllChannel
    channel_status: new
    orderer:
      name: ordorg
    participants:
    - organization:
      name: org1
      type: creator       # creator organization will create the channel and instantiate chaincode, in addition to joining the channel and install chaincode
      org_status: existing
      peers:
      - peer:
        name: peer0
        gossipAddress: peer0.org1-net:7051 # External or internal URI of the gossip peer
        peerAddress: peer0.org1-net:7051
      ordererAddress: orderer1.ordorg-net:7050             # External or internal URI of the orderer
    - organization:
      name: org2
      type: joiner        # joiner organization will only join the channel and install chaincode
      org_status: existing
      peers:
      - peer:
        name: peer0
        gossipAddress: peer0.org2-net:7051
        peerAddress: peer0.org2-net:7051
      ordererAddress: orderer1.ordorg-net:7050
    - organization:
      name: org3
      type: joiner        # joiner organization will only join the channel and install chaincode
      org_status: new
      peers:
      - peer:
        name: peer0
        gossipAddress: peer0.org3-net:7051
        peerAddress: peer0.org3-net:7051
      ordererAddress: orderer1.ordorg-net:7050
    endorsers:
      name:
      - org1
      - org2
      - org3
      corepeerAddress:
      - peer0.org1-net:7051
      - peer0.org2-net:7051
      - peer0.org3-net:7051
    genesis:
      name: OrdererGenesis

  # 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: ordorg
      country: UK
      state: London
      location: London
      subject: "O=Orderer,L=51.50/-0.13/London,C=GB"
      type: orderer
      external_url_suffix: <some endpoint>
      org_status: existing
      ca_data:
        url: ca.ordorg-net:7054
        certificate: file/server.crt        # This has not been implemented in 0.2.0.0

      cloud_provider: azure   # Options: aws, azure, gcp, 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:
        region: "cluster_region"
        context: "<context>"
        config_file: "/home/blockchain-automation-framework/build/config"

      # Hashicorp Vault server address and root-token. Vault should be unsealed.
      # Do not check-in root_token
      vault:
        url: "<vault-url>"
        root_token: "<vault-login>"

      # Git Repo details which will be used by GitOps/Flux.
      # Do not check-in git_access_token
      gitops:
        git_ssh: "ssh://git@github.com/sivaramsk/blockchain-automation-framework.git"         # Gitops ssh url for flux value files
        branch: "dotest"           # Git branch where release is being made
        release_dir: "platforms/hyperledger-fabric/releases/dotest" # Relative Path in the Git repo for flux sync per environment.
        chart_source: "platforms/hyperledger-fabric/charts"     # Relative Path where the Helm charts are stored in Git repo
        git_push_url: "github.com/sivaramsk/blockchain-automation-framework.git"   # Gitops https URL for git push  (without https://)
        username: "sivaramsk"          # Git Service user who has rights to check-in in all branches
        password: "<git-ops-key>"          # Git Server user password
        email: "sivaramsk@gmail.com"                # Email to use in git config
        private_key: "/home/blockchain-automation-framework/build/gitops"          # Path to private key file which has write-access to the git repo

      # Services maps to the pods that will be deployed on the k8s cluster
      # This sample is an orderer service and includes a zk-kafka consensus
      services:
        ca:
          name: ca
          subject: "/C=GB/ST=London/L=London/O=Orderer/CN=ca.ordorg-net"
          type: ca
          grpc:
            port: 7054

        consensus:
          name: raft
          type: broker        #This field is not consumed for raft consensus
          replicas: 4         #This field is not consumed for raft consensus
          grpc:
            port: 9092        #This field is not consumed for raft consensus

        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

    - organization:
      name: org1
      country: GB
      state: London
      location: London
      subject: "O=Org1,OU=Org1,OU=admin,L=51.50/-0.13/London,C=GB"
      type: peer
      external_url_suffix: <some endpoint>
      org_status: existing
      cli: enabled
      ca_data:
        url: ca.org1-net:7054
        certificate: file/server.crt

      cloud_provider: azure   # Options: aws, azure, gcp, 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:
        region: "cluster_region"
        context: "<context>"
        config_file: "/home/blockchain-automation-framework/build/config"

      # Hashicorp Vault server address and root-token. Vault should be unsealed.
      # Do not check-in root_token
      vault:
        url: "<vault-url>"
        root_token: "<vault-login>"

      # Git Repo details which will be used by GitOps/Flux.
      # Do not check-in git_access_token
      gitops:
        git_ssh: "ssh://git@github.com/sivaramsk/blockchain-automation-framework.git"         # Gitops ssh url for flux value files
        branch: "dotest"           # Git branch where release is being made
        release_dir: "platforms/hyperledger-fabric/releases/dotest" # Relative Path in the Git repo for flux sync per environment.
        chart_source: "platforms/hyperledger-fabric/charts"     # Relative Path where the Helm charts are stored in Git repo
        git_push_url: "github.com/sivaramsk/blockchain-automation-framework.git"   # Gitops https URL for git push  (without https://)
        username: "sivaramsk"          # Git Service user who has rights to check-in in all branches
        password: "<git-ops-key>"          # Git Server user password
        email: "sivaramsk@gmail.com"                # Email to use in git config
        private_key: "/home/blockchain-automation-framework/build/gitops"          # Path to private key file which has write-access to the git repo

      services:
        ca:
          name: ca
          subject: "/C=GB/ST=London/L=London/O=Org1/CN=ca.org1-net"
          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.org1-net:7051 # Internal Address of the other peer in same Org for gossip, same peer if there is only one peer
          peerAddress: peer0.org1-net:7051
          certificate: "/home/blockchain-automation-framework/build/ca.crt"
          cli: enabled
          grpc:
            port: 7051
          events:
            port: 7053
          couchdb:
            port: 5984
          restserver:
            targetPort: 20001
            port: 20001
          expressapi:
            targetPort: 3000
            port: 3000
          chaincode:
            name: "fabcar" #This has to be replaced with the name of the chaincode
            version: "1" #This has to be replaced with the version of the chaincode
            maindirectory: "go"  #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: "sivaramsk"          # Git Service user who has rights to check-in in all branches
              password: "<git-ops-key>"
              url: "github.com/sivaramsk/fabric-samples.git"
              branch: develop
              path: "fabric-samples/chaincode"   #The path to the chaincode
            arguments: '\"init\",\"\"' #Arguments to be passed along with the chaincode parameters
            endorsements: "" #Endorsements (if any) provided along with the chaincode

    - organization:
      name: org2
      country: US
      state: New York
      location: New York
      subject: "O=Org2,OU=Org2,OU=admin,L=40.73/-74/New York,C=US"
      type: peer
      external_url_suffix: <some endpoint>
      org_status: existing
      cli: enabled
      ca_data:
        url: ca.org2-net:7054
        certificate: file/server.crt

      cloud_provider: azure   # Options: aws, azure, gcp, 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:
        region: "cluster_region"
        context: "<context>"
        config_file: "/home/blockchain-automation-framework/build/config"

      # Hashicorp Vault server address and root-token. Vault should be unsealed.
      # Do not check-in root_token
      vault:
        url: "<vault-url>"
        root_token: "<vault-login>"

      # Git Repo details which will be used by GitOps/Flux.
      # Do not check-in git_access_token
      gitops:
        git_ssh: "ssh://git@github.com/sivaramsk/blockchain-automation-framework.git"         # Gitops ssh url for flux value files
        branch: "dotest"           # Git branch where release is being made
        release_dir: "platforms/hyperledger-fabric/releases/dotest" # Relative Path in the Git repo for flux sync per environment.
        chart_source: "platforms/hyperledger-fabric/charts"     # Relative Path where the Helm charts are stored in Git repo
        git_push_url: "github.com/sivaramsk/blockchain-automation-framework.git"   # Gitops https URL for git push  (without https://)
        username: "sivaramsk"          # Git Service user who has rights to check-in in all branches
        password: "<git-ops-key>"          # Git Server user password
        email: "sivaramsk@gmail.com"                # Email to use in git config
        private_key: "/home/blockchain-automation-framework/build/gitops"          # Path to private key file which has write-access to the git repo

      #Optional for infrastructure configuration files.
      infrastructure:
        target_state: "present"  # Options: present, absent, planned
        refresh_inventory: yes

      services:
        ca:
          name: ca
          subject: "/C=US/ST=New York/L=New York/O=Org2/CN=ca.org2-net"
          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.org2-net:7051 # Internal Address of the other peer in same Org for gossip, same peer if there is only one peer
          peerAddress: peer0.org2-net:7051
          certificate: "/home/blockchain-automation-framework/build/ca.crt"
          cli: enabled
          grpc:
            port: 7051
          events:
            port: 7053
          couchdb:
            port: 5984
          restserver:
            targetPort: 20001
            port: 20001
          expressapi:
            targetPort: 3000
            port: 3000
          chaincode:
            name: "fabcar" #This has to be replaced with the name of the chaincode
            version: "1" #This has to be replaced with the version of the chaincode
            maindirectory: "go"  #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: "sivaramsk"          # Git Service user who has rights to check-in in all branches
              password: "<git-ops-key>"
              url: "github.com/sivaramsk/fabric-samples.git"
              branch: develop
              path: "fabric-samples/chaincode"   #The path to the chaincode
            arguments: '\"init\",\"\"' #Arguments to be passed along with the chaincode parameters
            endorsements: "" #Endorsements (if any) provided along with the chaincode

    - organization:
      name: org3
      country: US
      state: New York
      location: New York
      subject: "O=Org3,OU=Org3,OU=admin,L=40.73/-74/New York,C=US"
      type: peer
      external_url_suffix: <some endpoint>
      org_status: new
      cli: enabled
      ca_data:
        url: ca.org3-net:7054
        certificate: file/server.crt

      cloud_provider: azure   # Options: aws, azure, gcp, 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:
          region: "cluster_region"
          context: "<context>"
          config_file: "/home/blockchain-automation-framework/build/config"

        # Hashicorp Vault server address and root-token. Vault should be unsealed.
        # Do not check-in root_token
        vault:
          url: "<vault-url>"
          root_token: "<vault-login>"

        # Git Repo details which will be used by GitOps/Flux.
        # Do not check-in git_access_token
        gitops:
          git_ssh: "ssh://git@github.com/sivaramsk/blockchain-automation-framework.git"         # Gitops ssh url for flux value files
          branch: "dotest"           # Git branch where release is being made
          release_dir: "platforms/hyperledger-fabric/releases/dotest" # Relative Path in the Git repo for flux sync per environment.
          chart_source: "platforms/hyperledger-fabric/charts"     # Relative Path where the Helm charts are stored in Git repo
          git_push_url: "github.com/sivaramsk/blockchain-automation-framework.git"   # Gitops https URL for git push  (without https://)
          username: "sivaramsk"          # Git Service user who has rights to check-in in all branches
          password: "<git-ops-key>"          # Git Server user password
          email: "sivaramsk@gmail.com"                # Email to use in git config
          private_key: "/home/blockchain-automation-framework/build/gitops"          # Path to private key file which has write-access to the git repo

      #Optional for infrastructure configuration files.
      infrastructure:
        target_state: "present"  # Options: present, absent, planned
        refresh_inventory: yes

      services:
        ca:
          name: ca
          subject: "/C=US/ST=New York/L=New York/O=Org3/CN=ca.org3-net"
          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.org3-net:7051 # Internal Address of the other peer in same Org for gossip, same peer if there is only one peer
          peerAddress: peer0.org3-net:7051
          certificate: "/home/blockchain-automation-framework/build/ca.crt"
          cli: enabled
          grpc:
            port: 7051
          events:
            port: 7053
          couchdb:
            port: 5984
          restserver:
            targetPort: 20001
            port: 20001
          expressapi:
            targetPort: 3000
            port: 3000
          chaincode:
            name: "fabcar" #This has to be replaced with the name of the chaincode
            version: "1" #This has to be replaced with the version of the chaincode
            maindirectory: "go"  #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: "sivaramsk"          # Git Service user who has rights to check-in in all branches
              password: "<git-ops-key>"
              url: "github.com/sivaramsk/fabric-samples.git"
              branch: develop
              path: "fabric-samples/chaincode"   #The path to the chaincode
            arguments: '\"init\",\"\"' #Arguments to be passed along with the chaincode parameters
            endorsements: "" #Endorsements (if any) provided along with the chaincode
jagpreetsinghsasan commented 3 years ago

Regarding this statement "Comparing the script with this document - https://developer.ibm.com/technologies/blockchain/tutorials/cl-add-an-organization-to-your-hyperledger-fabric-blockchain/. If you look at the update_config.json, it has all the orgs added to the Application.groups, where as the add-new-organization.yaml script has only the org that is being added as part of the Application.group."

The BAF code also does the exact same thing. The channel block is fetched, which already has the information of the existing organizations under the application.groups, and then via the script, we add it to the exisiting block (which we have fetched). Thus after adding the new org details in the application.group, we will also see all the organizations in it.

In the above IBM tutorials, this screenshot (pasted below), mentions the updated config block, which is same in BAF's case as well. image

jagpreetsinghsasan commented 3 years ago

The network.yaml mentioned in this github issue, looks fine to me. We will be assigning this issue to someone shortly.

lakshyakumar commented 3 years ago

Hi @sivaramsk , I tried to add a new organization in fabric network version 2.2.0 from the latest code in the feature/fabric220 branch, I was not able to reproduce this issue and the addition of a new organization worked fine on the fabric network version 2.2.0 . You can use this guide to add organization to exisitng network, also make sure the orderer certificates already exisits on the path provided in orderer.uri in network.yaml for tha addition of the new organization. image Although the invoke functionality is broken as of now, working on the same on issue #1206 .