Date   

create a fabric supporting thin peers

qs meng <qsmeng@...>
 

Hi,
   I want to make some modification to the fabric  such that the peer only save blockheaders, not the transactions, not the meta data.  A peer with the code is called a thin peer which needs less storage.  But I still want a thin peer can check the correctness of transactions. 
   Now I want you some help.  
  1. is the idea feasible?
  2. what codes should be modified?  what I find is  " common/ledger/blkstorage/fsblkstorage/blockfile_mgr.go".  is there any other codes?
  Thank you.
  best regards,
qsmeng


 


Users Wallet managment #fabric-questions

Ahmed Al-Yamani <a7med.yamani@...>
 

Hello

we are designing a solution where users will have their own wallets where their keys will be used for encrypting and signing content.

our concerns are that all wallets are stored on the server which runs the fabric-sdk file system and can be accessed by an administrator or hacker 

what are the best practice to mange and secure users wallets. Some articles suggest HSM and others suggest re-enrollment on every transaction/session.


Re: Hyperledger Fabric meets Kubernetes

Hakan Eryargi
 

A small update: Restriction for using cryptogen versions <1.4.3 is relaxed. We now support NodeOU.

Best,
Hakan

On Thu, Mar 5, 2020 at 10:07 AM Hakan Eryargi via Lists.Hyperledger.Org <hakan.eryargi=gmail.com@...> wrote:
Hi Craig,

Thanks. Indeed, this is the most advanced and convenient way of running Fabric in Kubernetes.

I will work with all 1.4.x versions. Limitation is only for cryptogen tool for creating the certificates. It should be < 1.4.3

We had tested it with pre 2.0 release. It's not compatible with the new chaincode lifecycle so you cannot use V2_0 capability. When capability is set to V1_4_x, it worked but Fabric didnt feel much stable that time.

Best,
Hakan

On Wed, Mar 4, 2020 at 5:04 PM Craig Allwardt <craiga@...> wrote:
Hello,

The documentation lists fabric 1.42 and 1.43 have you tested any of these with fabric2?  This work looks really promising

Thanks

CHA

From: fabric@... <fabric@...> on behalf of Eryargi, Hakan via Lists.Hyperledger.Org <hakan.eryargi=accenture.com@...>
Sent: Friday, February 28, 2020 7:00 AM
To: fabric@... <fabric@...>
Cc: fabric@... <fabric@...>
Subject: Re: [Hyperledger Fabric] Hyperledger Fabric meets Kubernetes
 

Dear All,

 

Below is a summary of recent updates to our Helm charts:

 

  • Support for hybrid networks. We also provided a sample of spreading the Fabric network over three Kubernetes clusters, covering all possible scenarios, with orderer, without orderer, etc.
    The same mechanism can be used for any combination of hybrid networks, some parts running on premises as plain Docker containers, or on bare metal or whatever.
    https://github.com/APGGroeiFabriek/PIVT/blob/master/README.md#cross-cluster-raft-network

  • Declaratively make almost arbitrary channel config updates. There is still room to improve here but it’s quite easy to extend and add more functionality
    https://github.com/APGGroeiFabriek/PIVT/blob/master/README.md#updating-channel-configuration

  • Support for Raft orderer without enabling TLS globally.  Thanks to Fabric 1.4.5 release, this is possible since FAB-15648 is backported to 1.4 branch.
    We were waiting for this feature since long time for transparent load balancing inside Kubernetes. Already applied to our environments and works great.
    But eventually we need to enable TLS and lose transparent load balancing again.
    I believe it will be really useful separating client and cluster facing ports on peers and orderers.  Please vote for FAB-17111 if you think similar.
    https://github.com/APGGroeiFabriek/PIVT/blob/master/README.md#scaled-up-raft-network-without-tls

  • Support and sample for Golang chaincode. Due to GOPATH variable they should be handled differently.
    Nobody reported any issue about Java chaincode, so possibly it just works out of the box.

So, cheers and happy Fabricing in Kubernetes as always!

Hakan



From: Eryargi, Hakan
Sent: Monday, 12 August 2019 15:13
To: 'fabric@...' <fabric@...>
Subject: RE: [Hyperledger Fabric] Hyperledger Fabric meets Kubernetes

 

Dear All,

 

We just recently published new functionality for our Helm charts. Managing peer organizations is now declarative.

 

To add new peer organizations:

  • Update configtx/crypto-config/network.yaml accordingly
  • Perform a cryptogen extend
  • Perform a helm upgrade
  • Run the new peer-org-flow

 

That’s it. This sequence launches everything, adds missing organizations to consortiums using the information in configtx.yaml and adds missing organizations to existing channels using the information in network.yaml.

 

