resolve #25

[SamYuan1990]

impl for chain code install on peer

Signed-off-by: Sam Yuan yy19902439@126.com

[SamYuan1990]

@davidkhala / @mbwhite if I am right, to install a chaincode as external chaincode. we just need to make a tar gz file for config as

.
├── chaincode.tar.gz
├── pkg
│   ├── code.tar.gz
│   └── metadata.json
└── src
    └── connection.json

and I am going to prepare a proposal for deployment as

    msg := &pb.ChaincodeDeploymentSpec{
        ChaincodeSpec: &pb.ChaincodeSpec{
            Type:        3, // hard code
            ChaincodeId: &pb.ChaincodeID{Name: ChaincodeName, Version: ChaincodeVersion},
            Input:       &pb.ChaincodeInput{Args: [][]byte{[]byte("")}},
        },
        CodePackage: ccPkgBytes, // read from  chaincode.tar.gz
    }

but error msg from peer as Unknown chaincodeType: CAR, which for my understand is the chain code been handled as java/go/nodejs, the peer try to find a docker file and build docker image base on the docker file inside the chaincode package.

Unexpected error:
      <*errors.fundamental | 0xc00000f1e8>: {
          msg: "install failed with status: 500 - chaincode installed to peer but could not build chaincode: docker build failed: platform builder failed: Failed to generate a Dockerfile: Unknown chaincodeType: CAR",
          stack: [0x9b5295, 0xa7f546, 0x7f[86](https://github.com/Hyperledger-TWGC/fabric-admin-sdk/runs/7703905092?check_suite_focus=true#step:7:87)6d, 0x46af61],
      }
      install failed with status: 500 - chaincode installed to peer but could not build chaincode: docker build failed: platform builder failed: Failed to generate a Dockerfile: Unknown chaincodeType: CAR

Is there any thing I missed? Hence making peer handle my request as a normal chaincode deploy? Please advise.

[davidkhala]

The hardcode Chaincode type 3 here refers to CAR type, is it? Chaincode type for external chaincode was a problem confusing me. Not sure what is the current status.

[jkneubuh]

Hi @SamYuan1990,

The CAR / chaincode type 3 is incorrect. For CCaaS, the metadata.json type should be declared as ccaas

Also the folder structure looks incorrect. It should be something like:

chaincode.tgz = tar { 
  metadata.json, 
  code.tar.gz = tar { 
    connection.json 
  }
}

A good example of preparing the CCaaS package by hand is at the full-stack-asset-transfer guide, on the chaincode for local development section.

Another example of preparing a CCaaS package is in the operator sample-network deployment bash scripts.

The important bit is that the metadata.json declares type: ccaas. This will force the CCaaS builder to pick up and manage the lifecycle for the contract.

Also I checked into fabric-protos-go/peer/chaincode.pb.go and it looks like there are no constant values declared for either ccaas or k8s builder types in the protobuf. In this case you may be better off just creating the chaincode.tgz archive manually, without serializing the protobuf to a json form.

[SamYuan1990]

Hi @SamYuan1990,

The CAR / chaincode type 3 is incorrect. For CCaaS, the metadata.json type should be declared as ccaas

Also the folder structure looks incorrect. It should be something like:

chaincode.tgz = tar { 
  metadata.json, 
  code.tar.gz = tar { 
    connection.json 
  }
}

A good example of preparing the CCaaS package by hand is at the full-stack-asset-transfer guide, on the chaincode for local development section.

Another example of preparing a CCaaS package is in the operator sample-network deployment bash scripts.

The important bit is that the metadata.json declares type: ccaas. This will force the CCaaS builder to pick up and manage the lifecycle for the contract.

Also I checked into fabric-protos-go/peer/chaincode.pb.go and it looks like there are no constant values declared for either ccaas or k8s builder types in the protobuf. In this case you may be better off just creating the chaincode.tgz archive manually, without serializing the protobuf to a json form.

it looks like there are no constant values declared for either ccaas or k8s builder types in the protobuf. In this case you may be better off just creating the chaincode.tgz archive manually, without serializing the protobuf to a json form.

that's the point @jkneubuh , and where am confused, and make this pr failed with CI checking. if there is not specific type in protobuf points out with ccaas, how/what makes peer cmd works?

[jkneubuh]

I don't think anyone has ever used the peer CLI command to prepare the chaincode package for ccaas or k8s deployments. The install activity is used to upload the contents of a CC package.tgz which had been created - by hand - using tar commands (or a script).

I think this works with the peer CLI because that code path is merely uploading the byte stream for the CC package archive file. It's not "building" the archive.

[SamYuan1990]

em... I suppose we'd try with CDSPackage or SignedCDSPackage for install chaincode instead of ChaincodeDeploymentSpec.

[SamYuan1990]

Unexpected error:
      <*errors.fundamental | 0xc0002ae120>: {
          msg: "could not unmarshal chaincode package to CDS or SignedCDS",
          stack: [0xa3bd71, 0xa3be92, 0xaa04[86](https://github.com/Hyperledger-TWGC/fabric-admin-sdk/actions/runs/3077338389/jobs/4972134482#step:7:87), 0x7fa62d, 0x46afa1],
      }
      could not unmarshal chaincode package to CDS or SignedCDS
  occurred

.... need more investigation.

[SamYuan1990]

well, I tried even copy a tar file from fabric sample output ... need more investigation for peer install steps.