Welcome to the Linux Foundation Forum!

Lab2: Question on pdf instructions when adding a new peer to an existing organisation

alejoacostaalejoacosta Posts: 2
in LFS272 Class Forum

Hi! The pdf instructions for Lab 2 ("Adding a new peer") indicate that a new genesis block must be generated via the following command:

../bin/configtxgen -profile OneOrgOrdererGenesis -outputBlock ./config/genesis.block

But I think there is no need to update the genesis block when adding a new peer to an existing organization (and a running HLF network!).
Moreover, the file configtx.yaml is never edited as part of the lab, so what is the point in running the configtxgen command?
Am I wrong? Thanks for clarification

Comments

  • NiklaskkkkNiklaskkkk Posts: 112

    @alejoacosta said:
    Hi! The pdf instructions for Lab 2 ("Adding a new peer") indicate that a new genesis block must be generated via the following command:

    ../bin/configtxgen -profile OneOrgOrdererGenesis -outputBlock ./config/genesis.block

    But I think there is no need to update the genesis block when adding a new peer to an existing organization (and a running HLF network!).
    Moreover, the file configtx.yaml is never edited as part of the lab, so what is the point in running the configtxgen command?
    Am I wrong? Thanks for clarification

    Hi @alejoacosta ,

    Yes, you are correct! I believe the reason for why this is done in the course, is for demonstration purposes, as later on in the course other organizations are added and then the configtx.yaml is updated.

    For anyone else interested in how configtxgen works, here is the official doc: https://hyperledger-fabric.readthedocs.io/en/release-2.0/commands/configtxgen.html

  • jason_jaanjason_jaan Posts: 5

    To add to this, genesis.block was created but then peer1.org1 joined allarewelcome channel's genesis block, so this does support the idea genesis.block is exercise only.
    On a related question, with the later step of export CORE_PEER_MSPCONFIGPATH, the path is set differently than the path inside docker-compose.yml for peer1.org0 that was added earlier when adding peer1. Is it because we need to be admin (not peer) in order to do the peer joining step?

    Also for peer1.org in docker-compose.yml, is there any reason peer1.org1's CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE isn't set to "startFiles_basic"? I believe COMPOSE_PROJECT_NAME has no value.

  • NiklaskkkkNiklaskkkk Posts: 112
    edited June 12

    @jason_jaan said:
    To add to this, genesis.block was created but then peer1.org1 joined allarewelcome channel's genesis block, so this does support the idea genesis.block is exercise only.
    On a related question, with the later step of export CORE_PEER_MSPCONFIGPATH, the path is set differently than the path inside docker-compose.yml for peer1.org0 that was added earlier when adding peer1. Is it because we need to be admin (not peer) in order to do the peer joining step?

    Also for peer1.org in docker-compose.yml, is there any reason peer1.org1's CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE isn't set to "startFiles_basic"? I believe COMPOSE_PROJECT_NAME has no value.

    @jason_jaan , correct, but this obviously depends on each individual channel policy set-up.

    Regarding the COMPOSE_PROJECT_NAME, correct. It could have been set to startFiles_basic by default.

Sign In or Register to comment.