fabric-admin package

[bestbeforetoday]

As a Fabric blockchain operator I want to use the Node SDK to deploy smart contracts So that I can implement administrative actions in Node instead of scripts using the CLI commands

Produce a v2 fabric-admin package based on the v2 SDK implementation. Ideally the implementation would use the fabric-network package where possible, and use the fabric-common package if there are cases where fabric-network does not provide required capability.

For reference, there is an implementation of admin operations based on fabric-network here:

https://github.com/IBM-Blockchain/blockchain-vscode-extension/tree/master/packages/blockchain-fabric-admin

[davidkhala]

Hi Mark, thanks for the sharing. And happy to see Calorine is still in IBM team helping commuinty project.

[bestbeforetoday]

@davidkhala If you are still keen to build a standard admin API to support packaging and deployment of chaincode, I wonder if moving forwards it would be better to build something based on the @hyperledger/fabric-gateway API instead of this SDK. fabric-gateway will be the supported client API as we move to Fabric v2.5 LTS, and provides consistent API and behaviour for Go and Java in addition to Node. What do you think?

[davidkhala]

@davidkhala If you are still keen to build a standard admin API to support packaging and deployment of chaincode, I wonder if moving forwards it would be better to build something based on the @hyperledger/fabric-gateway API instead of this SDK. fabric-gateway will be the supported client API as we move to Fabric v2.5 LTS, and provides consistent API and behaviour for Go and Java in addition to Node. What do you think?

Due to my lacking of knowledge on recent update on gateway feature, but can gateway api now allow calling system chaincode towards only specified peers?

[bestbeforetoday]

You are absolutely correct. Right now the Fabric Gateway client API generally just figures out the best peers to use for endorsement of any transactions, taking into account chaincode, private data collection and key-/state-based endorsement policies. It does have a mechanism for the client to specify the endorsing organisations but this is only intended to be used in certain edge cases where the Gateway has no way to handle selection automatically while guaranteeing that private data is not seen by organisations that are not supposed to see it. There is no mechanism to target specific peers for endorsement.

In general I am nervous about adding peer targeting to the Fabric Gateway client API as it might tempt people to use that capability instead of letting the Gateway use the optimal set of peers, and actually cause problems for themselves. Outside of very specific use-cases, like doing chaincode deployment on specific peers, there really is no need for it. But if there is real interest in developing admin APIs in Node, Go and/or Java based on the Fabric Gateway client API, it is definitely something we can consider.

[davidkhala]

You are absolutely correct. Right now the Fabric Gateway client API generally just figures out the best peers to use for endorsement of any transactions, taking into account chaincode, private data collection and key-/state-based endorsement policies. It does have a mechanism for the client to specify the endorsing organisations but this is only intended to be used in certain edge cases where the Gateway has no way to handle selection automatically while guaranteeing that private data is not seen by organisations that are not supposed to see it. There is no mechanism to target specific peers for endorsement.

In general I am nervous about adding peer targeting to the Fabric Gateway client API as it might tempt people to use that capability instead of letting the Gateway use the optimal set of peers, and actually cause problems for themselves. Outside of very specific use-cases, like doing chaincode deployment on specific peers, there really is no need for it. But if there is real interest in developing admin APIs in Node, Go and/or Java based on the Fabric Gateway client API, it is definitely something we can consider.

We are going to create a new SIG under TWGC to continue this conversation on tech steering. Although I cannot represent the community roadmap, but I believe continue to use exisiting grpc endpoint, which are also used in current peer binary design, is enough especially if maintainers can continuously provide protobuf translator for each language (nodejs, Java, Go).

[bestbeforetoday]

@davidkhala now that you look to be making progress on a separate Fabric admin API package, should we close this issue?

[davidkhala]

@davidkhala now that you look to be making progress on a separate Fabric admin API package, should we close this issue?

I think so. Fine to close.