Afterwards run the channel and chaincode flows to create new channels and populate existing channels and chaincodes regarding new organizations.

 

More details here:

https://github.com/APGGroeiFabriek/PIVT/blob/master/README.md#adding-new-peers-to-organizations

 

One of our initial promises was making it as easy as possible to add/remove organizations to an already running network and I guess we kept that promise :) Possibly this can’t get easier without a Fabric operator.

 

So, cheers and happy Fabricing in Kubernetes!

Hakan

 

 

From: Eryargi, Hakan
Sent: Wednesday, 31 July 2019 15:26
To: 'fabric@...' <fabric@...>
Subject: RE: [Hyperledger Fabric] Hyperledger Fabric meets Kubernetes

 

Dear HL Fabric Community,

 

We just recently published new functionality for our Helm charts:

https://github.com/APGGroeiFabriek/PIVT

 

  • Now the channel and chaincode flows are declarative and idempotent. They can be run several times. They query the network state and take action only required. They create channels only if not created, join peers to channels only not joined, install/instantiate/upgrade chaincodes only required, etc.
  • We have a new flow for adding new peer organization(s) to an already running network. It both adds new orgs to existing channels and also to consortiums.

 

Our next aim is making peer org flow declarative and idempotent.

 

I think, we are now so close to wrapping up everything in a Kubernetes operator, it will be even closer with a declarative peer org flow.

 

On the other hand, unfortunately we lack the Go language knowledge and experience. But still this looks so achievable by using CoreOS’s operator SDK. If there are experienced Go developers out there and willing to contribute such a project, please contact me.

https://github.com/operator-framework/operator-sdk

 

Remarks: As mentioned in our repo, declarative channel and chaincode flows use our home built CLI tools based on this patch. This patch didn’t go into Fabric codebase yet and needs some unit tests. If there are some volunteers for implementing unit tests, we will highly appreciate it! :)

 

Cheers and happy Fabricing in Kubernetes!

Hakan

 

From: Eryargi, Hakan
Sent: Thursday, 27 June 2019 12:59
To: fabric@...
Subject: Re: [Hyperledger Fabric] Hyperledger Fabric meets Kubernetes

 

Dear HL Fabric Community,

 

As promised, we had implemented support for Raft Orderer and also as a side effect for TLS and using actual domain names. This work is also published at our public GitHub repo.

 

Details can be found at relevant sections:

https://github.com/APGGroeiFabriek/PIVT#tls

https://github.com/APGGroeiFabriek/PIVT#scaled-up-raft-network

 

However, enabling TLS came with a huge cost, we lost transparent load balancing for peers and orderers.

 

As discussed in another email, we don’t need internal TLS since nothing is exposed to outer world. Even if we expose, since we have Ingress for TLS termination, internal TLS is still not required. As suggested by Yacov Manevich, I had created a Jira ticket that time, hopefully will be implemented soon.

https://jira.hyperledger.org/browse/FAB-15648

 

This is my post at Accenture’s public open source blog, contains some additional information which is not present in the GitHub repo (motivation, how it works, benefits regarding Accenture NFR's, etc.)

https://accenture.github.io/blog/2019/06/25/hl-fabric-meets-kubernetes.html

 

Last but not the least, please see the “Future (Dream) Work” section in the post.

https://accenture.github.io/blog/2019/06/25/hl-fabric-meets-kubernetes.html#future-dream-work

 

I’m not sure if we will have the resources to implement all of that, however there is one thing in particular I want to implement, which will be a major step towards that goal: making channel and chaincode flows declarative, i.e. given the desired state of network, flows will try to reach that state. Obviously one needs to query the current state of the network to achieve this. While it’s possible to implement this with current CLI tool, it’s not that easy and requires processing the output of CLI tool without additional fragile tools, like grep, awk, etc.

 

That’s why I also created a Jira ticket for making CLI scripting friendly:
https://jira.hyperledger.org/browse/FAB-15824

 

I’m guessing both Jira tickets are relatively easy to implement, so we will highly appreciate if these are implemented soon:)

 

Cheers and happy Fabricing in Kubernetes!

Hakan

 

 

From: Eryargi, Hakan
Sent: Tuesday, 4 June 2019 19:32
To: fabric@...
Subject: RE: [External] Re: [Hyperledger Fabric] Hyperledger Fabric meets Kubernetes

 

Hi,

 

We were aware of Cello, we didn’t try it but checked the docs. The tool we had implemented, call it fabric-kube and Cello are different. Maybe fabric-kube can be a complementary part of Cello but judging from the docs, it’s a bit hard to imagine that with current focus of Cello. But I guess better to discuss that with Cello maintainers :)

 

