Date   

Hyperledger Fabric Application Developer Community call -- today's call (Thursday 25th June) has been CANCELLED please note

Paul O'Mahoney <mahoney@...>
 

please note that today's call has been cancelled - the next call planned is on 9th July.

best regards Paul

Paul O'Mahony
Community Lead - Hyperledger Fabric Developer Community
RocketChat:  mahoney1
mahoney@...

----- Forwarded by Paul O'Mahoney/UK/IBM on 25/06/2020 14:37 -----

From:        Paul O'Mahoney/UK/IBM
To:        fabric@...
Date:        22/06/2020 09:49
Subject:        Next Hyperledger Fabric Application Developer Community call  -- this Thursday 25th June @ 3pm UTC time: 4pm UK, 11am ET, 8am PT




dear Fabric Application Developer,


the next  Fabric Application Developer community call is: Thursday 25th June - 3pm UTC,  4pm UK time (+1), 11am ET (-5 hrs), 8am PT (-8 hrs)  - other time zones here.   It lasts approx 30-60 mins FYI.

The agenda will be posted here -> https://wiki.hyperledger.org/display/fabric/Agendas%3A+Fabric+Application+Developer+Community+Call+Meetings  

This community call is held bi-weekly via Zoom webconference and is aimed at :

- helping the worldwide Hyperledger Fabric Application Developer community grow (eg. developing applications, smart contracts, client apps using the SDKs, tutorials/demos etc -  eg using NodeJS/TypeScript, Java, Go etc etc) 
- helping app developers understand / hear more about exciting new things in Fabric, eg. features upcoming or work in progress - ie things that appeal to the developer
- foster more interest, best practices etc in developing applications (eg developing solutions, use cases) with Hyperledger Fabric. 
- opportunity to ask questions of the Fabric team eg. you may have feedback/questions on your experiences developing solutions with Fabric
- to share stuff you've done with the community, eg sample code / sample use cases that others may be interested in

If you wish to share content on a call, just let me know via email direct or DM me on Rocketchat (ID: mahoney1) and I'll put an item on the agenda. Provide the following:
- the topic (state whether its presentation, or demo etc)
- the full name of the presenter, and 
- approx length of your pitch in minutes


The Zoom webconference ID is https://zoom.us/my/hyperledger.community   

More information can be found on the community page -> https://wiki.hyperledger.org/display/fabric/Fabric+Application+Developer+Community+Calls

You can get calendar invites (eg iCal) here

many thanks for your time - feel free to forward this email if you think it is of interest to a colleague.

Paul O'Mahony
Community Lead - Hyperledger Fabric Developer Community
RocketChat:  mahoney1

mahoney@...


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


Re: Peer failed getting private key from HSM

Gari Singh <garis@...>
 

The easiest thing to do is to find the CKA_ID attribute of the private key stored in the HSM and then set the AltID property for the PKCS11 BCCSP.
AltID was added in 1.4.6 as I recall to help facilitate this type of config.

-----------------------------------------
Gari Singh
Distinguished Engineer, CTO - IBM Blockchain
IBM Middleware
550 King St
Littleton, MA 01460
Cell: 978-846-7499
garis@...
-----------------------------------------

-----fabric@... wrote: -----
To: carlos.ellery@...
From: "Brett T Logan"
Sent by: fabric@...
Date: 06/24/2020 07:57PM
Cc: fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Peer failed getting private key from HSM

Are you setting up the peer and orderer to communicate with the external CA's HSM?

Did you generate the CSR yourself, and thus you have the private key and you provided it to them for import, or did the external CA provider generate everything and they fully own the private key? BCCSP doesn't use the SKI extension of the cert, it computes its own SKI by doing a SHA256 over the private key, the corresponding public signing cert is named with this SKI (SHA256) of the private key. If you had the private key (or access to it via PKCS11) you could perform the same operation BCCSP does to compute the SHA256 SKI.

Brett Logan
Software Engineer, IBM Blockchain
Phone: 1-984-242-6890
E-mail: brett.t.logan@...

----- Original message -----
From: "Carlos Eduardo Matos Ellery" <carlos.ellery@...>
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] Peer failed getting private key from HSM
Date: Wed, Jun 24, 2020 7:11 PM

Hi everyone,

I'm trying to use a certificate issued by an external CA trough an HSM integration but it's not working. The peer node (v1.4.7) doesn't start and gives the following output (complete log available at https://pastebin.com/J6npgd6G):

