Extend lifecycle protos to checkcommitreadiness to provide discrepancy details

[satota2]

This patch extends lifecycle protos to checkcommitreadiness to provide discrepancy details.

Type of change

• New feature

Description

I have proposed an extension to lifecycle chaincode checkcommitreadiness to provide details of the discrepancies as shown in hyperledger/fabric#4428.

As a sub-task stemming from issue #4428, this patch extends lifecycle protos to checkcommitreadiness to provide discrepancy details.
To maintain backward compatibility with the previous versions of checkcommitreadiness, I've opted to introduce a field named mismatches.

Once this patch is merged, I plan to enhance the command and submit it to the Fabric repository. A provisional implementation is provided below:

• satota2/fabric@58db22d
• satota2/fabric@9ea8ad1

The example of output when executing checkcommitreadiness with inspect flag in the provisional implementation:

peer lifecycle chaincode checkcommitreadiness --channelID mychannel --name basic --version 2.0 --sequence 2 --inspect
Chaincode definition for chaincode 'basic', version '2.0', sequence '2' on channel 'mychannel' approval status by org:
Org1MSP: false (mismatch: [EndorsementInfo, ValidationInfo, Collections])
Org2MSP: false (mismatch: [ChaincodeParameters])

peer lifecycle chaincode checkcommitreadiness --channelID mychannel --name basic --version 2.0 --sequence 2 --inspect --output json
{
        "approvals": {
                "Org1MSP": false,
                "Org2MSP": false
        },
        "mismatches": {
                "Org1MSP": {
                        "items": [
                                "EndorsementInfo (Check the Version, InitRequired, EndorsementPlugin)",
                                "ValidationInfo (Check the ValidationParameter, ValidationPlugin)",
                                "Collections (Check the Collections)"
                        ]
                },
                "Org2MSP": {
                        "items": [
                                "ChaincodeParameters (Check the Sequence, ChaincodeName)"
                        ]
                }
        }
}

Related Issues

• Extend to lifecycle chaincode checkcommitreadiness to provide details of the discrepancies fabric#4428

[denyeart]

Minor comment - since this contains a repeated list, should it be called "Mismatches" instead of "Mismatch"?

[satota2]

@denyeart
Thank you for your review.
I've updated the PR based on your comments and also revised the comment statements for this message.
Please review it once again.

[denyeart]

Ok, it looks like all the bindings got built successfully with the proto change (node, java, go, go apiv2).

@bestbeforetoday @satota2 Shall I proceed with a v0.3.1 PR and then create v0.3.1 release tag so that fabric main branch can pull in github.com/hyperledger/fabric-protos-go v0.3.1?

I don't think the gateway SDKs will need to update since they still use v02.x, but wanted to check with @bestbeforetoday in case I've missed something...

[satota2]

@bestbeforetoday @satota2 Shall I proceed with a v0.3.1 PR and then create v0.3.1 release tag so that fabric main branch can pull in github.com/hyperledger/fabric-protos-go v0.3.1?

@denyeart @bestbeforetoday
For my part, I would greatly appreciate it if you could proceed with the v0.3.1 PR and v0.3.1 release. It would help me move forward with the implementation in fabric main repository. Thank you in advance.

[bestbeforetoday]

@denyeart This should not disrupt the client SDKs since they depend on v0.2.x versions. Releasing should be as simple as creating a GitHub release, as described in the RELEASING document.

However... I would recommend merging this pull request first to ensure the tagging of the published Node bindings remains sane. There is a similar pull request to update the v0.1.x branch that should also be merged but won't affect a new release tag against the main branch.

[denyeart]

Thanks @bestbeforetoday.

I've merged the PRs, created PR #194 to document your suggestions, created v0.3.1 release, confirmed the bindings have been pushed (except I think maven java repository update is delayed), and created PR #195 to update versions for next v03.2 release.