Date   

Re: Hyperledger Fabric GitHub Migration

Christopher Ferris
 

Nice work! Thanks. Hopefully, this will make it easier for people to contribute - using the more familiar Github workflow.

Chris

On Nov 21, 2019, at 1:10 AM, Brett T Logan <Brett.T.Logan@...> wrote:


Hello Contributors,
 
The time has finally come. The Hyperledger Fabric maintainers are planning for a migration of the core Fabric repository to GitHub this Friday morning Eastern Standard Time.
 
We are asking that effective immediately, all contributors stop pushing changes to Gerrit. Instead contributors can open their changes as pull requests using the Hyperledger Fabric repository in Github https://github.com/hyperledger/fabric. We have already configured CI to run against new pull requests using Azure Pipelines. This will allow the maintainers time merge as many Gerrit CR's as they can before the cutover.
 
Any changes that don't make it in before the Friday cutover will be abandoned and contributors will need to reopen them in GitHub. If you feel it's unlikely your change will make it in by Friday morning, we ask that you move it to GitHub now, and close your CR so maintainers can focus on changes that will get merged in the next day.
 
We will be publishing updated documentation about best practices, but in the meantime a few reminders about GitHub contributions:
  • Commits should be focused and small
  • Commit messages should include the Jira number on their first line and the body should include meaningful information on the change
  • Your signature must be included in your commit message, you can do this using the "-s" flag when running the "git commit" command
  • When opening a pull request it must come from your fork of the Fabric repository
  • When opening the pull request, your pull request message should include a meaningful title and provide the reasoning around the change, this will help maintainers understand what you are attempting to achieve (we will be publishing an automatic template yet this week, once that happens you should fill out the template accordingly)
With this migration, Hyperledger will have migrated all of its development repositories off of Gerrit and Jenkins. Contributions are welcome to any of the Hyperledger projects through GitHub moving forward. It is our hope that by adopting this industry standard we can lower the barrier of entry for new contributors and attract even more of the community to participate in contributing.
 
As always, thank you for your contributions!
 
Brett Logan
Software Engineer, IBM Blockchain
Phone: 1-984-242-6890
 
<Image.15743153835240.png>


Hyperledger Fabric GitHub Migration

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

Hello Contributors,
 
The time has finally come. The Hyperledger Fabric maintainers are planning for a migration of the core Fabric repository to GitHub this Friday morning Eastern Standard Time.
 
We are asking that effective immediately, all contributors stop pushing changes to Gerrit. Instead contributors can open their changes as pull requests using the Hyperledger Fabric repository in Github https://github.com/hyperledger/fabric. We have already configured CI to run against new pull requests using Azure Pipelines. This will allow the maintainers time merge as many Gerrit CR's as they can before the cutover.
 
Any changes that don't make it in before the Friday cutover will be abandoned and contributors will need to reopen them in GitHub. If you feel it's unlikely your change will make it in by Friday morning, we ask that you move it to GitHub now, and close your CR so maintainers can focus on changes that will get merged in the next day.
 
We will be publishing updated documentation about best practices, but in the meantime a few reminders about GitHub contributions:
  • Commits should be focused and small
  • Commit messages should include the Jira number on their first line and the body should include meaningful information on the change
  • Your signature must be included in your commit message, you can do this using the "-s" flag when running the "git commit" command
  • When opening a pull request it must come from your fork of the Fabric repository
  • When opening the pull request, your pull request message should include a meaningful title and provide the reasoning around the change, this will help maintainers understand what you are attempting to achieve (we will be publishing an automatic template yet this week, once that happens you should fill out the template accordingly)
With this migration, Hyperledger will have migrated all of its development repositories off of Gerrit and Jenkins. Contributions are welcome to any of the Hyperledger projects through GitHub moving forward. It is our hope that by adopting this industry standard we can lower the barrier of entry for new contributors and attract even more of the community to participate in contributing.
 
As always, thank you for your contributions!
 
Brett Logan
Software Engineer, IBM Blockchain
Phone: 1-984-242-6890
 


Re: Error while migrating from kafka to RAFT

Jason Yellick <jyellick@...>
 

You need to sign and submit with the OrdererMSP admin identity to change consensus type parameters, not the application/peer org admins.

Thanks,
~Jason
 

----- Original message -----
From: "Adhav Pavan" <adhavpavan@...>
Sent by: fabric@...
To: fabric@...
Cc: saurabh@...
Subject: [EXTERNAL] [Hyperledger Fabric] Error while migrating from kafka to RAFT
Date: Wed, Nov 20, 2019 11:48 PM
 