...
2020-06-24 22:32:42.176 UTC [bccsp_p11] getSession -> DEBU 038 Reusing existing pkcs11 session 1 on slot 1
2020-06-24 22:32:42.231 UTC [msp] getSigningIdentityFromConf -> DEBU 039 Could not find SKI [d69fe5487378e0914e8d65870128a8d4b55d05a502c45daddea30c7452a1fe2c], trying KeyMaterial field: Key with SKI d69fe5487378e0914e8d65870128a8d4b55d05a502c45daddea30c7452a1fe2c not found in msp/keystoreFailed getting key for SKI [[214 159 229 72 115 120 224 145 78 141 101 135 1 40 168 212 181 93 5 165 2 196 93 173 222 163 12 116 82 161 254 44]]
...
2020-06-24 22:32:42.231 UTC [main] InitCmd -> ERRO 03a Cannot run peer because error when setting up MSP of type bccsp from directory /etc/hyperledger/fabric/msp: KeyMaterial not found in SigningIdentityInfo

I've found that my certificate (located at msp/signcerts) doesn't have the SKID extension (https://tools.ietf.org/html/rfc3280#section-4.2.1.2) and the CA tech support have the excuse that this is a non-critical extension for end certificates. Now, is there a way BCCSP can find the corresponding private key of my certificate on the HSM?


Thanks for the help,
--
Carlos Eduardo Matos Ellery


Upcoming Event: Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere - Fri, 06/26/2020 6:00am-7:00am #cal-reminder

fabric@lists.hyperledger.org Calendar <fabric@...>
 

Reminder: Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere

When: Friday, 26 June 2020, 6:00am to 7:00am, (GMT+01:00) Europe/London

Where:https://zoom.us/j/6223336701

View Event

Organizer: Anthony O'Dowd a_o-dowd@... +441962816761

Description: Documentation workgroup call.
Agenda, minutes and recordings: https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group


Re: Peer failed getting private key from HSM

Ashutosh Kumar
 

SKI is generated at the time key pair is generated (which feeds into CSR). If you have disjoint operation , the way you have , your solution is not going to work.

Ashutosh Kumar


From: fabric@... <fabric@...> on behalf of Carlos Eduardo Matos Ellery <carlos.ellery@...>
Sent: Wednesday, June 24, 2020 7:09 PM
To: fabric@... <fabric@...>
Subject: [Hyperledger Fabric] Peer failed getting private key from HSM
 
Hi everyone,

I'm trying to use a certificate issued by an external CA trough an HSM integration but it's not working. The peer node (v1.4.7) doesn't start and gives the following output (complete log available at https://pastebin.com/J6npgd6G):

...
2020-06-24 22:32:42.176 UTC [bccsp_p11] getSession -> DEBU 038 Reusing existing pkcs11 session 1 on slot 1
2020-06-24 22:32:42.231 UTC [msp] getSigningIdentityFromConf -> DEBU 039 Could not find SKI [d69fe5487378e0914e8d65870128a8d4b55d05a502c45daddea30c7452a1fe2c], trying KeyMaterial field: Key with SKI d69fe5487378e0914e8d65870128a8d4b55d05a502c45daddea30c7452a1fe2c not found in msp/keystore
Failed getting key for SKI [[214 159 229 72 115 120 224 145 78 141 101 135 1 40 168 212 181 93 5 165 2 196 93 173 222 163 12 116 82 161 254 44]]
...
2020-06-24 22:32:42.231 UTC [main] InitCmd -> ERRO 03a Cannot run peer because error when setting up MSP of type bccsp from directory /etc/hyperledger/fabric/msp: KeyMaterial not found in SigningIdentityInfo

I've found that my certificate (located at msp/signcerts) doesn't have the SKID extension (https://tools.ietf.org/html/rfc3280#section-4.2.1.2) and the CA tech support have the excuse that this is a non-critical extension for end certificates. Now, is there a way BCCSP can find the corresponding private key of my certificate on the HSM?


Thanks for the help,
--
Carlos Eduardo Matos Ellery


Re: Peer failed getting private key from HSM

Brett T Logan <brett.t.logan@...>
 

Are you setting up the peer and orderer to communicate with the external CA's HSM?
 
Did you generate the CSR yourself, and thus you have the private key and you provided it to them for import, or did the external CA provider generate everything and they fully own the private key? BCCSP doesn't use the SKI extension of the cert, it computes its own SKI by doing a SHA256 over the private key, the corresponding public signing cert is named with this SKI (SHA256) of the private key. If you had the private key (or access to it via PKCS11) you could perform the same operation BCCSP does to compute the SHA256 SKI.
 
Brett Logan
Software Engineer, IBM Blockchain
Phone: 1-984-242-6890
 
 
 

----- Original message -----
From: "Carlos Eduardo Matos Ellery" <carlos.ellery@...>
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] Peer failed getting private key from HSM
Date: Wed, Jun 24, 2020 7:11 PM
 
Hi everyone,

I'm trying to use a certificate issued by an external CA trough an HSM integration but it's not working. The peer node (v1.4.7) doesn't start and gives the following output (complete log available at https://pastebin.com/J6npgd6G):

...
2020-06-24 22:32:42.176 UTC [bccsp_p11] getSession -> DEBU 038 Reusing existing pkcs11 session 1 on slot 1
2020-06-24 22:32:42.231 UTC [msp] getSigningIdentityFromConf -> DEBU 039 Could not find SKI [d69fe5487378e0914e8d65870128a8d4b55d05a502c45daddea30c7452a1fe2c], trying KeyMaterial field: Key with SKI d69fe5487378e0914e8d65870128a8d4b55d05a502c45daddea30c7452a1fe2c not found in msp/keystore
Failed getting key for SKI [[214 159 229 72 115 120 224 145 78 141 101 135 1 40 168 212 181 93 5 165 2 196 93 173 222 163 12 116 82 161 254 44]]
...
2020-06-24 22:32:42.231 UTC [main] InitCmd -> ERRO 03a Cannot run peer because error when setting up MSP of type bccsp from directory /etc/hyperledger/fabric/msp: KeyMaterial not found in SigningIdentityInfo

I've found that my certificate (located at msp/signcerts) doesn't have the SKID extension (https://tools.ietf.org/html/rfc3280#section-4.2.1.2) and the CA tech support have the excuse that this is a non-critical extension for end certificates. Now, is there a way BCCSP can find the corresponding private key of my certificate on the HSM?


Thanks for the help,
--
Carlos Eduardo Matos Ellery
 


Peer failed getting private key from HSM

Carlos Eduardo Matos Ellery
 

Hi everyone,

I'm trying to use a certificate issued by an external CA trough an HSM integration but it's not working. The peer node (v1.4.7) doesn't start and gives the following output (complete log available at https://pastebin.com/J6npgd6G):

...
2020-06-24 22:32:42.176 UTC [bccsp_p11] getSession -> DEBU 038 Reusing existing pkcs11 session 1 on slot 1
2020-06-24 22:32:42.231 UTC [msp] getSigningIdentityFromConf -> DEBU 039 Could not find SKI [d69fe5487378e0914e8d65870128a8d4b55d05a502c45daddea30c7452a1fe2c], trying KeyMaterial field: Key with SKI d69fe5487378e0914e8d65870128a8d4b55d05a502c45daddea30c7452a1fe2c not found in msp/keystore
Failed getting key for SKI [[214 159 229 72 115 120 224 145 78 141 101 135 1 40 168 212 181 93 5 165 2 196 93 173 222 163 12 116 82 161 254 44]]
...
2020-06-24 22:32:42.231 UTC [main] InitCmd -> ERRO 03a Cannot run peer because error when setting up MSP of type bccsp from directory /etc/hyperledger/fabric/msp: KeyMaterial not found in SigningIdentityInfo

I've found that my certificate (located at msp/signcerts) doesn't have the SKID extension (https://tools.ietf.org/html/rfc3280#section-4.2.1.2) and the CA tech support have the excuse that this is a non-critical extension for end certificates. Now, is there a way BCCSP can find the corresponding private key of my certificate on the HSM?


Thanks for the help,
--
Carlos Eduardo Matos Ellery


University Course on Fabric [call for suggestions/contributors]

Rafael André Pestana Belchior
 

Hello all,
I'm building a university course on Hyperledger Technologies, with focus on Hyperledger Fabric. This course is open source and will be exposed as an Hyperledger Lab.


In particular, this course would benefit greatly from people with experience not only on Fabric, but with other Hyperledger projects as well.

I would like very much to welcome any ideas, suggestions, and contributions.
Please feel free to reach me!

Cheers,
--
Rafael Belchior
Ph.D. student in Computer Science and Engineering, Blockchain - Técnico Lisboa
https://rafaelapb.github.io/
https://www.linkedin.com/in/rafaelpbelchior/



Re: Fabric support on MIPS 64 based architecture

Gari Singh <garis@...>
 

We try to ensure that we do not do anything which would prevent the code from compiling on platforms supported by Golang.
That being said, the official open source Fabric deliverable is the source code. You are free to use it / compile it how you see fit.
We don't want to be in the business of building and maintaining binaries for every possible platform.

And while we are happy to accept pull requests, historically we find that people will submit a change and then not maintain things going forward.

-----------------------------------------
Gari Singh
Distinguished Engineer, CTO - IBM Blockchain
IBM Middleware
550 King St
Littleton, MA 01460
Cell: 978-846-7499
garis@...
-----------------------------------------

-----fabric@... wrote: -----
To: huyinsong@...
From: "Brett T Logan"
Sent by: fabric@...
Date: 06/23/2020 11:43PM
Cc: fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Fabric support on MIPS 64 based architecture

Hi Ethan,

You can check out a pull request we had recently around this same request with regard to supporting arm64 which has a lot of information and feedback from the Fabric maintainers: https://github.com/hyperledger/fabric/pull/1086

I think Gari says it best: https://github.com/hyperledger/fabric/pull/1086#issuecomment-615883076

The gist of it is, there haven't been a lot of requests for this, and there is more than just providing the images and binaries. In particular, project contributors and maintainers have to commit to fixing any code that may not work on MIPS. Just publishing the images and binaries isn't enough, without a strong commitment from contributors who have a history of contributing to fabric, moving forward with this request is difficult. Providing official artifacts and support for maintaining the code on MIPS is a much much larger undertaking than most realize.

That being said, major requests like this go through an RFC process that is documented here: https://github.com/hyperledger/fabric-rfcs

Brett Logan
Software Engineer, IBM Blockchain
Phone: 1-984-242-6890
E-mail: brett.t.logan@...

----- Original message -----
From: "胡 银松" <huyinsong@...>
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] Fabric support on MIPS 64 based architecture
Date: Tue, Jun 23, 2020 10:57 PM

Hi all,
I am Ethan.
Recently I was working on a MIPS-64 based system. The operation system is Debian like os which runs on MIPS-64 based virtual machine. I am going to run fabric on this virtual machine. For now fabric could run on x86 based system. I wonder if there are fabric versions which could run on MIPS-64 based system? And if no, Is there a plan to support this?


Dynamically assign endorsing or chaincode query role to channel peers in the Fabric Node SDK #fabric-sdk-node #fabric #hyperledger-fabric

chintanr97@...
 

I am using the following Fabric Versions:
1. Fabric binaries: 1.4.4.
2. Fabric Node SDK version: 1.4.9 (fabric-network, fabric-client, fabric-ca-client).
3. Node.js version: v8.10.0

I wish to perform "query" operation on the channel using Fabric Node SDK, preferably using the "fabric-network" components. I have only 1 peer as the endorsing peer (one that has chaincode installed on it) out of 3 peers in total on the channel for that peer organization. NOTE: I do not have the roles assigned to these peers in the "connection-profile" explicitly and I am using "discovery" to be enabled on the channel. 

I assumed that the SDK function "setEndorsingPeers" from the "transaction.js" module will allow me to dynamically assign role to the peers based upon user input. But when I deep-dived into the Fabric Node SDK code, I saw that, the "evaluate" function in the "transaction.js" calls the default query handler, which sends the proposal randomly to one of the peers using "MSPID_SCOPE_SINGLE" phenomenon.

But because the discovery is enabled, the request may go to dynamically a committing peer, and returns failure. I know one possible solution is to use my custom query handler. But, I wish to identify, if dynamically I can assign endorsing or chaincode query role to channel peers in the Fabric Node SDK (v1.4.9)?


Fabric CA unable to register user "attempt to write a readonly database" #fabricca #fabric-ca #fabric-questions #fabric

Mattia Bolzonella
 

Hi, I'm trying to register a user via Fabric Java SDK but I get the error: "Registration of 'UserToRegister' failed: Error adding identity 'UserToRegister' to the database: attempt to write a readonly database".

To register the user I'm using the certificates of an organization admin previously registerd and enrolled on the same CA. 
The registration was made using the following command (sensible infos are replaced with variables):

fabric-ca-client register -d --id.name Admin@$DOMAIN --id.secret $ADMINPSW --id.type admin --id.attrs "hf.Registrar.Roles=client,hf.Registrar.Attributes=*,hf.Revoker=true,hf.GenCRL=true,admin=true:ecert,abac.init=true:ecert" -u https://ca.$DOMAIN:$CAPORT

And enrolled with:
fabric-ca-client enroll -d -u https://Admin@$DOMAIN:$ADMINPSW@ca.$DOMAIN:$CAPORT

I'm trying to register users with client roles, ad looking at the register command I understand that the Admin@$Domain user can do so, but when I try I get the error above:
Registration of 'UserToRegister' failed: Error adding identity 'UserToRegister' to the database: attempt to write a readonly database

What I'm missing?
 


Re: Fabric support on MIPS 64 based architecture

Brett T Logan <brett.t.logan@...>
 

Hi Ethan,
 
You can check out a pull request we had recently around this same request with regard to supporting arm64 which has a lot of information and feedback from the Fabric maintainers: https://github.com/hyperledger/fabric/pull/1086
 
 
The gist of it is, there haven't been a lot of requests for this, and there is more than just providing the images and binaries. In particular, project contributors and maintainers have to commit to fixing any code that may not work on MIPS. Just publishing the images and binaries isn't enough, without a strong commitment from contributors who have a history of contributing to fabric, moving forward with this request is difficult. Providing official artifacts and support for maintaining the code on MIPS is a much much larger undertaking than most realize.
 
That being said, major requests like this go through an RFC process that is documented here: https://github.com/hyperledger/fabric-rfcs
 
Brett Logan
Software Engineer, IBM Blockchain
Phone: 1-984-242-6890
 
 
 

----- Original message -----
From: "胡 银松" <huyinsong@...>
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] Fabric support on MIPS 64 based architecture
Date: Tue, Jun 23, 2020 10:57 PM
 
Hi all,
    I am Ethan. 
    Recently I was working on a MIPS-64 based system. The operation system is Debian like os which runs on MIPS-64 based virtual machine. I am going to run fabric on this virtual machine. For now fabric could run on x86 based system. I wonder if there are fabric versions which could run on MIPS-64 based system? And if no, Is there a plan to support this?
 
 


Fabric support on MIPS 64 based architecture

胡 银松
 

Hi all,
    I am Ethan. 
    Recently I was working on a MIPS-64 based system. The operation system is Debian like os which runs on MIPS-64 based virtual machine. I am going to run fabric on this virtual machine. For now fabric could run on x86 based system. I wonder if there are fabric versions which could run on MIPS-64 based system? And if no, Is there a plan to support this?


Re: Chaincode as an external service

Brian Behlendorf <bbehlendorf@...>
 

I just wanted to say, this thread is such a stellar example of Doing Open Source Right - a clear explanation of an issue & decision needing to be made, followed by a call for volunteers, followed by those who were interested in this committing to work together to complete the work. Kudos to everyone!

Brian

On 6/22/20 6:57 PM, Xiang Dong Hu wrote:
Hello David,
 
We are also trying to leverage the chaincode as an external service feature since it brings new possibility of deployment model for chaincode...
I'm also interested in contributing to this feature including integration test.
 
----- Original message -----
From: "David Enyeart" <enyeart@...>
Sent by: fabric@...
To: fabric <fabric@...>
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] Chaincode as an external service
Date: Mon, Jun 22, 2020 5:28 PM
 

