hyperledger-labs / fablo Goto Github PK

Current:

      "orgs": [
        {
          "key": "org1",
          "peers": [
            "peer0"
          ]
        },
        {
          "key": "org2",
          "peers": [
            "peer0",
            "peer1"
          ]
        }
      ]

Proposed:

      "orgs": [
        {
          "organization": "org1",
          "peer": "peer0"
        },
        {
          "organization": "org2",
          "peer": "peer0"
        },
        {
          "organization": "org2",
          "peer": "peer1"
        }
      ]

Or:

      "orgs": {
        "org1": [
          "peer0"
        ],
        "org2": [
          "peer0",
          "peer1"
        ]
      }

After generation a lot of scripts contain pointless indents.
We should format them.
#61 (comment)

Problems:

• docker run requires absolute paths, docker compose may use relative ones
• relative path to chaincodes and config differ for fabrikka.sh generate config and fabrikka.sh generate config target
• relative path is different for docker compose and npm build
• support for relative paths drops support for absolute paths

curl sh script + chmod

We can improve supportedFabricVersions field of generator.
Some options in newer fabric versions can be turn on by default and overwritten in config.

commandsGenerated.sh can be structured better, inspiration in :
https://github.com/hyperledger/fabric-samples/blob/master/test-network/scripts/createChannel.sh

probably we should test versions: 1.3, 1.4.? (before RAFT), 1.4.4, 2.0, 2.2.x

Probably only simple net, 2 orgs and raft config are required

#!/bin/sh

peer="peer1.org1.com"
channel="my-channel2"
chaincode="chaincode1"
command='{"Args":["KVContract:get", "name"]}'

docker exec "cli.org1.com" peer chaincode invoke \
  --peerAddresses "$peer:7051" \
  --tlsRootCertFiles "/var/hyperledger/cli/crypto/peers/peer1.org1.com/tls/ca.crt" \
  -C "$channel" \
  -n "$chaincode" \
  -c "$command" \
  --waitForEvent \
  --tls \
  --cafile "/var/hyperledger/cli/crypto/daTls/msp/tlscacerts/tlsca.root.com-cert.pem" \
  2>&1

in the line with --tlsRootCertFiles we can change peer1 with peer0 and everything will work since the content of files /var/hyperledger/cli/crypto/peers/peer1.org1.com/tls/ca.crt and /var/hyperledger/cli/crypto/peers/peer0.org1.com/tls/ca.crt is the same

#76 (comment)

https://www.hashicorp.com/blog/announcing-waypoint

see: https://hyperledger-fabric.readthedocs.io/en/release-2.2/endorsement-policies.html#endorsement-policy-syntax

it should probably be implemented in yeoman generators

• dist script and dist command line (wget/curl + chmod)
• docker image published
• create logo
• consider the license
• consider autoupdates
• update documentation with installation instructions
• update documentation with logo
• create CHANGELOG.md
• add Fabrica to producthunt.com
• create release

Right now Jenkins runs sample-01. Maybe it should run all samples, maybe another sample or maybe there should be a separate Jenkins job for this kind of tests...

Is using .yo-rs.json as a config file a good idea ?
Motivation:

1. It looks like internal Yeoman config file
2. It's a hidden file. network-configuration file should be shared between developers and is crucial part of preparing/running network.

From network-config file we should generate also :

1. configtx.yml
2. crypto-config.yml
3. scripts for starting/stopping network

#76 (comment)

• check if works
• add tests

functions:

• certsGenerate
• genesisBlockCreate
• createChannelTx
• createAnchorPeerUpdateTx

Run docker container to generate Fabric's artifacts. Thanks to that we can ommit installing various HLF utils in path and we always have same, stable version of cli utils.
But they all have one flaw : every error in part docker exec -it will exit container but won't remove it, so we can have dandling containers if error occurs.
Solution ideas :

1. Like in my helper scripts

#!/bin/bash
set -e

SITE_URL=$1
PDF_NAME=$2

if [ ! -z "$SITE_URL" ] || [ ! -z "$PDF_NAME" ]; then
  echo "Downloading $SITE_URL as $PDF_NAME..."
  docker run --rm -it --user $(id -u):$(id -g) -v $(pwd):/pandoc --name pandoc1 hejwo/pandoc-web-to-pdf-util \
  pandoc --highlight-style tango --pdf-engine=xelatex -V geometry:margin=1.5cm -s -r html $SITE_URL -o $PDF_NAME
