CODEWITHSUNDEEP
hyperledger-fabrichyperledger-chaincode
gilvictor
gilvictor

Reputation: 107

Hyperledger Fabric v2.5.9 - CCAAS - Install chaincode tries to build a docker image, not taking into consideration that for CCAAS should not do it

I have deployed a Hyperledger Fabric network v2.5.9 with K8S.

The core.yaml in the peer v2.5.9 image already includes the externalBuilder section:

# List of directories to treat as external builders and launchers for
    # chaincode. The external builder detection processing will iterate over the
    # builders in the order specified below.
    # If you don't need to fallback to the default Docker builder, also unconfigure vm.endpoint above.
    # To override this property via env variable use CORE_CHAINCODE_EXTERNALBUILDERS: [{name: x, path: dir1}, {name: y, path: dir2}]
    # The path must be an absolute path.
    externalBuilders:
      - name: ccaas_builder
        path: /opt/hyperledger/ccaas_builder/ccaas/bin
        propagateEnvironment:
          - CHAINCODE_AS_A_SERVICE_BUILDER_CONFIG

So after I deployed the network and create the application channel i am trying to install the chaincode to the peers and get the PACKAGE_ID in order i can deploy manually the CCAAS_K8S_POD to which the peer will connect to handle the chaincode lifecycle.

Here is where i am a little confused, because i would expect that if I connect to the peer client and try to install the following asset-transfer-basic-external.tgz file:

tar cfz code.tar.gz connection.json
tar cfz asset-transfer-basic-external.tgz metadata.json code.tar.gz

'''metadata.json { "path": "", "type": "external", "label": "basic" } '''

By executing on the peer client:

peer lifecycle chaincode install asset-transfer-basic-external.tgz;

It would try to install the chaincode that does not contain the source code, following the new logic for CCAAS.

But instead I get this error, where it looks like is trying to deploy a docker container for the chaincode as for older versions:

Error: chaincode install failed with status: 500 - failed to invoke backing implementation of 'InstallChaincode': could not build chaincode: docker build failed: docker image inspection failed: Get "http://unix.sock/images/basic-0e9393b17bb6e3f64ec9d7914c3c935e95aa9a0b3da49b5c75967cdd83e31878-a72aa90629f3437f96bf68400e4bc835d979697e52787dd5acf19a272dc7934d/json": dial unix /var/run/docker.sock: connect: no such file or directory

And this is the peer1 logs:

2024-07-26 16:56:39.962 UTC 0057 INFO [endorser] callChaincode -> finished chaincode: _lifecycle duration: 109ms channel= txID=e4d26ce9
2024-07-26 16:56:39.963 UTC 0058 INFO [comm.grpc.server] 1 -> unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=10.42.0.44:38732 grpc.code=OK grpc.call_duration=110.039141ms

The peer logs should be executing the detect binary?

So why is this happening?

I am assuming that when we run the chaincode install command the detect binary is executed and if the type in the metadata file is the same as the one defined in the external builder detect binary (this is type=extnernal) then does not try to run the older version of the lifecycle.

Is that true? What makes the peer understand it should not try to create the docker container for the chaincode itself?

Many thanks

Upvotes: 0

Views: 108

Answers (2)

gilvictor
gilvictor

Reputation: 107

I resolved the problem. The thing is that we can define in the peer core.yaml file multiple externalBuilders.

From v2.4 fabric peer image comes with a default builder binaries named "ccaas" that we can use to install chaincode as a service.

But we can also use any other custom builder like the one named "external" in the /fabric-samples/asset-transfer-basic/chaincode-external/sampleBuilder that point to a different version of the binaries which instead of looking for "ccaas" in the metadata file, it looks for "external".

But i also saw a custom builder named k8s somewhere in the community that offers other advantatges.

Where we need to be consistent is based on the builder we use, update the metadata.json file accordingly.

In my case, i was overriding the ccaas builder binaries that comes by default with the peer image, by some other binaries I don't remember from where i got it from. So the detect binary it was probably trying to find in the metadata.json file a different wording than CCAAS.

So I fixed my issue, by using the default builder binaries and core.yaml and by defining the type field in the metadata.json as "ccaas".

Upvotes: 0

bestbeforetoday
bestbeforetoday

Reputation: 1649

From the current code, it looks like the type property in metadata.json should be ccaas instead of external.

Upvotes: 0

Related Questions