Date   

Re: Problematic raspberry support

Nikos Karamolegkos
 

Thank you for your time. I just ran the test-network (after your contribution) but the error remains. My steps were: make docker clean, make docker, make native, copy the bin into fabric samples.


Re: Fabric Contributor Meeting - March 17, 2021 - any agenda topics?

Vitalii Demianets
 

Hi David and all!

I would like to propose one more item for March 31st agenda. We would like to open a discussion on our RFC:
https://github.com/hyperledger/fabric-rfcs/pull/44
I am planning to attend and present it from the norbloc side.

--
// Vitalii Demianets @ norbloc AB


On Tue, Mar 16, 2021 at 11:53 PM David Enyeart <enyeart@...> wrote:

Hyperledger Fabric Contributor Meeting

When: Every other Wednesday 9am US Eastern, 13:00 UTC (during US daylight savings time)

Where: https ://zoom.us/j/51849 47650?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

Agendas and Recordings: https://wiki.hyperledger.org/display/fabric/Contributor+Meetings

----------------------------------------------------------------------------------------------------

Agenda for March 17, 2021
There are no big agenda topics scheduled for this week yet.
We will do a quick update on the transition from 'master' to 'main' as the default branch.
Feel free to propose an agenda item!

For March 31 meeting, an update on the Fabric Gateway is planned.


Re: peer discovery/collection errors when calling chaincode from nodejs client

Mark Lewis
 

You might need to set some discovery interests for the private data collections you are using. See the "using chaincode to chaincode calls and collections" section on this page for details:

https://hyperledger.github.io/fabric-sdk-node/release-2.2/tutorial-discovery-fabric-network.html

You can also explicitly specify the endorsing organizations to use for a given transaction submit:

https://hyperledger.github.io/fabric-sdk-node/release-2.2/module-fabric-network.Transaction.html#setEndorsingOrganizations


Re: Fabric network org structure reg.

Tsvetan Georgiev
 

Hi Indirajith,

Yes it is better to use dedicated MSP for the ordering orgs. This means a business organization may use multiple MSPs to run peers or orderers.



I recommend going though the production deployment guide: https://hyperledger-fabric.readthedocs.io/en/release-2.2/deployment_guide_overview.html

Hope that helps!

Senofi

Tsvetan Georgiev
Director, Senofi Inc.

438-494-7854 | tsvetan@...

www.senofi.ca

www.consortia.io







---- On Wed, 24 Mar 2021 04:40:35 -0400 indirajith <indirajithv@...> wrote ----

Dear Fabric Community,

I would like to know what is the best practice or prefered method to design a fabric network in 2.x versions? Shall we have orderers in the same organization as peers or should we need to have a seperate org for orderers? Or should we have two different orgs for peers and orderers for each participating orgs? Can anyone shed some light and point me to resources? I could not get any response for the query in the chat channel.

Thanks in advance. 
Regards,
Indirajith.






Hyperledger Fabric Documentation Workgroup call - Western hemisphere - Fri, 03/26/2021 11:00am-12:00pm #cal-reminder

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

Reminder: Hyperledger Fabric Documentation Workgroup call - Western hemisphere

When: Friday, 26 March 2021, 11:00am to 12:00pm, (GMT-04:00) America/New York

Where:https://zoom.us/my/hyperledger.community.backup?pwd=dkJKdHRlc3dNZEdKR1JYdW40R2pDUT09

View Event

Organizer: Pam Andrejko pama@...

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

Join Zoom Meeting
https://zoom.us/j/6223336701?pwd=dkJKdHRlc3dNZEdKR1JYdW40R2pDUT09
 
Meeting ID: 622 333 6701
Passcode: 475869


peer discovery/collection errors when calling chaincode from nodejs client

Simeon MacMillen
 

Hello Fabric community,