Hello Team,
 
I am migrating from kafka to raft, When I have changed state from "NORMAL" to "STATE_MAINTENANCE"  and created the final expected envelope as per the procedure.
 
Note: We are using BYFN script
 
My CLI pointed to Org1MSP, I signed config update transaction, later I changed CLI pointing to Org2MSP and signed, finally submitted the new channel config update to the orderer.
After submission, getting a following error message.
 
Error on CLI: "Error: got unexpected status: BAD_REQUEST -- error applying config update to existing channel 'mychannel': error authorizing update: error validating DeltaSet: policy for [Value]  /Channel/Orderer/ConsensusType not satisfied: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Admins' sub-policies to be satisfied"
 
Orderer log: "[channel: mychannel] Rejecting broadcast of config message from 172.21.0.13:51078 because of error: error applying config update to existing channel 'mychannel': error authorizing update: error validating DeltaSet: policy for [Value]  /Channel/Orderer/ConsensusType not satisfied: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Admins' sub-policies to be satisfied"
 
Please let me know if I am doing something wrong.
 
Thanks in advance.
 

Heartfelt Regards,
Pavan Adhav

Blockchain Developer
Cell Phone:
+91-8390114357  E-Mail: adhavpavan@...
 

 


To install chaincode, do you use source code or packaged cds file?

Yueming Xu
 

When you use `peer chaincode install` to install chaincode from source code, it automatically package it as cds format and upload it to a peer node. But how would you install a cds file if you already packaged the code into cds format and got it signed by multiple orgs? Do you simply copy the signed cds file to the peer node using `kubectl cp` or `docker cp`? Guess that is why release 2.0 made improvement on this, but not sure if I misunderstood.


Error while migrating from kafka to RAFT

Adhav Pavan
 

Hello Team,

I am migrating from kafka to raft, When I have changed state from "NORMAL" to "STATE_MAINTENANCE"  and created the final expected envelope as per the procedure.

Note: We are using BYFN script

My CLI pointed to Org1MSP, I signed config update transaction, later I changed CLI pointing to Org2MSP and signed, finally submitted the new channel config update to the orderer.
After submission, getting a following error message.

Error on CLI: "Error: got unexpected status: BAD_REQUEST -- error applying config update to existing channel 'mychannel': error authorizing update: error validating DeltaSet: policy for [Value]  /Channel/Orderer/ConsensusType not satisfied: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Admins' sub-policies to be satisfied"

Orderer log: "[channel: mychannel] Rejecting broadcast of config message from 172.21.0.13:51078 because of error: error applying config update to existing channel 'mychannel': error authorizing update: error validating DeltaSet: policy for [Value]  /Channel/Orderer/ConsensusType not satisfied: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Admins' sub-policies to be satisfied"

Please let me know if I am doing something wrong.

Thanks in advance.

Heartfelt Regards,
Pavan Adhav

Blockchain Developer
Cell Phone:
+91-8390114357  E-Mail: adhavpavan@...


Re: Does Raft orderer work across multiple Kubernetes clusters?

Yueming Xu
 

@Alexandre Pauwels: could you please point me to some references about where to get started to make RAFT work using coredns?  Thanks.


Re: How to add new orderer? #fabric-ca #raft

leixianting@...
 

We have the same question, anyone can help us??


How to add new orderer? #fabric-ca #raft

pwong00710@...
 

We are using fabric server to generate certs and use raft.  Is there any reference to add new orderers?


Re: Does Raft orderer work across multiple Kubernetes clusters?

Jay Guo
 

Nye,

It would be nice if you could share some technical details of k8s that harm p2p network. I believe it could benefit both communities (HL and CNCF)

cheers,
- J

On Tue, Nov 19, 2019 at 3:35 PM Nye Liu <nye@...> wrote:
Not to stray too far off topic, but k8s emerged from a client/server microservices/stack deployment requirement, not a p2p requirement.

Its popularity for that purpose has (unfortunately, IMO) bled into places it isn’t really appropriate for because there are more fullstack devs than p2p devs.

Just my 2 cents, I know it is an unpopular opinion.

On Nov 19, 2019, at 2:31 PM, Hakan Eryargi <hakan.eryargi@...> wrote:

I guess K8S is the preferred way to deploy many things not only Fabric ;) and we will go production in a few months with Fabric in K8S.

We are not mixing K8S clusters for now, as it's not a requirement ATM, but will eventually be the case, mixing K8S with other K8S or on premises or whatever. That time possibly my preferred way of doing it will be using hostAliases to point to other nodes.  