else
  echo "Usage: pdfMe http://site.to.download.com pdf-name.pdf"
fi

2. Some kind od try { ... } finnally { ...} in bash

Currentlly we're using org.key to create organization mspId's.
It's not a good option since it'sused for iteratin purposes only and with every next org it will be org1, org2 and so on.
We might want to have meaningful user input here.

Introduce raft/etcdraft type in rootOrg.orderer.consensus

Currently we have no ESLint in project, would be good to add something ;)

Currently all organisations are just added to AllOrgChannel profile and then this profile is used to generate ALL channels. Why that's wrong ?

• we have 3 organisations: org1, org2, org3
• channel channel1 defined between org1, org2
• org3 can just fetch & join channel1 because of AllOrgChannel used

https://github.com/rjsf-team/react-jsonschema-form seems promising (better UI, better support + is will support $data for cross validation)

TODO:

• .env (Docker network name)
• remove network subdir from fabrikka-target

Won't do:

• fabrikka-target/networkName
• fabrikka.sh up (select network???)
• JSON schema + validation (the field won't be added to JSON)

Before Raft we assumed that Orderer will be part of root ogranization and suborganizations will not host Orderer instance.
This statement is no longer true in Raft mode. .

Check list:

• Propose different Fabrikka's config file format to support both old and new approach
• Organization can have Orderer hosted, but only in Raft mode.
• We should validate the case
• Implement new config

There are no tests for our generators. It's time to add some.
Simple, basic ones for start would be good.

Useful stuff :
https://yeoman.io/authoring/testing.html

add generator to create simple chaincode.
It would ease up testing + could be valuable feature for quick start with Fabric

to reproduce, just call yo --no-insight fabrikka:setup-compose "/tmp/config.json"

Create tests that:

• install chaincode in simple network #52
• install chaincode in network with raft #55
• call chaincodes

Currently our network tests verify only invoke with endorsement policies when one of the organization is supposed to endorse (OR ('Org1MSP.member', 'Org2MSP.member')). The case when both organizations need to endorse (AND ('Org1MSP.member', 'Org2MSP.member')) is not covered, since it requires changes in the test scripts for invoke (expect-invoke.sh). In this case we need to explicitly provide --peerAdresses for peer chaincode invoke.

rootCaOnly is kinna flacky idea.
If we have 2 orgs channel, and rootCaOnly: true only root ca will be generated and no ca's for organisations.
So organisation won't be able to properly enroll it's users (it can't be done in rootCa) and use chaincode. That's really unnecessary and confusing

probably it is possible to get docker containers to down via docker ps

also: probably it would be good to check if network can be generated by current network name (if it exists)

Right now fabric-network allows us for step by step process of generating network setting.
We must also introduce single CLI command generation, that would be really useful in automatic environments. Example :

yo fabric-network:create-network myNetwork ... ... ...

should generate valid .yo-rc.json that can be use to start docker-compose or other network.

Useful links:
https://www.npmjs.com/package/yeoman-option-or-prompt

probably README would be sufficient

For configuration with 2 peers in channel:

============ \U1F60B Building 'chaincode1' \U1F60B ==============

> [email protected] build /Users/jakubdzikowski/IdeaProjects/generator-fabric-network/e2e-network/test-01-simple.sh.tmpdir/chaincode-kv-node
> echo "No need to build the chaincode"

No need to build the chaincode
============ \U1F60E Installing 'chaincode1' on my-channel1/Org1/peer0 \U1F60E ==============
Installing chaincode on my-channel1...
   CHAINCODE_NAME: chaincode1 
   CHAINCODE_VERSION: 0.0.1 
   CHAINCODE_LANG: node 
   CHAINCODE_DIR_PATH: /Users/jakubdzikowski/IdeaProjects/generator-fabric-network/e2e-network/test-01-simple.sh.tmpdir/chaincode-kv-node 
   PEER_ADDRESS: peer0.org1.com:7051 
   ORDERER_URL: orderer0.root.com:7050 
   CLI_NAME: cli.org1.com 
2020-10-05 14:23:26.914 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 001 Using default escc
2020-10-05 14:23:26.914 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 002 Using default vscc
Verifying if container peer0.org1.com is ready (2)...
Verifying if container peer0.org1.com is ready (3)...
Verifying if container peer0.org1.com is ready (4)...
Verifying if container peer0.org1.com is ready (5)...
Verifying if container peer0.org1.com is ready (6)...
Container peer0.org1.com is ready!
Verifying if container peer1.org1.com is ready (1)...
Verifying if container peer1.org1.com is ready (2)...
Container peer1.org1.com is ready!
jakubdzikowski@MacBook-Pro e2e-network % 2020-10-05 14:23:35.350 UTC [chaincodeCmd] install -> INFO 003 Installed remotely response:<status:200 payload:"OK" > 
==== \U1F618 Instantiating 'chaincode1' on my-channel1/Org1/peer0 \U1F618 ====
Instantiating chaincode on my-channel1...
   CHAINCODE_NAME: chaincode1 
   CHAINCODE_VERSION: 0.0.1 
   CHAINCODE_LANG: node 
   CHAINCODE_DIR_PATH: /Users/jakubdzikowski/IdeaProjects/generator-fabric-network/e2e-network/test-01-simple.sh.tmpdir/chaincode-kv-node 
   INIT_PARAMS: {"Args":[]} 
   ENDORSEMENT: AND ('Org1.member') 
   PEER_ADDRESS: peer0.org1.com:7051 
   ORDERER_URL: orderer0.root.com:7050 
   CLI_NAME: cli.org1.com 
2020-10-05 14:23:35.666 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 001 Using default escc
2020-10-05 14:23:35.666 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 002 Using default vscc
============ \U1F60E Installing 'chaincode1' on my-channel1/Org1/peer1 \U1F60E ==============
Installing chaincode on my-channel1...
   CHAINCODE_NAME: chaincode1 
   CHAINCODE_VERSION: 0.0.1 
   CHAINCODE_LANG: node 
   CHAINCODE_DIR_PATH: /Users/jakubdzikowski/IdeaProjects/generator-fabric-network/e2e-network/test-01-simple.sh.tmpdir/chaincode-kv-node 
   PEER_ADDRESS: peer1.org1.com:7051 
   ORDERER_URL: orderer0.root.com:7050 
   CLI_NAME: cli.org1.com 
2020-10-05 14:23:54.747 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 001 Using default escc
2020-10-05 14:23:54.747 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 002 Using default vscc
2020-10-05 14:24:03.184 UTC [chaincodeCmd] install -> INFO 003 Installed remotely response:<status:200 payload:"OK" > 
==== \U1F618 Instantiating 'chaincode1' on my-channel1/Org1/peer1 \U1F618 ====
Instantiating chaincode on my-channel1...
   CHAINCODE_NAME: chaincode1 
   CHAINCODE_VERSION: 0.0.1 
   CHAINCODE_LANG: node 
   CHAINCODE_DIR_PATH: /Users/jakubdzikowski/IdeaProjects/generator-fabric-network/e2e-network/test-01-simple.sh.tmpdir/chaincode-kv-node 
   INIT_PARAMS: {"Args":[]} 
   ENDORSEMENT: AND ('Org1.member') 
   PEER_ADDRESS: peer1.org1.com:7051 
   ORDERER_URL: orderer0.root.com:7050 
   CLI_NAME: cli.org1.com 
2020-10-05 14:24:03.500 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 001 Using default escc
2020-10-05 14:24:03.500 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 002 Using default vscc
Error: could not assemble transaction, err proposal response was not successful, error code 500, msg chaincode with name 'chaincode1' already exists

However both peers return proper instantiated chaincodes:

Get instantiated chaincodes on channel my-channel1:
Name: chaincode1, Version: 0.0.1, Path: /var/hyperledger/cli/chaincode1/, Escc: escc, Vscc: vscc

Probably for https://github.com/koalaman/shellcheck

It should test script code style in CI for generated files

No comments needed. Currently we support only 1.4.3, 1.4.4 versions

Depends on: #16

Original conception was to use generator to create fabrikkaConfig.json, but we decided to change it. And base on fabrikkaConfig only