Date   

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

Harris Niavis
 

Thanks Joe,

So it is technically feasible but not recommended for decentralization purposes, right? 

I could imagine a use case where we don't have such a large organization with different arms like BoA and it could make sense to have a single organization for peers and orderers. e.g. the fisherman in the supply chain paradigm.
Should we still split the peers and orderers (of the same conceptual organization) to different fabric organizations?

Best,
Harris

On Fri, 22 Nov 2019 at 10:57, Joe Alewine <Joe.Alewine@...> wrote:
Harris,
 
This is not a recommended configuration. Each entity (ie, Bank of America) should have an org that owns their peers and a separate org that owns their ordering nodes. Regulations or business preferences might make it desirable (or necessary) for BOA to split up their operations even further (a different CA for their investment arm than for their housing arm, for example), but ordering nodes and peers should not have the same root of trust (the same root CA).
 
Fabric will ALLOW you to do this --- there is no internal mechanism that checks to make sure the roots of trust are different --- but it is not recommended.
 
Regards,
 
Joe Alewine
IBM Blockchain, Raleigh
 
rocket chat: joe-alewine
slack: joe.alewine
 
 
 
----- Original message -----
From: Harris Niavis <harniavis@...>
To: "Jean-Gaël Dominé" <jgdomine@...>, joe.alewine@...
Cc: fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] #fabric #raft Orderers and organization, how to organize them?
Date: Fri, Nov 22, 2019 10:43 AM
 
Hi Joe and Jean,
 
Looking at the example of Jean I am wondering if it is possible to use Org1 and Org2 as the organizations of the orderers.
 
So instead of creating new organizations for each orderer (Org1Ord and Org2Ord), can I have a single Org1 for both peer1 and orderer1 and another Org2 for both peer2 and orderer2?
 
Best,
Harris
 
On Fri, 22 Nov 2019 at 10:24, Jean-Gaël Dominé <jgdomine@...> wrote:
Joe,

Thank you very much for your great explanation which was exactly the kind of insights I was looking for.
Unless I'm wrong (if so correct me please), the illustration I made in my previous post matches the description you made of the way things should be “organized".
It seems to me that the notion of organization in Fabric is now much clearer.

Thank you again for your time!

Jean-Gaël

 

 

 
 
 



--
Harris Niavis
Yale Institute of Network Science (YINS)
University of Thessaly (UTH)
Centre for Research and Technology Hellas (CERTH)
s: niavisharris


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

Joe Alewine <joe.alewine@...>
 

Harris,
 
This is not a recommended configuration. Each entity (ie, Bank of America) should have an org that owns their peers and a separate org that owns their ordering nodes. Regulations or business preferences might make it desirable (or necessary) for BOA to split up their operations even further (a different CA for their investment arm than for their housing arm, for example), but ordering nodes and peers should not have the same root of trust (the same root CA).
 
Fabric will ALLOW you to do this --- there is no internal mechanism that checks to make sure the roots of trust are different --- but it is not recommended.
 
Regards,
 
Joe Alewine
IBM Blockchain, Raleigh
 
rocket chat: joe-alewine
slack: joe.alewine
 
 
 

----- Original message -----
From: Harris Niavis <harniavis@...>
To: "Jean-Gaël Dominé" <jgdomine@...>, joe.alewine@...
Cc: fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] #fabric #raft Orderers and organization, how to organize them?
Date: Fri, Nov 22, 2019 10:43 AM
 
Hi Joe and Jean,
 
Looking at the example of Jean I am wondering if it is possible to use Org1 and Org2 as the organizations of the orderers.
 
So instead of creating new organizations for each orderer (Org1Ord and Org2Ord), can I have a single Org1 for both peer1 and orderer1 and another Org2 for both peer2 and orderer2?
 
Best,
Harris
 
On Fri, 22 Nov 2019 at 10:24, Jean-Gaël Dominé <jgdomine@...> wrote:
Joe,

Thank you very much for your great explanation which was exactly the kind of insights I was looking for.
Unless I'm wrong (if so correct me please), the illustration I made in my previous post matches the description you made of the way things should be “organized".
It seems to me that the notion of organization in Fabric is now much clearer.

Thank you again for your time!

Jean-Gaël

 

 

 
 
 


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

Harris Niavis
 

Hi Joe and Jean,

Looking at the example of Jean I am wondering if it is possible to use Org1 and Org2 as the organizations of the orderers.

So instead of creating new organizations for each orderer (Org1Ord and Org2Ord), can I have a single Org1 for both peer1 and orderer1 and another Org2 for both peer2 and orderer2?

Best,
Harris

On Fri, 22 Nov 2019 at 10:24, Jean-Gaël Dominé <jgdomine@...> wrote:
Joe,

Thank you very much for your great explanation which was exactly the kind of insights I was looking for.
Unless I'm wrong (if so correct me please), the illustration I made in my previous post matches the description you made of the way things should be “organized".
It seems to me that the notion of organization in Fabric is now much clearer.

Thank you again for your time!

Jean-Gaël



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

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

Joe,

Thank you very much for your great explanation which was exactly the kind of insights I was looking for.
Unless I'm wrong (if so correct me please), the illustration I made in my previous post matches the description you made of the way things should be “organized".
It seems to me that the notion of organization in Fabric is now much clearer.

Thank you again for your time!

Jean-Gaël


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

Yueming Xu
 

Ah. Thanks for the explanation.