We also had investigated the existing work to run HL Fabric in Kubernetes before implementing fabric-kube. There are a few Helm charts out there and a few non-Helm based samples, and none of them is reducing complexity. Our main focus is reducing complexity and running Fabric in a managed environment -like Kubernetes-  instead of plain Docker containers in a DevOps (CI/CD) friendly way.

 

As mentioned we had developed fabric-kube for our own needs, we will continue to improve it again based on project’s needs, in particular will add support for Raft orderer and make it as easy as possible to add/remove organizations to an already running network. But for long term commitment, honestly I’m not sure if that is possible. That’s the reason we strongly encourage fabric community to take ownership of fabric-kube.

 

Best,

Hakan

 

From: fabric@... <fabric@...> On Behalf Of Brian Behlendorf
Sent: Tuesday, 4 June 2019 18:43
To: Brett T Logan <Brett.T.Logan@...>
Cc: fabric@...
Subject: [External] Re: [Hyperledger Fabric] Hyperledger Fabric meets Kubernetes

 

I got that.  I also realize Cello has a lot of this kind of work going on, but wasn't sure if it was right there.  This code or something like it should land somewhere, if not within a Fabric-related repo then documented clearly from the Fabric docs so someone else doesn't think it doesn't exist and re-builds it.  Or did the original author not realize Cello already has this?

 

Brian

 

On 6/4/19 9:12 AM, Brett T Logan wrote:

This isn't support within Fabric for Kubernetes, it is a set of tools (Helm Charts) for deploying the existing Fabric components

 

----- Original message -----
From: "Brian Behlendorf" <bbehlendorf@...>
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Hyperledger Fabric meets Kubernetes
Date: Tue, Jun 4, 2019 11:59 AM
 

Thanks Hakan.  And thank you to APG and Accenture NL for agreeing to open up the code.  With major contributions like this it's always best to engage the community at the start of the work, so you can build upon what's been done already, or contribute to existing efforts.  Hopefully you didn't duplicate much ongoing work.  Presuming it didn't, the best course will be to submit it as a PR to Gerrit, rather than just posting a link to a Github repo.  And with all contributions of code, hopefully it comes with an implied commitment to help maintain it going forward, as presumably you'd be maintaining it for your own needs yourselves going forward anyways.

 

Can a Fabric maintainer comment on the current or anticipated state of Kube support in Fabric is?  Whether this code is helpful or a different approach is being taken?

 

Brian

 

On 6/4/19 4:59 AM, Hakan Eryargi wrote:

Dear HL Fabric Community,

 

We are so happy and excited to announce that we have just opened our source code for running HL Fabric in Kubernetes :)

https://github.com/APGGroeiFabriek/PIVT

 

This repository contains a couple of Helm charts to:

 

·         Configure and launch the whole HL Fabric network, either:

o    A simple one, one peer per organization and Solo orderer

o    Or scaled up one, multiple peers per organization and Kafka orderer

·         Populate the network:

o    Create the channels, join peers to channels, update channels for Anchor peers

o    Install/Instantiate all chaincodes, or some of them, or upgrade them to newer version

·         Backup and restore the state of whole network

 

This work is a result of collaborative effort between APG and Accenture NL.

 

We had implemented these Helm charts for our project's needs, and as the results looks very promising, decided to share the source code with HL Fabric community. Hopefully it will fill a large gap! Special thanks to APG for allowing opening the source code :)

 

We strongly encourage the HL Fabric community to take ownership of this repository, extend it for further use cases, use it as a test bed and adapt it to the Fabric provided samples to get rif of endless Docker Compose files and Bash scripts.

 

Cheers and happy BlockChaining in Kubernetes!

Hakan Eryargi (r a f t)

 

 

 

 

 

 

 



This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________

www.accenture.com

 

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

 

 

 

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


Hyperledger Fabric Documentation Workgroup call - Western hemisphere - Fri, 03/06/2020 #cal-notice

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

Hyperledger Fabric Documentation Workgroup call - Western hemisphere

When:
Friday, 6 March 2020
4:00pm to 5:00pm
(GMT+00:00) Europe/London

Where:
https://zoom.us/j/6223336701

Organizer:
a_o-dowd@... +441962816761

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


Re: Question: How to recovery if blockfile crashed

Wenjian Qiao
 

In both cases, you can use the "peer node reset" command to reset all channels to the genesis block. Upon restart, the peer will receive blocks from an orderer and rebuild the block store and state db. Refer to https://hyperledger-fabric.readthedocs.io/en/release-1.4/commands/peernode.html for more information of the reset command.

For case 2, there is an option to manually copy the archived blockfile and delete all dependency DBs in the ledger. However, due to the involvement of manual steps, it is recommended to use the reset command unless there are lots of blocks that may take a long time to get blocks from an orderer.


