Date   

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

David Enyeart
 

You need to drop the entire CouchDB data volume (or /data directory within the volume) to trigger the state database rebuild, not individual databases within the CouchDB instance.


Dave Enyeart

Siddharth Jain ---11/21/2019 10:01:29 PM---see this video where it is shown that dropping the db and restarting the peer does not rebuild the d

From: Siddharth Jain <siddjain@...>
To: David Enyeart <enyeart@...>
Cc: "fabric@..." <fabric@...>
Date: 11/21/2019 10:01 PM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Extremely strange behavior with Fabric - modifying ledger out of band





see this video where it is shown that dropping the db and restarting the peer does not rebuild the db:
https://youtu.be/h0NjZRH9RXE
Rebuilding Fabric State Database
youtu.be



From: David Enyeart <enyeart@...>
Sent:
Tuesday, November 19, 2019 10:32 PM
To:
Siddharth Jain <siddjain@...>
Cc:
fabric@... <fabric@...>
Subject:
Re: [Hyperledger Fabric] Extremely strange behavior with Fabric - modifying ledger out of band

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: How to add new orderer? #fabric-ca #raft

Yueming Xu
 

I got it working, as described in section "add new orderer node" of my project: https://github.com/yxuco/fabric-operation/blob/master/operations.md
You need to update the system channel config with new consenter info (which includes base64 encoding of the new orderer's certificate).  I used the following jq filter to edit the channel config:
cat ${chan}-config.json | jq '.channel_group.values.OrdererAddresses.value.addresses += '"${addrs}"'' | jq '.channel_group.groups.Orderer.values.ConsensusType.value.metadata.consenters += '"${cons}"'' > ${chan}-config-modified.json

The limitation is that you can add only one node at a time, even though in principle, you should be able to add multiple nodes as long as you have more nodes running.  But, at least for the release 1.4.3, it allows me to add only one node in each update.

Besides, you have to use an orderer user to update the channels.  You have to update the system channel first, and then update other application channels separately.


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

Siddharth Jain
 

see this video where it is shown that dropping the db and restarting the peer does not rebuild the db:


From: David Enyeart <enyeart@...>
Sent: Tuesday, November 19, 2019 10:32 PM
To: Siddharth Jain <siddjain@...>
Cc: fabric@... <fabric@...>
Subject: Re: [Hyperledger Fabric] Extremely strange behavior with Fabric - modifying ledger out of band
 

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: Hyperledger Fabric GitHub Migration

Michael Wang
 

That's great news.


On Thu, Nov 21, 2019 at 7:51 PM Christopher Ferris <chris.ferris@...> wrote:
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>



--
This is my life,but world of us~~


Re: #fabric #raft Orderers and organization, how to organize them? #fabric #raft

Joe Alewine <joe.alewine@...>
 

Jean-Gael,
 
Check out https://hyperledger-fabric.readthedocs.io/en/release-1.4/orderer/ordering_service.html. It should have some of the answers to your questions.
 
Regards,
 
Joe Alewine
IBM Blockchain, Raleigh
 
rocket chat: joe-alewine
slack: joe.alewine
 
 
 

----- Original message -----
From: "Jean-Gaël Dominé" <jgdomine@...>
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] #fabric #raft Orderers and organization, how to organize them?
Date: Thu, Nov 21, 2019 10:39 AM
 
Hi all,

This topic is more a conceptual one around orderers and organizations as we are moving from solo mode to Raft.
In solo mode, as we had a single orderer, the organization matter was quite simple :)

But with Raft we were thinking of having 4 orderers. We just have doubts about how they should be structured on an organization level.
In fact, we created two different 2-orderer organizations. One would be linked to peer organization A and the other one to peer organization B.
Thus, A and B have the same number of orderers.
CAs from A and B would respectively be responsible for issuing the certificates/keys of "their" orderers.

Well, that's one way of designing it we had but we really are not sure that is the good practice.

Would anybody have insight on that matter?

Thank you in advance
 


Documentation Workgroup: Agenda for Friday, 22 November

Anthony O'Dowd <a_o-dowd@...>
 

Hello All,

We hold our regular documentation workgroup call this week, both Eastern and Western hemispheres.

As is now usual, you can read the summary minutes for last week's call: https://wiki.hyperledger.org/display/fabric/2019+11+15+DWG+Agenda
and catch up via recordings page: https://wiki.hyperledger.org/display/fabric/Recordings

A particular highlight last week was Pam's walk through of the changes to the MSP concept topic. A very good discussion as well, thanks to Chris and Jim. Review the MSP material: https://gerrit.hyperledger.org/r/c/fabric/+/34174/

Please feel free to read, and contribute to, the agenda for this week: https://wiki.hyperledger.org/display/fabric/2019+11+22+DWG+Agenda

We won't be having a meeting next week as the US celebrate Thanksgiving, so look out for our next meetings on Dec 6!

Best regards,

Anthony, Pam, Joe, Nik

Meeting Details
-------------
Please use the following link to attend the meeting:  https://zoom.us/j/6223336701

The meeting times are as follows: https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group

Meeting 106A: Friday 22 Nov
                   1130 India Standard Time
                   1400 China Standard Time
                   1500 Japan Standard Time
                   1700 Australia Eastern Time
                   1400 Singapore Time
                   1000 Gulf Standard Time
                   0900 Moscow Standard Time
                   0600 Greenwich Mean Time
                   0700 Central European Time    

Meeting 106B: Friday 22 Nov
              1000 Central Daylight Time
                   1100 Eastern Daylight Time
                   0800 Pacific Daylight Time
                   1200 Brasil Standard Time
                   1600 Greenwich Mean Time
                   1700 Central European Time
                   1800 Moscow Standard Time



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


#fabric #raft Orderers and organization, how to organize them? #fabric #raft

Jean-Gaël Dominé <jgdomine@...>
 

Hi all,

This topic is more a conceptual one around orderers and organizations as we are moving from solo mode to Raft.
In solo mode, as we had a single orderer, the organization matter was quite simple :)

But with Raft we were thinking of having 4 orderers. We just have doubts about how they should be structured on an organization level.
In fact, we created two different 2-orderer organizations. One would be linked to peer organization A and the other one to peer organization B.
Thus, A and B have the same number of orderers.
CAs from A and B would respectively be responsible for issuing the certificates/keys of "their" orderers.

Well, that's one way of designing it we had but we really are not sure that is the good practice.

Would anybody have insight on that matter?

Thank you in advance


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.

4321 - 4340 of 11527