splitting the peer into a client and a server

Makefile

@@ -86,7 +86,7 @@ GO_TAGS ?=
 RELEASE_EXES = orderer $(TOOLS_EXES)
 RELEASE_IMAGES = baseos ccenv orderer peer
 RELEASE_PLATFORMS = darwin-amd64 darwin-arm64 linux-amd64 linux-arm64 windows-amd64
-TOOLS_EXES = configtxgen configtxlator cryptogen discover ledgerutil osnadmin peer
+TOOLS_EXES = configtxgen configtxlator cryptogen discover ledgerutil osnadmin peer cli
 
 pkgmap.configtxgen    := $(PKGNAME)/cmd/configtxgen
 pkgmap.configtxlator  := $(PKGNAME)/cmd/configtxlator
@@ -96,6 +96,7 @@ pkgmap.ledgerutil     := $(PKGNAME)/cmd/ledgerutil
 pkgmap.orderer        := $(PKGNAME)/cmd/orderer
 pkgmap.osnadmin       := $(PKGNAME)/cmd/osnadmin
 pkgmap.peer           := $(PKGNAME)/cmd/peer
+pkgmap.cli            := $(PKGNAME)/cmd/cli
 
 .DEFAULT_GOAL := all
 

RELEASING.md

@@ -67,9 +67,9 @@ export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/peerOrganizations/org1.e
 export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
 export CORE_PEER_ADDRESS=localhost:7051
 