Upcoming Event: Hyperledger Fabric Documentation Workgroup call - Western hemisphere - Fri, 03/06/2020 4:00pm-5:00pm #cal-reminder

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

Reminder: Hyperledger Fabric Documentation Workgroup call - Western hemisphere

When: Friday, 6 March 2020, 4:00pm to 5:00pm, (GMT+00:00) Europe/London

Where:https://zoom.us/j/6223336701

View Event

Organizer: Anthony O'Dowd a_o-dowd@... +441962816761

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


key voult

Bozhidar Ignatov
 

Hi everyone,

Is there any possibilities to use key voult service of AWS, Azure or Google for certs issuing and storing in Hyperledger Fabric nodes (orderers, peers and CAs)?

Regards,
Bozhidar
--

CST LTD
Bozhidar Ignatov

Software Team Lead



Documentation Workgroup: Agenda for Friday, 06 Mar

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

Hello!

We will hold the documentation workgroup call this Friday as usual -- with both an Eastern hemisphere and Western hemisphere call.

You can read all about last week's call at https://wiki.hyperledger.org/display/fabric/2020+02+28+DWG+Agenda It included a V2 status update from Pam and Joe, a discussion on LTS release documentation, a general discussion on token technologies including ERC20 and TTI/TTF, and an extensive discussion on the new Deployment guide which is coming along very nicely.

You can catch up with the recording: https://wiki.hyperledger.org/display/fabric/Recordings

You'll see that there are lots of interesting items for this week: https://wiki.hyperledger.org/display/fabric/2020+03+06+DWG+Agenda

Please feel free to contribute using the wiki, including helping to build next week's agenda: https://wiki.hyperledger.org/display/fabric/2020+03+13+DWG+Agenda

Thanks!

Pam, Anthony,  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 118A: Friday 06 Mar
                   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 118B: Friday 06 Mar
              1100 Central Daylight Time
                   1200 Eastern Daylight Time
                   0900 Pacific Daylight Time
                   1400 Brasil Time (BRT)
                   1700 Greenwich Mean Time
                   1800 Central European Time
                   1900 Moscow Standard Tim

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


Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere - Fri, 03/06/2020 #cal-notice

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

Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere

When:
Friday, 6 March 2020
6:00am to 7:00am
(GMT+00:00) Europe/London

Where:
https://zoom.us/j/6223336701

Organizer:
a_o-dowd@... +441962816761

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


Question: How to recovery if blockfile crashed

Lei Zhao
 

Hi
 if the blockfile crashed, peer supposed to be down, how to recover it?
in case
1. there is no other peers nor achiving.
2. there is no other peers, but exists old archived blockfile, how to let archived blockfile work.
Many thanks


Re: Restricting access to an ordering channel - how is that done?

Joe Alewine <joe.alewine@...>
 

Only ordering organizations have ordering system channel, so this is referring to those organizations. Peers are not joined to the ordering system channel.
 
Regards,
 
Joe Alewine
IBM Blockchain, Raleigh
 
rocket chat: joe-alewine
slack: joe.alewine
 
 
 

----- Original message -----
From: "Trevor Lee Oakley" <trevor@...>
Sent by: fabric@...
To: <fabric@...>
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] Restricting access to an ordering channel - how is that done?
Date: Thu, Mar 5, 2020 9:43 AM
 
I am working via the docs describing the channels for orderers and applications. I saw under 9.4.4 it states - 
 
"Note that any member with read access to the ordering system channel may see all channel creations, so this channel’s access should be restricted."
 
This is referring to peers seeing the txns on the ordering system channel and hence knowing about application channels. It states that should be restricted but how is that done? If the peer has all the txns for the channel config anyway, how can we restrict access?
 
Trevor
 


Restricting access to an ordering channel - how is that done?

Trevor Lee Oakley <trevor@...>
 

I am working via the docs describing the channels for orderers and applications. I saw under 9.4.4 it states - 
 
"Note that any member with read access to the ordering system channel may see all channel creations, so this channel’s access should be restricted."
 
This is referring to peers seeing the txns on the ordering system channel and hence knowing about application channels. It states that should be restricted but how is that done? If the peer has all the txns for the channel config anyway, how can we restrict access?
 
Trevor


BC for supply chain management

Mohan <mohan.search@...>
 

hi,

Can anyone help me to understand which is the suitable BC frame work for Supply chain management and why ?

regards
Mohan


Re: Criticial: Admin Certificate expired in Fabric production network V1.4. Lockout situation. #fabric #fabric-ca #tls #hyperledger-fabric

Yacov
 

The error has nothing to do with an expired certificate.
I suggest you turn on the MSP logging to debug level and then see why the policy wasn't satisfied.