Check Raft orderer section in our repo for how we do it:
https://github.com/APGGroeiFabriek/PIVT#scaled-up-raft-network  

On Tue, Nov 19, 2019 at 11:23 PM Yueming Xu <yxucolo@...> wrote:
So, in the case of a network across 2 k8s clusters, I have to make all orderer nodes accessible outside of k8s, and put the public host names and ports in the genesis block.  Correct?  K8s is still a preferred way to deploy the fabric network as I can see it, so such scenario will occur in production.  Thanks.




Re: Extremely strange behavior with Fabric - modifying ledger out of band

David Enyeart
 

To rebuild peer's state database:
stop peer, drop state database, restart peer. State database will automatically be rebuilt from the blockchain.

To rebuild peer's channel blockchains and state database:
stop peer, drop state database, use "peer node reset" to reset channels to genesis blocks, restart peer. Peer will automatically re-pull and re-process blocks.

Peer log will indicate rebuild progress.


Dave Enyeart

"Siddharth Jain" ---11/19/2019 02:03:45 PM---Thanks for the reply. also adding another link to this thread about same question: https://urldefens

From: "Siddharth Jain" <siddjain@...>
To: fabric@...
Date: 11/19/2019 02:03 PM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Extremely strange behavior with Fabric - modifying ledger out of band
Sent by: fabric@...





Thanks for the reply. also adding another link to this thread about same question: https://stackoverflow.com/questions/49934312/how-your-data-is-safe-in-hyperledger-fabric-when-one-can-make-changes-to-couchdb

How do we rebuild the state database? we tried to drop the database (mychannel_test) (screenshot below)
https://imagebin.ca/v/52UG2V44kOFz
and restart the network but that does not rebuild the database. It is completely lost.





Re: Does Raft orderer work across multiple Kubernetes clusters?

Nye Liu <nye@...>
 

Not to stray too far off topic, but k8s emerged from a client/server microservices/stack deployment requirement, not a p2p requirement.

Its popularity for that purpose has (unfortunately, IMO) bled into places it isn’t really appropriate for because there are more fullstack devs than p2p devs.

Just my 2 cents, I know it is an unpopular opinion.

On Nov 19, 2019, at 2:31 PM, Hakan Eryargi <hakan.eryargi@...> wrote:

I guess K8S is the preferred way to deploy many things not only Fabric ;) and we will go production in a few months with Fabric in K8S.

We are not mixing K8S clusters for now, as it's not a requirement ATM, but will eventually be the case, mixing K8S with other K8S or on premises or whatever. That time possibly my preferred way of doing it will be using hostAliases to point to other nodes.  

Check Raft orderer section in our repo for how we do it:
https://github.com/APGGroeiFabriek/PIVT#scaled-up-raft-network  

On Tue, Nov 19, 2019 at 11:23 PM Yueming Xu <yxucolo@...> wrote:
So, in the case of a network across 2 k8s clusters, I have to make all orderer nodes accessible outside of k8s, and put the public host names and ports in the genesis block.  Correct?  K8s is still a preferred way to deploy the fabric network as I can see it, so such scenario will occur in production.  Thanks.




Re: Interested in adding csharp support - guidelines needed

Srinivasan Muralidharan
 

To add a bit more to Brian's note...

If you target upcoming 2.0 (and that'd be my advice) you lessen fabric side changes considerably thanks to the "external" builder framework. So good to get started on the shim side using the Java chaincode repo for guidance as suggested by Brian and not worry too much about the fabric side for now. I can provide some help if you like ("muralisr" on Rocket Chat).

Murali

On Tue, Nov 19, 2019 at 2:40 PM Segments via Lists.Hyperledger.Org <Segments777=protonmail.com@...> wrote:
Many thanks Brian, this is helpful and very much appreciated!


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, November 19, 2019 6:56 PM, Brian Behlendorf <bbehlendorf@...> wrote:

Modest insights ahead, and IANAM (I am not a maintainer):

Both seem like non-trivial lifts, so be sure that you really need each of them.  There is emerging and improving support for the Microsoft developer tools ecosystem with Fabric, including a Visual Studio plugin, if that's all you need:


For a C# SDK, there is likely no better approach than taking an SDK in a language you are most familiar - be it Python or Java or Node - and looking at how they work.  The GRPC protos are documented here for 1.4:


and here for the current branch, what will end up in 2.0:


For C# Chaincode support, it may be best to start with the Java chaincode repo:


which looks like it contains some good high level explanation on how it integrates.

Hope this helps,

Brian

On 11/19/19 2:10 AM, Segments via Lists.Hyperledger.Org wrote:
Can anyone help? Even modest insights would be appreciated.
Thanks


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, November 12, 2019 8:43 AM, Segments <Segments777@...> wrote:

Hello,

I am interested in adding csharp support to Fabric and bringing it on par with Java or even Go support. I want to add chaincode support and client.

Could someone please help me find my way and provide me a high-level list of what I'll need to do and where I'll need to look into. I do not have much experience with Fabric but I've read the docs extensively so I am familiar with the concepts. I also have a basic background in blockchain programming.

This undertaking (which is a prerequisite for us to be able to work with Fabric), will also allow me to get familiar with it in depth in a productive way.

Thank you,

Segments


Sent with ProtonMail Secure Email.



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



--
Thanks,
Murali
"Practice is a means of inviting the perfection desired." - Martha Graham
“We ran and ran. We were exhausted, but we kept running.” - Homare Sawa after winning 2011 Women's Soccer world cup


Re: Does Raft orderer work across multiple Kubernetes clusters?

Hakan Eryargi
 

I guess K8S is the preferred way to deploy many things not only Fabric ;) and we will go production in a few months with Fabric in K8S.