I am encountering a couple issues when accessing/writing data to a Fabric (2.3) network from a Node.js client.  I have a 4-org network running on 4 different VPS instances.  (Each VPS hosts 1 org with dockerized peer and orderer instances.  The VPSs are linked via a Docker swarm overlay network.)  There are 2 shared private data collections, one with 3 orgs, 1 with 2 orgs.  (Only 1 org is a member of both collections.)

When I start my node client (on any of the VPS instances), I get error messages like these:

2021-03-25T10:48:10.616Z - error: [ServiceEndpoint]: Error: Failed to connect before the deadline on Endorser- name: peer0.orgb.scm.com:7051, url:grpcs://localhost:7051, connected:false, connectAttempted:true
2021-03-25T10:48:10.617Z - error: [ServiceEndpoint]: waitForReady - Failed to connect to remote gRPC server peer0.orgb.scm.com:7051 url:grpcs://localhost:7051 timeout:3000
2021-03-25T10:48:10.618Z - error: [DiscoveryService]: _buildPeer[scm1] - Unable to connect to the discovered peer peer0.orgb.scm.com:7051 due to Error: Failed to connect before the deadline on Endorser- name: peer0.orgb.scm.com:7051, url:grpcs://localhost:7051, connected:false, connectAttempted:true

It seems that the client org is having trouble connecting with the other orgs outside of Docker.  Note that "asLocalhost" is set to true.

However, after displaying the error messages, I can use the client to successfully read and write to the ledger.  So it seems the error messages are more of a cosmetic issue than a functional issue?  (They certainly would not inspire confidence in a demo!)  The error messages also occur randomly after other read/write requests.


To deal with this problem, I tried dockerizing my node client.  This way, the client could use the same docker overlay network and natively resolve the other hosts.  This worked great (I thought) - no more errors on startup or queries!  However, when I try to write data to the ledger, I get this error:

--> Submit Transaction: AddPart A2
2021-03-24T23:18:55.339Z - error: [Transaction]: Error: No valid responses from any peers. Errors:
    peer=peer0.orga.scm.com:7051, status=500, message=AddPart cannot be performed: Error client from org ORGBMSP is not authorized to read or write private data from an org ORGAMSP peer
Error detected when calling addPart function:Error: No valid responses from any peers. Errors:
    peer=peer0.orga.scm.com:7051, status=500, message=AddPart cannot be performed: Error client from org ORGBMSP is not authorized to read or write private data from an org ORGAMSP peer

So I solved the discovery problem, but now the client is connecting to any organization peer it wants to?  I could avoid calling the verifyClientOrgMatchesPeerOrg function in the Chaincode, but that would potentially introduce other problems.

Is there a way to force the client to only use the client org's peer?  Or is there a better approach here?

Sincerely,
Simeon MacMillen



Re: HyperLedger Fabric v2.3 Endorsement Policy did not come into action

David Enyeart
 

This is working as expected. You updated the size field but not the version field. The read set check only checks the version field. It is up to the chaincode to check other fields such as asset ownership (and size, if there are business rules around that, such as size not being allowed to change in an update). The asset transfer chaincode is a trivial sample and only checks for asset existence in state database by key. So in your case chaincode execution succeeded because it passed the asset existence check, endorsements succeeded, and validation succeeded since both endorsements were over the same read set (version) and write set.
You get the CouchDB warning because the internal CouchDB revision number was different due to your external update, but this is not a fatal problem and gets resolved by a retry (CouchDB internal revision numbers are not guaranteed to be the same across state databases since peer may update the same state multiple times, e.g. in crash recovery scenarios).


Dave Enyeart

"Ming Xian Ng" ---03/25/2021 12:11:11 AM---Hi, I was trying to test out the endorsement policy feature of Fabric with

From: "Ming Xian Ng" <ngmx.sean@...>
To: fabric@...
Date: 03/25/2021 12:11 AM
Subject: [EXTERNAL] [Hyperledger Fabric] HyperLedger Fabric v2.3 Endorsement Policy did not come into action
Sent by: fabric@...





