[WIP] Experimental integration test runner using microfab

[CaptainIRS]

Some issues/notes as of now:

• TLS (see IBM-Blockchain/microfab#105)
• There seems to be an issue selecting the correct endorsing peers when using the older Fabric SDK (works well using the newer Fabric Gateway API though)
• Normal installation of chaincode doesn't seem to work in microfab (can only install using CCAS)

[codecov[bot]]

Codecov Report

Merging #1465 (35873cf) into main (943ab2a) will not change coverage. The diff coverage is n/a.

:exclamation: Current head 35873cf differs from pull request most recent head fffa938. Consider uploading reports for the commit fffa938 to get more accurate results

@@           Coverage Diff           @@
##             main    #1465   +/-   ##
=======================================
  Coverage   55.89%   55.89%           
=======================================
  Files         105      105           
  Lines        4507     4507           
  Branches      688      688           
=======================================
  Hits         2519     2519           
  Misses       1435     1435           
  Partials      553      553           

Flag	Coverage Δ
caliper-core	44.98% <ø> (ø)
caliper-fabric	80.46% <ø> (ø)
generator-caliper	83.62% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[davidkel]

@CaptainIRS

1. TLS is the default for most fabrics (except microfab) and we would need to be able to test the option where we declare the peer information in a network config file
2. Can you elaborate on selecting the correct endorsing peers. microfab only has 1 peer per org and the SDKs should use discovery to determine the peer to select based on the cc endorsement policy so I would not expect a problem here from microfab (unless it doesn't set up anchor peers correctly)
3. microfab docker image used to include a set of external builders, so it used to work and we shouldn't need to resort to CCAAS can you provide some more info on what you saw

[davidkel]

@CaptainIRS the errors are very odd and the fact they happen in both 1.4 and 2.2 node sdks only with microfab. Not surprised with the fabric-gateway as it does event handing differently. I'll see if I can get someone to look at it too.

[mbwhite]

Hello @CaptainIRS ... I've been trying to recreate this problem with Microfab, without much success I'm afraid. I believe that (logically) there are 2 processes, each running an application sending transactions. Is each just doing one org are does it swap?

I've got two apps here that are using the 2.2 NodeSDK submitting transactions to microfab; it seems completely stable.

Chaincode Signature Policy is --signature-policy "OR('org1MSP.peer','org2MSP.peer')" Microfab config

        "endorsing_organizations":[
            {
                "name": "org1"
            },
            {
                "name": "org2"
            }
        ],
        "channels":[
            {
                "name": "mychannel",
                "endorsing_organizations":[
                    "org1","org2"
                ]
            }

        ],
        "capability_level":"V2_0"
    }'

[mbwhite]

@CaptainIRS found the problem!!

For microfab the asLocalhost setting must be false. Irrespective of the fact it is local... it needs the full hostnames.

caliper:
    fabric:
       gateway:
         localhost: false

Added that to my local caliper configuration caliper.yaml and all is well.

[davidkel]

Thank you @mbwhite for investigating. @CaptainIRS Best way is to add

--caliper-fabric-gateway-localhost false

when launching caliper eg

${CALL_METHOD} launch manager --caliper-workspace phase4 --caliper-flow-only-test --caliper-fabric-gateway-localhost false

It's interesting that microfab appears to work using the legacy sdks when localhost is set to true for a lot of the time so definitely something that microfab should document. I thought it used hostname for routing and as the endpoint urls get translated to localhost:8080 I wasn't expecting that to work at all. The problem was that the endorsers were being discovered and the endpoints were being translated to the same endpoint of localhost:8080 from org1peer-api.127-0-0-1.nip.io:8080 and org2peer-api.127-0-0-1.nip.io:8080 and thus you could only have one at that endpoint so in some cases was being loaded with the wrong peer for the mspid of the identity. I also suspect that if the chaincode had an AND endorsement policy it would have failed for all submissions as it wouldn't be able to get all endorsements as there would only be 1 endorser in the channel object.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[davidkel]

Closing this pull request because microfab is has gone dormant with the maintainers now not involved in hyperledger fabric anymore and it's unlikely to be maintained in the future.