As many of you know, Fabric v2.0 introduced external builders and launchers for chaincode: https://hyperledger-fabric.readthedocs.io/en/latest/cc_launcher.html.
This feature is seeing adoption from people that don't want to rely on the elevated peer privileges required to build and launch chaincode using the Docker daemon. It is well tested in Fabric CI and maintained as a first class Fabric feature.

A related feature called Chaincode as an external service ( https://hyperledger-fabric.readthedocs.io/en/latest/cc_service.html ) was also introduced and allowed for running chaincode as an external service (perhaps as a clustered service), where the peer simply connects to an existing chaincode service rather than building and launching it. This feature has not seen as much traction - the integration test was not completed in the automated CI test suite and the original contributors have largely moved on to other work outside Fabric and are not using it. This begs the question of what to do with the Chaincode as an external service feature going forward. Let me ask a few questions to the community to start a dialog on the topic...

- Has anybody started to adopt the Chaincode as an external service deployment model?
- Would anybody be interested in helping to complete the integration test and maintain the feature going forward?

In general, features that are not adopted or maintained may get deprecated and eventually removed from the project. Obviously this is not a desired outcome for a new feature, therefore please respond if you are interested in the feature and able to help.

Finally, it is worth highlighting the general operating policy that new features must include unit and integration test automated CI coverage before becoming available in a release. This feature made it into v2.0 since the integration tests were in progress and it looked like they would be completed prior to the v2.0 release date. That didn't happen and still hasn't happened however. In the future I think we as maintainers need to be more rigorous about enforcing the test coverage policies, and removing features before a release if needed, to avoid having such features in limbo.


Dave Enyeart

 


-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf


Re: Chaincode as an external service

Xiang Dong Hu <huxd@...>
 

Hello David,
 
We are also trying to leverage the chaincode as an external service feature since it brings new possibility of deployment model for chaincode...
I'm also interested in contributing to this feature including integration test.
 

----- Original message -----
From: "David Enyeart" <enyeart@...>
Sent by: fabric@...
To: fabric <fabric@...>
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] Chaincode as an external service
Date: Mon, Jun 22, 2020 5:28 PM
 