Hi, I was trying to test out the endorsement policy feature of Fabric with the Running a Fabric Application tutorial and I have encountered a few questions/issues. Instead of using LevelDB, I up the network using CouchDB by changing the command ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Hi,
I was trying to test out the endorsement policy feature of Fabric with the Running a Fabric Application tutorial and I have encountered a few questions/issues.
Instead of using LevelDB, I up the network using CouchDB by changing the command to ./network.sh up createChannel -c mychannel -ca -s couchdb. After the call to InitLedger, I manually edit asset2's "Size" field value to another random value through fauxton, accessed from http://127.0.0.1:5984/_utils/ (couchdb0, which belongs to organization 1). So at this point, asset2 has 2 different value sitting in couchdb0 and couchdb1.
Then I invoke the UpdateAsset function in the chaincode to update asset2's value. I was expecting an error about endorsement policy is not met or something to be thrown as the different value of asset2 in couchdb0 and couchdb1 should results in different RW set.
peer0.org1.example.com|2021-03-23 09:03:09.568 UTC [statecouchdb] commitUpdates -> WARN 0b4 CouchDB batch document update encountered an problem. Reason:Document update conflict., Retrying update for document ID:asset2

I did notice this warning in logspout however there was no error caught in my try catch block, and it seems that a valid block is committed and the world states is getting updated as usual without any error.
Shouldn't the different RW Set would cast the transaction as invalid and the world states wouldn't be updated?

Regards,
Sean





HyperLedger Fabric v2.3 Endorsement Policy did not come into action

Ming Xian Ng
 

Hi,

I was trying to test out the endorsement policy feature of Fabric with the Running a Fabric Application tutorial and I have encountered a few questions/issues.

Instead of using LevelDB, I up the network using CouchDB by changing the command to ./network.sh up createChannel -c mychannel -ca -s couchdb. After the call to InitLedger, I manually edit asset2's "Size" field value to another random value through fauxton, accessed from http://127.0.0.1:5984/_utils/ (couchdb0, which belongs to organization 1). So at this point, asset2 has 2 different value sitting in couchdb0 and couchdb1.

Then I invoke the UpdateAsset function in the chaincode to update asset2's value. I was expecting an error about endorsement policy is not met or something to be thrown as the different value of asset2 in couchdb0 and couchdb1 should results in different RW set.

peer0.org1.example.com|2021-03-23 09:03:09.568 UTC [statecouchdb] commitUpdates -> WARN 0b4 CouchDB batch document update encountered an problem. Reason:Document update conflict., Retrying update for document ID:asset2

I did notice this warning in logspout however there was no error caught in my try catch block, and it seems that a valid block is committed and the world states is getting updated as usual without any error.

Shouldn't the different RW Set would cast the transaction as invalid and the world states wouldn't be updated?


Regards,

Sean


Re: Problematic raspberry support

Matthew Sykes
 

I had some time this morning so I played around with the peer image created on linux/aarch64 (linux/arm64). To get to the bottom of why the program was dying during initialization, I commented out all of the code in the peer main and slowly added back in the package imports until I hit the segfault again. I went to the package introducing the problem and repeated the process until I got to the bottom.