-peer chaincode invoke -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls --cafile ${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C mychannel -n basicgo --peerAddresses localhost:7051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt --peerAddresses localhost:9051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt -c '{"function":"InitLedger","Args":[]}'
+cli chaincode invoke -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls --cafile ${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C mychannel -n basicgo --peerAddresses localhost:7051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt --peerAddresses localhost:9051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt -c '{"function":"InitLedger","Args":[]}'
 
-peer chaincode query -C mychannel -n basicgo -c '{"Args":["GetAllAssets"]}'
+cli chaincode query -C mychannel -n basicgo -c '{"Args":["GetAllAssets"]}'
 
 docker logs peer0.org1.example.com
 

cmd/cli/main.go

@@ -0,0 +1,61 @@
+/*
+Copyright IBM Corp. All Rights Reserved.
+
+SPDX-License-Identifier: Apache-2.0
+*/
+
+package main
+
+import (
+	_ "net/http/pprof"
+	"os"
+	"strings"
+
+	"github.com/hyperledger/fabric-lib-go/bccsp/factory"
+	"github.com/hyperledger/fabric/internal/peer/chaincode"
+	"github.com/hyperledger/fabric/internal/peer/channel"
+	"github.com/hyperledger/fabric/internal/peer/common"
+	"github.com/hyperledger/fabric/internal/peer/lifecycle"
+	"github.com/hyperledger/fabric/internal/peer/snapshot"
+	"github.com/hyperledger/fabric/internal/peer/version"
+	"github.com/spf13/cobra"
+	"github.com/spf13/viper"
+)
+
+// The main command describes the service and
+// defaults to printing the help message.
+var mainCmd = &cobra.Command{Use: "cli"}
+
+func main() {
+	setEnvConfig(viper.GetViper())
+
+	// Define command-line flags that are valid for all cli commands and
+	// subcommands.
+	mainFlags := mainCmd.PersistentFlags()
+
+	mainFlags.String("logging-level", "", "Legacy logging level flag")
+	viper.BindPFlag("logging_level", mainFlags.Lookup("logging-level"))
+	mainFlags.MarkHidden("logging-level")
+
+	cryptoProvider := factory.GetDefault()
+
+	mainCmd.AddCommand(version.Cmd())
+	mainCmd.AddCommand(chaincode.Cmd(nil, cryptoProvider))
+	mainCmd.AddCommand(channel.Cmd(nil))
+	mainCmd.AddCommand(lifecycle.Cmd(cryptoProvider))
+	mainCmd.AddCommand(snapshot.Cmd(cryptoProvider))
+
+	// On failure Cobra prints the usage message and error string, so we only
+	// need to exit with a non-0 status
+	if mainCmd.Execute() != nil {
+		os.Exit(1)
+	}
+}
+
+func setEnvConfig(v *viper.Viper) {
+	v.SetEnvPrefix(common.CmdRoot)
+	v.AllowEmptyEnv(true)
+	v.AutomaticEnv()
+	replacer := strings.NewReplacer(".", "_")
+	v.SetEnvKeyReplacer(replacer)
+}

cmd/cli/main_test.go

@@ -0,0 +1,31 @@
+/*
+Copyright IBM Corp. All Rights Reserved.
+
+SPDX-License-Identifier: Apache-2.0
+*/
+
+package main
+
+import (
+	"testing"
+
+	"github.com/spf13/viper"
+	"github.com/stretchr/testify/assert"
+	"github.com/stretchr/testify/require"
+)
+
+func TestSetEnvConfig(t *testing.T) {
+	vp := viper.New()
+	t.Setenv("CORE_FRUIT", "Apple")
+	t.Setenv("CORE_COLOR", "")
+	err := vp.BindEnv("Fruit")
+	require.NoError(t, err)
+	err = vp.BindEnv("Color")
+	require.NoError(t, err)
+	vp.SetDefault("Color", "Green")
+
+	setEnvConfig(vp)
+
+	assert.Equal(t, "Apple", vp.Get("Fruit"))
+	assert.Equal(t, "", vp.Get("Color"))
+}

cmd/peer/main.go

@@ -11,13 +11,8 @@ import (
 	"os"
 	"strings"
 
-	"github.com/hyperledger/fabric-lib-go/bccsp/factory"
-	"github.com/hyperledger/fabric/internal/peer/chaincode"
-	"github.com/hyperledger/fabric/internal/peer/channel"
 	"github.com/hyperledger/fabric/internal/peer/common"
-	"github.com/hyperledger/fabric/internal/peer/lifecycle"
 	"github.com/hyperledger/fabric/internal/peer/node"
-	"github.com/hyperledger/fabric/internal/peer/snapshot"
 	"github.com/hyperledger/fabric/internal/peer/version"
 	"github.com/spf13/cobra"
 	"github.com/spf13/viper"
@@ -38,14 +33,8 @@ func main() {
 	viper.BindPFlag("logging_level", mainFlags.Lookup("logging-level"))
 	mainFlags.MarkHidden("logging-level")
 
-	cryptoProvider := factory.GetDefault()
-
 	mainCmd.AddCommand(version.Cmd())
 	mainCmd.AddCommand(node.Cmd())
-	mainCmd.AddCommand(chaincode.Cmd(nil, cryptoProvider))
-	mainCmd.AddCommand(channel.Cmd(nil))
-	mainCmd.AddCommand(lifecycle.Cmd(cryptoProvider))
-	mainCmd.AddCommand(snapshot.Cmd(cryptoProvider))
 
 	// On failure Cobra prints the usage message and error string, so we only
 	// need to exit with a non-0 status

core/chaincode/platforms/golang/platform.go

@@ -39,7 +39,7 @@ func (p *Platform) Name() string {
 // ValidatePath is used to ensure that path provided points to something that
 // looks like go chainccode.
 //
-// NOTE: this is only used at the _client_ side by the peer CLI.
+// NOTE: this is only used at the _client_ side by the CLI.
 func (p *Platform) ValidatePath(rawPath string) error {
 	_, err := DescribeCode(rawPath)
 	if err != nil {
@@ -52,7 +52,7 @@ func (p *Platform) ValidatePath(rawPath string) error {
 // NormalizePath is used to extract a relative module path from a module root.
 // This should not impact legacy GOPATH chaincode.
 //
-// NOTE: this is only used at the _client_ side by the peer CLI.
+// NOTE: this is only used at the _client_ side by the CLI.
 func (p *Platform) NormalizePath(rawPath string) (string, error) {
 	modInfo, err := moduleInfo(rawPath)
 	if err != nil {
@@ -113,7 +113,7 @@ var gzipCompressionLevel = gzip.DefaultCompression
 // GetDeploymentPayload creates a gzip compressed tape archive that contains the
 // required assets to build and run go chaincode.
 //
-// NOTE: this is only used at the _client_ side by the peer CLI.
+// NOTE: this is only used at the _client_ side by the CLI.
 func (p *Platform) GetDeploymentPayload(codepath string) ([]byte, error) {
 	codeDescriptor, err := DescribeCode(codepath)
 	if err != nil {

core/ledger/kvledger/kv_ledger_provider.go

@@ -429,7 +429,7 @@ func (p *Provider) Close() {
 
 // deletePartialLedgers scans for and deletes any ledger with a status of UNDER_CONSTRUCTION or UNDER_DELETION.
 // UNDER_CONSTRUCTION ledgers represent residual structures created as a side effect of a crash during ledger creation.
-// UNDER_DELETION ledgers represent residual structures created as a side effect of a crash during a peer channel unjoin.
+// UNDER_DELETION ledgers represent residual structures created as a side effect of a crash during a cli channel unjoin.
 func (p *Provider) deletePartialLedgers() error {
 	logger.Debug("Removing ledgers in state UNDER_CONSTRUCTION or UNDER_DELETION")
 	itr := p.idStore.db.GetIterator(metadataKeyPrefix, metadataKeyStop)

docs/source/cc_basic.md

@@ -68,7 +68,7 @@ export PATH=${PWD}/../bin:$PATH
 export FABRIC_CFG_PATH=${PWD}/../config
 
 # invoke the function
-peer chaincode query -C mychannel -n basicts -c '{"Args":["org.hyperledger.fabric:GetMetadata"]}' | jq
+cli chaincode query -C mychannel -n basicts -c '{"Args":["org.hyperledger.fabric:GetMetadata"]}' | jq
 ```
 
 Note that `| jq` can be omitted if `jq` is not installed. However, the metadata shows details of the deployed contract in JSON, so `jq` provides legibility. To confirm that the smart contract is working, repeat the prior commands for `org2`.

docs/source/cc_launcher.md

@@ -6,7 +6,7 @@ This approach limited chaincode implementations to a handful of languages, requi
 
 Starting with Fabric 2.0, External Builders and Launchers address these limitations by enabling operators to extend the peer with programs that can build, launch, and discover chaincode. To leverage this capability you will need to create your own buildpack and then modify the peer core.yaml to include a new `externalBuilder` configuration element which lets the peer know an external builder is available. The following sections describe the details of this process.
 
-Note that if no configured external builder claims a chaincode package, the peer will attempt to process the package as if it were created with the standard Fabric packaging tools such as the peer CLI.
+Note that if no configured external builder claims a chaincode package, the peer will attempt to process the package as if it were created with the standard Fabric packaging tools such as the CLI.
 
 **Note:** This is an advanced feature which will likely require custom packaging of the peer image with everything your builders and launchers depend on unless your builders and launchers are simple enough, such as those used in the [basic asset transfer external chaincode Fabric sample](https://github.com/hyperledger/fabric-samples/blob/main/asset-transfer-basic/chaincode-external). For example, the following samples use `go` and `bash`, which are not included in the current official `fabric-peer` image.
 
@@ -202,11 +202,11 @@ If you do not need to fallback to the legacy Docker build process for your chain
 
 ## Chaincode packages
 
-A chaincode package contains chaincode and associated metadata in a compressed gzip file that can be installed to a peer. The peer command `peer lifecycle chaincode package` can be used to create a chaincode package. You can also create a chaincode package using third party tools.
+A chaincode package contains chaincode and associated metadata in a compressed gzip file that can be installed to a peer. The peer command `cli lifecycle chaincode package` can be used to create a chaincode package. You can also create a chaincode package using third party tools.
 
 ### Lifecycle chaincode package contents
 
-A lifecycle chaincode package contains two files. The first file, `code.tar.gz` is a gzip compressed POSIX tape archive. This file includes the source artifacts for the chaincode. Packages created by the peer CLI will place the chaincode implementation source under the `src` directory and chaincode metadata (like CouchDB indexes) under the `META-INF` directory.
+A lifecycle chaincode package contains two files. The first file, `code.tar.gz` is a gzip compressed POSIX tape archive. This file includes the source artifacts for the chaincode. Packages created by the CLI will place the chaincode implementation source under the `src` directory and chaincode metadata (like CouchDB indexes) under the `META-INF` directory.
 
 The second file, `metadata.json` is a JSON document with three keys:
 - `type`: the chaincode type (e.g. GOLANG, JAVA, NODE)

docs/source/cc_service.md

@@ -234,7 +234,7 @@ func (s *SimpleChaincode) Invoke(stub shim.ChaincodeStubInterface) pb.Response {
 
 //NOTE - parameters such as ccid and endpoint information are hard coded here for illustration. This can be passed in a variety of standard ways
 func main() {
-       //The ccid is assigned to the chaincode on install (using the “peer lifecycle chaincode install <package>” command) for instance
+       //The ccid is assigned to the chaincode on install (using the “cli lifecycle chaincode install <package>” command) for instance
         ccid := "mycc:fcbf8724572d42e859a7dd9a7cd8e2efb84058292017df6e3d89178b64e6c831"
 
         server := &shim.ChaincodeServer{
@@ -253,7 +253,7 @@ func main() {
 ```
 The key to running the chaincode as an external service is the use of `shim.ChaincodeServer`. This uses the new shim API `shim.ChaincodeServer` with the chaincode service properties described below:
 
-* **CCID** (string)- CCID should match chaincode's package name on peer. This is the `CCID` associated with the installed chaincode as returned by the `peer lifecycle chaincode install <package>` CLI command. This can be obtained post-install using the "peer lifecycle chaincode queryinstalled" command.
+* **CCID** (string)- CCID should match chaincode's package name on peer. This is the `CCID` associated with the installed chaincode as returned by the `cli lifecycle chaincode install <package>` CLI command. This can be obtained post-install using the "cli lifecycle chaincode queryinstalled" command.
 * **Address** (string) - Address is the listen address of the chaincode server
 * **CC** (Chaincode) -  CC is the chaincode that handles Init and Invoke
 * **TLSProps** (TLSProperties) - TLSProps is the TLS properties passed to chaincode server

docs/source/chaincode4ade.rst

@@ -588,8 +588,8 @@ dependencies with ``go mod vendor`` before packaging your chaincode.
 This places the external dependencies for your chaincode into a local ``vendor``
 directory.
 
-Once dependencies are vendored in your chaincode directory, ``peer chaincode package``
-and ``peer chaincode install`` operations will then include code associated with the
+Once dependencies are vendored in your chaincode directory, ``cli chaincode package``
+and ``cli chaincode install`` operations will then include code associated with the
 dependencies into the chaincode package.
 
 JSON determinism

docs/source/chaincode_lifecycle.md

@@ -55,20 +55,20 @@ every organization on a channel needs to complete each step.
 
 This topic provides a detailed overview of the operations of the Fabric
 chaincode lifecycle rather than the specific commands. To learn more about how
-to use the Fabric lifecycle using the peer CLI, see the
+to use the Fabric lifecycle using the CLI, see the
 [Deploying a smart contract to a channel tutorial](deploy_chaincode.html)
-or the [peer lifecycle command reference](commands/peerlifecycle.html).
+or the [cli lifecycle command reference](commands/clilifecycle.html).
 
 ### Step One: Packaging the smart contract
 
 Chaincode needs to be packaged in a tar file before it can be installed on your
-peers. You can package a chaincode using the Fabric peer binary
+peers. You can package a chaincode using the Fabric cli binary
 or a third party tool such as GNU tar. When you create a chaincode
 package, you need to provide a chaincode package label to create a succinct and
 human readable description of the package.
 
 If you use a third party tool to package the chaincode, the resulting file needs
-to be in the format below. The Fabric peer binary will
+to be in the format below. The Fabric cli binary will
 automatically create a file in this format.
 - The chaincode needs to be packaged in a tar file, ending with a `.tar.gz` file
   extension.
@@ -91,7 +91,7 @@ label.*
 ### Step Two: Install the chaincode on your peers
 
 You need to install the chaincode package on every peer that will execute and
-endorse transactions. You need to complete this step with the peer CLI using the
+endorse transactions. You need to complete this step with the CLI using the
 credentials of the **Peer Administrator**. Your peer will build the chaincode
 after the chaincode is installed, and return a build error if there is a problem
 with your chaincode.
@@ -116,7 +116,7 @@ is the package label combined with a hash of the package. This package
 identifier is used to associate a chaincode package installed on your peers with
 a chaincode definition approved by your organization. **Save the identifier**
 for next step. You can also find the package identifier by querying the packages
-installed on your peer using the peer CLI.
+installed on your peer using the CLI.
 
   ![Installing the chaincode](lifecycle/Lifecycle-install.png)
 
@@ -169,10 +169,10 @@ consistent across organizations:
   time you increment the version of a chaincode, assuming the chaincode definition
   that increments the version indicates that `Init` is required.
 
-  If you are using the Fabric peer CLI, you can use the `--init-required` flag
+  If you are using the Fabric CLI, you can use the `--init-required` flag
   when you approve and commit the chaincode definition to indicate that the `Init`
   function must be called to initialize the new chaincode version. To call `Init`
-   using the Fabric peer CLI, use the `peer chaincode invoke` command and pass the
+   using the Fabric CLI, use the `cli chaincode invoke` command and pass the
   `--isInit` flag.
 
   If you are using the Fabric contract API, you do not need to include an `Init`
@@ -219,7 +219,7 @@ Once a sufficient number of channel members have approved a chaincode definition
 one organization can commit the definition to the channel. You can use the
 ``checkcommitreadiness`` command to check whether committing the chaincode
 definition should be successful based on which channel members have approved a
-definition before committing it to the channel using the peer CLI. The commit
+definition before committing it to the channel using the CLI. The commit
 transaction proposal is first sent to the peers of channel members, who query the
 chaincode definition approved for their organizations and endorse the definition
 if their organization has approved it. The transaction is then submitted to the