|
Documentation Workgroup: Agenda for Friday, 28 Feb
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+21+DWG+Agenda It included a V2 status update from Pam and Joe, a review of the 1.4.5 LTS release, an update on the Deployment guide including CA deployment instructions. Thanks again to Joe for recording. Catch up here: 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+02+28+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+06+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 117A: Friday 28 Feb 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 117B: Friday 28 Feb 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
|
|
|
|
Upcoming Event: Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere - Fri, 02/28/2020 6:00am-7:00am
#cal-reminder
fabric@lists.hyperledger.org Calendar <fabric@...>
Reminder: Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere When: Friday, 28 February 2020, 6:00am to 7:00am, (GMT+00:00) Europe/London Where:https://zoom.us/j/6223336701 Organizer: Anthony O'Dowd a_o-dowd@... +441962816761 Description: Documentation workgroup call.
|
|
|
|
ANNOUNCEMENT: Hyperledger Fabric v2.0.1 is now available!
David Enyeart
The first set of fixes on v2.0 is now available. See release notes for details:
|
|
|
|
Re: Doubt in defining an Asset
Matthew White
Hi - the world state is a set of key-value pairs - the value can be whatever data format you wish. Marshalling these is part of the job of the client applications.
Regards, Matthew.
Matthew B White IBM Blockchain Solutions Architect
Email me at WHITEMAT@...
Find me on StackOverflow, and generally at calanais.me.uk
Note: restricted availability for meetings 14:30 to 17:00 UK Tuesday
IBM United Kingdom Limited, Hursley Park, Winchester, Hampshire, SO21 2JN
"The wrong answers are the ones you go looking for when the right answers stare you in the face" ----- Original message ----- IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
|
|
|
|
Doubt in defining an Asset
t-amsi@...
Hi,
I had two questions.
I wanted to know if it would be possible to define an asset which is self-referential. Also when defining assets such as these, do they work in the traditional way of how we think about self-referential structures? i.e do they store the address of the node but now the address is on the blockchain DB.
I’m trying something that would look like –
type playlist struct { name string `json:"name"` head *song `json:"head"` nowPlaying *song `json:"nowPlaying"` }
Thanks for any help!
Ameya Sinha.
|
|
|
|
回复: [Hyperledger Fabric] Hashing of World State.
david liu <david-khala@...>
in what aspect you mean hashing the world state?
发件人: fabric@... <fabric@...> 代表 qwert limframe <qwertlimframe@...>
发送时间: 2020年2月27日 0:00 收件人: hyperledger-fabric@... <hyperledger-fabric@...> 主题: [Hyperledger Fabric] Hashing of World State. Is the World State Hashed?
If yes, though world state is a constantly changing database. why is it hashed?
|
|
|
|
Hashing of World State.
qwert limframe
Is the World State Hashed? If yes, though world state is a constantly changing database. why is it hashed?
|
|
|
|
Re: ANNOUNCEMENT: Hyperledger Fabric v1.4.6 is now available!
David Enyeart
A few more fixes got merged in the last week, so we went ahead and released Fabric and Fabric CA v1.4.6 today. Hyperledger Fabric and Fabric CA v1.4.5 are now available. See details of the included fixes in the release notes: https://github.com/hyperledger/fabric/releases/tag/v1.4.5 https://github.com/hyperledger/fabric-ca/releases/tag/v1.4.5 We have received some questions about LTS release status. v1.4.x continues to be the LTS release and 3rd digit patch releases will continue to be made available on the v1.4.x release stream. Once the maintainers designate a v2.x minor release as the next LTS release, there will be an overlap period where maintenance fixes will continue to be provided for both releases, to allow existing production networks time to perform rolling upgrades. Thanks to all the community members who reported an issue or provided a fix in the v1.4.5 release! Your efforts help to ensure that Fabric is well tuned for production workloads and operations. Dave Enyeart _._,_._,_
|
|
|
|
回复: [Hyperledger Fabric]
#fabric
#fabric-questions
#fabric-ca
#fabric-ca-client
david liu <david-khala@...>
Before you blame it to fabric-ca-client, please help to re-test it again with `fabric-ca-client` command tool.
发件人: fabric@... <fabric@...> 代表 chauhan.kartik25@... <chauhan.kartik25@...>
发送时间: 2020年2月21日 20:15 收件人: fabric@... <fabric@...> 主题: [Hyperledger Fabric] #fabric #fabric-questions #fabric-ca #fabric-ca-client I tried to register & enroll a user with the name 苏南 on Fabric-CA. The registration is getting successful but getting below error during enrollment. The error clearly says that the letters are not supported in UTF-8 encoding. Can I change the default encoding while enrolling? If yes, which enoding scheme do I've to use to support Chinese letters?
Also, I tried to create a
|
|
|
|
Re: [External] RE: [Hyperledger Fabric] Reverting from incorrect capability version
Eryargi, Hakan
I see.
Then maybe orderer should accept a version it doesn’t recognize only when
This way, at least you can give the users a chance to notice and correct their errors instead of making the channel unusable for good.
Best, Hakan
From: Joe Alewine <Joe.Alewine@...>
Hakan,
I understand your concern. However, the only way for the ordering service to know about the newest application capability levels is to keep it at the latest binary version. A 1.3 ordering node would not, for example, know about any 1.4.x application capabilities, and would therefore reject even valid ones. I'm not sure that's a better system than what we currently have.
Regards,
Joe Alewine IBM Blockchain, Raleigh
rocket chat: joe-alewine slack: joe.alewine
|
|
|
|
Re: Reverting from incorrect capability version
Jason Yellick <jyellick@...>
Unfortunately, this is "working as designed". We could revisit the validation that ordering does, but the original capabilities concept was to allow independent management of the orderers and peers. From the documentation:
https://hyperledger-fabric.readthedocs.io/en/release-1.4/capabilities_concept.html "Take caution when specifying or modifying an application capability. Because the ordering service does not validate that the capability level is valid, it will allow a channel to be created (or modified) to contain, for example, a v1.8 application capability even if no such capability exists. Any peer attempting to read a configuration block with this capability would, as we have shown, crash, and even if it was possible to modify the channel once again to a valid capability, it would not matter, as no peer would be able to get past the block with the invalid v1.8 capability." Basically, the idea is to allow you to keep your orderers at an older level, while upgrading your peers and enabling new functionality for them. As far as recovery goes, your only practical option is to revert to a backup taken before the capability was introduced. The other option would be to create a custom build of your peer which supports this capability (add an entry with your capability to this map: https://github.com/hyperledger/fabric/blob/add77fa9803c768897f0bbfb9046c64345179de2/common/capabilities/application.go#L50-L60 ) though you would need to maintain this forked code indefinitely. Thanks, ~Jason
----- Original message -----
|
|
|
|
Re: Reverting from incorrect capability version
Joe Alewine <joe.alewine@...>
Hakan,
I understand your concern. However, the only way for the ordering service to know about the newest application capability levels is to keep it at the latest binary version. A 1.3 ordering node would not, for example, know about any 1.4.x application capabilities, and would therefore reject even valid ones. I'm not sure that's a better system than what we currently have.
Regards,
Joe Alewine
IBM Blockchain, Raleigh
rocket chat: joe-alewine
slack: joe.alewine
----- Original message -----
|
|
|
|
Re: Reverting from incorrect capability version
Eryargi, Hakan
Hi Joe,
Thanks for the clarification. So, there is no way of reverting back from that state except restoring from a backup.
I guess it’s a good idea to guard against this at orderer as it’s so easy to make a mistake here, especially regarding capability versions does not necessarily follow Fabric versions.
Best, Hakan
From: Joe Alewine <Joe.Alewine@...>
As it says in our conceptual documentation on capabilities:
Take caution when specifying or modifying an application capability. Because the ordering service does not validate that the capability level is valid, it will allow a channel to be created (or modified) to contain, for example, a v1.8 application capability even if no such capability exists. Any peer attempting to read a configuration block with this capability would, as we have shown, crash, and even if it was possible to modify the channel once again to a valid capability, it would not matter, as no peer would be able to get past the block with the invalid v1.8 capability.
Regards,
Joe Alewine IBM Blockchain, Raleigh
rocket chat: joe-alewine slack: joe.alewine
|
|
|
|
Re: Reverting from incorrect capability version
Joe Alewine <joe.alewine@...>
As it says in our conceptual documentation on capabilities:
Take caution when specifying or modifying an application capability. Because the ordering service does not validate that the capability level is valid, it will allow a channel to be created (or modified) to contain, for example, a v1.8 application capability even if no such capability exists. Any peer attempting to read a configuration block with this capability would, as we have shown, crash, and even if it was possible to modify the channel once again to a valid capability, it would not matter, as no peer would be able to get past the block with the invalid v1.8 capability.
Regards,
Joe Alewine
IBM Blockchain, Raleigh
rocket chat: joe-alewine
slack: joe.alewine
----- Original message -----
|
|
|
|
Re: Reverting from incorrect capability version
Eryargi, Hakan
Sure, they are attached.
From: Yacov Manevich <YACOVM@...>
Can you attach logs?
This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links and attachments.
|
|
|
|
Re: Reverting from incorrect capability version
Yacov
Can you attach logs?
toggle quoted messageShow quoted text
From: "Eryargi, Hakan via Lists.Hyperledger.Org" <hakan.eryargi=accenture.com@...> To: Yacov Manevich <YACOVM@...> Cc: fabric@... Date: 02/24/2020 01:51 PM Subject: Re: [External] Re: [Hyperledger Fabric] Reverting from incorrect capability version Sent by: fabric@... Yup exactly that happened. I made a config update for application capability for version V1_4_3, orderers accepted the block and peers crashed. Below json path to be more precise: .channel_group.groups.Application.values.Capabilities.value.capabilities Fabric binary version is 1.4.4 for both peers and orderers.
From: Yacov Manevich <YACOVM@...>
Sent: Monday, 24 February 2020 12:45 To: Eryargi, Hakan <hakan.eryargi@...> Cc: fabric@... Subject: [External] Re: [Hyperledger Fabric] Reverting from incorrect capability version This message is
from an EXTERNAL SENDER - be CAUTIOUS, particularly with links and attachments. Did you manage to reach a situation where the orderers accepted the block but the peers didn't? Were the orderers at a higher software version than the peers? From: "Eryargi, Hakan via Lists.Hyperledger.Org" <hakan.eryargi=accenture.com@...> To: "fabric@..." <fabric@...> Cc: fabric@... Date: 02/24/2020 01:41 PM Subject: [EXTERNAL] [Hyperledger Fabric] Reverting from incorrect capability version Sent by: fabric@... Hi, Is there a way of reverting from an incorrect capability version? (except restoring the whole Fabric network from a backup) For example Application capability V1_4_3 does not exist, and when a config update is performed for that version, orderers accept the value but peers crash immediately when they receive the update block from orderer. Making another config update will not help in this case as peers crash immediately when they receive the first update. If my understanding is correct, this is actually very dangerous behavior. The whole channel may render unusable. Maybe orderers should not accept the value in the first place? Thanks, Hakan
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
|
|
|
|
Re: [External] Re: [Hyperledger Fabric] Reverting from incorrect capability version
Eryargi, Hakan
Yup exactly that happened.
I made a config update for application capability for version V1_4_3, orderers accepted the block and peers crashed.
Below json path to be more precise: .channel_group.groups.Application.values.Capabilities.value.capabilities
Fabric binary version is 1.4.4 for both peers and orderers.
From: Yacov Manevich <YACOVM@...>
This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links and attachments.
Did you manage to reach a situation where the orderers accepted the block but the peers didn't? Were the orderers at a higher software version than the peers?
|
|
|
|
Re: Reverting from incorrect capability version
Yacov
Did you manage to reach a situation where
the orderers accepted the block but the peers didn't? Were the orderers
at a higher software version than the peers?
From: "Eryargi, Hakan via Lists.Hyperledger.Org" <hakan.eryargi=accenture.com@...> To: "fabric@..." <fabric@...> Cc: fabric@... Date: 02/24/2020 01:41 PM Subject: [EXTERNAL] [Hyperledger Fabric] Reverting from incorrect capability version Sent by: fabric@... Hi, Is there a way of reverting from an incorrect capability version? (except restoring the whole Fabric network from a backup) For example Application capability V1_4_3 does not exist, and when a config update is performed for that version, orderers accept the value but peers crash immediately when they receive the update block from orderer. Making another config update will not help in this case as peers crash immediately when they receive the first update. If my understanding is correct, this is actually very dangerous behavior. The whole channel may render unusable. Maybe orderers should not accept the value in the first place? Thanks, Hakan 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
|
|
|
|
Reverting from incorrect capability version
Eryargi, Hakan
Hi,
Is there a way of reverting from an incorrect capability version? (except restoring the whole Fabric network from a backup)
For example Application capability V1_4_3 does not exist, and when a config update is performed for that version, orderers accept the value but peers crash immediately when they receive the update block from orderer. Making another config update will not help in this case as peers crash immediately when they receive the first update.
If my understanding is correct, this is actually very dangerous behavior. The whole channel may render unusable.
Maybe orderers should not accept the value in the first place?
Thanks, Hakan 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
|
|
|
|
Error in Commercial Paper Example
Trevor Lee Oakley <trevor@...>
The first part works, then the final commit fails (page 202 of the Fabric 2.0 manual) -
peer lifecycle chaincode commit -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --peerAddresses localhost:7051 --tlsRootCertFiles ${PEER0_ORG1_CA} --peerAddresses localhost:9051 --tlsRootCertFiles ${PEER0_ORG2_CA} --channelID mychannel --name papercontract -v 0 --sequence 1 --tls --cafile $ORDERER_CA --waitForEvent
Error: proposal failed with status: 500 - failed to invoke backing implementation of 'CommitChaincodeDefinition': chaincode definition not agreed to by this org (Org1MSP) ubuntu@ip-10-0-1-151:~/fabric-samples/commercial-paper/organization/magnetocorp$ I tried switching to Digibank, sourcing the file for that Org and the same error. It seems related to the definition but that was approved.
:~/fabric-samples/commercial-paper/organization/magnetocorp$ peer lifecycle chaincode queryinstalled
Installed chaincodes on peer: Package ID: cp_0:71f681bb6359681f7bcde58ce3521cd49364409668e361b90255496a0be31bc6, Label: cp_0 ubuntu@ip-10-0-1-151:~/fabric-samples/commercial-paper/organization/magnetocorp$ What am I missing?
|
|
|
"David Enyeart" ---02/20/2020 08:58:02 AM---Hyperledger Fabric and Fabric CA v1.4.5 are now available. See details of the included fixes in the