After running down the tree, the package that caused the problem was `plugin’ and the only import left in Fabric is from `github.com/hyperledger/fabric/core/handlers/library`. It looks like plugins work with glibc (the native builds and tests seem fine) so it has something to do with musl.

I’ll put together a PR to enable builds without plugins some time today. After that’s in, the images built with alpine and musl should work on linux/aarch64 (linux/arm64). It’s still not something we’ll be testing and supporting at this time but it may unblock your efforts.


Fabric network org structure reg.

indirajith
 

Dear Fabric Community,

I would like to know what is the best practice or prefered method to design a fabric network in 2.x versions? Shall we have orderers in the same organization as peers or should we need to have a seperate org for orderers? Or should we have two different orgs for peers and orderers for each participating orgs? Can anyone shed some light and point me to resources? I could not get any response for the query in the chat channel.

Thanks in advance. 
Regards,
Indirajith.


Re: Smart BFT

grapebaba
 

Hi guys

I looked at several git branch prefix release-1.4-BFT, what is the difference between them? What is the correct version for docker https://hub.docker.com/r/smartbft/fabric-peer

On Mon, Oct 26, 2020 at 10:59 PM Oleg Martianov <olegmartianov@...> wrote:
Dear Community members! 

IDEAS Center has been deeply involved in the development of SmartBFT consensus library and would like to propose RFC https://github.com/hyperledger/fabric-rfcs/pull/33 that argues about  the necessity of BFT protocol as part of enterprise grade blockchain platform. The RFC highlights the implementation details and the efforts required to integrate the library into Hyperledger Fabric. Currently we are seeking for engagements with community and in particular with Hyperledger Fabric maintainers in order to identify milestones and formulate reasonable integration strategy and the roadmap, striving to generate small self containable deliverables and providing on going support going forward. 

In the heart of the BFT ordering service for Hyperledger Fabric implementation lies a new consensus library, based on the BFT-Smart protocol, implemented in Go. The library presents APIs suited for permissioned blockchain applications, such as Fabric. It delegates many of the core functions that any such library must use to the application employing it, allowing for maximal flexibility and generality. For example, cryptographic functions, identity management, as well as point to point communication are not embedded but are exposed through proper interfaces, to be implemented by the application using it. This allowed us to re-use some of the sophisticated mechanisms that Fabric already possessed. In the quest to make Fabric a truly end-to-end BFT system, it is not enough to augment the ordering service alone. We took special care to ensure that the peer and the client SDK interact properly with the BFT ordering service.

We chose to implement the BFT-Smart protocol because of its simplicity and elegance. This protocol is significantly simpler than PBFT, because it does not allow for a transaction pipeline. In BFTSmart there is only a single proposed transaction by a given leader at any point in time, which dramatically simplifies the view change sub-protocol. This simplicity greatly increases our confidence in the correctness of the implementation and reduced the effort it took to implement the library. However, these advantages come with a cost – reduced performance. This is especially salient when comparing against the highly mature and optimized etcd/raft library, which uses pipelining extensively. Despite the cost of reduced performance relative to etcd/raft, our implementation exhibits levels of performance that are sufficient for most permissioned blockchain applications: a 7 node BFT ordering service (𝐹 = 2) can support over 2500 TPS in a LAN, and over 1000 TPS in a WAN. These numbers are for a single channel; a Fabric network can scale horizontally by adding channels.

IDEAS Center is managing Smart BFT additional development at the moment and will be responsible for the following support and new Fabric versions compatibility.


Thank you!


Begin forwarded message:

From: Oleg Martianov <olegmartianov@...>
Subject: Smart BFT
Date: 17 September 2020, 17:41:51 GMT+3

Hello Team!

SC Idea sponsored and worked on BFT based ordering service - Smart BFT (BYZANTINE FAULT TOLERANCE) library (https://github.com/SmartBFT-Go/consensus/) that has been developed in Open Source by IBM Research lab in the frames of the contract with SC Idea. There is an implementation of Hyperledger Fabric BFT based ordering service which is built on top of Smart BFT library: https://github.com/SmartBFT-Go/fabric/

SC Idea team would like to suggest resources and integrate BFT based ordering service with the Hyperledger Fabric mainstream, we strongly believe that that will significantly improve functionality and provide long long desired  end to end functionality into. In order to initiate the process we would like to propose RFC: https://github.com/hyperledger/fabric-rfcs/pull/33

We would be glad to hear and collect your feedback and really looking forward for fruitful collaboration and maintainers support for our initiative.


Re: Orderer ledger pruning

Vitalii Demianets
 

The RFC draft has been submitted, here:
https://github.com/hyperledger/fabric-rfcs/pull/44

Please review!
--
// Vitalii Demianets @ norbloc AB


On Thu, Feb 25, 2021 at 1:06 PM Vitalii Demianets via lists.hyperledger.org <vitalii=norbloc.com@...> wrote:
Thank you all for the discussion and your input!
I think we now have a high-level understanding of what has to be done, looks simple enough.
Now we start the process of drafting the RFC. It will take some time though, as we want to familiarize ourselves with the internals of the code and the architecture from the Fabric dev point of view, but I hope it will not take more than 3-4 weeks.

--
// Vitalii Demianets @ norbloc AB


On Tue, Feb 23, 2021 at 3:56 PM Manish Sethi <manish.sethi@...> wrote:
In regards to changes to the blockstore, Jason is right that they would be very trivial. For the peers case, this function (https://github.com/hyperledger/fabric/blob/e0253ef0466e4e16364f3d1d3cc537ad9d8b1c4f/common/ledger/blkstorage/blockstore_provider.go#L103) does the job. For the orderer, I would expect an even simpler function (say, "BootstrapFromSnapshotInfo"), as there is nothing much other than the information of the initial state that needs to be supplied.

Thanks,
Manish

On Tue, Feb 23, 2021 at 6:27 AM Vitalii Demianets <vitalii@...> wrote:
Hi Jason!

>
> At a very high level I would suggest.
>
> 1) Modifying the channel participation API to allow specifying a minimum block sequence number to replicate to when joining.
> 2) Add a new pruning function to the channel participation API, which allows reconfiguring that minimum block sequence to a higher sequence number. (Implicitly existing channels would have this sequence set to 0).
> 3) Ignoring the system channel case, instead prereq-ing that channel participation API.
> 4) Introducing a new return status for the Deliver API indicating to peers and clients that the sequence is too old to help users understand why a block request is being rejected.  You'll actually notice that the APi already has the notion of 'OLDEST' as a seek position, as the earliest incarnations of the orderer ledger were RAM based and self-pruning.
>
> Perhaps Manish can weigh in here, but I believe the block storage code was already modified in the peer to handle starting from a later block.  The orderer uses a thin wrapping layer around the peer blockstore, so if not already exposed, exposing it should be relatively simple.

In the above description you do not mention snapshot at all. Do I understand this correctly that we basically do not need any of the peer snapshot functionality (private data collections, stateDB, transactions id list) to start an orderer from an arbitrary block? Basically from your description it follows that we only need to supply the latest config block and the desired start block number, and the orderer will happily start from that info? (given it is able to fetch the start block and other blocks on top of it)
In other words, for orderers the "snapshot" is only the latest config block + start block number?

>
> It might also be helpful to extend the block height discovery in the orderer block replication to discover the lowest block height as well, to detect when an orderer cannot catch up, though I'm not sure I would consider this a blocking item for an initial implementation.

Yes, in our use case the condition that we start the orderer from the block that can be discovered is satisfied, so it makes sense not to add this complexity from the start.
After all if an orderer is not able to find a block, it will be more or less obvious from the logs.

>
> I would argue that the most challenging aspect of implementing pruning at the orderer is an operational one.  The orderers are necessarily not involved in the peer snapshot operations, but, if the orderers prune to a block after the peer's most recent snapshot, onboarding will be broken until peers take a new snapshot.  In the worst case, if the orderer prunes before the blocks are disseminated to the peers, then data loss could occur.
>

We are going to keep several peers as "archiving" nodes, having all the history of blocks from block 0.
Will this solve the issue?

--
// Vitalii Demianets @ norbloc AB


Private Chaincode Lab - Tue, 03/23/2021 #cal-notice

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

Private Chaincode Lab

When:
Tuesday, 23 March 2021
8:00am to 9:00am
(GMT-07:00) America/Los Angeles

Where:
https://zoom.us/my/hyperledger.community.3?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

Organizer:
bur@...

Description:
Two of the Hyperleger Labs projects (private data objects and private chain code) are collaborating to develop a "private smart contracts" capability.

Join Zoom Meeting https://zoom.us/j/5184947650?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09 Meeting ID: 518 494 7650 Passcode: 475869


Re: Problematic raspberry support

Matthew Sykes
 

Yeah, they’re all my commits so I’m very familiar with them. The change you’re referencing this time was required to get through the link phase in the alpine containers but the binaries in the containers still aren’t exercised.

As for clues, I don’t have any. If the binaries are going belly-up with a segfault, I’d start with that. It’s probably related to the musl libc used in the alpine container.


Re: Problematic raspberry support

Brett T Logan <development.brett@...>
 

While I hold that those changes do in fact make building Fabric for ARM64 possible, as Matt mentioned it's not officially supported. I can say that I've tested that change on PI4 and when done right with Go chaincode, that change in itself makes it possible to run Fabric on ARM64. There are many threads all over the place with people who have had success doing this.


On Tue, Mar 23, 2021 at 9:46 AM Nikos Karamolegkos <nkaram@...> wrote:

Sorry I misclick the commit link. The correct one is this. Also, this answer made me believe that raspberry pi4 is supported (even at an early stage). I can take a look on the problem but I need some clues. Where should I start?

-- 
Nikos Karamolegkos
R & D engineer at ICS-FORTH
Telecommunications and Networks Lab (TNL)


Re: Problematic raspberry support

Nikos Karamolegkos
 

Sorry I misclick the commit link. The correct one is this. Also, this answer made me believe that raspberry pi4 is supported (even at an early stage). I can take a look on the problem but I need some clues. Where should I start?

-- 
Nikos Karamolegkos
R & D engineer at ICS-FORTH
Telecommunications and Networks Lab (TNL)


Re: Problematic raspberry support

Matthew Sykes
 

Nikos, the Fabric team doesn’t do anything to support Raspberry Pi. The commit you’re referencing enables _development_ of Fabric on the new arm64 based M1 macs using the code in the core Fabric tree. That should not be interpreted as “added support for fabric in raspberry.”

We do not build and publish images for linux/arm64, we do not run CI on linux/arm64, we don’t exercise the samples and test networks on lnux/arm64, and we certainly don’t do anything with Java chaincode on linux/arm64. Since we don’t exercise the paths, it’s not surprising that you’re running into difficulties.

If the containers are exiting with a 139, it’s dying with a segmentation fault. That means it’s a bad binary. Given everything above, that’s not a huge surprise. If you end up finding the cause of these problems and wish to deliver a fix upstream, we’d be happy to work with you.


Problematic raspberry support

Nikos Karamolegkos
 

In latest commits you added support for fabric in raspberry as described here. I am trying so many days to build fabric-chaincode-java without success (the help in the chats or the list was almost zero). So I decide to check the test-network in GO. Thus the steps are:

1) In latest fabric folder: make docker, make native
2) I ignored the fabric-ca
3) copy bin/ from fabric folder to samples folder, same for the config/
4) In latest fabric-samples/test-network folder:  ./network down, ./network up

Starting nodes with CLI timeout of '5' tries and CLI delay of '3' seconds and using database 'leveldb' with crypto from 'cryptogen'
LOCAL_VERSION=2.4.0
DOCKER_IMAGE_VERSION=
Local fabric binaries and docker images are out of  sync. This may cause problems.
/home/ubuntu/fabric-samples/test-network/../bin/cryptogen
Generating certificates using cryptogen tool
Creating Org1 Identities
+ cryptogen generate --config=./organizations/cryptogen/crypto-config-org1.yaml --output=organizations
org1.example.com
+ res=0
Creating Org2 Identities
+ cryptogen generate --config=./organizations/cryptogen/crypto-config-org2.yaml --output=organizations
org2.example.com
+ res=0
Creating Orderer Org Identities
+ cryptogen generate --config=./organizations/cryptogen/crypto-config-orderer.yaml --output=organizations
+ res=0
Generating CCP files for Org1 and Org2
Creating network "fabric_test" with the default driver
Creating volume "docker_orderer.example.com" with default driver
Creating volume "docker_peer0.org1.example.com" with default driver
Creating volume "docker_peer0.org2.example.com" with default driver
Creating orderer.example.com    ... done
Creating peer0.org2.example.com ... done
Creating peer0.org1.example.com ... done
Creating cli                    ... done
CONTAINER ID        IMAGE                               COMMAND             CREATED             STATUS                       PORTS                                            NAMES
fb943546dc4f        hyperledger/fabric-tools:latest     "/bin/bash"         3 seconds ago       Up Less than a second                                                         cli
d0a9bed586c3        hyperledger/fabric-peer:latest      "peer node start"   6 seconds ago       Exited (139) 2 seconds ago                                                    peer0.org1.example.com
a2bd075ecac5        hyperledger/fabric-orderer:latest   "orderer"           6 seconds ago       Up 2 seconds                 0.0.0.0:7050->7050/tcp, 0.0.0.0:7053->7053/tcp   orderer.example.com
67f4a76afb85        hyperledger/fabric-peer:latest      "peer node start"   6 seconds ago       Exited (139) 1 second ago                                                     peer0.org2.example.com

DOCKER_IMAGE_VERSION is empty, and the peer containers are exiting with code 139.

Is this a bug?

-- 
Nikos Karamolegkos
R & D engineer at ICS-FORTH
Telecommunications and Networks Lab (TNL)


docker run to extract images version

Nikos Karamolegkos
 

Hello,
When I am running docker run --rm hyperledger/fabric-peer:latest peer version the command does not return anything. Why?
The command docker run --rm hyperledger/fabric-orderer:latest orderer version returns the versions as 
orderer:
 Version: 2.2.2
 Commit SHA: bebb75f
 Go version: go1.14.12
 OS/Arch: linux/arm64

-- 
Nikos Karamolegkos
R & D engineer at ICS-FORTH
Telecommunications and Networks Lab (TNL)


Re: Rename default branch to 'main' in Fabric repositories

David Enyeart
 

The switch to 'main' is complete in all Fabric repositories. Please use the instructions below to switch any local development environments over to 'main'.


Dave Enyeart

David Enyeart---03/15/2021 01:52:34 PM---Based on industry and Hyperledger recommendations, we will be switching default branch from 'master'

From: David Enyeart/Durham/IBM
To: fabric <fabric@...>
Date: 03/15/2021 01:52 PM
Subject: Rename default branch to 'main' in Fabric repositories




Based on industry and Hyperledger recommendations, we will be switching default branch from 'master' to 'main' on all Fabric repositories.

I plan to switch all Fabric repositories on Friday March 19th. Doing them all the same day will limit any temporary link breakages across the repositories and docs. Everything should be in working order by Monday.

A few of the repositories have been done already. I've tested the process on Fabric CA repository since it follows similar CI and doc approach as Fabric.

Here is the process that I will be following for each repository:
- Use the new Github feature to rename default branch. This automatically re-targets PRs to "main" and updates branch protections rules.
- PR to update master references in CI pipelines, docs, etc
- Update default branch in Azure Pipelines

Once it is done for a repository, each developer that has a local fork will need to perform the following steps to update their local environment, push the main branch to their fork and associate with local main branch, and ensure local main is rebased on the upstream main branch:
git checkout master
git branch -m master main
git fetch origin
git push origin main
git branch -u origin/main main
git fetch upstream
git rebase upstream/main

The steps assume you are following the Github fork and upstream remote instructions here:
https://hyperledger-fabric.readthedocs.io/en/latest/github/github.html

Please let us know if you have any other suggestions or comments.


Thank you,

Dave Enyeart


861 - 880 of 10574