We are not mixing K8S clusters for now, as it's not a requirement ATM, but will eventually be the case, mixing K8S with other K8S or on premises or whatever. That time possibly my preferred way of doing it will be using hostAliases to point to other nodes.  

Check Raft orderer section in our repo for how we do it:
https://github.com/APGGroeiFabriek/PIVT#scaled-up-raft-network  


On Tue, Nov 19, 2019 at 11:23 PM Yueming Xu <yxucolo@...> wrote:
So, in the case of a network across 2 k8s clusters, I have to make all orderer nodes accessible outside of k8s, and put the public host names and ports in the genesis block.  Correct?  K8s is still a preferred way to deploy the fabric network as I can see it, so such scenario will occur in production.  Thanks.


Re: Does Raft orderer work across multiple Kubernetes clusters?

Alexandre Pauwels
 

I've said it before on this mailing list and I guess I'll say it again, I don't understand this hate with k8s and Fabric.

Using nginx and coredns you can achieve nearly any sort of routing combination you want. The ONLY port that needs to be exposed to the outside world is 443, any endpoint on any internal pod can be defined as a subdomain and routed to the correct pod internally using clusterIP services. CoreDNS rewrites are leveraged to avoid hairpinning traffic (which I don't see as hack...it's just using DNS for what it was meant to do, interpreting a hostname and routing it to the appropriate IP, no more no less).

To answer the original question: yes, RAFT orderers on multiple clusters absolutely CAN communicate with each other AND identify each other using TLS certificate pinning, and without exposing anything other than the default port 443. Select an ingress which supports TLS passthrough/L4 routing (nginx supports this just fine). Enable passthrough on your ingress resource. Define your ingress to route a particular subdomain to a specific port on your orderer's service.

I think putting down leveraging k8s to host Fabric is harmful to Fabric adoption as a whole. K8s is an apt host of Fabric services.

Alex

On Tue, Nov 19, 2019, 17:08 Nye Liu <nye@...> wrote:
This is precisely why k8s and p2p are never a good match. K8s simply breaks far too many networking rfcs. It is suitable for asymmetric client/server microservices or stacks, and even then a tiny subset of networking protocols.

On Tue, Nov 19, 2019, 1:47 PM Yueming Xu <yxucolo@...> wrote:
If I have 2 orgs contributing orderer nodes using etcd raft consensus, and each org runs its nodes in its own Kubernetes cluster.  How can I make Raft work across these 2 orgs? I guess that every orderer node will have to make some ports open to outside of its K8s cluster via e.g., ELB, but I am not sure which port and whether all orderer nodes must be open to public.  Is there a concept like the anchor peer, where each org need to make only the anchor peer open to external world?

Or, should I simply make all orderer nodes live in the same Kubernetes cluster as a best practice?  Thanks.



Re: Does Raft orderer work across multiple Kubernetes clusters?

Yueming Xu
 

So, in the case of a network across 2 k8s clusters, I have to make all orderer nodes accessible outside of k8s, and put the public host names and ports in the genesis block.  Correct?  K8s is still a preferred way to deploy the fabric network as I can see it, so such scenario will occur in production.  Thanks.


Re: Does Raft orderer work across multiple Kubernetes clusters?

Nye Liu <nye@...>
 

This is precisely why k8s and p2p are never a good match. K8s simply breaks far too many networking rfcs. It is suitable for asymmetric client/server microservices or stacks, and even then a tiny subset of networking protocols.


