|
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.
toggle quoted message
Show quoted text
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.
|
|||
|
|
|||
|
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:
--
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?
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:
|
|||
|
|
|||
|
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? |
|||
|
|
|||
|
Re: Does Raft orderer work across multiple Kubernetes clusters?
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? |
|||
|
|
|||
|
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:
|
|||
|
|
|||
|
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. |
|||
|
|
|||
|
Re: Interested in adding csharp support - guidelines needed
Brian Behlendorf <bbehlendorf@...>
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:
-- Brian Behlendorf Executive Director, Hyperledger bbehlendorf@... Twitter: @brianbehlendorf |
|||
|
|
|||
|
Re: Interested in adding csharp support - guidelines needed
Segments
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:
|
|||
|
|
|||
|
Re: Java chaincode 1.4.4 failed to submit task for processing
#fabric-questions
#fabric-chaincode
#fabric
Matthew White
FYI issue raised here
https://jira.hyperledger.org/browse/FAB-17110
Regards, Matthew.
Matthew B White IBM Blockchain Solutions Architect
Email me at WHITEMAT@...
Find me on StackOverflow, and generally at calanais.me.uk
Note: restricted availability for meetings 14:30 to 17:00 UK Tuesday
IBM United Kingdom Limited, Hursley Park, Winchester, Hampshire, SO21 2JN
"The wrong answers are the ones you go looking for when the right answers stare you in the face" ----- Original message ----- IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU |
|||
|
|
|||
|
Re: Java chaincode 1.4.4 failed to submit task for processing
#fabric-questions
#fabric-chaincode
#fabric
Matthew White
Hello; could you give me some more info please about how you're sending transactions.
Do you have the chaincode logs for example? Or post to rocketchat #fabric-chaincode-java and we can discuss there.
Regards, Matthew.
Matthew B White IBM Blockchain Solutions Architect
Email me at WHITEMAT@...
Find me on StackOverflow, and generally at calanais.me.uk
Note: restricted availability for meetings 14:30 to 17:00 UK Tuesday
IBM United Kingdom Limited, Hursley Park, Winchester, Hampshire, SO21 2JN
"The wrong answers are the ones you go looking for when the right answers stare you in the face" ----- Original message ----- IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU |
|||
|
|
|||
|
Java chaincode 1.4.4 failed to submit task for processing
#fabric-questions
#fabric-chaincode
#fabric
Mattia Bolzonella
After upgrading to 1.4.4 i receive the following error in my chaincode logs: `
transaction returned with failure: Failed to submit task for processing` I'm sending transactions in a multithread envirorment, it's not supported anymore?I've tested both with Fabric 1.4.3 and 1.4.4 but the result is the same. |
|||
|
|
|||
|
回复: [Hyperledger Fabric] Hyperledger Fabric Vs Composer ACLs
david liu <david-khala@...>
1. It might leak sensitive information of the user inside the certificate
For concern of sensitive information in certificate, you could consider use idemix as a ZKP
2. It is hard to handle the provenance of the attributes, as administrator could add any attributes as he want to an identity
That is why he is admin of his organization.
3. Each time Updating the attributes need to update the Certificate too, so there might be many versions of certificate if we manage to keep it as archive
Instead of rotate the certificate, you could consider upgrade the chaincode who identifies certificate and behaves.
发件人: fabric@... <fabric@...> 代表 Kimheng SOK <sok.kimheng@...>
发送时间: 2019年11月18日 18:13 收件人: Brett T Logan <Brett.T.Logan@...> 抄送: fabric@... <fabric@...> 主题: Re: [Hyperledger Fabric] Hyperledger Fabric Vs Composer ACLs Dear Brett Logan,
Thank for your answer, related to fine-grained access control by adding attributes to identity of the user
I found that:
1. It might leak sensitive information of the user inside the certificate
2. It is hard to handle the provenance of the attributes, as administrator could add any attributes as he want to an identity
3. Each time Updating the attributes need to update the Certificate too, so there might be many versions of certificate if we manage to keep it as archive
What do you think?
Bests,
On Mon, Nov 18, 2019 at 4:53 PM Brett T Logan <Brett.T.Logan@...> wrote:
|
|||
|
|
|||
|
How to update anchor peer after adding a new org to a channel?
Yueming Xu
I followed the tutorial “Adding an Org to a channel”. The new org works, but it does not seem to have an anchor peer defined. How should I update it to include definition of an anchor peer for the new org? Thanks.
|
|||
|
|
|||
|
Re: Extremely strange behavior with Fabric - modifying ledger out of band
David Enyeart
Remember that blockchains are decentralized ledgers. What you've done here is essentially tampered/corrupted your own local peer's state database so that it is not in sync with the blockchain blocks. This would be similar to tampering/corrupting a bitcoin node's chainstate database of unspent transactions. You won't be able to convince other nodes in the network that your data is correct. In fact they will detect the bad data upon the next endorsement request, and choose never to do business with you again, which was why you'd want to join a Fabric network consortium in the first place. see this video: https://youtu.be/KOS5CeP-mNY
the resolution is very poor but it contains the steps to repro the issue. From: David Enyeart <enyeart@...>
Sent: Saturday, November 16, 2019 6:52 AM To: Siddharth Jain <siddjain@...> Cc: fabric@... <fabric@...> Subject: Re: [Hyperledger Fabric] Extremely strange behavior with Fabric - modifying ledger out of band Something else must be going on, since what you've described is not possible. New blocks with validated transactions drive the CouchDB state database updates, never the other way around. Watch the peer log as you make updates and I expect you'll discovery something else going on. Use a logging string when starting peer such as: FABRIC_LOGGING_SPEC=info:kvledger,statecouchdb,couchdb=debug Dave Enyeart  "Siddharth Jain" ---11/15/2019 08:35:29 PM---Summary: we created a simple Fabric network that comes with the IBM Blockchain extension and uses CoFrom: "Siddharth Jain" <siddjain@...> To: "fabric@..." <fabric@...> Date: 11/15/2019 08:35 PM Subject: [EXTERNAL] [Hyperledger Fabric] Extremely strange behavior with Fabric - modifying ledger out of band Sent by: fabric@... Summary: we created a simple Fabric network that comes with the IBM Blockchain extension and uses CouchDB and one peer and one orderer. we made some chaincode invocation requests and created some data in the ledger. Then we made changes to CouchDB records from the CouchDB web based UI (Fauxton) which can be accessed at http://localhost:17055/_utils. Observed: It resulted in new blocks being appended to the ledger! When we re-started the network we could see the block height increased and changes made by Fauxton showed up! Expected: No new blocks should have been appended to the ledger. Fauxton doesn't even know who I am. It doesn't know my X.509 certificate. Who signed the new blocks? How did the changes get endorsed? How did making changes from Fauxton result in generation of a Fabric transaction? This is truly bizarre. Our understanding of Fabric was that the ledger data is stored in blocks under /var/hyperledger/production/ledgersData folder and the couchdb docker container would read these blocks and initialize the couchdb database. A user is not prevented from modifying records using Fauxton but that won't change anything under the /var/hyperledger/production/ledgersData folder which stores the actual blocks. So if the network is re-started, it should not show any out-of-band changes. But that simply did not turn out to be true. Can anyone explain this? e.g., we start with this:  we click on this record which gives  we change createdBy to david and click on save changes button  when we stop and re-start the network the record has been permanently modified and its creator is now david! so anyone can make whatever changes they want to the ledger?!
|
|||
|
|
|||
|
Re: Hyperledger Fabric Vs Composer ACLs
Kimheng SOK
Dear Brett Logan, Thank for your answer, related to fine-grained access control by adding attributes to identity of the user I found that: 1. It might leak sensitive information of the user inside the certificate 2. It is hard to handle the provenance of the attributes, as administrator could add any attributes as he want to an identity 3. Each time Updating the attributes need to update the Certificate too, so there might be many versions of certificate if we manage to keep it as archive What do you think? Bests, On Mon, Nov 18, 2019 at 4:53 PM Brett T Logan <Brett.T.Logan@...> wrote:
|
|||
|
|
|||
|
Re: Wrong world state
#fabric
#fabric-questions
Joao Antunes
Hi Tong, I'll give an update when I reach a conclusion. |
|||
|
|
