splitting the peer into a client and a server

[pfi79]

I think it is necessary to divide the peer into a server program (peer) and a client program (cli).
I don't think it's right that the client and server teams are in the same application.

[satota2]

@pfi79 Thank you for this PR. The motivation to separate the peer server runtime from the client-side CLI tooling is reasonable, and I agree that having both in the same binary is not ideal from a separation of concerns perspective.

I have two concerns I'd like to discuss before moving forward:

1. Command compatibility and migration path

The peer command with its subcommands (peer channel join, peer lifecycle chaincode install, peer chaincode invoke, peer snapshot, etc.) has been the standard operator interface for many years. A large number of users have built operational scripts, CI/CD pipelines, and documentation around this command structure. An abrupt breaking change would likely cause significant confusion.

Fabric has historically provided deprecation periods across LTS releases. For example, the legacy chaincode lifecycle was deprecated in v2.x and removed in v3.0, and the system channel followed a similar pattern. I think we should follow the same approach here:

• In the initial release that introduces the new CLI binary, the existing peer subcommands that are being moved should be retained but marked as deprecated (with deprecation warnings printed).
• The new CLI binary can be introduced alongside, and users can migrate at their own pace.
• The deprecated subcommands can then be removed in a subsequent major release.

What do you think about this approach?

2. Naming of the CLI binary

The name cli feels too generic and could easily collide with other tools in a user's PATH. A couple of alternatives to consider:

• peeradmin — This would be consistent with the existing osnadmin naming convention for the orderer administration CLI, giving Fabric's tooling a uniform naming pattern (osnadmin for orderer admin, peeradmin for peer admin).
• peer-cli — Makes the relationship to the peer component explicit while distinguishing it from the server binary.

Reference: prior art

As you may already be aware, there was a previous effort to extract the CLI into a separate repository: [hyperledger/fabric-cli](https://github.com/hyperledger/fabric-cli). While this project has seen little activity in recent years, it may serve as a reference point.

[pfi79]

Fabric has historically provided deprecation periods across LTS releases. For example, the legacy chaincode lifecycle was deprecated in v2.x and removed in v3.0, and the system channel followed a similar pattern. I think we should follow the same approach here:

• In the initial release that introduces the new CLI binary, the existing peer subcommands that are being moved should be retained but marked as deprecated (with deprecation warnings printed).
• The new CLI binary can be introduced alongside, and users can migrate at their own pace.
• The deprecated subcommands can then be removed in a subsequent major release.

What do you think about this approach?

I like the approach. I did it on purpose so that I could discuss and do everything right. Questions:

• if the functionality is temporarily duplicated, at what point should the documentation be changed?
• I'm not sure that there will be big changes in the next year or two. We release a version at least once a quarter. It seems to me that the stages of cancellation will need to be thought through more flexibly.

Naming of the CLI binary

• peeradmin - I disagree, there is also non-admin functionality.
• peer-cli - good
• peercli - we can still call it that.

[bestbeforetoday]

There was an intention for a long time to create new Fabric CLI commands, decoupled from the peer (server) codebase. The fabric-cli repository (based on the legacy Go SDK) was one attempt. More recently there was a desire to create a new admin CLI based on the fabric-admin-sdk:

• Chaincode CLI issue.
• Initial draft of a replacement peer CLI.

fabric-admin-sdk makes use of the peer Gateway service so allows some operations to be performed with less end-user configuration and client-side code than the existing peer CLI implementation. For example, the client does not need to know the endorsement policy, supply multiple endorsing peers, or supply the orderer address to perform operations such as chaincode commit. A single peer endpoint is sufficient. This makes a much better end user experience.

I think extracting the CLI from the server codebase is a great idea. I am not sure just using the existing peer CLI codebase is the best approach.

On migration, I agree that a deprecation period is necessary where both the old and new CLI commands existing alongside each other before the old ones are removed. Perhaps once new CLI commands are available, the old peer command can be deprecated in an LTS release based on Fabric 3.x, and then removed in a subsequent LTS release.

Finally, I'm not certain PR comments are the most visible place to have this kind of architecture / strategy discussion. Maybe at least an issue or even an RFC would be more appropriate.

[pfi79]

There was an intention for a long time to create new Fabric CLI commands, decoupled from the peer (server) codebase. The fabric-cli repository (based on the legacy Go SDK) was one attempt. More recently there was a desire to create a new admin CLI based on the fabric-admin-sdk:

I don't mind someone making some kind of cli. But I think that now it will be immediately dead.

I believe that fabric itself (out of the box) should have all the utilities to deploy it.

I think extracting the CLI from the server codebase is a great idea. I am not sure just using the existing peer CLI codebase is the best approach.

In fabric, we have utilities that are in a single code base, but are created as separate programs (configtxgen, configtxlator, cryptogen, osnadmin). I think it should be left that way.

On migration, I agree that a deprecation period is necessary where both the old and new CLI commands existing alongside each other before the old ones are removed. Perhaps once new CLI commands are available, the old peer command can be deprecated in an LTS release based on Fabric 3.x, and then removed in a subsequent LTS release.

We still have version 2 in LTS. Version 3 is not in LTS yet.

When duplicating functionality, at what point should the documentation be changed?

Finally, I'm not certain PR comments are the most visible place to have this kind of architecture / strategy discussion. Maybe at least an issue or even an RFC would be more appropriate.

We don't have many participants to start a discussion or an rfc on such an issue. It's easier and faster for me (1-2 days) to write an option and offer to consider it. We'll discuss it, come to an agreement, close it, and propose a new change.

[bestbeforetoday]

If you have the bandwidth to implement the new CLI commands then I am fine with that happening in the fabric repository. The new CLI commands must provide the usability improvements possible using the peer Gateway service and not propagate the limitations of the existing CLI commands.

New CLI commands could be added to Fabric v2.5 and v3.x alongside the legacy CLI commands. Once new CLI commands are available and stabilized, the legacy CLI commands could be deprecated. If you prefer to add the new commands only to the v3.x release, I think it would make sense to then declare v3.x as the current LTS release so production deployments can have more confidence transitioning from v2.5 to v3.x and the new CLI commands.

Since people are already using the legacy CLI commands with v3.x, I am not sure it is reasonable to remove them before a next major release version. It is too big a breaking change.