From:        keerthycbe@...
To:        fabric@...
Date:        03/05/2020 03:56 PM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Criticial: Admin Certificate expired in Fabric production network V1.4. Lockout situation. #fabric #fabric-ca #tls #hyperledger-fabric
Sent by:        fabric@...




Hi Yacov
 
Thanks for your immediate reponse. We upgraded all our nodes to 1.4.6 with ORDERER_GENERAL_AUTHENTICATION_NOEXPIRATIONCHECKS flag set to true in orderer nodes. After this, we created a channel config update to add new admin certificate. This updated channel config was signed with old admin certificate and submitted it to orderer. There is an error in the orderer saying the channel config update did not meet the policy. Except the expired admin certificate, we are not sure what else could be wrong. Please let us know your thoughts.
 
Error details:
 
2020-03-05 10:42:01.024 UTC [orderer.common.broadcast] ProcessMessage -> WARN 8960 [channel: channel1 ] Rejecting broadcast of config message from 192.168.36.132:42070 because of error: error applying config update to existing channel 'channel1': error authorizing update: error validating DeltaSet: policy for [Value]  /Channel/Application/org1/MSP not satisfied: signature set did not satisfy policy
 
Thanks and Regards
Keerthi




Re: Criticial: Admin Certificate expired in Fabric production network V1.4. Lockout situation. #fabric #fabric-ca #tls #hyperledger-fabric

keerthycbe@...
 

Hi Yacov
 
Thanks for your immediate reponse. We upgraded all our nodes to 1.4.6 with ORDERER_GENERAL_AUTHENTICATION_NOEXPIRATIONCHECKS flag set to true in orderer nodes. After this, we created a channel config update to add new admin certificate. This updated channel config was signed with old admin certificate and submitted it to orderer. There is an error in the orderer saying the channel config update did not meet the policy. Except the expired admin certificate, we are not sure what else could be wrong. Please let us know your thoughts.
 
Error details:
 
2020-03-05 10:42:01.024 UTC [orderer.common.broadcast] ProcessMessage -> WARN 8960 [channel: channel1 ] Rejecting broadcast of config message from 192.168.36.132:42070 because of error: error applying config update to existing channel 'channel1': error authorizing update: error validating DeltaSet: policy for [Value]  /Channel/Application/org1/MSP not satisfied: signature set did not satisfy policy 
 
Thanks and Regards
Keerthi


Re: Configtx and docs - error?

Joe Alewine <joe.alewine@...>
 

The configuration of a channel is stored on the ledger, so semantically it is referred to as a "transaction", not just because it is stored on the ledger, but because the process for updating a channel involves a "configuration update transaction", in which the normal rules for approving, validating, and committing a transaction apply.
 
Keep in mind that a ledger will likely consist of several configuration transactions. The latest is the one that is used.
 
Check out this doc for some more information about updating channels: https://hyperledger-fabric.readthedocs.io/en/release-2.0/config_update.html
 
Regards,
 
Joe Alewine
IBM Blockchain, Raleigh
 
rocket chat: joe-alewine
slack: joe.alewine
 
 
 

----- Original message -----
From: "Trevor Lee Oakley" <trevor@...>
Sent by: fabric@...
To: <fabric@...>
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] Configtx and docs - error?
Date: Thu, Mar 5, 2020 3:31 AM
 
I have seen this - 
Shared configuration for a Hyperledger Fabric blockchain network is stored in a collection configuration transactions, one per channel. Each configuration transaction is usually referred to by the shorter name configtx.
 
From - 
 
Under 9.4
 
I cannot really understand that summary sentence, Is this referring to configtx.yaml? Also this is referring to txns and then it states there is a collection of config txns. I think the sentence needs expanding to make it clearer. It is very confused. I assume from this there is a collection of txns and each one is referred to as configtx. Is this referring to configtxgen and using the yaml file to create the channel or change it?
 
Trevor
 
 
 


Re: Hyperledger Fabric meets Kubernetes

Hakan Eryargi
 

Hi Craig,

Thanks. Indeed, this is the most advanced and convenient way of running Fabric in Kubernetes.

I will work with all 1.4.x versions. Limitation is only for cryptogen tool for creating the certificates. It should be < 1.4.3

We had tested it with pre 2.0 release. It's not compatible with the new chaincode lifecycle so you cannot use V2_0 capability. When capability is set to V1_4_x, it worked but Fabric didnt feel much stable that time.

Best,
Hakan

On Wed, Mar 4, 2020 at 5:04 PM Craig Allwardt <craiga@...> wrote:
Hello,

The documentation lists fabric 1.42 and 1.43 have you tested any of these with fabric2?  This work looks really promising

Thanks

CHA