As many of you know, Fabric v2.0 introduced external builders and launchers for chaincode: https://hyperledger-fabric.readthedocs.io/en/latest/cc_launcher.html.
This feature is seeing adoption from people that don't want to rely on the elevated peer privileges required to build and launch chaincode using the Docker daemon. It is well tested in Fabric CI and maintained as a first class Fabric feature.

A related feature called Chaincode as an external service ( https://hyperledger-fabric.readthedocs.io/en/latest/cc_service.html ) was also introduced and allowed for running chaincode as an external service (perhaps as a clustered service), where the peer simply connects to an existing chaincode service rather than building and launching it. This feature has not seen as much traction - the integration test was not completed in the automated CI test suite and the original contributors have largely moved on to other work outside Fabric and are not using it. This begs the question of what to do with the Chaincode as an external service feature going forward. Let me ask a few questions to the community to start a dialog on the topic...

- Has anybody started to adopt the Chaincode as an external service deployment model?
- Would anybody be interested in helping to complete the integration test and maintain the feature going forward?

In general, features that are not adopted or maintained may get deprecated and eventually removed from the project. Obviously this is not a desired outcome for a new feature, therefore please respond if you are interested in the feature and able to help.

Finally, it is worth highlighting the general operating policy that new features must include unit and integration test automated CI coverage before becoming available in a release. This feature made it into v2.0 since the integration tests were in progress and it looked like they would be completed prior to the v2.0 release date. That didn't happen and still hasn't happened however. In the future I think we as maintainers need to be more rigorous about enforcing the test coverage policies, and removing features before a release if needed, to avoid having such features in limbo.


Dave Enyeart

 


Re: Chaincode as an external service

David Enyeart
 

Thank you Pancham and Taku for offering to help with the integration test. Sounds like there is interest to keep the feature moving forward. I've sent you both a note with some additional background to get the ball rolling.


Dave Enyeart

taku.shimosawa---06/22/2020 06:08:34 PM---Hello, We started to try the chaincode server feature because we consider the server model is

From: taku.shimosawa@...
To: fabric <fabric@...>
Date: 06/22/2020 06:08 PM
Subject: [EXTERNAL] Re: [EXT] [Hyperledger Fabric] Chaincode as an external service
Sent by: fabric@...





Hello,

We started to try the chaincode server feature because we consider the server model is
more suitable when HLF is used with Kubernetes.
I recently contributed to the implementation of the feature in node.js chaincode,
and also am interested in the contribution to the integration tests.

Regards,
Taku Shimosawa

From: fabric@... <fabric@...> On Behalf Of David Enyeart
Sent:
Monday, June 22, 2020 2:28 AM
To:
fabric <fabric@...>
Subject:
[EXT] [Hyperledger Fabric] Chaincode as an external service

As many of you know, Fabric v2.0 introduced external builders and launchers for chaincode: https://hyperledger-fabric.readthedocs.io/en/latest/cc_launcher.html.
This feature is seeing adoption from people that don't want to rely on the elevated peer privileges required to build and launch chaincode using the Docker daemon. It is well tested in Fabric CI and maintained as a first class Fabric feature.

A related feature called Chaincode as an external service ( https://hyperledger-fabric.readthedocs.io/en/latest/cc_service.html ) was also introduced and allowed for running chaincode as an external service (perhaps as a clustered service), where the peer simply connects to an existing chaincode service rather than building and launching it. This feature has not seen as much traction - the integration test was not completed in the automated CI test suite and the original contributors have largely moved on to other work outside Fabric and are not using it. This begs the question of what to do with the Chaincode as an external service feature going forward. Let me ask a few questions to the community to start a dialog on the topic...

- Has anybody started to adopt the Chaincode as an external service deployment model?
- Would anybody be interested in helping to complete the integration test and maintain the feature going forward?

In general, features that are not adopted or maintained may get deprecated and eventually removed from the project. Obviously this is not a desired outcome for a new feature, therefore please respond if you are interested in the feature and able to help.

Finally, it is worth highlighting the general operating policy that new features must include unit and integration test automated CI coverage before becoming available in a release. This feature made it into v2.0 since the integration tests were in progress and it looked like they would be completed prior to the v2.0 release date. That didn't happen and still hasn't happened however. In the future I think we as maintainers need to be more rigorous about enforcing the test coverage policies, and removing features before a release if needed, to avoid having such features in limbo.


Dave Enyeart





Re: [EXT] [Hyperledger Fabric] Chaincode as an external service

taku.shimosawa@...
 

Hello,

 

We started to try the chaincode server feature because we consider the server model is

more suitable when HLF is used with Kubernetes.

I recently contributed to the implementation of the feature in node.js chaincode,

and also am interested in the contribution to the integration tests.

 

Regards,

Taku Shimosawa

 

From: fabric@... <fabric@...> On Behalf Of David Enyeart
Sent: Monday, June 22, 2020 2:28 AM
To: fabric <fabric@...>
Subject: [EXT] [Hyperledger Fabric] Chaincode as an external service

 

As many of you know, Fabric v2.0 introduced external builders and launchers for chaincode: https://hyperledger-fabric.readthedocs.io/en/latest/cc_launcher.html.
This feature is seeing adoption from people that don't want to rely on the elevated peer privileges required to build and launch chaincode using the Docker daemon. It is well tested in Fabric CI and maintained as a first class Fabric feature.

A related feature called Chaincode as an external service ( https://hyperledger-fabric.readthedocs.io/en/latest/cc_service.html ) was also introduced and allowed for running chaincode as an external service (perhaps as a clustered service), where the peer simply connects to an existing chaincode service rather than building and launching it. This feature has not seen as much traction - the integration test was not completed in the automated CI test suite and the original contributors have largely moved on to other work outside Fabric and are not using it. This begs the question of what to do with the Chaincode as an external service feature going forward. Let me ask a few questions to the community to start a dialog on the topic...

- Has anybody started to adopt the Chaincode as an external service deployment model?
- Would anybody be interested in helping to complete the integration test and maintain the feature going forward?

In general, features that are not adopted or maintained may get deprecated and eventually removed from the project. Obviously this is not a desired outcome for a new feature, therefore please respond if you are interested in the feature and able to help.

Finally, it is worth highlighting the general operating policy that new features must include unit and integration test automated CI coverage before becoming available in a release. This feature made it into v2.0 since the integration tests were in progress and it looked like they would be completed prior to the v2.0 release date. That didn't happen and still hasn't happened however. In the future I think we as maintainers need to be more rigorous about enforcing the test coverage policies, and removing features before a release if needed, to avoid having such features in limbo.


Dave Enyeart

 


Re: Chaincode as an external service

Pancham Singh <pksingh8878@...>
 

I had started to play with this feature sometime back and had a brief chat with you on this topic at Hyperledger conference in Phoenix earlier this year.

I am interested in completing the integration tests and maintaining this feature.

Pancham


On Mon, Jun 22, 2020 at 4:28 AM David Enyeart <enyeart@...> wrote:

As many of you know, Fabric v2.0 introduced external builders and launchers for chaincode: https://hyperledger-fabric.readthedocs.io/en/latest/cc_launcher.html.
This feature is seeing adoption from people that don't want to rely on the elevated peer privileges required to build and launch chaincode using the Docker daemon. It is well tested in Fabric CI and maintained as a first class Fabric feature.

A related feature called Chaincode as an external service ( https://hyperledger-fabric.readthedocs.io/en/latest/cc_service.html ) was also introduced and allowed for running chaincode as an external service (perhaps as a clustered service), where the peer simply connects to an existing chaincode service rather than building and launching it. This feature has not seen as much traction - the integration test was not completed in the automated CI test suite and the original contributors have largely moved on to other work outside Fabric and are not using it. This begs the question of what to do with the Chaincode as an external service feature going forward. Let me ask a few questions to the community to start a dialog on the topic...

- Has anybody started to adopt the Chaincode as an external service deployment model?
- Would anybody be interested in helping to complete the integration test and maintain the feature going forward?

In general, features that are not adopted or maintained may get deprecated and eventually removed from the project. Obviously this is not a desired outcome for a new feature, therefore please respond if you are interested in the feature and able to help.

Finally, it is worth highlighting the general operating policy that new features must include unit and integration test automated CI coverage before becoming available in a release. This feature made it into v2.0 since the integration tests were in progress and it looked like they would be completed prior to the v2.0 release date. That didn't happen and still hasn't happened however. In the future I think we as maintainers need to be more rigorous about enforcing the test coverage policies, and removing features before a release if needed, to avoid having such features in limbo.


Dave Enyeart


Chaincode as an external service

David Enyeart
 

As many of you know, Fabric v2.0 introduced external builders and launchers for chaincode: https://hyperledger-fabric.readthedocs.io/en/latest/cc_launcher.html.
This feature is seeing adoption from people that don't want to rely on the elevated peer privileges required to build and launch chaincode using the Docker daemon. It is well tested in Fabric CI and maintained as a first class Fabric feature.

A related feature called Chaincode as an external service ( https://hyperledger-fabric.readthedocs.io/en/latest/cc_service.html ) was also introduced and allowed for running chaincode as an external service (perhaps as a clustered service), where the peer simply connects to an existing chaincode service rather than building and launching it. This feature has not seen as much traction - the integration test was not completed in the automated CI test suite and the original contributors have largely moved on to other work outside Fabric and are not using it. This begs the question of what to do with the Chaincode as an external service feature going forward. Let me ask a few questions to the community to start a dialog on the topic...

- Has anybody started to adopt the Chaincode as an external service deployment model?
- Would anybody be interested in helping to complete the integration test and maintain the feature going forward?

In general, features that are not adopted or maintained may get deprecated and eventually removed from the project. Obviously this is not a desired outcome for a new feature, therefore please respond if you are interested in the feature and able to help.

Finally, it is worth highlighting the general operating policy that new features must include unit and integration test automated CI coverage before becoming available in a release. This feature made it into v2.0 since the integration tests were in progress and it looked like they would be completed prior to the v2.0 release date. That didn't happen and still hasn't happened however. In the future I think we as maintainers need to be more rigorous about enforcing the test coverage policies, and removing features before a release if needed, to avoid having such features in limbo.


Dave Enyeart


Next Hyperledger Fabric Application Developer Community call -- this Thursday 25th June @ 3pm UTC time: 4pm UK, 11am ET, 8am PT

Paul O'Mahoney <mahoney@...>
 

dear Fabric Application Developer,


the next  Fabric Application Developer community call is: Thursday 25th June - 3pm UTC,  4pm UK time (+1), 11am ET (-5 hrs), 8am PT (-8 hrs)  - other time zones here.   It lasts approx 30-60 mins FYI.

The agenda will be posted here -> https://wiki.hyperledger.org/display/fabric/Agendas%3A+Fabric+Application+Developer+Community+Call+Meetings  

This community call is held bi-weekly via Zoom webconference and is aimed at :

- helping the worldwide Hyperledger Fabric Application Developer community grow (eg. developing applications, smart contracts, client apps using the SDKs, tutorials/demos etc -  eg using NodeJS/TypeScript, Java, Go etc etc) 
- helping app developers understand / hear more about exciting new things in Fabric, eg. features upcoming or work in progress - ie things that appeal to the developer
- foster more interest, best practices etc in developing applications (eg developing solutions, use cases) with Hyperledger Fabric. 
- opportunity to ask questions of the Fabric team eg. you may have feedback/questions on your experiences developing solutions with Fabric
- to share stuff you've done with the community, eg sample code / sample use cases that others may be interested in

If you wish to share content on a call, just let me know via email direct or DM me on Rocketchat (ID: mahoney1) and I'll put an item on the agenda. Provide the following:
- the topic (state whether its presentation, or demo etc)
- the full name of the presenter, and 
- approx length of your pitch in minutes


The Zoom webconference ID is https://zoom.us/my/hyperledger.community   

More information can be found on the community page -> https://wiki.hyperledger.org/display/fabric/Fabric+Application+Developer+Community+Calls

You can get calendar invites (eg iCal) here

many thanks for your time - feel free to forward this email if you think it is of interest to a colleague.

Paul O'Mahony
Community Lead - Hyperledger Fabric Developer Community
RocketChat:  mahoney1

mahoney@...


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


Re: Inconsistent Private Data Collection Write operation

David Enyeart
 

Thanks Adhav, I think you've assessed correctly. If the client gets two endorsements back it may randomly pick one of the responses to submit and apply both peer endorser signatures. In this case one of endorsed results is different and therefore one of the signatures won't match the results. Upon validation on each peer, the non-matching signature gets thrown out with warning "signature for identity 1 is invalid: The signature is invalid". Half the time org1 endorsement results will be passed, and half the time org2 endorsement results will be passed, hence the inconsistency. A well behaving client should detect the different endorsed results before submitting the transaction to orderer, so that it fails early rather than failing at validation time. I *think* Fabric Network can do that comparison, at least, it should be an option if not already.

As for the questions...

Question 1: I tried this field with both (true/false) value, giving the same result and it is expected. If anyone is able to read PDC then it beat the purpose of having private data. What is the purpose of having this field- "MemberReadOnly"?
                    If we make it false, do other members of org can read data? Does this field relate to signature policy?


Answer 1: PDC specifies which org PEERS are able to persist the private data, and request it from other peers if needed. The access control for CLIENTS may or may not align with that definition. Here's how the documentation explains MemberOnlyRead:
"a value of true indicates that peers automatically enforce that only clients belonging to one of the collection member organizations are allowed read access to private data. If a client from a non-member org attempts to execute a chaincode function that performs a read of a private data key, the chaincode invocation is terminated with an error. Utilize a value of false if you would like to encode more granular access control within individual chaincode functions."


Question2: If transactions require only one endorsement, does SDK(Fabric Network) send tx to all endorsing peers or only one?

Answer 2: With service discovery you can pass in a collection name, and it will return the minimum set of peers required to get an endorsement (one of either org's peers in this scenario). For using Fabric Network Node.js SDK with service discovery, see https://hyperledger.github.io/fabric-sdk-node/master/tutorial-discovery-fabric-network.html. I suspect in this scenario the collection name was not passed correctly to service discovery.


Question 3: If the client gets both endorsements (One is correct and one is wrong(peer from org2 could not read data)) from endorsing peer and client send tx(Having both endorsement response from both peer) to orderer and orderer to committing peer.                         Does Committing peer check only one endorsement or both?

Answer 3: As stated at the top, only one result is submitted, and both signatures are applied. If the endorsing peers signed over different data, then the signature that doesn't match gets thrown out as invalid. This leaves only one endorsement to be evaluated against the endorsement policy. In this scenario, the 'right' endorsement was being provided half the time.


Dave Enyeart