Confusing with package install logic when chain code as a service.

[SamYuan1990]

https://github.com/hyperledger/fabric/blob/07e6231e452f941dbc508f21e50d4897a9dd47a4/internal/peer/chaincode/install.go#L162-L199

as lines above, when chain code as a service case, the chain code with package as

tree basic-asset
basic-asset
├── code.tar.gz
└── metadata.json

0 directories, 2 files

with usage as lines below from fabric sample:

packageChaincode() {

  address="{{.peername}}_${CC_NAME}_ccaas:${CCAAS_SERVER_PORT}"
  prefix=$(basename "$0")
  tempdir=$(mktemp -d -t "$prefix.XXXXXXXX") || error_exit "Error creating temporary directory"
  label=${CC_NAME}_${CC_VERSION}
  mkdir -p "$tempdir/src"

cat > "$tempdir/src/connection.json" <<CONN_EOF
{
  "address": "${address}",
  "dial_timeout": "10s",
  "tls_required": false
}
CONN_EOF

   mkdir -p "$tempdir/pkg"

cat << METADATA-EOF > "$tempdir/pkg/metadata.json"
{
    "type": "ccaas",
    "label": "$label"
}
METADATA-EOF

    tar -C "$tempdir/src" -czf "$tempdir/pkg/code.tar.gz" .
    tar -C "$tempdir/pkg" -czf "$CC_NAME.tar.gz" metadata.json code.tar.gz
     rm -Rf "$tempdir"

    successln "Chaincode is packaged  ${address}"

}

and

# installChaincode PEER ORG
function installChaincode() {
  ORG=$1
  setGlobals $ORG
  set -x
  echo ${CC_NAME}
  export FABRIC_LOGGING_SPEC=DEBUG
  peer lifecycle chaincode install ${CC_NAME}.tar.gz >&log.txt
  res=$?
  { set +x; } 2>/dev/null
  cat log.txt
  verifyResult $res "Chaincode installation on peer0.org${ORG} has failed"
  successln "Chaincode is installed on peer0.org${ORG}"
}

what confusing me as the tar.gz of chaincode as a service package fails as

could not unmarshal chaincode package to CDS [failed to unmarshal deployment spec from bytes]or SignedCDS [failed to unmarshal envelope from bytes] 436 ./basicj.tar.gz

so logically, as the marshal step having error, the install of chaincode as a service should be fail right? or what's the correct steps to package chaincode as a service?

ref https://github.com/Hyperledger-TWGC/fabric-admin-sdk/pull/26

[SamYuan1990]

btw, can anyone help add external chaincode test case in peer install path?

[mbwhite]

@SamYuan1990 let me take a look; we've known that the peer command has had some issues... @jt-nti keeps reminding us as well.

https://github.com/hyperledger-labs/weft is an alternative for packaging all types of contracts

[SamYuan1990]

https://github.com/hyperledger-labs/weft

good to know this project. @davidkhala , could you please take a look at weft and admin-sdk on nodejs and typescript?

[mbwhite]

@SamYuan1990 I just tried the fabric-samples test-network using the deployCCAAS command. That worked out and deployed the chaincode fine... Just wondering was the peer configured correctly to use the -as-a-service builders?

[SamYuan1990]

@SamYuan1990 I just tried the fabric-samples test-network using the deployCCAAS command. That worked out and deployed the chaincode fine... Just wondering was the peer configured correctly to use the -as-a-service builders?

https://github.com/Hyperledger-TWGC/fabric-admin-sdk/blob/main/.github/workflows/golange2e.yml#L23-L25

if I am right, to enable -as-a-service builders with test network, we don't need any specific parameters during network.sh up right?

[mbwhite]

correct @SamYuan1990 the builders where added I think it was in Fabric 2.3.... but that workflow looks good to me.

not all the example chaincodes though have a dockerfile. So not all can be built and run by the test-network. I went with the typescript one.

./network.sh deployCCAAS -ccn basic -ccp ../asset-transfer-basic/chaincode-typescript -ccl node -ccs 1

[SamYuan1990]

@SamYuan1990 I just tried the fabric-samples test-network using the deployCCAAS command. That worked out and deployed the chaincode fine... Just wondering was the peer configured correctly to use the -as-a-service builders?