From: fabric@... <fabric@...> on behalf of Eryargi, Hakan via Lists.Hyperledger.Org <hakan.eryargi=accenture.com@...>
Sent: Friday, February 28, 2020 7:00 AM
To: fabric@... <fabric@...>
Cc: fabric@... <fabric@...>
Subject: Re: [Hyperledger Fabric] Hyperledger Fabric meets Kubernetes
 

Dear All,

 

Below is a summary of recent updates to our Helm charts:

 

  • Support for hybrid networks. We also provided a sample of spreading the Fabric network over three Kubernetes clusters, covering all possible scenarios, with orderer, without orderer, etc.
    The same mechanism can be used for any combination of hybrid networks, some parts running on premises as plain Docker containers, or on bare metal or whatever.
    https://github.com/APGGroeiFabriek/PIVT/blob/master/README.md#cross-cluster-raft-network

  • Declaratively make almost arbitrary channel config updates. There is still room to improve here but it’s quite easy to extend and add more functionality
    https://github.com/APGGroeiFabriek/PIVT/blob/master/README.md#updating-channel-configuration

  • Support for Raft orderer without enabling TLS globally.  Thanks to Fabric 1.4.5 release, this is possible since FAB-15648 is backported to 1.4 branch.
    We were waiting for this feature since long time for transparent load balancing inside Kubernetes. Already applied to our environments and works great.
    But eventually we need to enable TLS and lose transparent load balancing again.
    I believe it will be really useful separating client and cluster facing ports on peers and orderers.  Please vote for FAB-17111 if you think similar.
    https://github.com/APGGroeiFabriek/PIVT/blob/master/README.md#scaled-up-raft-network-without-tls

  • Support and sample for Golang chaincode. Due to GOPATH variable they should be handled differently.
    Nobody reported any issue about Java chaincode, so possibly it just works out of the box.

So, cheers and happy Fabricing in Kubernetes as always!

Hakan



From: Eryargi, Hakan
Sent: Monday, 12 August 2019 15:13
To: 'fabric@...' <fabric@...>
Subject: RE: [Hyperledger Fabric] Hyperledger Fabric meets Kubernetes

 

Dear All,

 

We just recently published new functionality for our Helm charts. Managing peer organizations is now declarative.

 

To add new peer organizations:

  • Update configtx/crypto-config/network.yaml accordingly
  • Perform a cryptogen extend
  • Perform a helm upgrade
  • Run the new peer-org-flow

 

That’s it. This sequence launches everything, adds missing organizations to consortiums using the information in configtx.yaml and adds missing organizations to existing channels using the information in network.yaml.

 

Afterwards run the channel and chaincode flows to create new channels and populate existing channels and chaincodes regarding new organizations.

 

More details here:

https://github.com/APGGroeiFabriek/PIVT/blob/master/README.md#adding-new-peers-to-organizations

 

One of our initial promises was making it as easy as possible to add/remove organizations to an already running network and I guess we kept that promise :) Possibly this can’t get easier without a Fabric operator.

 

So, cheers and happy Fabricing in Kubernetes!

Hakan

 

 

From: Eryargi, Hakan
Sent: Wednesday, 31 July 2019 15:26
To: 'fabric@...' <fabric@...>
Subject: RE: [Hyperledger Fabric] Hyperledger Fabric meets Kubernetes

 

Dear HL Fabric Community,

 

We just recently published new functionality for our Helm charts:

https://github.com/APGGroeiFabriek/PIVT

 

  • Now the channel and chaincode flows are declarative and idempotent. They can be run several times. They query the network state and take action only required. They create channels only if not created, join peers to channels only not joined, install/instantiate/upgrade chaincodes only required, etc.
  • We have a new flow for adding new peer organization(s) to an already running network. It both adds new orgs to existing channels and also to consortiums.

 

Our next aim is making peer org flow declarative and idempotent.

 

I think, we are now so close to wrapping up everything in a Kubernetes operator, it will be even closer with a declarative peer org flow.

 

On the other hand, unfortunately we lack the Go language knowledge and experience. But still this looks so achievable by using CoreOS’s operator SDK. If there are experienced Go developers out there and willing to contribute such a project, please contact me.

https://github.com/operator-framework/operator-sdk

 

Remarks: As mentioned in our repo, declarative channel and chaincode flows use our home built CLI tools based on this patch. This patch didn’t go into Fabric codebase yet and needs some unit tests. If there are some volunteers for implementing unit tests, we will highly appreciate it! :)

 

Cheers and happy Fabricing in Kubernetes!

Hakan

 

From: Eryargi, Hakan
Sent: Thursday, 27 June 2019 12:59
To: fabric@...
Subject: Re: [Hyperledger Fabric] Hyperledger Fabric meets Kubernetes

 