On Nov 22, 2019, at 7:58 AM, Gari Singh <garis@...> wrote:

There's not actually a flag ... you simply specify the full path to the package (e.g. ./mypackage.cds) as an argument (e.g. after all the flags).

peer chaincode install -n mycc -v 1.0 -p github.com/mycc mycc.cds



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


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

Gari Singh <garis@...>
 

There's not actually a flag ... you simply specify the full path to the package (e.g. ./mypackage.cds) as an argument (e.g. after all the flags).

peer chaincode install -n mycc -v 1.0 -p github.com/mycc mycc.cds



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


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

Yueming Xu
 

How do you do it, Gari?  I checked 'peer chaincode install --help', and could not see a flag to specify a cds package.  My version of the peer command is 1.4.4.  Thanks.


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

Joe Alewine <joe.alewine@...>
 

Jean-Gael,
 
So Fabric organizations are similar to organizations as we think of them in the real world (Bank of America is an "organization"), but there are differences that affect the way you should organize things (if you'll forgive the pun).
 
Organizations are defined through an MSP, which is a series of folders that, most importantly, establish two things: 1) the admins of the organization (there are other kinds of users, but admins are the most important), and 2) the root of trust for the organization (its root CA). These organizations then, as you know, are associated with a node during the creation of the node, signaling that the node is "owned" by the organization. 
 
The best practice is for each organization to have its own CA (its own root CA cert), and for individuals or groups or corporations or whathaveyou to create separate organizations for the organizations that own peers and own ordering nodes. This separation of organizations reflects the separation of the roles of the different nodes, even if ultimately the same Bank of America-type "organization" owns all of the CAs and ordering nodes and peers.
 
From a deployment perspective, this means you should have one CA (one root CA, at least, though you're free to create intermediate CAs if you want) that creates an organization that owns all of your ordering nodes. And you should have a separate CA that creates an organization that owns all of your peers. The decentralization of your ordering service will actually come through other people creating their own CAs and their own ordering organizations and then their own nodes and joining their nodes and your nodes together to form the ordering service. 
 
Hope that helps,
 
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] Re: [Hyperledger Fabric] #fabric #raft Orderers and organization, how to organize them?
Date: Fri, Nov 22, 2019 8:30 AM
 
Thanks for you quick reply.

I read this documentation a while ago and indeed some elements are present there:
I have a couple of questions though about some sentences I found:
Just like peers, ordering nodes belong to an organization. And similar to peers, a separate Certificate Authority (CA) should be used for each organization
I feel a bit confused about the notion of organization. I'll take a more concrete example to illustrate and check that I get it right.
Let's take two companies/organizations Org1 and Org2 that have 3 peers each.
Let's say that I want an orderer in each organization so that the ordering service is decentralized.

Then, from my understanding, comes the configtx.yaml file that introduces its own notion of organization since in it I'm going two define 4 organizations:
  • 2 for each orderer: Org1Ord and Org2Ord
  • 2 for each set of peers: Org1 and Org2
From the extract of the documentation, I understand that a dedicated CA should be in place for each organization, meaning I should have 4 CAs.
  • CAOrg1Ord to issue certificates/keys for Org1Ord
  • CAOrg1 to issue certificates/keys for Org2Ord
  • CAOrg2Ord to issue certificates/keys for Org1
  • CAOrg2 to issue certificates/keys for Org2
They could all be Root Certificate Authorities or CAOrgXOrd could be an intermediate of CAOrgX (or the other way around) but in any case the root certificate would be provided by the company in charge of it.

Does my illustration make sense ? Am I understanding things correctly?

Thank you
 
 


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

Gari Singh <garis@...>
 

You can actually specify the package as an argument to the command:

peer chaincode install [flags] pkg

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

-----fabric@... wrote: -----
To: fabric@...
From: "Yueming Xu"
Sent by: fabric@...
Date: 11/21/2019 12:47AM
Subject: [EXTERNAL] [Hyperledger Fabric] To install chaincode, do you use source code or packaged cds file?

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.


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

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

Thanks for you quick reply.

I read this documentation a while ago and indeed some elements are present there:
I have a couple of questions though about some sentences I found:
Just like peers, ordering nodes belong to an organization. And similar to peers, a separate Certificate Authority (CA) should be used for each organization
I feel a bit confused about the notion of organization. I'll take a more concrete example to illustrate and check that I get it right.
Let's take two companies/organizations Org1 and Org2 that have 3 peers each.
Let's say that I want an orderer in each organization so that the ordering service is decentralized.

Then, from my understanding, comes the configtx.yaml file that introduces its own notion of organization since in it I'm going two define 4 organizations:
  • 2 for each orderer: Org1Ord and Org2Ord
  • 2 for each set of peers: Org1 and Org2
From the extract of the documentation, I understand that a dedicated CA should be in place for each organization, meaning I should have 4 CAs.
  • CAOrg1Ord to issue certificates/keys for Org1Ord
  • CAOrg1 to issue certificates/keys for Org2Ord
  • CAOrg2Ord to issue certificates/keys for Org1
  • CAOrg2 to issue certificates/keys for Org2
They could all be Root Certificate Authorities or CAOrgXOrd could be an intermediate of CAOrgX (or the other way around) but in any case the root certificate would be provided by the company in charge of it.

Does my illustration make sense ? Am I understanding things correctly?

Thank you


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@...
 

 

4221 - 4240 of 11437