luxoft / fabric-utils Goto Github PK

https://hyperledger-fabric.readthedocs.io/en/release-1.3/whatsnew.html

https://hyperledger-fabric.readthedocs.io/en/release-1.4/idemix.html

See https://hyperledger-fabric.readthedocs.io/en/release-1.4/private-data/private-data.html and https://hyperledger-fabric.readthedocs.io/en/release-1.4/whatsnew.html#private-data-enhancements

We use both java and kotlin. A kotlin-specific wrapper could be nice thing to have

fabric-utils should provide switching strategy of peers and orderers if they are not available

https://hyperledger-fabric.readthedocs.io/en/release-1.4/discovery-overview.html

Fabric java SDK now has it's own configuration file, handled by NetworkConfig class. Need to examine it and and migrate to it if possible.
If seems this config file has no information related to network configuration, only connectivity. So we can consider migrating to it partially.

Move this to some variable
fabric-utils/fabric-connector/src/main/java/com/luxoft/fabric/FabricConfig.java

instantiateProposalRequest.setProposalWaitTime(120000);
...
upgradeProposalRequest.setProposalWaitTime(120000);

StringMapDeserialzier was implemented to handle wrong syntax in fabric.yaml, when maps of object were defined as map of array of a single object.

peers:
  - peer1:
    ...
  - peer2
    ...

should be (in yaml syntax)

peers:
  peer1:
    ...
  peer2:
    ...

StringMapDeserialzier should have issue deprecation warning asking to update fabric.yaml to valid map format

publishing contains private repo url

License & copyright, maintainer, etc.

We have fabric explorer. Consider moving it here.

I think it is highly advisable to bring in git history since it helps in squashing bugs. We'll have to review and potentially clean-up history but a cursory review showed no blockers to my eye.

We have implemented scripts to reorganize fabric network.
Consider moving them to this project.

https://hyperledger-fabric.readthedocs.io/en/release-1.4/peer_event_services.html

In case of MVCC_READ_CONFLICT_VALUE or PHANTOM_READ_CONFLICT_VALUE validation errors its good to have option to retry same transaction. These errors happen during parallel chaincode request and basically mean that one transaction is reading states affected by another.

FabricConnector should have configurable parameters - retry delay and max number of retries.

Delay may (in future) directly depend on Block generation timeout (BatchTimeout in configtx.yaml).

When calling invoke() methods callers can specify number of retries (including 0 in case they want to handle such errors themselves)

Java is now supported to write chaincode. Consider implementing java chaincode as example/starting point.

https://hyperledger-fabric.readthedocs.io/en/release-1.3/couchdb_tutorial.html#cdb-pagination

example chaincode in files/chaincode/src/map/map.go seems to be originally copied from HLF sources with lots of not so simple things, related permissions, added.
It seems to be an example from some other project.
Thus I suggest to revert to the original map.go from the HLF examples or to use the similar sample chaincode from fabric-skeleton

https://hyperledger-fabric.readthedocs.io/en/release-1.4/operations_service.html

He have some implementation of fabric backup procedure (incomplete yet).
Consider moving it here and fix

Currently fabric-utils is quite difficult to run on Windows. In particular, the dependency on bash to handle fabric.sh, and use it in integration test should be removed.
I suggest to use gradle with docker/docker-compose plugin to manage docker invocation instead of shell script, and replace fabric.sh use in integration test calling gradle.

currently yaml config file is parsed as jackson dynamic object, and accesses using string keys.
Needs to reimplement this, mapping config elements to POJO classes, and exposing these from the library whenever possible.