Dear HL Fabric Community,

 

As promised, we had implemented support for Raft Orderer and also as a side effect for TLS and using actual domain names. This work is also published at our public GitHub repo.

 

Details can be found at relevant sections:

https://github.com/APGGroeiFabriek/PIVT#tls

https://github.com/APGGroeiFabriek/PIVT#scaled-up-raft-network

 

However, enabling TLS came with a huge cost, we lost transparent load balancing for peers and orderers.

 

As discussed in another email, we don’t need internal TLS since nothing is exposed to outer world. Even if we expose, since we have Ingress for TLS termination, internal TLS is still not required. As suggested by Yacov Manevich, I had created a Jira ticket that time, hopefully will be implemented soon.

https://jira.hyperledger.org/browse/FAB-15648

 

This is my post at Accenture’s public open source blog, contains some additional information which is not present in the GitHub repo (motivation, how it works, benefits regarding Accenture NFR's, etc.)

https://accenture.github.io/blog/2019/06/25/hl-fabric-meets-kubernetes.html

 

Last but not the least, please see the “Future (Dream) Work” section in the post.

https://accenture.github.io/blog/2019/06/25/hl-fabric-meets-kubernetes.html#future-dream-work

 

I’m not sure if we will have the resources to implement all of that, however there is one thing in particular I want to implement, which will be a major step towards that goal: making channel and chaincode flows declarative, i.e. given the desired state of network, flows will try to reach that state. Obviously one needs to query the current state of the network to achieve this. While it’s possible to implement this with current CLI tool, it’s not that easy and requires processing the output of CLI tool without additional fragile tools, like grep, awk, etc.

 

That’s why I also created a Jira ticket for making CLI scripting friendly:
https://jira.hyperledger.org/browse/FAB-15824

 

I’m guessing both Jira tickets are relatively easy to implement, so we will highly appreciate if these are implemented soon:)

 

Cheers and happy Fabricing in Kubernetes!

Hakan

 

 

From: Eryargi, Hakan
Sent: Tuesday, 4 June 2019 19:32
To: fabric@...
Subject: RE: [External] Re: [Hyperledger Fabric] Hyperledger Fabric meets Kubernetes

 

Hi,

 

We were aware of Cello, we didn’t try it but checked the docs. The tool we had implemented, call it fabric-kube and Cello are different. Maybe fabric-kube can be a complementary part of Cello but judging from the docs, it’s a bit hard to imagine that with current focus of Cello. But I guess better to discuss that with Cello maintainers :)

 

We also had investigated the existing work to run HL Fabric in Kubernetes before implementing fabric-kube. There are a few Helm charts out there and a few non-Helm based samples, and none of them is reducing complexity. Our main focus is reducing complexity and running Fabric in a managed environment -like Kubernetes-  instead of plain Docker containers in a DevOps (CI/CD) friendly way.

 

As mentioned we had developed fabric-kube for our own needs, we will continue to improve it again based on project’s needs, in particular will add support for Raft orderer and make it as easy as possible to add/remove organizations to an already running network. But for long term commitment, honestly I’m not sure if that is possible. That’s the reason we strongly encourage fabric community to take ownership of fabric-kube.

 

Best,

Hakan

 

From: fabric@... <fabric@...> On Behalf Of Brian Behlendorf
Sent: Tuesday, 4 June 2019 18:43
To: Brett T Logan <Brett.T.Logan@...>
Cc: fabric@...
Subject: [External] Re: [Hyperledger Fabric] Hyperledger Fabric meets Kubernetes

 

I got that.  I also realize Cello has a lot of this kind of work going on, but wasn't sure if it was right there.  This code or something like it should land somewhere, if not within a Fabric-related repo then documented clearly from the Fabric docs so someone else doesn't think it doesn't exist and re-builds it.  Or did the original author not realize Cello already has this?

 

Brian

 

On 6/4/19 9:12 AM, Brett T Logan wrote:

This isn't support within Fabric for Kubernetes, it is a set of tools (Helm Charts) for deploying the existing Fabric components

 

----- Original message -----
From: "Brian Behlendorf" <bbehlendorf@...>
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Hyperledger Fabric meets Kubernetes
Date: Tue, Jun 4, 2019 11:59 AM
 

Thanks Hakan.  And thank you to APG and Accenture NL for agreeing to open up the code.  With major contributions like this it's always best to engage the community at the start of the work, so you can build upon what's been done already, or contribute to existing efforts.  Hopefully you didn't duplicate much ongoing work.  Presuming it didn't, the best course will be to submit it as a PR to Gerrit, rather than just posting a link to a Github repo.  And with all contributions of code, hopefully it comes with an implied commitment to help maintain it going forward, as presumably you'd be maintaining it for your own needs yourselves going forward anyways.

 