and what confused me is that when we upload a tar file as chaincode-as-a-service, what's happening during peer install running with the tar file. as the tar file with tar -cxvf command can't convert to golang module during function InitFromBuffer... for SignedCDSPackage or CDSPackage. hence from code path, seems GetCCPackage in package ccprovider will exit with error.

could not unmarshal chaincode package to CDS [failed to unmarshal deployment spec from bytes]or SignedCDS [failed to unmarshal envelope from bytes] 436 ./basicj.tar.gz

but in fact, it's not.(as fabric sample)

hence it looks wired, as I trace the code with path below:

https://github.com/hyperledger/fabric/blob/main/internal/peer/chaincode/install.go#L120

https://github.com/hyperledger/fabric/blob/e8c6102cc38d835dd6f3efe7b90a2f1133d21a68/internal/peer/chaincode/install.go#L162

https://github.com/hyperledger/fabric/blob/e8c6102cc38d835dd6f3efe7b90a2f1133d21a68/internal/peer/chaincode/install.go#L164 here is not match so skipped to path below:

https://github.com/hyperledger/fabric/blob/e8c6102cc38d835dd6f3efe7b90a2f1133d21a68/internal/peer/chaincode/install.go#L179 https://github.com/hyperledger/fabric/blob/e8c6102cc38d835dd6f3efe7b90a2f1133d21a68/internal/peer/chaincode/install.go#L242

i.Input.PackageFile is the tar file, which not following SignedCDSPackage or CDSPackage format cause

ccpack, err := ccprovider.GetCCPackage(ccPkgBytes, cryptoProvider) 

return error.

or for tar file as chaincode as a service, we have a specific path as implementation?

I also try to find a sample from test code, but seems this path is not covered. https://github.com/hyperledger/fabric/blob/e8c6102cc38d835dd6f3efe7b90a2f1133d21a68/internal/peer/chaincode/install_test.go

[SamYuan1990]

correct @SamYuan1990 the builders where added I think it was in Fabric 2.3.... but that workflow looks good to me.

not all the example chaincodes though have a dockerfile. So not all can be built and run by the test-network. I went with the typescript one.

./network.sh deployCCAAS -ccn basic -ccp ../asset-transfer-basic/chaincode-typescript -ccl node -ccs 1

yes, @mbwhite , I just confused with the path above, and if path above is correct, then how a tar file with structure below

yuanyi@yuanyideMacBook-Pro e2e % tree basicj
basicj
├── code.tar.gz
└── metadata.json

works with https://github.com/hyperledger/fabric/blob/e8c6102cc38d835dd6f3efe7b90a2f1133d21a68/core/common/ccprovider/cdspackage.go#L212 or https://github.com/hyperledger/fabric/blob/e8c6102cc38d835dd6f3efe7b90a2f1133d21a68/core/common/ccprovider/sigcdspackage.go#L256

[SamYuan1990]

https://github.com/hyperledger/fabric/blob/7785a62aae7323560f0ece31fe8509ebffec2398/internal/peer/lifecycle/chaincode/install.go#L180

I suppose I found where the different between release 2.4 and main branch for the path. basicj.tar.gz

basicj.tar.gz is from my local running result of chaincode as a service from fabric sample

basic-asset.tar.gz

basic-asset.tar.gz is the one I generated from admin-sdk project.

@mbwhite , let's further investigation and keep in touch.

[SamYuan1990]

hi @mbwhite , after switch to release-2.4 way of implementation, admin-sdk part code successful.

[SamYuan1990]

oh @mbwhite , I see, there is a "install" under peer/chaincode, and another one under peer/lifecycle/chaincode

[SamYuan1990]

should we consider keep only one implementation ?

[mbwhite]

Hi @SamYuan1990 ... the peer/chaincode is for the old lifecycle - and at some point will be removed. So for ccaas the peer lifecycle chaincode should be used.

There shouldn't be any needs for the code to go anywhere near the CDS handling - it should check for the builders that are installed. Match up the type specified in the package with the correct builder.

If there's no builder available, it will fail.

Does that answer the question?

[SamYuan1990]

Hi @SamYuan1990 ... the peer/chaincode is for the old lifecycle - and at some point will be removed. So for ccaas the peer lifecycle chaincode should be used.

There shouldn't be any needs for the code to go anywhere near the CDS handling - it should check for the builders that are installed. Match up the type specified in the package with the correct builder.

If there's no builder available, it will fail.

Does that answer the question?

yes, this comment answer the question.