On Tue, Nov 19, 2019, 1:47 PM Yueming Xu <yxucolo@...> wrote:
If I have 2 orgs contributing orderer nodes using etcd raft consensus, and each org runs its nodes in its own Kubernetes cluster.  How can I make Raft work across these 2 orgs? I guess that every orderer node will have to make some ports open to outside of its K8s cluster via e.g., ELB, but I am not sure which port and whether all orderer nodes must be open to public.  Is there a concept like the anchor peer, where each org need to make only the anchor peer open to external world?

Or, should I simply make all orderer nodes live in the same Kubernetes cluster as a best practice?  Thanks.



Re: Does Raft orderer work across multiple Kubernetes clusters?

Hakan Eryargi
 

The idea of anchor peer is providing information about other peers in the same organization. There is no need for a peer to be completely public but it should be at least accessible by other peers somehow. VPN, white listing or whatever. If only anchor peer is accessible by outer world/other peers, what is the point of providing information about some peers which are not accessible? ;)

Regarding your question, each Raft orderer node should be access to each other. port is by default 7050 and the host/port is actually defined in configtx.yaml and encoded in the genesis block.

Best,
Hakan

On Tue, Nov 19, 2019 at 10:47 PM Yueming Xu <yxucolo@...> wrote:
If I have 2 orgs contributing orderer nodes using etcd raft consensus, and each org runs its nodes in its own Kubernetes cluster.  How can I make Raft work across these 2 orgs? I guess that every orderer node will have to make some ports open to outside of its K8s cluster via e.g., ELB, but I am not sure which port and whether all orderer nodes must be open to public.  Is there a concept like the anchor peer, where each org need to make only the anchor peer open to external world?

Or, should I simply make all orderer nodes live in the same Kubernetes cluster as a best practice?  Thanks.



Does Raft orderer work across multiple Kubernetes clusters?

Yueming Xu
 

If I have 2 orgs contributing orderer nodes using etcd raft consensus, and each org runs its nodes in its own Kubernetes cluster. How can I make Raft work across these 2 orgs? I guess that every orderer node will have to make some ports open to outside of its K8s cluster via e.g., ELB, but I am not sure which port and whether all orderer nodes must be open to public. Is there a concept like the anchor peer, where each org need to make only the anchor peer open to external world?

Or, should I simply make all orderer nodes live in the same Kubernetes cluster as a best practice? Thanks.


Re: Interested in adding csharp support - guidelines needed

Segments
 

Many thanks Brian, this is helpful and very much appreciated!


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, November 19, 2019 6:56 PM, Brian Behlendorf <bbehlendorf@...> wrote:

Modest insights ahead, and IANAM (I am not a maintainer):

Both seem like non-trivial lifts, so be sure that you really need each of them.  There is emerging and improving support for the Microsoft developer tools ecosystem with Fabric, including a Visual Studio plugin, if that's all you need:


For a C# SDK, there is likely no better approach than taking an SDK in a language you are most familiar - be it Python or Java or Node - and looking at how they work.  The GRPC protos are documented here for 1.4:


and here for the current branch, what will end up in 2.0:


For C# Chaincode support, it may be best to start with the Java chaincode repo:


which looks like it contains some good high level explanation on how it integrates.

Hope this helps,

Brian

On 11/19/19 2:10 AM, Segments via Lists.Hyperledger.Org wrote:
Can anyone help? Even modest insights would be appreciated.
Thanks


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, November 12, 2019 8:43 AM, Segments <Segments777@...> wrote:

Hello,

I am interested in adding csharp support to Fabric and bringing it on par with Java or even Go support. I want to add chaincode support and client.

Could someone please help me find my way and provide me a high-level list of what I'll need to do and where I'll need to look into. I do not have much experience with Fabric but I've read the docs extensively so I am familiar with the concepts. I also have a basic background in blockchain programming.

This undertaking (which is a prerequisite for us to be able to work with Fabric), will also allow me to get familiar with it in depth in a productive way.

Thank you,

Segments


Sent with ProtonMail Secure Email.



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


Re: Extremely strange behavior with Fabric - modifying ledger out of band

Siddharth Jain
 

Thanks for the reply. also adding another link to this thread about same question: https://stackoverflow.com/questions/49934312/how-your-data-is-safe-in-hyperledger-fabric-when-one-can-make-changes-to-couchdb

How do we rebuild the state database? we tried to drop the database (mychannel_test) (screenshot below)
https://imagebin.ca/v/52UG2V44kOFz
and restart the network but that does not rebuild the database. It is completely lost.

4321 - 4340 of 11520