Can a Fabric maintainer comment on the current or anticipated state of Kube support in Fabric is?  Whether this code is helpful or a different approach is being taken?

 

Brian

 

On 6/4/19 4:59 AM, Hakan Eryargi wrote:

Dear HL Fabric Community,

 

We are so happy and excited to announce that we have just opened our source code for running HL Fabric in Kubernetes :)

https://github.com/APGGroeiFabriek/PIVT

 

This repository contains a couple of Helm charts to:

 

·         Configure and launch the whole HL Fabric network, either:

o    A simple one, one peer per organization and Solo orderer

o    Or scaled up one, multiple peers per organization and Kafka orderer

·         Populate the network:

o    Create the channels, join peers to channels, update channels for Anchor peers

o    Install/Instantiate all chaincodes, or some of them, or upgrade them to newer version

·         Backup and restore the state of whole network

 

This work is a result of collaborative effort between APG and Accenture NL.

 

We had implemented these Helm charts for our project's needs, and as the results looks very promising, decided to share the source code with HL Fabric community. Hopefully it will fill a large gap! Special thanks to APG for allowing opening the source code :)

 

We strongly encourage the HL Fabric community to take ownership of this repository, extend it for further use cases, use it as a test bed and adapt it to the Fabric provided samples to get rif of endless Docker Compose files and Bash scripts.

 

Cheers and happy BlockChaining in Kubernetes!

Hakan Eryargi (r a f t)

 

 

 

 

 

 

 



This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________

www.accenture.com

 

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

 

 

 

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


Configtx and docs - error?

Trevor Lee Oakley <trevor@...>
 

I have seen this - 
Shared configuration for a Hyperledger Fabric blockchain network is stored in a collection configuration transactions, one per channel. Each configuration transaction is usually referred to by the shorter name configtx.
 
From - 
 
Under 9.4
 
I cannot really understand that summary sentence, Is this referring to configtx.yaml? Also this is referring to txns and then it states there is a collection of config txns. I think the sentence needs expanding to make it clearer. It is very confused. I assume from this there is a collection of txns and each one is referred to as configtx. Is this referring to configtxgen and using the yaml file to create the channel or change it?
 
Trevor
 
 


Re: Criticial: Admin Certificate expired in Fabric production network V1.4. Lockout situation. #fabric #fabric-ca #tls #hyperledger-fabric

Yacov
 

It should work with 1.4.6, there is an integration test that simulates this very thing:

https://github.com/hyperledger/fabric/blob/release-1.4/integration/e2e/cft_test.go#L471-L600

When("admin certificate expires", func() {


It("is still possible to replace them", func() {

Make sure to boot your orderer(s) with ORDERER_GENERAL_AUTHENTICATION_NOEXPIRATIONCHECKS=true  
to prevent checking for expiration.





From:        keerthycbe@...
To:        fabric@...
Date:        03/05/2020 07:43 AM
Subject:        [EXTERNAL] [Hyperledger Fabric] Criticial: Admin Certificate expired in Fabric production network V1.4. Lockout situation. #fabric #fabric-ca #tls #hyperledger-fabric
Sent by:        fabric@...




We have a production blockchain network using  Fabric 1.4.0. Recently we came to know that all the org admin certs expired. We were trying to update the network to replace the admin certificate with new ceritifcate. We did this channel config update with old admin cert. But the network checks for signing identity expiry and rejects the channel config update by the old admin cert. We also looked for this kind of issue reported anywhere and then we encountered FAB-16141 where the same issue has been reported. Based on the comments in that issue, I understood that the Fabric has been updated in v2.0 to allow to replace admin cert even if it is expired and the same has been backported to v1.4.X. As our current network is set up with 1.4.0, we upgraded it to 1.4.6 belivieing this had fix for this. But this did not work and we still have the same issue. The chaincode transactions are going throught but we can't perfrom administrative operations using this expired admin cert. we are in a lockout situation and we don't know how to get out of this. We really need immediate help here to address this issue. Our company is part of Hyperledger consoritum. As Fabric 1.4 provides LTS, I'm asking for help here. Please let me know if this is not the right place to ask and if I've to go to different forum to get immediate attention and remedy for this issue.  




Upcoming Event: Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere - Fri, 03/06/2020 6:00am-7:00am #cal-reminder

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

Reminder: Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere

When: Friday, 6 March 2020, 6:00am to 7:00am, (GMT+00:00) Europe/London

Where:https://zoom.us/j/6223336701

View Event

Organizer: Anthony O'Dowd a_o-dowd@... +441962816761

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

3721 - 3740 of 11527