markparz (Thu, 02 Feb 2017 23:31:56 GMT):
Channel used for technical discussions of both endorsing and committing along with Gossip.
markparz (Thu, 02 Feb 2017 23:33:00 GMT):
Channel used for technical discussions of both endorser and committer.
nickgaski (Thu, 02 Feb 2017 23:49:03 GMT):
Has joined the channel.
C0rWin (Fri, 03 Feb 2017 00:11:37 GMT):
Has joined the channel.
salmanbaset (Fri, 03 Feb 2017 01:19:59 GMT):
Has joined the channel.
tuand (Fri, 03 Feb 2017 02:30:08 GMT):
Has joined the channel.
yacovm (Fri, 03 Feb 2017 02:36:03 GMT):
Has joined the channel.
Ratnakar (Fri, 03 Feb 2017 02:52:26 GMT):
Has joined the channel.
grapebaba (Fri, 03 Feb 2017 06:26:26 GMT):
Has joined the channel.
frbrkoala (Fri, 03 Feb 2017 07:02:19 GMT):
Has joined the channel.
nvlasov (Fri, 03 Feb 2017 07:13:26 GMT):
Has joined the channel.
cca88 (Fri, 03 Feb 2017 08:21:36 GMT):
Has joined the channel.
dave.enyeart (Fri, 03 Feb 2017 11:20:57 GMT):
Has joined the channel.
jdockter (Fri, 03 Feb 2017 11:39:24 GMT):
Has joined the channel.
wlahti (Fri, 03 Feb 2017 13:37:55 GMT):
Has joined the channel.
silliman (Fri, 03 Feb 2017 13:57:16 GMT):
Has joined the channel.
jeffgarratt (Fri, 03 Feb 2017 14:38:59 GMT):
Has joined the channel.
jeffgarratt (Fri, 03 Feb 2017 14:39:16 GMT):
wow, the elevator tone is a bit scary when you join :)
gormand (Fri, 03 Feb 2017 14:43:17 GMT):
Has joined the channel.
muralisr (Fri, 03 Feb 2017 16:25:15 GMT):
Has joined the channel.
marcusvcs (Fri, 03 Feb 2017 18:48:12 GMT):
Has joined the channel.
rickr (Fri, 03 Feb 2017 19:02:47 GMT):
Has joined the channel.
fz (Fri, 03 Feb 2017 19:28:18 GMT):
Has joined the channel.
karkal (Fri, 03 Feb 2017 19:53:34 GMT):
Has joined the channel.
jiangyaoguo (Sat, 04 Feb 2017 01:31:41 GMT):
Has joined the channel.
genggjh (Sat, 04 Feb 2017 03:44:55 GMT):
Has joined the channel.
lehors (Sun, 05 Feb 2017 09:06:03 GMT):
Has joined the channel.
mandler (Sun, 05 Feb 2017 10:47:43 GMT):
Has joined the channel.
mastersingh24 (Sun, 05 Feb 2017 18:45:00 GMT):
Has joined the channel.
mastersingh24 (Sun, 05 Feb 2017 18:45:17 GMT):
@jeffgarratt - seriously - quite scary
mastersingh24 (Sun, 05 Feb 2017 18:46:00 GMT):
@greg.haskins @muralisr - I'm looking at https://gerrit.hyperledger.org/r/#/c/4943/
greg.haskins (Sun, 05 Feb 2017 18:46:00 GMT):
Has joined the channel.
mastersingh24 (Sun, 05 Feb 2017 18:51:59 GMT):
does this mean that when sending over a deploy from say the NodeJS SDK that a Dockerfile should / must no longer be included in the archive?
greg.haskins (Sun, 05 Feb 2017 19:05:16 GMT):
@mastersingh24 "should not" is most appropriate
greg.haskins (Sun, 05 Feb 2017 19:05:24 GMT):
if you add one, it will be completely disregarded
greg.haskins (Sun, 05 Feb 2017 19:05:41 GMT):
but nothing will break, at least at the peer level
greg.haskins (Sun, 05 Feb 2017 19:06:10 GMT):
(obviously if you were somehow taking advantage of the dockerfile for your chaincode to do something for you, that would break
mastersingh24 (Sun, 05 Feb 2017 20:12:53 GMT):
cool - that's what it looked like to me as well - but just wanted to make sure. And of course with the ccenv container we no longer need to vendor the fabric / shim src?
greg.haskins (Sun, 05 Feb 2017 20:24:04 GMT):
Correct. If you do not vendor the shim, it will implicitly give you the one that matches the peer
greg.haskins (Sun, 05 Feb 2017 20:24:25 GMT):
If you do vendor it, the vendor should override
Honglei (Sun, 05 Feb 2017 23:57:33 GMT):
Has joined the channel.
hanhzf (Mon, 06 Feb 2017 03:36:40 GMT):
Has joined the channel.
bryanhuang (Mon, 06 Feb 2017 04:34:31 GMT):
Has joined the channel.
gennadyl (Mon, 06 Feb 2017 08:20:23 GMT):
Has joined the channel.
david.peyronnin (Mon, 06 Feb 2017 09:52:46 GMT):
Has joined the channel.
mastersingh24 (Mon, 06 Feb 2017 13:36:15 GMT):
@greg.haskins - https://jira.hyperledger.org/browse/FAB-2046 - I imagine that this was likely a point in time statement? I have not tried this using snapshot builds, but I assume that this was likely caused by the fact the the published ccenv image(s) have not been updated since we added these packages?
greg.haskins (Mon, 06 Feb 2017 13:37:28 GMT):
your assessment sounds reasonable to me
greg.haskins (Mon, 06 Feb 2017 13:38:29 GMT):
basically, we _still_ dont support anything but building from source (FAB-678) and if you do, the shim should be tightly coupled to the peer/fabric by virtue of sharing the source
greg.haskins (Mon, 06 Feb 2017 13:39:02 GMT):
once FAB-678 is in place, we will continue to have that tight coupling even with dockerhub images and binary deployments
mastersingh24 (Mon, 06 Feb 2017 13:39:18 GMT):
cool
greg.haskins (Mon, 06 Feb 2017 13:39:21 GMT):
until then, any mismatches are probably people pulling incompatible things together
mastersingh24 (Mon, 06 Feb 2017 13:39:30 GMT):
that's what I figured
muralisr (Mon, 06 Feb 2017 13:41:12 GMT):
one thing @mastersingh24 ... this is besides the main point ... but ACL api's would likely change too (and they don;t work now). So one option would be to just release note that for alpha
harrijk (Mon, 06 Feb 2017 15:14:33 GMT):
Has joined the channel.
yuki-kon (Mon, 06 Feb 2017 16:53:28 GMT):
Has joined the channel.
lehors (Mon, 06 Feb 2017 20:24:52 GMT):
@mastersingh24 you wrote in another channel that "the CLI needs a real overhaul in this aspect as it should be a real client of the orderer", could you please explain? What does the CLI do today instead?
weeds (Mon, 06 Feb 2017 20:25:48 GMT):
Has joined the channel.
mgutala (Mon, 06 Feb 2017 21:39:12 GMT):
Has joined the channel.
tarima (Tue, 07 Feb 2017 01:11:17 GMT):
Has joined the channel.
crazybit (Tue, 07 Feb 2017 05:31:35 GMT):
Has joined the channel.
bur (Tue, 07 Feb 2017 07:33:42 GMT):
Has joined the channel.
mbaizan (Tue, 07 Feb 2017 07:44:32 GMT):
Has joined the channel.
vitaly.ilinykh (Tue, 07 Feb 2017 08:41:35 GMT):
Has joined the channel.
gvlax (Tue, 07 Feb 2017 11:02:49 GMT):
Has joined the channel.
MKabanau (Tue, 07 Feb 2017 14:13:53 GMT):
Has joined the channel.
kenzhang (Tue, 07 Feb 2017 14:35:09 GMT):
Has joined the channel.
cbf (Tue, 07 Feb 2017 15:14:14 GMT):
Has joined the channel.
cbf (Tue, 07 Feb 2017 15:15:00 GMT):
is it just me or is this channel name unnecessarily verbose?
mastersingh24 (Tue, 07 Feb 2017 15:16:05 GMT):
it's just you
mastersingh24 (Tue, 07 Feb 2017 15:16:20 GMT):
I think it was a merge of the other channels - so name was just for recognition
adc (Tue, 07 Feb 2017 15:19:01 GMT):
Has joined the channel.
mpage (Tue, 07 Feb 2017 15:28:53 GMT):
Has joined the channel.
troyronda (Tue, 07 Feb 2017 16:32:01 GMT):
Has joined the channel.
beauson45 (Tue, 07 Feb 2017 20:58:39 GMT):
Has joined the channel.
mgk (Tue, 07 Feb 2017 22:06:12 GMT):
Has joined the channel.
yp (Wed, 08 Feb 2017 02:57:53 GMT):
Has joined the channel.
kushnir.grigoriy (Wed, 08 Feb 2017 13:50:18 GMT):
Has joined the channel.
shaih (Wed, 08 Feb 2017 13:58:52 GMT):
Has joined the channel.
frank.felhoffer (Wed, 08 Feb 2017 14:34:41 GMT):
Has joined the channel.
weeds (Thu, 09 Feb 2017 01:09:33 GMT):
agree- it was for recognition
binhn (Thu, 09 Feb 2017 14:52:32 GMT):
Has joined the channel.
rahulhegde (Thu, 09 Feb 2017 15:04:55 GMT):
Has joined the channel.
kenzhang (Fri, 10 Feb 2017 00:22:52 GMT):
does anyone know if the orderer support TLS yet? I am getting errors which doesn't seem to make sense to me:
2017-02-09 19:21:41.594 EST [orderer/config] completeInitialization -> INFO 003 Validated configuration to: &{General:{LedgerType:ram QueueSize:10 MaxWindowSize:1000 ListenAddress:127.0.0.1 ListenPort:7050 TLS:{Enabled:true `ServerKey`:/etc/hyperledger/fabric/orderer-server-key.pem `ServerCertificate`:/etc/hyperledger/fabric/orderer-server-cert.pem ServerRootCAs:[/etc/hyperledger/fabric/ca-cert.pem] ClientAuthEnabled:false ClientRootCAs:[]} GenesisMethod:provisional GenesisFile:./genesisblock Profile:{Enabled:false Address:0.0.0.0:6060} LogLevel:debug LocalMSPDir:/etc/hyperledger/fabric/msp/sampleconfig} RAMLedger:{HistorySize:1000} FileLedger:{Location: Prefix:hyperledger-fabric-ordererledger} Kafka:{Brokers:[127.0.0.1:9092] Retry:{Period:3s Stop:1m0s} Verbose:false Version:{version:[0 9 0 1]}} Genesis:{OrdererType:solo BatchTimeout:10s BatchSize:{MaxMessageCount:10 AbsoluteMaxBytes:103809024 PreferredMaxBytes:524288} SbftShared:{N:1 F:0 RequestTimeoutNsec:1000000000 Peers:map[:6101:sbft/testdata/cert1.pem]}} SbftLocal:{PeerCommAddr::6101 CertFile:sbft/testdata/cert1.pem KeyFile:sbft/testdata/key.pem DataDir:/tmp}}
Failed to return new GRPC server: secureConfig must contain both `ServerKey` and `ServerCertificate` when UseTLS is true
kenzhang (Fri, 10 Feb 2017 00:22:52 GMT):
does anyone know if the orderer support TLS yet? I am getting errors which doesn't seem to make sense to me:
2017-02-09 19:21:41.594 EST [orderer/config] completeInitialization -> INFO 003 Validated configuration to: &{General:{LedgerType:ram QueueSize:10 MaxWindowSize:1000 ListenAddress:127.0.0.1 ListenPort:7050 TLS:{Enabled:true `ServerKey`:/etc/hyperledger/fabric/orderer-server-key.pem `ServerCertificate`:/etc/hyperledger/fabric/orderer-server-cert.pem ServerRootCAs:[/etc/hyperledger/fabric/ca-cert.pem] ClientAuthEnabled:false ClientRootCAs:[]} GenesisMethod:provisional GenesisFile:./genesisblock Profile:{Enabled:false Address:0.0.0.0:6060} LogLevel:debug LocalMSPDir:/etc/hyperledger/fabric/msp/sampleconfig} RAMLedger:{HistorySize:1000} FileLedger:{Location: Prefix:hyperledger-fabric-ordererledger} Kafka:{Brokers:[127.0.0.1:9092] Retry:{Period:3s Stop:1m0s} Verbose:false Version:{version:[0 9 0 1]}} Genesis:{OrdererType:solo BatchTimeout:10s BatchSize:{MaxMessageCount:10 AbsoluteMaxBytes:103809024 PreferredMaxBytes:524288} SbftShared:{N:1 F:0 RequestTimeoutNsec:1000000000 Peers:map[:6101:sbft/testdata/cert1.pem]}} SbftLocal:{PeerCommAddr::6101 CertFile:sbft/testdata/cert1.pem KeyFile:sbft/testdata/key.pem DataDir:/tmp}}
Failed to return new GRPC server: secureConfig must contain both `ServerKey` and `ServerCertificate` when UseTLS is true
kenzhang (Fri, 10 Feb 2017 00:23:26 GMT):
the `ServerKey` and `ServerCertificate` is specified and recognized in the config but it's complained not found later on
mastersingh24 (Fri, 10 Feb 2017 10:22:42 GMT):
@kenzhang - we have not yet hooked up TLS on the orderer as none of the other components will be able to talk to it if TLS is enabled
mastersingh24 (Fri, 10 Feb 2017 10:25:04 GMT):
but I'll fix this up right now anyway in terms of making sure that we can start the orderer with TLS
yacovm (Fri, 10 Feb 2017 10:37:19 GMT):
Is there tls support for alpha ?
yacovm (Fri, 10 Feb 2017 10:38:02 GMT):
Or should i say- will there be tls support for alpha?
mastersingh24 (Fri, 10 Feb 2017 10:40:49 GMT):
well minimally I am going to try to get the grpcServer stuff integrated into the peer this weekend in preparation for that. I'd like to see if we *can* get the TLS path working ASAP
mastersingh24 (Fri, 10 Feb 2017 10:41:34 GMT):
I'll get the prereq stuff in this weekend hopefully and then we can work on seeing if we can actually get TLS working :)
kenzhang (Fri, 10 Feb 2017 13:01:44 GMT):
Thanks for the update. Is the March release an alpha release? or a GA release?
xixuejia (Fri, 10 Feb 2017 13:17:00 GMT):
Has joined the channel.
tsnyder (Fri, 10 Feb 2017 13:35:36 GMT):
Has joined the channel.
ssaddem (Fri, 10 Feb 2017 13:52:22 GMT):
Has joined the channel.
frankylu (Sun, 12 Feb 2017 00:10:09 GMT):
Has joined the channel.
s.narayanan (Mon, 13 Feb 2017 15:52:29 GMT):
Has joined the channel.
shibo.lin (Tue, 14 Feb 2017 06:21:15 GMT):
Has joined the channel.
joshhus (Tue, 14 Feb 2017 18:14:35 GMT):
Has joined the channel.
sanchezl (Tue, 14 Feb 2017 19:54:48 GMT):
Has joined the channel.
siddhid (Wed, 15 Feb 2017 03:37:20 GMT):
Has joined the channel.
siddhid (Wed, 15 Feb 2017 03:37:57 GMT):
Hi Guys
In fabric 1.0 we can create multiple channels. But wanted to know if there is a way where we create a dedicated channel between 2 peers, such that the third peer is prevented from joining the channel?
Thanks
siddhid (Wed, 15 Feb 2017 04:28:47 GMT):
what is the command prompt command for specifying the peer certificates to be included/avoided while creating the channel?
dave.enyeart (Wed, 15 Feb 2017 12:05:16 GMT):
@muralisr I pulled the latest this morning, instantiate is failing in peer as follows:
dave.enyeart (Wed, 15 Feb 2017 12:05:27 GMT):
peer chaincode instantiate -C myc1 -n marbles2 -p github.com/hyperledger/fabric/examples/chaincode/go/marbles02 -c '{"Args":["init"]}' -v 2
dave.enyeart (Wed, 15 Feb 2017 12:06:00 GMT):
2017-02-15 12:01:15.086 UTC [protoutils] validateChannelHeader -> INFO a4a validateChannelHeader info: header type 3
2017-02-15 12:01:15.086 UTC [protoutils] checkSignatureFromCreator -> INFO a4b checkSignatureFromCreator starts
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x8cba43]
goroutine 2256 [running]:
panic(0xafea40, 0xc4200100c0)
/opt/go/src/runtime/panic.go:500 +0x1a1
github.com/hyperledger/fabric/common/configtx/handlers/msp.(*MSPConfigHandler).DeserializeIdentity(0xc42153c8c0, 0xc421a11000, 0x3a6, 0x3a6, 0x0, 0x0, 0xc421410070, 0x1)
muralisr (Wed, 15 Feb 2017 12:56:58 GMT):
@dave.enyeart thanks will try out shortly
adc (Wed, 15 Feb 2017 12:57:24 GMT):
mhh, it should fail anyway more gracefully. Probably more checks are needed at the MSP level
muralisr (Wed, 15 Feb 2017 12:58:13 GMT):
@adc but why does it fail int the first place ?
adc (Wed, 15 Feb 2017 12:58:52 GMT):
trying to figure it out. It look like something might be missing in the MSP identity
yacovm (Wed, 15 Feb 2017 12:59:04 GMT):
isn't it the SAMPLE thing?
adc (Wed, 15 Feb 2017 12:59:08 GMT):
but the stacktrace does not give exact position
yacovm (Wed, 15 Feb 2017 12:59:39 GMT):
Perhaps it's https://gerrit.hyperledger.org/r/#/c/6021 ?
muralisr (Wed, 15 Feb 2017 13:00:26 GMT):
we should try to make sure e-2-e scenarios work before submitting CRs
yacovm (Wed, 15 Feb 2017 13:01:00 GMT):
we should have an e-2-e test
yacovm (Wed, 15 Feb 2017 13:01:03 GMT):
that runs in CI
yacovm (Wed, 15 Feb 2017 13:02:14 GMT):
If you compute the time it takes to test e-2-e scenarios and multiply it by number of commits, you get an insane amount of person years ;)
aso (Wed, 15 Feb 2017 13:04:52 GMT):
Has joined the channel.
aso (Wed, 15 Feb 2017 13:05:12 GMT):
it will be fixed when 5989 and 6021 are merged afaik
aso (Wed, 15 Feb 2017 13:05:28 GMT):
(but there's a defect in MSP because it should fail gracefully)
yacovm (Wed, 15 Feb 2017 13:06:28 GMT):
thanks @aso
yacovm (Wed, 15 Feb 2017 13:22:25 GMT):
But @muralisr of course you're also right in the general sense.
murrekatt (Thu, 16 Feb 2017 06:18:08 GMT):
Has joined the channel.
murrekatt (Thu, 16 Feb 2017 06:34:42 GMT):
for version v1.0 what's the best read to understand the network protocols? i see it changed a lot from v0.6
wutongtree (Thu, 16 Feb 2017 10:06:19 GMT):
Has joined the channel.
s.narayanan (Thu, 16 Feb 2017 18:28:17 GMT):
A few questions on endorsing peers. How does a client look up endorsing peers for a chaincode transaction? Presume the client can send the transaction proposal to multiple endorsing peers in parallel? Also presume channels are only needed for ordering services (consensus). Does a client have to use to a channel to submit requests for endorsement?
s.narayanan (Thu, 16 Feb 2017 18:28:17 GMT):
A few questions on endorsing peers. How does a client look up endorsing peers for a transaction? Presume the client can send the transaction proposal to multiple endorsing peers in parallel?
jeffgarratt (Thu, 16 Feb 2017 22:04:26 GMT):
@s.narayanan As to the multiple endorsers in parallel, yes. As to who the endorsers are, that is more involved. It depends on the configuration of the channel and it's MSP/policy setup.
jeffgarratt (Thu, 16 Feb 2017 22:04:51 GMT):
and the response was wrt to v1.0
ylsGit (Fri, 17 Feb 2017 02:29:14 GMT):
Has joined the channel.
gormand (Fri, 17 Feb 2017 12:02:59 GMT):
Hi - I'm getting some in depth questions about what are the triggers for a peer to know it is out of date and needs to resync either with the channel or with another peer? Does it check the block height with the channel and therefore know it's out of date? If a peer tries to resync with another peer, how does it know the other peer is up to date?
yacovm (Fri, 17 Feb 2017 12:44:42 GMT):
a peer knows it is out of date by having other peers tell it their ledger height.
Also, a peer can query for the latest block from the ordering service https://github.com/hyperledger/fabric/blob/master/protos/orderer/ab.proto#L37-L43
gormand (Fri, 17 Feb 2017 12:55:35 GMT):
Thanks @yacovm !!
dave.enyeart (Fri, 17 Feb 2017 15:29:21 GMT):
@muralisr I pulled the latest this morning. Now instantiate fails as follows:
dave.enyeart (Fri, 17 Feb 2017 15:29:27 GMT):
```vagrant@hyperledger-devenv:v0.3.0-36bbeb6:/opt/gopath/src/github.com/hyperledger/fabric$ peer chaincode instantiate -C myc1 -n marbles2 -p github.com/hyperledger/fabric/examples/chaincode/go/marbles02 -c '{"Args":["init"]}' -v 2
Error: Error endorsing chaincode: rpc error: code = 2 desc = Error starting container: API error (404): {"message":"oci runtime error: container_linux.go:247: starting container process caused \"exec: \\\"chaincode\\\": executable file not found in $PATH\"\n"}```
muralisr (Fri, 17 Feb 2017 15:29:57 GMT):
I have seen this @dave.enyeart
muralisr (Fri, 17 Feb 2017 15:30:05 GMT):
I had to destroy vagrant and restart
dave.enyeart (Fri, 17 Feb 2017 15:30:09 GMT):
ok
muralisr (Fri, 17 Feb 2017 15:30:24 GMT):
I assumed some fundamental change
muralisr (Fri, 17 Feb 2017 15:30:56 GMT):
but let me pull latest and try too (have to do that anyway) @dave.enyeart
dave.enyeart (Fri, 17 Feb 2017 15:52:14 GMT):
@muralisr After vagrant up it fails with a different error:
dave.enyeart (Fri, 17 Feb 2017 15:52:20 GMT):
```vagrant@hyperledger-devenv:v0.3.0-ea5b30c:/opt/gopath/src/github.com/hyperledger/fabric$ peer chaincode instantiate -C myc1 -n marbles2 -p github.com/hyperledger/fabric/examples/chaincode/go/marbles02 -c '{"Args":["init"]}' -v 2
Error: Got unexpected status: NOT_FOUND```
dave.enyeart (Fri, 17 Feb 2017 15:52:47 GMT):
peer looked ok during instantiate:
dave.enyeart (Fri, 17 Feb 2017 15:52:52 GMT):
```2017-02-17 15:51:29.304 UTC [lockbasedtxmgr] GetTxSimulationResults -> DEBU 53b Simulation completed, getting simulation results
2017-02-17 15:51:29.304 UTC [lockbasedtxmgr] Done -> DEBU 53c Done query executer/ tx simulator [62c95d2f-3cb3-4962-9a65-c38bbc0817ec]```
muralisr (Fri, 17 Feb 2017 15:56:09 GMT):
ok. That sounds like a orderer issue
muralisr (Fri, 17 Feb 2017 15:56:24 GMT):
haven't had a chance to try it yet
muralisr (Fri, 17 Feb 2017 15:56:33 GMT):
will do so in a few mins
muralisr (Fri, 17 Feb 2017 16:20:40 GMT):
@dave.enyeart I'm seeing a different error `Error: Error endorsing chaincode: rpc error: code = 2 desc = failure opening codepackage gzip stream: EOF`
muralisr (Fri, 17 Feb 2017 16:21:37 GMT):
( @greg.haskins something with the filter changes.... investigating )
greg.haskins (Fri, 17 Feb 2017 16:26:29 GMT):
@muralisr @dave.enyeart Dave's error looks like a stale-container problem
greg.haskins (Fri, 17 Feb 2017 16:27:28 GMT):
I changed the launch sequence recently from "$GOPATH/bin/$name" to "chaincode" where the chaincode binary is in /usr/local/bin
greg.haskins (Fri, 17 Feb 2017 16:27:49 GMT):
the fact that its not finding "chaincode" implies the container was not rebuilt after the update
greg.haskins (Fri, 17 Feb 2017 16:28:27 GMT):
a vagrant destroy/up would fix it by virtue of destroying the docker cache
greg.haskins (Fri, 17 Feb 2017 16:28:38 GMT):
but there are lighterweight options im sure
greg.haskins (Fri, 17 Feb 2017 16:29:05 GMT):
as far as that gzip decode error @muralisr, thats a mystery
muralisr (Fri, 17 Feb 2017 16:29:37 GMT):
indeed... I'll look at that as I can recreate and update @greg.haskins
greg.haskins (Fri, 17 Feb 2017 16:29:43 GMT):
ok
greg.haskins (Fri, 17 Feb 2017 16:30:07 GMT):
@muralisr did you see that error in the context of UTs or run-time ?
muralisr (Fri, 17 Feb 2017 16:30:24 GMT):
when I was doing end-2-end
muralisr (Fri, 17 Feb 2017 16:30:44 GMT):
so basically CLI commands
muralisr (Fri, 17 Feb 2017 16:31:08 GMT):
I'm thinking some code needs to be modified in that path
muralisr (Fri, 17 Feb 2017 16:31:08 GMT):
I'm thinking some code needs to be modified in that path @greg.haskins
greg.haskins (Fri, 17 Feb 2017 16:32:51 GMT):
im not sure how you would get into this circumstance, but its hitting this: https://github.com/hyperledger/fabric/blob/master/core/chaincode/platforms/golang/platform.go#L115
greg.haskins (Fri, 17 Feb 2017 16:33:25 GMT):
the code is hardwired to expect cds.CodePackage is a tar.gz
greg.haskins (Fri, 17 Feb 2017 16:33:35 GMT):
is it possible that it may sometimes be empty, such as LCCC?
greg.haskins (Fri, 17 Feb 2017 16:33:54 GMT):
thats the only legit scenario that I can think of
greg.haskins (Fri, 17 Feb 2017 16:35:40 GMT):
@muralisr assuming the theory is right, I think an "if cds.CodePackage && len(cds.CodePackage) { return }" should fix it
muralisr (Fri, 17 Feb 2017 16:36:05 GMT):
I think that's exactly right @greg.haskins
greg.haskins (Fri, 17 Feb 2017 16:36:30 GMT):
do you want to patch on your end so you can test?
greg.haskins (Fri, 17 Feb 2017 16:36:35 GMT):
otherwise, happy to submit a CR
muralisr (Fri, 17 Feb 2017 16:36:46 GMT):
I'll copy paste the above and test
greg.haskins (Fri, 17 Feb 2017 16:36:58 GMT):
ok
muralisr (Fri, 17 Feb 2017 16:37:01 GMT):
and let you know ?
greg.haskins (Fri, 17 Feb 2017 16:37:05 GMT):
of course
muralisr (Fri, 17 Feb 2017 16:37:14 GMT):
Rocket is stalling :-)
muralisr (Fri, 17 Feb 2017 16:37:42 GMT):
my statements are coming in delayed a bit...
muralisr (Fri, 17 Feb 2017 16:45:32 GMT):
that was it @greg.haskins
muralisr (Fri, 17 Feb 2017 16:45:35 GMT):
Message Attachments
muralisr (Fri, 17 Feb 2017 16:45:40 GMT):
that fixes it
muralisr (Fri, 17 Feb 2017 16:45:47 GMT):
and its a valid fix
chris.elder (Fri, 17 Feb 2017 16:58:51 GMT):
Has joined the channel.
muralisr (Fri, 17 Feb 2017 17:02:26 GMT):
@greg.haskins ^^^
greg.haskins (Fri, 17 Feb 2017 17:03:01 GMT):
looks good, sorry for not catching that case
greg.haskins (Fri, 17 Feb 2017 17:03:28 GMT):
do you want me to push?
greg.haskins (Fri, 17 Feb 2017 17:03:37 GMT):
im fine either way
muralisr (Fri, 17 Feb 2017 17:03:45 GMT):
actually I shoud have seen it too ... (not your fault at all I think)
muralisr (Fri, 17 Feb 2017 17:03:47 GMT):
please
greg.haskins (Fri, 17 Feb 2017 17:03:51 GMT):
ok
greg.haskins (Fri, 17 Feb 2017 17:04:18 GMT):
can you file JIRA?
muralisr (Fri, 17 Feb 2017 17:04:23 GMT):
will do
muralisr (Fri, 17 Feb 2017 17:04:28 GMT):
one moment
muralisr (Fri, 17 Feb 2017 17:10:22 GMT):
https://jira.hyperledger.org/browse/FAB-2341 .... thanks @greg.haskins
muralisr (Fri, 17 Feb 2017 20:16:22 GMT):
with https://gerrit.hyperledger.org/r/#/c/6161 end-to-end tests work (channel create/join, chaincode install/instantiate/invoke/query)
elli-androulaki (Sat, 18 Feb 2017 10:27:22 GMT):
Has joined the channel.
warm3snow (Tue, 21 Feb 2017 05:18:47 GMT):
Has joined the channel.
tuand (Tue, 21 Feb 2017 23:11:28 GMT):
anyone have a serialized policy I can use for testing ? trying to send a CC instantiate request and want to populate the ChaincodeInput struct ... @muralisr @jeffgarratt
muralisr (Tue, 21 Feb 2017 23:11:42 GMT):
hey Tuan
muralisr (Tue, 21 Feb 2017 23:12:23 GMT):
policy as in endorsement policy ?
muralisr (Tue, 21 Feb 2017 23:12:49 GMT):
the "-P" option in CLI's "instantiate" command ?
murrekatt (Wed, 22 Feb 2017 10:10:54 GMT):
on current master, what does `[gossip/comm#-1] func1 -> WARN 02c 0.0.0.0:7051, PKIid:[] isn't responsive: EOF` in the logs from the peer mean and what can be done to address it?
yacovm (Wed, 22 Feb 2017 11:00:47 GMT):
@murrekatt remove the 0.0.0.0:7051 from https://github.com/hyperledger/fabric/blob/master/peer/core.yaml#L72
murrekatt (Wed, 22 Feb 2017 12:01:55 GMT):
@yacovm thanks, what is needed from the system with the current value? could i e.g. put in a peer there or how does it work?
yacovm (Wed, 22 Feb 2017 12:34:26 GMT):
you can put a peer there instead
yacovm (Wed, 22 Feb 2017 12:34:36 GMT):
if you run a single peer, you can simply not put anything and leave it empty
yacovm (Wed, 22 Feb 2017 12:34:42 GMT):
if you run some peers in the same organization
yacovm (Wed, 22 Feb 2017 12:34:56 GMT):
you can just select some peer among them
yacovm (Wed, 22 Feb 2017 12:34:59 GMT):
and put its ip:port
yacovm (Wed, 22 Feb 2017 12:35:03 GMT):
@murrekatt
yacovm (Wed, 22 Feb 2017 12:35:09 GMT):
(was in a meeting so couldn't answer)
murrekatt (Wed, 22 Feb 2017 12:43:11 GMT):
thanks @yacovm
murrekatt (Wed, 22 Feb 2017 12:44:40 GMT):
btw, the `core.yml` file is that a container build time thing or can that be provided from outside the container? @yacovm
yacovm (Wed, 22 Feb 2017 12:46:39 GMT):
so, the core.yml is also copied at the build time
yacovm (Wed, 22 Feb 2017 12:46:42 GMT):
but it can be overrided
yacovm (Wed, 22 Feb 2017 12:46:46 GMT):
by the docker-compose environment params
murrekatt (Wed, 22 Feb 2017 12:55:17 GMT):
to give a whole new yml file?
yacovm (Wed, 22 Feb 2017 13:01:26 GMT):
what do you mean?
murrekatt (Wed, 22 Feb 2017 13:04:07 GMT):
can i provide an env variable that says use this other core.yml file or you meant that i can override some of the configs one by one using env variables?
psa (Wed, 22 Feb 2017 13:06:55 GMT):
Has joined the channel.
yacovm (Wed, 22 Feb 2017 13:07:07 GMT):
the latter
murrekatt (Wed, 22 Feb 2017 13:08:44 GMT):
ok then i knew all options :)
murrekatt (Wed, 22 Feb 2017 13:10:31 GMT):
one more thing related to the bootstrap, in a multi-peer setup (say a test setup on one machine) if a peer doesn't have a bootstrap endpoint do the peers still connect?
murrekatt (Wed, 22 Feb 2017 13:10:50 GMT):
i'm atm looking at the example compose files in `fabric/docs`
yacovm (Wed, 22 Feb 2017 13:22:04 GMT):
so, in this case
yacovm (Wed, 22 Feb 2017 13:22:12 GMT):
it'll take the endpoint from the anchor peer set
yacovm (Wed, 22 Feb 2017 13:22:16 GMT):
when you create a channel
yacovm (Wed, 22 Feb 2017 13:22:27 GMT):
invoke: `peer channel create -h` and you'll see, there is a `-a` flag
murrekatt (Wed, 22 Feb 2017 13:44:45 GMT):
ok, yes i saw that one. what's the bootstrap peer config vs anchor peers that you mention?
yacovm (Wed, 22 Feb 2017 13:45:59 GMT):
so, the bootstrap is at startup
yacovm (Wed, 22 Feb 2017 13:46:05 GMT):
the anchor peer list is when you join a channel
lohitkrishnan (Wed, 22 Feb 2017 13:47:59 GMT):
Has joined the channel.
murrekatt (Wed, 22 Feb 2017 13:59:36 GMT):
right. and the bootstrap can be for any channels, even those the peer cannot access?
yacovm (Wed, 22 Feb 2017 14:13:00 GMT):
so
yacovm (Wed, 22 Feb 2017 14:13:17 GMT):
the bootstrap peer is something you define in the configuration and isn't related to channels
tuand (Wed, 22 Feb 2017 14:34:23 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=L93zzvGQ6BFN8CbwC) @muralisr i think so ... that's what becomes `policyMarhsalled` in peer/chaincode/common.go ?
murrekatt (Wed, 22 Feb 2017 14:51:22 GMT):
@yacovm ok, so joining a channel must be explicit and will not happen when a peer connects with another peer?
yacovm (Wed, 22 Feb 2017 14:51:35 GMT):
yeah
murrekatt (Wed, 22 Feb 2017 14:53:26 GMT):
so bootstrap just provides a way to find other peers but that doesn't mean they exchange any info like channels
yacovm (Wed, 22 Feb 2017 14:53:32 GMT):
exactly
murrekatt (Wed, 22 Feb 2017 14:54:08 GMT):
just coming from the situation when a peer needs to join the very first time or for some reason lost track of channels it should be on
murrekatt (Wed, 22 Feb 2017 14:54:38 GMT):
as i understand you the peers must know that themselves and there is no way they find that out just by using their say certificates
yacovm (Wed, 22 Feb 2017 14:55:40 GMT):
a peer joins a channel manually
murrekatt (Wed, 22 Feb 2017 14:55:41 GMT):
remember reading somewhere about the system channel that keeps some info about this in some special cases...need to see where i read that
yacovm (Wed, 22 Feb 2017 14:55:42 GMT):
*not* automatically
murrekatt (Wed, 22 Feb 2017 14:55:48 GMT):
right
yacovm (Wed, 22 Feb 2017 14:55:50 GMT):
no no noi
yacovm (Wed, 22 Feb 2017 14:55:54 GMT):
the system channel is not in the peers
murrekatt (Wed, 22 Feb 2017 14:56:00 GMT):
yes in the orderer
yacovm (Wed, 22 Feb 2017 14:56:03 GMT):
yeah
murrekatt (Wed, 22 Feb 2017 14:56:42 GMT):
thanks @yacovm
murrekatt (Wed, 22 Feb 2017 14:57:30 GMT):
trying to find out things reading partially outdated docs but not clear what is and what isn't outdated
muralisr (Wed, 22 Feb 2017 15:16:22 GMT):
@tuan, yes
muralisr (Wed, 22 Feb 2017 15:16:22 GMT):
@tuand yes
davidkel (Wed, 22 Feb 2017 16:26:57 GMT):
Has joined the channel.
tuand (Wed, 22 Feb 2017 22:05:37 GMT):
from java sdk, trying to run install/instantiate/invoke/query flow and getting this error on peer ?
tuand (Wed, 22 Feb 2017 22:05:57 GMT):
```[36m2017-02-22 21:34:08.151 UTC [shim] func1 -> DEBU 4d2[0m [2cd3e0f8]Received message TRANSACTION from shim
[36m2017-02-22 21:34:08.151 UTC [shim] handleMessage -> DEBU 4d3[0m [2cd3e0f8]Handling ChaincodeMessage of type: TRANSACTION(state:ready)
[36m2017-02-22 21:34:08.151 UTC [shim] enterTransactionState -> DEBU 4d4[0m [2cd3e0f8]Received TRANSACTION, invoking transaction on chaincode(Src:ready, Dst:ready)
2017-02-22 21:34:08.151 UTC [vscc] Invoke -> INFO 4d5[0m VSCC invoked
[36m2017-02-22 21:34:08.151 UTC [cauthdsl] func1 -> DEBU 4d6[0m Gate evaluation starts: (&{N:1 policies:
tuand (Wed, 22 Feb 2017 22:06:47 GMT):
I instantiated the CC with policy `AND('DEFAULT.member')`
tuand (Wed, 22 Feb 2017 22:07:38 GMT):
this flow works fine if I don't set the policy
tuand (Wed, 22 Feb 2017 22:08:20 GMT):
running with fabric commit e3fe66b
muralisr (Thu, 23 Feb 2017 16:03:14 GMT):
@tuand lets check with @aso ^^^
tuand (Thu, 23 Feb 2017 16:33:50 GMT):
interesting, I can't find Ale @aso in the user list ... @adc or @eli , can you help ? ^^^
mastersingh24 (Thu, 23 Feb 2017 16:39:18 GMT):
@tuand - what configuration are you using for the peer?
mastersingh24 (Thu, 23 Feb 2017 16:39:33 GMT):
and ordering service?
mastersingh24 (Thu, 23 Feb 2017 16:40:19 GMT):
and actually I think instantiate might require "admin" not "member"?
tuand (Thu, 23 Feb 2017 16:41:04 GMT):
I tried with both DEFAULT.admin and DEFAULT.member with same result
mastersingh24 (Thu, 23 Feb 2017 16:41:08 GMT):
oh - I guess you are having problems after you've already instantiated?
mastersingh24 (Thu, 23 Feb 2017 16:41:19 GMT):
or with actually instantiate
tuand (Thu, 23 Feb 2017 16:42:47 GMT):
on invoke i think, sdk got an event back for instantiate
tuand (Thu, 23 Feb 2017 16:44:54 GMT):
attaching docker-compose file ... 1 sec
tuand (Thu, 23 Feb 2017 16:45:46 GMT):
Message Attachments
mastersingh24 (Thu, 23 Feb 2017 16:46:37 GMT):
you may also want to pull down https://gerrit.hyperledger.org/r/gitweb?p=fabric.git;a=commit;h=2fc6bc606bc5f732d9b04ce28e1d28dfbd220173
tuand (Thu, 23 Feb 2017 16:48:57 GMT):
ok. might be a bit slow responding, might need to do some fixup as java sdk is finicky with latest fabric commits
mastersingh24 (Thu, 23 Feb 2017 16:58:30 GMT):
I'd recommend pulling in at least what I posted above as that's where it actually starts really enforcing stuff
aso (Thu, 23 Feb 2017 17:29:23 GMT):
Hi @tuand
aso (Thu, 23 Feb 2017 17:29:36 GMT):
```
panic: Not yet implemented
```
means you need to pull again
aso (Thu, 23 Feb 2017 17:30:08 GMT):
that was implemented in https://gerrit.hyperledger.org/r/#/c/6349/
tuand (Thu, 23 Feb 2017 17:37:02 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=NwfW4sDSNwbc6dm3w) got it. Thanks @aso !
tuand (Thu, 23 Feb 2017 18:51:26 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=h5P5MLt7SpQjahmax) java sdk can send instantiateCC request with policy now. thanks @aso
rickr (Thu, 23 Feb 2017 23:49:47 GMT):
Hi -- I can run inst/init/invoke/query on the testchainid chain. Recycle orderer/peer and first create an 'foo' chain and join the peer. From that there's no idication that I can see anything went wrong. The proposal for joining the peer is succesful. I then start running that scenario on this new chain. Install is ok but instiate proposal fails. peer dies.
https://jpst.it/U6TW
```
goroutine 312 [running]:
panic(0xb3fa60, 0xc42000e0d0)
/usr/local/lib/go/src/runtime/panic.go:500 +0x1a1
github.com/hyperledger/fabric/common/configvalues/msp.(*MSPConfigHandler).DeserializeIdentity(0xc42149db60, 0xc421504300, 0x2ed, 0x2ed, 0x0, 0x0, 0x3, 0xc4214772f0)
rickr (Thu, 23 Feb 2017 23:52:04 GMT):
```
commit e3fe66ba19c3d77d88431d74d5647d0372496313
Merge: 9b972b2 011cd41
Author: Binh Nguyen
CarlXK (Fri, 24 Feb 2017 02:02:49 GMT):
Has joined the channel.
ryokawajp (Fri, 24 Feb 2017 11:00:57 GMT):
Has joined the channel.
RangaOnkaram (Fri, 24 Feb 2017 14:47:28 GMT):
Has joined the channel.
tuand (Fri, 24 Feb 2017 20:52:18 GMT):
@jeffgarratt do we ( will we ) have an "official tool" for users to create the bootstrap blocks, policies and what not ? I'm asking since the SDK is supposed to be fed these artifacts as binary files or byte arrays. Want to see if there's any conventions like standard filenames, output directories, etc.. yet
jeffgarratt (Fri, 24 Feb 2017 21:54:28 GMT):
@tuand I am in hold mode until the system has stabilized a bit. I am hoping to clarify the usage a bit more before make determinations on tooling.
tuand (Fri, 24 Feb 2017 22:05:23 GMT):
ok @jeffgarratt I'll ask again monday when we'll all be sitting around with nothing to do ;)
muralisr (Fri, 24 Feb 2017 22:24:24 GMT):
@jeffgarratt @tuand hopefully once https://gerrit.hyperledger.org/r/#/c/6489/ https://gerrit.hyperledger.org/r/#/c/6379/ https://gerrit.hyperledger.org/r/#/c/5955/ are merged (imminent) we can be back on track
jeffgarratt (Fri, 24 Feb 2017 22:25:06 GMT):
:)
bretharrison (Sat, 25 Feb 2017 14:51:32 GMT):
Has joined the channel.
muralisr (Sat, 25 Feb 2017 15:10:23 GMT):
@rickr can you give some instructions to setup and test with java SDK ?
jimthematrix (Sat, 25 Feb 2017 20:25:08 GMT):
Has joined the channel.
jimthematrix (Sat, 25 Feb 2017 20:26:04 GMT):
I just tested the latest, the sdk definitely still suffers the “signature invalid” problem that was reported two days ago. from inspecting the golang source where this happens, it’s actually past the validation of the cert, indicating that as far as msp config is concerned it seems fine. but it failed as the signature verification step, which never happened before, this implies a problem in the crypto layer. @adc @aso would need your help to investigate
jimthematrix (Sat, 25 Feb 2017 20:26:04 GMT):
I just tested the latest, the sdk definitely still suffers the “signature invalid” problem that was reported two days ago. from inspecting the golang source where this happens, it’s actually past the validation of the cert, indicating that as far as msp config is concerned it seems fine. but it failed as the signature verification step, which never happened before, this implies an issue in the crypto layer. @adc @aso would need your help to investigate
muralisr (Sat, 25 Feb 2017 20:41:51 GMT):
@jimthematrix the right MSPID and matching crypto needs to be used
muralisr (Sat, 25 Feb 2017 20:43:17 GMT):
so we could generated config tx with DEFAULT using msp/sampleconfig (generated from fabric-ca so should match the crypto being used in SDK)
jimthematrix (Sat, 25 Feb 2017 20:43:19 GMT):
what's the value for the "testchainid"?
muralisr (Sat, 25 Feb 2017 20:43:27 GMT):
ah yes
muralisr (Sat, 25 Feb 2017 20:43:54 GMT):
so there are two options there... best to create a chain ("foo") and join it
muralisr (Sat, 25 Feb 2017 20:46:36 GMT):
need to play with the testchainid option a bit (have been focusing on using "real" channels for a while)
jimthematrix (Sat, 25 Feb 2017 20:48:30 GMT):
i wonder how that got past cert validation before the signature verify, if the msp wasn't set up right...
muralisr (Sat, 25 Feb 2017 20:52:03 GMT):
good question.. let me check something (I assume you were using default testchainid ?)
muralisr (Sat, 25 Feb 2017 21:01:45 GMT):
@jimthematrix need to try something... will update soon Jim
muralisr (Sat, 25 Feb 2017 21:12:22 GMT):
@jimthematrix how do you run the orderer ?
muralisr (Sat, 25 Feb 2017 21:12:42 GMT):
if from docker, can you share the compose yml ?
bretharrison (Sat, 25 Feb 2017 22:05:38 GMT):
Message Attachments
bretharrison (Sat, 25 Feb 2017 22:06:04 GMT):
had to use txt, yml was not allowed to be uploaded
jimthematrix (Sun, 26 Feb 2017 00:24:40 GMT):
@muralisr how do you debug peer code these days? i used to be able to use a command like below to debug:
```CORE_PEER_ID=vp0 CORE_PEER_PROFILE_ENABLED=true CORE_PEER_COMMITTER_LEDGER_ORDERER=localhost:7050 CORE_PEER_MSPCONFIGPATH=/Users/jimzhang/workspace/go/src/github.com/hyperledger/fabric/msp/sampleconfig/ dlv debug -- node start```
but now it panics and exits
jimthematrix (Sun, 26 Feb 2017 00:24:40 GMT):
@muralisr how do you debug peer code these days? i used to be able to use a command like below in the `peer` folder to debug:
```CORE_PEER_ID=vp0 CORE_PEER_PROFILE_ENABLED=true CORE_PEER_COMMITTER_LEDGER_ORDERER=localhost:7050 CORE_PEER_MSPCONFIGPATH=/Users/jimzhang/workspace/go/src/github.com/hyperledger/fabric/msp/sampleconfig/ dlv debug -- node start```
but now it panics and exits
jimthematrix (Sun, 26 Feb 2017 00:41:46 GMT):
```2017-02-25 19:23:43.512 EST [msp] Validate -> INFO 018 MSP DEFAULT validating identity
2017-02-25 19:23:43.512 EST [gossip/gossip#0.0.0.0:7051] NewGossipService -> WARN 019 External endpoint is empty, peer will not be accessible outside of its organization
2017-02-25 19:23:43.512 EST [gossip/gossip#0.0.0.0:7051] Stop -> INFO 01b Stopping gossip
2017-02-25 19:23:43.512 EST [gossip/discovery#0.0.0.0:7051] Stop -> INFO 01c Stopping
2017-02-25 19:23:43.512 EST [gossip/gossip#0.0.0.0:7051] start -> INFO 01a Gossip instance 0.0.0.0:7051 started
2017-02-25 19:23:43.512 EST [gossip/discovery#0.0.0.0:7051] Stop -> INFO 01e Stopped
2017-02-25 19:23:43.512 EST [gossip/comm#-1] Stop -> INFO 01d Stopping
2017-02-25 19:23:43.512 EST [gossip/comm#-1] 1 -> WARN 01f Recovered
2017-02-25 19:23:43.512 EST [gossip/comm#-1] Stop -> INFO 020 Stopped
panic: ---empty version---(chain=,chaincode=cscc,version=,txid=d14f1427-d73c-4066-9ce6-7a0c9e7672b9,syscc=true,proposal=0x0
goroutine 1 [running]:
github.com/hyperledger/fabric/core/common/ccprovider.NewCCContext(0x0, 0x0, 0x4870c67, 0x4, 0x0, 0x0, 0xc4202fb7d0, 0x24, 0x4498d01, 0x0, ...)
/Users/jimzhang/workspace/go/src/github.com/hyperledger/fabric/core/common/ccprovider/ccprovider.go:202 +0x9c8
github.com/hyperledger/fabric/core/chaincode.(*ccProviderImpl).GetCCContext(0xc4217c9d80, 0x0, 0x0, 0x4870c67, 0x4, 0x0, 0x0, 0xc4202fb7d0, 0x24, 0xc42001f301, ...)
/Users/jimzhang/workspace/go/src/github.com/hyperledger/fabric/core/chaincode/ccproviderimpl.go:71 +0xb3
github.com/hyperledger/fabric/core/scc.deploySysCC(0x0, 0x0, 0x4c66f00, 0x0, 0x0)
/Users/jimzhang/workspace/go/src/github.com/hyperledger/fabric/core/scc/sysccapi.go:121 +0x515
github.com/hyperledger/fabric/core/scc.DeploySysCCs(0x0, 0x0)
/Users/jimzhang/workspace/go/src/github.com/hyperledger/fabric/core/scc/importsysccs.go:79 +0x65
github.com/hyperledger/fabric/peer/node.initSysCCs()
/Users/jimzhang/workspace/go/src/github.com/hyperledger/fabric/peer/node/start.go:82 +0x33
github.com/hyperledger/fabric/peer/node.serve(0x4c8f358, 0x0, 0x0, 0x0, 0x0)
/Users/jimzhang/workspace/go/src/github.com/hyperledger/fabric/peer/node/start.go:162 +0x978
```
yacovm (Sun, 26 Feb 2017 07:19:00 GMT):
Did you build it using go build?
yacovm (Sun, 26 Feb 2017 07:19:07 GMT):
@jimthematrix
jimthematrix (Sun, 26 Feb 2017 07:19:34 GMT):
`dlv debug`
jimthematrix (Sun, 26 Feb 2017 07:19:50 GMT):
does the build with debug instrumentation
yacovm (Sun, 26 Feb 2017 07:20:31 GMT):
Empty version is usually because you need to pass some magical phrase to the build, like `make peer` does
jimthematrix (Sun, 26 Feb 2017 07:31:45 GMT):
yeah i'm pretty sure it's the need to pass `-ldflags` but i've tried various way to no avail,
```dlv debug --build-flag="-ldflags='-X ....'"```
jimthematrix (Sun, 26 Feb 2017 07:33:38 GMT):
i think the "invalid signature" problem mystery was caused by the fact that peer node uses SHA3 (instead of SHA2) 256 hashing, which was recently changed. changing the signing to use SHA3 256 got me past that error
jimthematrix (Sun, 26 Feb 2017 07:33:38 GMT):
i think the "invalid signature" problem mystery was caused by the fact that peer node uses SHA3 (instead of SHA2) 256 hashing, which was recently changed. changing the signing to use SHA3 256 got me past that error (@rickr)
jimthematrix (Sun, 26 Feb 2017 07:33:38 GMT):
i think the "invalid signature" problem mystery was caused by the fact that peer node uses SHA3 (instead of SHA2) 256 hashing, which was recently changed. changing the signing to use SHA3 256 got me past that error @rickr
jimthematrix (Sun, 26 Feb 2017 07:33:38 GMT):
i think the "invalid signature" problem mystery was caused by the fact that peer node uses SHA3 (instead of SHA2) 256 hashing, which was recently changed. changing the signing to use SHA3 256 got me past that error @rickr @pmullaney
jimthematrix (Sun, 26 Feb 2017 07:34:48 GMT):
the next error was comparing the tx ID where the peer reconstructed the id based on creator and nonce. it failed because the peer uses SHA2 256 for this particular step
jimthematrix (Sun, 26 Feb 2017 07:35:18 GMT):
I've got node SDK to change the hashing algo according, and that got me a little further
jimthematrix (Sun, 26 Feb 2017 07:35:49 GMT):
and now encountering this:
```error: [Peer.js]: GRPC client got an error response from the peer. Error: Illegal file detected in payload: "."```
jimthematrix (Sun, 26 Feb 2017 07:44:12 GMT):
that's the first entry in the tarball for the install proposal. seems harmless to me, why should that be considered "illegal"? @greg.haskins ?
jimthematrix (Sun, 26 Feb 2017 08:15:07 GMT):
http://gerrit.hyperledger.org/r/6543 for the signature (and txId generation) issue related to using SHA2/3 256 at various points
greg.haskins (Sun, 26 Feb 2017 12:37:23 GMT):
@jimthematrix "Illegal" was probably too strong of a word. "Invalid" would have been a better choice. Bottom line, the only valid content is text files that end with (go|c|h). Anything else (like the directory ".") has no business in that payload and is just slop on behalf of the payload creator
greg.haskins (Sun, 26 Feb 2017 12:38:37 GMT):
Considering that the payload has implications in multiple dimensions (security, network strain, etc) we really want to discourage slop
greg.haskins (Sun, 26 Feb 2017 13:11:09 GMT):
@jimthematrix Regarding dlv, try "dlv exec" against the binary built by "make peer" instead
greg.haskins (Sun, 26 Feb 2017 13:11:19 GMT):
Thats how I run
greg.haskins (Sun, 26 Feb 2017 13:11:49 GMT):
The you don't need to worry about replicating the build
jimthematrix (Sun, 26 Feb 2017 15:16:26 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=nu52dehrrc6cRs9B3) @greg.haskins i briefly searched for a tarball packer that doesn't include the "." but haven't found one. i think that's how most tarball packers work though (including the "." entry). can we be more practical on this one? what harm can the "." entry do?
greg.haskins (Sun, 26 Feb 2017 18:48:16 GMT):
@jimthematrix Every byte is a liability so unless there is no other way we should strive to be as efficient as possible. I don't think we have crossed the "there is no other way" threshold yet. I am not aware of any fundamental tendency of tar encoders to include the dir/symlink. I already have patches underway for the SDK to clean up how we generate the golang package. Let's see if it can be solved first before punting.
greg.haskins (Sun, 26 Feb 2017 21:56:47 GMT):
@jimthematrix @mastersingh24 https://jira.hyperledger.org/browse/FAB-2493
jimthematrix (Sun, 26 Feb 2017 21:58:44 GMT):
yes I'm working on this, got past the illegal file entries error by forcing the "entries" to be src/chaincodePath on the tarball packer. now need to set the files to have -rw-rw-rw- mode
greg.haskins (Sun, 26 Feb 2017 21:59:05 GMT):
ok, I am working on a refactor too, we should sync up
greg.haskins (Sun, 26 Feb 2017 21:59:08 GMT):
https://gerrit.hyperledger.org/r/#/c/6551/
greg.haskins (Sun, 26 Feb 2017 21:59:39 GMT):
still WIP, and more patches to come to complete FAB-2493
greg.haskins (Sun, 26 Feb 2017 22:00:08 GMT):
dealing with a weird UT failure now related to fs.copy() that I do not understand
muralisr (Sun, 26 Feb 2017 22:03:11 GMT):
@greg.haskins to make sure I understand...the suggestion in https://jira.hyperledger.org/browse/FAB-2493 is at the collection time (say in the SDK) and not in the peer at executing the install correct ?
jimthematrix (Sun, 26 Feb 2017 22:03:15 GMT):
i added https://gerrit.hyperledger.org/r/#/c/6551/4 comment for the trick to exclude the unnecessary folder entries
muralisr (Sun, 26 Feb 2017 22:03:32 GMT):
ie not a filter on the filter
muralisr (Sun, 26 Feb 2017 22:03:36 GMT):
oops
muralisr (Sun, 26 Feb 2017 22:03:42 GMT):
not a filter on the peer
greg.haskins (Sun, 26 Feb 2017 22:03:50 GMT):
@muralisr correct, it would be done by the entity assembling the codepackage, namely the SDK or CLI
muralisr (Sun, 26 Feb 2017 22:04:05 GMT):
makes sense, @greg.haskins ...thanks
jimthematrix (Sun, 26 Feb 2017 22:04:36 GMT):
@greg.haskins what UT failure are you seeing?
muralisr (Sun, 26 Feb 2017 22:04:59 GMT):
(the lines get blurred when talking of CLI and peer sometimes.. hence the question)
greg.haskins (Sun, 26 Feb 2017 22:06:52 GMT):
@jimthematrix look at the result of patch v4: https://jenkins.hyperledger.org/job/fabric-sdk-node-verify-x86_64/572/
greg.haskins (Sun, 26 Feb 2017 22:13:50 GMT):
@jimthematrix does that ring a bell at all?
greg.haskins (Sun, 26 Feb 2017 22:13:57 GMT):
i am confused what it is telling me
greg.haskins (Sun, 26 Feb 2017 22:14:22 GMT):
it seems like either fs.mkdtemp() or fs.copy() isnt recognized, but I dont understand why that is different from the original impl
jimthematrix (Mon, 27 Feb 2017 01:34:22 GMT):
hi @greg.haskins those two methods are from the "fs-extra" module
jimthematrix (Mon, 27 Feb 2017 01:34:42 GMT):
if you swap the "fs" for "fs-extra" the error should be fixed
jimthematrix (Mon, 27 Feb 2017 01:34:42 GMT):
if you swap the "fs" for "fs-extra" in golang.js the error should be fixed
jimthematrix (Mon, 27 Feb 2017 01:35:33 GMT):
(sorry had to drop off daughter for volleyball practice)
greg.haskins (Mon, 27 Feb 2017 01:42:46 GMT):
@jimthematrix oh man, I dont know how long it would have taken to notice that!
greg.haskins (Mon, 27 Feb 2017 01:42:48 GMT):
thanks!
greg.haskins (Mon, 27 Feb 2017 01:43:05 GMT):
pushed v5, fingers crossed
greg.haskins (Mon, 27 Feb 2017 01:43:05 GMT):
pushed v6, fingers crossed
jimthematrix (Mon, 27 Feb 2017 01:43:56 GMT):
:ok_hand:
jimthematrix (Mon, 27 Feb 2017 02:00:30 GMT):
Greg, looks like there's more issues in utils.js
jimthematrix (Mon, 27 Feb 2017 03:24:53 GMT):
6551 is merged
hyp0th3rmi4 (Mon, 27 Feb 2017 08:04:52 GMT):
Has joined the channel.
mastersingh24 (Mon, 27 Feb 2017 13:31:38 GMT):
FYI folks - I'm working a little tool to help generate artifacts to use in the e2e similar to the stuff generated by the BDD tests. I'm doing it all in Go and will make it available as a command line tool
divyank (Mon, 27 Feb 2017 16:59:38 GMT):
Has joined the channel.
Rweb2 (Tue, 28 Feb 2017 01:10:43 GMT):
Has joined the channel.
jeffchi (Tue, 28 Feb 2017 02:57:20 GMT):
Has joined the channel.
stchrysa (Tue, 28 Feb 2017 10:00:45 GMT):
Has joined the channel.
suryalanka (Tue, 28 Feb 2017 14:20:44 GMT):
Has joined the channel.
mastersingh24 (Tue, 28 Feb 2017 15:49:13 GMT):
@muralisr @yacovm - https://gerrit.hyperledger.org/r/#/c/6635/
mastersingh24 (Tue, 28 Feb 2017 15:49:28 GMT):
it's a WIP but it actually does work. let me know what you thing
mastersingh24 (Tue, 28 Feb 2017 15:49:28 GMT):
it's a WIP but it actually does work. let me know what you think
yacovm (Tue, 28 Feb 2017 15:49:34 GMT):
Will check it today
toddinpal (Tue, 28 Feb 2017 15:50:49 GMT):
Has joined the channel.
toddinpal (Tue, 28 Feb 2017 15:52:48 GMT):
In the new fabric 1.0 model, where/how are Byzantine faults handled? Specifically who or where is a faulty endorser detected? In other words if an endorser presents a different ReadWriteSet from other endorsers, how/where is that caught?
crmiles (Tue, 28 Feb 2017 17:46:32 GMT):
Has joined the channel.
muralisr (Tue, 28 Feb 2017 17:56:33 GMT):
@mastersingh24 nice ! I know WIP... but if we can eliminate one user error prone path and also generate configtx.yaml, would be a very nice to have. Just a thought (and does not ahve to be done in this CR...)
muralisr (Tue, 28 Feb 2017 17:56:48 GMT):
and like @yacovm will check it closely later today
mastersingh24 (Tue, 28 Feb 2017 18:03:20 GMT):
@muralisr - you read my mind
mastersingh24 (Tue, 28 Feb 2017 18:03:26 GMT):
that's actually next on the agenda
mastersingh24 (Tue, 28 Feb 2017 18:03:46 GMT):
I think I can generate all the org stuff, etc in the configtx.yaml
muralisr (Tue, 28 Feb 2017 18:07:08 GMT):
right! .. only thing will be user may have to go in and change the MSP path if he has too ... but then he shoudn't have to if he chaose is input directory param wisely
mastersingh24 (Tue, 28 Feb 2017 18:08:22 GMT):
well I'll generate the file in the same structure and point the absolute paths in the file
mastersingh24 (Tue, 28 Feb 2017 18:08:37 GMT):
so should be able to run the configtx tool and just point it at the file
mastersingh24 (Tue, 28 Feb 2017 18:08:50 GMT):
for bonus points, I want to also spit out a compose file ;)
C0rWin (Tue, 28 Feb 2017 18:13:19 GMT):
Just to make sure I have got it correct. We will be using tool to generate configtx.yaml file which will be fed into another tool to generate genesis block, which will be input into third tool to generate/create channel. Is this correct?
C0rWin (Tue, 28 Feb 2017 18:15:47 GMT):
\/\/cc @mastersingh24 @muralisr
C0rWin (Tue, 28 Feb 2017 18:15:47 GMT):
./cc @mastersingh24 @muralisr
mastersingh24 (Tue, 28 Feb 2017 18:23:11 GMT):
@C0rWin - I think that's right. I'll look to simplify things as best I can over time
C0rWin (Tue, 28 Feb 2017 18:26:39 GMT):
@mastersingh24 Although this much easier than manually handling configtx.yaml, sounds pretty complex ;) why not to generate config block instead of intermidiate config file?
mastersingh24 (Tue, 28 Feb 2017 18:27:21 GMT):
yeah - that's doable as well
mastersingh24 (Tue, 28 Feb 2017 18:27:21 GMT):
yeah - that's doable as well - just had to read the directions ;)
mastersingh24 (Tue, 28 Feb 2017 18:28:27 GMT):
I can generate the crypto material, configtx.yaml (in case someone wants to modify it), the genesis block and the blob needed for create channel
C0rWin (Tue, 28 Feb 2017 18:30:43 GMT):
Sounds pretty awesome
s.narayanan (Tue, 28 Feb 2017 19:24:31 GMT):
What is the process of deploying system chaincodes (ESCC, VSCC, LSCC, CSCC etc.).? Do they come up automatically with the peer or need to be explicitly deployed?
jimthematrix (Tue, 28 Feb 2017 21:12:45 GMT):
@jyellick @muralisr seeing the following error when creating channel using CLI:
```jimzhang:fabric jimzhang$ CORE_PEER_COMMITTER_LEDGER_ORDERER=localhost:7050 build/bin/peer channel create -c foo -f foo.tx
Error: Got unexpected status: BAD_REQUEST
Usage:
peer channel create [flags]
Global Flags:
-b, --blockpath string Path to file containing genesis block
-c, --chain string In case of a newChain command, the chain ID to create.
-f, --file string Configuration transaction file generated by a tool such as configtxgen for submitting to orderer
--logging-level string Default logging level and overrides, see core.yaml for full syntax
--test.coverprofile string Done (default "coverage.cov")
-v, --version Display current version of fabric peer server
```
jyellick (Tue, 28 Feb 2017 21:12:46 GMT):
Has joined the channel.
jimthematrix (Tue, 28 Feb 2017 21:13:34 GMT):
the peer and orderer log:
```peer1 | 2017-02-28 21:11:17.720 UTC [gossip/discovery#192.168.0.4:7051] periodicalSendAlive -> DEBU 1bd Sleeping 5s
orderer | 2017-02-28 21:11:18.579 UTC [orderer/main] Deliver -> DEBU 340 Starting new Deliver handler
orderer | 2017-02-28 21:11:18.579 UTC [orderer/common/deliver] Handle -> DEBU 341 Starting new deliver loop
orderer | 2017-02-28 21:11:18.579 UTC [orderer/common/deliver] Handle -> DEBU 342 Attempting to read seek info message
orderer | 2017-02-28 21:11:18.580 UTC [orderer/main] Broadcast -> DEBU 343 Starting new Broadcast handler
orderer | 2017-02-28 21:11:18.580 UTC [orderer/common/broadcast] Handle -> DEBU 344 Preprocessing CONFIG_UPDATE
orderer | 2017-02-28 21:11:18.580 UTC [orderer/multichain] Process -> DEBU 345 Processing channel reconfiguration request for channel foo
orderer | 2017-02-28 21:11:18.583 UTC [orderer/common/deliver] Handle -> ERRO 346 Error reading from stream: stream error: code = 1 desc = "context canceled"
peer2 | 2017-02-28 21:11:18.883 UTC [gossip/discovery#192.168.0.5:7051] periodicalSendAlive -> DEBU 1bd Sleeping 5s
peer3 | 2017-02-28 21:11:19.221 UTC [gossip/discovery#192.168.0.6:7051] periodicalSendAlive -> DEBU 1bd Sleeping 5s
peer1 | 2017-02-28 21:11:22.722 UTC [gossip/discovery#192.168.0.4:7051] periodicalSendAlive -> DEBU 1be Sleeping 5s
```
muralisr (Tue, 28 Feb 2017 21:40:45 GMT):
@jimthematrix I see that when the channel is already there (for example)
muralisr (Tue, 28 Feb 2017 21:41:03 GMT):
let me check something
muralisr (Tue, 28 Feb 2017 21:43:48 GMT):
right I issued `peer channel create...` twice in succession ...got the BAD_REQUEST error the second time
jimthematrix (Tue, 28 Feb 2017 21:44:51 GMT):
ok i'll try this again
jimthematrix (Tue, 28 Feb 2017 21:45:15 GMT):
i'm pretty sure i saw this error even the first attempt to create channel
jimthematrix (Tue, 28 Feb 2017 21:45:22 GMT):
but i'll know for sure soon
jimthematrix (Tue, 28 Feb 2017 21:45:31 GMT):
just pulled the latest and rebuilding docker
jimthematrix (Tue, 28 Feb 2017 21:46:00 GMT):
(was told the change to use SKIs to track private keys were backed out)
muralisr (Tue, 28 Feb 2017 21:46:02 GMT):
ok
jsong1230 (Wed, 01 Mar 2017 03:22:25 GMT):
Has joined the channel.
SyneBlockChainTeam (Wed, 01 Mar 2017 11:42:27 GMT):
Has joined the channel.
bkvellanki (Wed, 01 Mar 2017 20:15:05 GMT):
Has joined the channel.
Donald Liu (Thu, 02 Mar 2017 01:21:44 GMT):
Has joined the channel.
jimthematrix (Fri, 03 Mar 2017 18:10:46 GMT):
@dave.enyeart @muralisr there doesn't seem to be a block event getting sent out when the genesis block gets committed to the ledger during join channel call, am I missing something?
jimthematrix (Fri, 03 Mar 2017 18:12:16 GMT):
I'm trying to get a reliable way to notify the app that the channel has been successfully joined on a peer. i thought "ok it's a block event". but looking at the peer log there doesn't seem to be one for this occasion
wisam.mohammed (Fri, 03 Mar 2017 19:07:19 GMT):
Has joined the channel.
wisam.mohammed (Fri, 03 Mar 2017 19:17:19 GMT):
Hi every one
wisam.mohammed (Fri, 03 Mar 2017 19:17:21 GMT):
I try to use CLI. I have the following error when I try to install the chaincode. BTW, create/join channal already done.
1:38:15 PM: ------------------
1:38:17 PM: root@peer-03:/fabric/peer# CORE_PEER_ADDRESS=peer-01:7051 peer chaincode install -n mycc -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 -v v0
2017-03-03 16:37:12.576 UTC [logging] InitFromViper -> DEBU 001 Setting default logging level to DEBUG for command 'chaincode'
2017-03-03 16:37:12.580 UTC [msp] GetLocalMSP -> DEBU 002 Returning existing local MSP
2017-03-03 16:37:12.580 UTC [msp] GetDefaultSigningIdentity -> DEBU 003 Obtaining default signing identity
panic: runtime error: index out of range
goroutine 1 [running]:
panic(0xc0b000, 0xc4200120e0)
/opt/go/src/runtime/panic.go:500 +0x1a1
github.com/hyperledger/fabric/core/chaincode/platforms/golang.(*Platform).ValidateSpec(0x130e338, 0xc420342580, 0x130e338, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/platforms/golang/platform.go:87 +0x36d
github.com/hyperledger/fabric/peer/chaincode.checkSpec(0xc420342580, 0x6, 0xc420196efc)
/opt/gopath/src/github.com/hyperledger/fabric/peer/chaincode/common.go:51 +0xf1
github.com/hyperledger/fabric/peer/chaincode.getChaincodeBytes(0xc420342580, 0xc420342501, 0x0, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/peer/chaincode/common.go:59 +0x147
github.com/hyperledger/fabric/peer/chaincode.chaincodeInstall(0xc4202146c0, 0xc42026a5a0, 0x0, 0x6, 0xc420336720, 0x9, 0x9)
/opt/gopath/src/github.com/hyperledger/fabric/peer/chaincode/install.go:105 +0x2b1
github.com/hyperledger/fabric/peer/chaincode.installCmd.func1(0xc4202146c0, 0xc42026a5a0, 0x0, 0x6, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/peer/chaincode/install.go:44 +0x52
github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).execute(0xc4202146c0, 0xc42026a3c0, 0x6, 0x6, 0xc4202146c0, 0xc42026a3c0)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:599 +0x234
github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0x12b8ce0, 0xf, 0xc4201f2da8, 0x7)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:689 +0x367
github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).Execute(0x12b8ce0, 0x10, 0xc4201f2da8)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:648 +0x2b
main.main()
/opt/gopath/src/github.com/hyperledger/fabric/peer/main.go:111 +0x52d
wisam.mohammed (Fri, 03 Mar 2017 19:18:09 GMT):
any idea :) ?
Ratnakar (Fri, 03 Mar 2017 19:21:28 GMT):
@wisam.mohammed what is your GOPATH ?
wisam.mohammed (Fri, 03 Mar 2017 19:23:40 GMT):
@Ratnakar I don't know :/
wisam.mohammed (Fri, 03 Mar 2017 19:25:43 GMT):
this is first time for me using cli
Ratnakar (Fri, 03 Mar 2017 19:28:36 GMT):
could you tell me which link you are following for instructions
dave.enyeart (Fri, 03 Mar 2017 19:29:15 GMT):
@jimthematrix I checked the code and you are right. Block events get sent from normal committer path. joinChain() is a separate path that doesn't go through the normal committer path, and therefore no block event. @muralisr @binhn Should joinChain() be calling producer.SendProducerBlockEvent(block)?
wisam.mohammed (Fri, 03 Mar 2017 19:29:47 GMT):
@Ratnakar http://hyperledger-fabric.readthedocs.io/en/latest/asset_setup.html#asset-transfer-with-cli AND https://github.com/hyperledger/fabric/blob/master/docs/source/install_instantiate.rst
jimthematrix (Fri, 03 Mar 2017 19:31:06 GMT):
thanks @dave.enyeart for confirming that, i would advocate for one and this seems a code that that's on the leaf branch
jimthematrix (Fri, 03 Mar 2017 19:31:13 GMT):
so it feels safe to do...
jimthematrix (Fri, 03 Mar 2017 19:31:28 GMT):
but will let @binhn and @muralisr weigh in
jimthematrix (Fri, 03 Mar 2017 19:31:52 GMT):
"I'll always have sleep()" :wink:
binhn (Fri, 03 Mar 2017 19:31:53 GMT):
@dave.enyeart the event is / should be emitted on the round-trip when the genesis block delivered to the peer who joined the channel
dave.enyeart (Fri, 03 Mar 2017 19:37:03 GMT):
@binhn the block event is currently not emitted for genesis blocks, since it goes through joinChain() rather than normal committer flow. I can add it to joinChain(). Agreed?
binhn (Fri, 03 Mar 2017 19:39:34 GMT):
no, it should be on the commit side like any other block; when a peer joins a channel, it eventually receives the GB and we should emit block event when we process that GB
binhn (Fri, 03 Mar 2017 19:39:53 GMT):
if that path is not there, we should defect it
mastersingh24 (Fri, 03 Mar 2017 19:49:20 GMT):
@dave.enyeart - I recall that's there a check in place for the type of block/transaction during commit? so perhaps config blocks don't make it to where we actually emit the events after commit?
dave.enyeart (Fri, 03 Mar 2017 20:02:00 GMT):
@mastersingh24 config blocks do emit events in general. genesis block is a special case though. tracking it down with binh and artem now.
C0rWin (Fri, 03 Mar 2017 20:03:05 GMT):
GB, block commit directly into the ledger during the channel creation
C0rWin (Fri, 03 Mar 2017 20:03:21 GMT):
otherwise there is a chicken and the egg problem
C0rWin (Fri, 03 Mar 2017 20:03:39 GMT):
just confirmed, no event for GB
wisam.mohammed (Fri, 03 Mar 2017 20:10:52 GMT):
@Ratnakar I set the GOPATH. now is "
/root"
wisam.mohammed (Fri, 03 Mar 2017 20:11:46 GMT):
@Ratnakar there gone. but new error it say "Error: Error getting chaincode code chaincode:"
wisam.mohammed (Fri, 03 Mar 2017 20:12:34 GMT):
@Ratnakar * the error gone. but there is new error it say "Error: Error getting chaincode code chaincode:"
Ratnakar (Fri, 03 Mar 2017 20:12:35 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=4d3Kssjp9nhorP5aD) @wisam.mohammed Those are little old instructions , Probably you can refer https://github.com/ratnakar-asara/e2e for now till this gets merged https://gerrit.hyperledger.org/r/#/c/6607
wisam.mohammed (Fri, 03 Mar 2017 20:13:59 GMT):
@Ratnakar Ok
dave.enyeart (Fri, 03 Mar 2017 20:15:25 GMT):
@jimthematrix @C0rWin @binhn Ok, Binh says that Artem will add the gb event emission in joinChain() as a temporary workaround.
dave.enyeart (Fri, 03 Mar 2017 20:17:59 GMT):
@C0rWin Just make sure the event emission is at the very end of joinChain(), so that all the infrastructure is ready before the event goes out
dave.enyeart (Fri, 03 Mar 2017 20:18:49 GMT):
In fact, if this is not a new chain, SDK would prefer that all known blocks are delivered before the event goes back
dave.enyeart (Fri, 03 Mar 2017 20:18:49 GMT):
In fact, if this is not a new chain in the network, SDK would prefer that all known blocks are delivered before the event goes back
dave.enyeart (Fri, 03 Mar 2017 20:19:03 GMT):
@bretharrison ^^^^^^
jimthematrix (Fri, 03 Mar 2017 21:24:07 GMT):
thanks @dave.enyeart @C0rWin !
C0rWin (Fri, 03 Mar 2017 21:35:26 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=D8fbSJeHS4QiDcZWB) @jimthematrix https://gerrit.hyperledger.org/r/#/c/6807/
dave.enyeart (Fri, 03 Mar 2017 22:24:58 GMT):
@C0rWin @jimthematrix I was thinking the event should be sent out at the end of joinChain(), to ensure the createChain() and InitChain() initialization steps completed before the event goes back to SDK. Otherwise SDK may try to use it before its initialized.
C0rWin (Fri, 03 Mar 2017 22:25:39 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=FddzM6u6NrhhWc4QF) @dave.enyeart make sense
C0rWin (Fri, 03 Mar 2017 22:25:50 GMT):
@jimthematrix what do you think?
dave.enyeart (Fri, 03 Mar 2017 22:26:25 GMT):
@bretharrison (on Jim's team) requested that
C0rWin (Fri, 03 Mar 2017 22:27:57 GMT):
ok, doing that will mean it will send event also on peer restart as well
dave.enyeart (Fri, 03 Mar 2017 22:28:22 GMT):
ugh, that's not good
C0rWin (Fri, 03 Mar 2017 22:28:58 GMT):
let me think how to do it
C0rWin (Fri, 03 Mar 2017 22:29:04 GMT):
I think I can handle it
yacovm (Fri, 03 Mar 2017 22:29:35 GMT):
perhaps use timestamp?
C0rWin (Fri, 03 Mar 2017 22:29:42 GMT):
no-no
C0rWin (Fri, 03 Mar 2017 22:29:52 GMT):
will move it into
C0rWin (Fri, 03 Mar 2017 22:29:57 GMT):
```func joinChain(blockBytes []byte) pb.Response {
if blockBytes == nil {
return shim.Error("Genesis block must not be nil.")
}
block, err := utils.GetBlockFromBlockBytes(blockBytes)
if err != nil {
return shim.Error(fmt.Sprintf("Failed to reconstruct the genesis block, %s", err))
}
if err = peer.CreateChainFromBlock(block); err != nil {
return shim.Error(err.Error())
}
chainID, err := utils.GetChainIDFromBlock(block)
if err != nil {
return shim.Error(fmt.Sprintf("Failed to get the chain ID from the configuration block, %s", err))
}
peer.InitChain(chainID)
return shim.Success(nil)
}```
yacovm (Fri, 03 Mar 2017 22:30:02 GMT):
ah
yacovm (Fri, 03 Mar 2017 22:30:04 GMT):
even better!
C0rWin (Fri, 03 Mar 2017 22:30:11 GMT):
so will be called only on join channel
yacovm (Fri, 03 Mar 2017 22:30:17 GMT):
:thumbsup:
C0rWin (Fri, 03 Mar 2017 22:30:22 GMT):
what do you think @dave.enyeart @jimthematrix ?
dave.enyeart (Fri, 03 Mar 2017 22:30:29 GMT):
loving it
C0rWin (Fri, 03 Mar 2017 22:31:39 GMT):
ok
C0rWin (Fri, 03 Mar 2017 22:32:15 GMT):
done
C0rWin (Fri, 03 Mar 2017 22:32:40 GMT):
https://gerrit.hyperledger.org/r/#/c/6807/
fbenhamo (Sat, 04 Mar 2017 02:52:32 GMT):
Has joined the channel.
jimthematrix (Sat, 04 Mar 2017 14:32:35 GMT):
@C0rWin 6807 looks good to me, sorry for the late response, thanks for providing the fix so quickly
calin.grecu (Sun, 05 Mar 2017 13:50:34 GMT):
Has joined the channel.
jeffgarratt (Mon, 06 Mar 2017 23:19:30 GMT):
@mffrench this is the channel I was referring to
mffrench (Mon, 06 Mar 2017 23:19:30 GMT):
Has joined the channel.
jeffgarratt (Mon, 06 Mar 2017 23:20:09 GMT):
I can take some time to upgrade to python 3.x since we now use virtual environments for setup.
jeffgarratt (Mon, 06 Mar 2017 23:37:23 GMT):
@mffrench please refer to https://github.com/hyperledger/fabric/tree/master/bddtests#welcome-to-the-behavioral-driven-development-bdd-subsytem-for-fabric for the instructions on setting up for behave testing using python 2.x through virtual environment. Will not impact your python 3 setup.
ziyuan (Mon, 06 Mar 2017 23:57:06 GMT):
Has joined the channel.
WeDoIoE (Tue, 07 Mar 2017 00:15:23 GMT):
Has joined the channel.
GenkiA (Tue, 07 Mar 2017 03:47:37 GMT):
Has joined the channel.
evafo (Tue, 07 Mar 2017 05:02:44 GMT):
Has joined the channel.
DannyWong (Tue, 07 Mar 2017 05:35:44 GMT):
Has joined the channel.
levinkwong (Tue, 07 Mar 2017 05:36:13 GMT):
Has joined the channel.
mffrench (Tue, 07 Mar 2017 08:18:30 GMT):
@jeffgarratt : thank you for your inputs ! will look to this deeper :)
mffrench (Tue, 07 Mar 2017 09:54:06 GMT):
FYI : some problem I get since yesterday :
```
$ make docker
Building docker testenv-image
docker build -t hyperledger/fabric-testenv build/image/testenv
Sending build context to Docker daemon 43.61 MB
Step 1 : FROM hyperledger/fabric-buildenv:x86_64-0.7.0-snapshot-01cc491
Pulling repository docker.io/hyperledger/fabric-buildenv
Error: image hyperledger/fabric-buildenv:x86_64-0.7.0-snapshot-01cc491 not found
Makefile:232: recipe for target 'build/image/testenv/.dummy-x86_64-0.7.0-snapshot-ba68129' failed
make: *** [build/image/testenv/.dummy-x86_64-0.7.0-snapshot-ba68129] Error 1
```
mffrench (Tue, 07 Mar 2017 09:54:06 GMT):
FYI : some problem I get since yesterday :
```
$ make docker
...
Building docker testenv-image
docker build -t hyperledger/fabric-testenv build/image/testenv
Sending build context to Docker daemon 43.61 MB
Step 1 : FROM hyperledger/fabric-buildenv:x86_64-0.7.0-snapshot-01cc491
Pulling repository docker.io/hyperledger/fabric-buildenv
Error: image hyperledger/fabric-buildenv:x86_64-0.7.0-snapshot-01cc491 not found
Makefile:232: recipe for target 'build/image/testenv/.dummy-x86_64-0.7.0-snapshot-ba68129' failed
make: *** [build/image/testenv/.dummy-x86_64-0.7.0-snapshot-ba68129] Error 1
```
mffrench (Tue, 07 Mar 2017 09:56:58 GMT):
because I clean my docker env manually in fact
mffrench (Tue, 07 Mar 2017 09:57:27 GMT):
after make docker-clean all dockerfile are cleaned properly with images
mffrench (Tue, 07 Mar 2017 09:58:50 GMT):
is there also some doc about docker images usage for DEV I should read ?
Manikanda Gunasekaran (Tue, 07 Mar 2017 10:21:07 GMT):
Has joined the channel.
jimthematrix (Tue, 07 Mar 2017 13:50:22 GMT):
getting the following error when sending transactions:
```peer3 | 2017-03-07 13:45:34.167 UTC [deliveryClient] NewDeliverService -> ERRO 031 Cannot dial to 127.0.0.1:7050, because of grpc: timed out when dialing
peer3 | 2017-03-07 13:45:34.168 UTC [gossip/service] InitializeChannel -> WARN 032 Cannot create delivery client, due to Wasn't able to connect to any of ordering service endpoints [127.0.0.1:7050]
peer3 | 2017-03-07 13:45:34.168 UTC [gossip/service] InitializeChannel -> WARN 033 Delivery client is down won't be able to pull blocks for chain mychannel
```
jimthematrix (Tue, 07 Mar 2017 13:51:48 GMT):
notice the peer is contacting '127.0.0.1:7050' even though the docker compose sets the orderer to a reference to the orderer container:
``` peer3:
container_name: peer3
image: hyperledger/fabric-peer
environment:
- CORE_PEER_ADDRESSAUTODETECT=true
- CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
- CORE_PEER_GOSSIP_ORGLEADER=false
- CORE_PEER_NETWORKID=peer3
- CORE_NEXT=true
- CORE_PEER_ENDORSER_ENABLED=true
- CORE_PEER_ID=peer3
- CORE_PEER_PROFILE_ENABLED=true
- CORE_PEER_COMMITTER_LEDGER_ORDERER=orderer:7050
- CORE_PEER_LOCALMSPID=Org2MSP
- CORE_PEER_MSPCONFIGPATH=/etc/hyperledger/configtx/crypto-config/peerOrganizations/peerOrg2/peers/peerOrg2Peer2/
working_dir: /opt/gopath/src/github.com/hyperledger/fabric
command: peer node start --peer-defaultchain=false
ports:
- 8056:7051
- 8058:7053
links:
- orderer:orderer
volumes:
- /var/run/:/host/var/run/
- ./:/etc/hyperledger/configtx
depends_on:
- orderer
- peer0
- peer1
- peer2
networks:
- bridge
```
C0rWin (Tue, 07 Mar 2017 13:52:41 GMT):
@jimthematrix have you configured config block to include valid address of the ordering service?
C0rWin (Tue, 07 Mar 2017 13:54:01 GMT):
the ` - CORE_PEER_COMMITTER_LEDGER_ORDERER=orderer:7050` is not longer valid, ordering service address should be provided in config transaction
jimthematrix (Tue, 07 Mar 2017 14:29:29 GMT):
wow that's a recent change right? it makes sense but kind of frustrating that we didn't heard anything about it until now
jimthematrix (Tue, 07 Mar 2017 14:31:24 GMT):
it allows each chain to pick a different orderering service so it's a good enhancement, but I wish we were told about it sooner
muralisr (Tue, 07 Mar 2017 14:35:41 GMT):
@jimthematrix since we know which orderer created the channel tx, we shouldn't have to specify TX
muralisr (Tue, 07 Mar 2017 14:35:41 GMT):
@jimthematrix since we know which orderer created the channel tx, we shouldn't have to specify orderer at the time of joining
C0rWin (Tue, 07 Mar 2017 15:23:32 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=bnYMcN3vCK2RGyLjQ) @jimthematrix well, I've reported about the change during scrums and also there was additional commit updating docs.
ManjeetGambhir (Tue, 07 Mar 2017 19:51:37 GMT):
Has joined the channel.
ManjeetGambhir (Wed, 08 Mar 2017 03:18:50 GMT):
@muralisr Thanks murali for working session ..it was really helpful..
Hangyu (Wed, 08 Mar 2017 04:02:35 GMT):
Has joined the channel.
SubhodI (Wed, 08 Mar 2017 09:12:47 GMT):
Has joined the channel.
SubhodI (Wed, 08 Mar 2017 09:16:35 GMT):
How to specify endorsement policy for a chaincode?
As on the docs "peer chaincode deploy -C testchainid -n mycc -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 -c '{"Args":["init","a","100","b","200"]}' -P "AND('Org1.member', 'Org2.member')" " my question is how does Org1.member and Org2.member looks like? any practical example?
mffrench (Wed, 08 Mar 2017 10:49:02 GMT):
Hi there
mffrench (Wed, 08 Mar 2017 10:49:18 GMT):
I'm currently facing a new issue on bdd tests
mffrench (Wed, 08 Mar 2017 10:50:23 GMT):
```
$ behave -k -D cache-deployment-spec
...
And the user "dev0Org0" broadcasts ConfigUpdate Tx "configUpdateTx1" to orderer "orderer0" to create channel "com.acme.blockchain.jdoe.Channel1" # steps/bootstrap_impl.py:214 0.000s
Traceback (most recent call last):
File "/home/mffrench/.echinopsii/.python2_env/behave_venv/local/lib/python2.7/site-packages/behave/model.py", line 1456, in run
match.run(runner.context)
File "/home/mffrench/.echinopsii/.python2_env/behave_venv/local/lib/python2.7/site-packages/behave/model.py", line 1903, in run
self.func(context, *args, **kwargs)
File "steps/bootstrap_impl.py", line 219, in step_impl
bootstrap_util.broadcastCreateChannelConfigTx(context=context, composeService=orderer, chainId=channelId, user=user, configTxEnvelope=configTxEnvelope)
File "/home/mffrench/.echinopsii/go_workspace/src/github.com/hyperledger/fabric/bddtests/steps/bootstrap_util.py", line 1001, in broadcastCreateChannelConfigTx
dataFunc=dataFunc)
File "/home/mffrench/.echinopsii/go_workspace/src/github.com/hyperledger/fabric/bddtests/steps/orderer_util.py", line 178, in broadcastMessages
abStub = self.getABStubForComposeService(context, composeService)
File "/home/mffrench/.echinopsii/go_workspace/src/github.com/hyperledger/fabric/bddtests/steps/orderer_util.py", line 198, in getABStubForComposeService
channel = getGRPCChannel(*bdd_test_util.getPortHostMapping(context.compose_containers, composeService, 7050))
File "/home/mffrench/.echinopsii/go_workspace/src/github.com/hyperledger/fabric/bddtests/steps/bdd_test_util.py", line 105, in getPortHostMapping
if port_protocol in container.ports:
TypeError: argument of type 'NoneType' is not iterable
Captured stdout:
Will copy gensisiBlock over at this point
after_step:
mffrench (Wed, 08 Mar 2017 10:50:53 GMT):
so I got a look to the running container and noticed the orderer one was not running
mffrench (Wed, 08 Mar 2017 10:51:06 GMT):
looking to the logs I get this error message :
mffrench (Wed, 08 Mar 2017 10:51:21 GMT):
```
$ docker logs 313a094603ea11e7b11c3c18a00389c0_orderer0_1
...
2017-03-08 10:30:10.295 UTC [orderer/multichain] newLedgerResources -> CRIT 040 Error creating configtx manager and handlers: Not found
```
mffrench (Wed, 08 Mar 2017 10:52:02 GMT):
will dig further into it meanwhile if you have any tips to help let me know !
jeffgarratt (Wed, 08 Mar 2017 13:40:25 GMT):
@mffrench working to get behave tests passing with latest updates. Can watch https://jira.hyperledger.org/browse/FAB-1141 for updates
mffrench (Wed, 08 Mar 2017 15:16:21 GMT):
@jeffgarratt : thank you for this input. I'm currently on my way to learn fabric in deep and I think these bddtests - and related problems - are perfect for my learning curve.
jeffgarratt (Wed, 08 Mar 2017 15:16:37 GMT):
good deal
jeffgarratt (Wed, 08 Mar 2017 15:16:46 GMT):
should be an update today
mffrench (Wed, 08 Mar 2017 15:20:40 GMT):
about the orderer problem it seems to come from a standard conf parameter missing : IngressPolicyNames (I did update the error message -> https://github.com/hyperledger/fabric/compare/master...mffrench:behave_py2)
Suma (Wed, 08 Mar 2017 15:43:48 GMT):
Has joined the channel.
mffrench (Wed, 08 Mar 2017 15:56:23 GMT):
@jeffgarratt : is there any logging policy for the bddtests ?
jeffgarratt (Wed, 08 Mar 2017 16:07:35 GMT):
that was removed
jeffgarratt (Wed, 08 Mar 2017 16:07:44 GMT):
IngressPolicyNames was recently removed
jeffgarratt (Wed, 08 Mar 2017 16:07:55 GMT):
the current issue is with BlockDatatHashStrcutureData
jeffgarratt (Wed, 08 Mar 2017 16:08:04 GMT):
fworking on that now
jeffgarratt (Wed, 08 Mar 2017 16:08:16 GMT):
will update jira 1141 asap
jimthematrix (Wed, 08 Mar 2017 16:31:43 GMT):
@jyellick seeing the following error when using the latest `configtxgen`:
```panic: Error copying group Application: Error copying group Org1MSP: Duplicate key: AnchorPeers
goroutine 1 [running]:
github.com/hyperledger/fabric/common/configtx/tool/provisional.(*bootstrapper).GenesisBlockForChannel(0xc420210c00, 0x45bbcd6, 0xb, 0x1)
/Users/jimzhang/workspace/go/src/github.com/hyperledger/fabric/common/configtx/tool/provisional/provisional.go:212 +0x211
main.doOutputBlock(0x483ff80, 0xc420210c00, 0x45bbcd6, 0xb, 0x7fff5fbffb33, 0x15, 0x4b, 0x0)
/Users/jimzhang/workspace/go/src/github.com/hyperledger/fabric/common/configtx/tool/configtxgen/main.go:42 +0xfb
main.main()
/Users/jimzhang/workspace/go/src/github.com/hyperledger/fabric/common/configtx/tool/configtxgen/main.go:207 +0x751
```
jimthematrix (Wed, 08 Mar 2017 16:32:18 GMT):
here's the configtx.yaml:
jimthematrix (Wed, 08 Mar 2017 16:33:23 GMT):
well can't paste here, let me try pasting in chunks
jimthematrix (Wed, 08 Mar 2017 16:33:39 GMT):
```Profiles:
TwoOrgs:
Orderer:
<<: *OrdererDefaults
Organizations:
- *OrdererOrg
Application:
<<: *ApplicationDefaults
Organizations:
- *Org0
- *Org1
```
jimthematrix (Wed, 08 Mar 2017 16:33:52 GMT):
```Organizations:
# SampleOrg defines an MSP using the sampleconfig. It should never be used
# in production but may be used as a template for other definitions
- &OrdererOrg
# DefaultOrg defines the organization which is used in the sampleconfig
# of the fabric.git development environment
Name: OrdererMSP
# ID to load the MSP definition as
ID: OrdererMSP
# MSPDir is the filesystem path which contains the MSP configuration
#########################################################################
# FIXME: this path needs to be fixed to point to the actual location of #
# the project 'fabric-sdk-node' in the file system #
#########################################################################
MSPDir: /Users/jimzhang/workspace/fabric-sdk-node/test/fixtures/channel/crypto-config/ordererOrganizations/ordererOrg1/msp
# BCCSP (Blockchain crypto provider): Select which crypto implementation or
# library to use
BCCSP:
Default: SW
SW:
Hash: SHA2
Security: 256
# Location of Key Store. If this is unset, a location will
# be chosen using 'MSPDir'/keystore
FileKeyStore:
KeyStore:```
jimthematrix (Wed, 08 Mar 2017 16:34:09 GMT):
``` - &Org0
# DefaultOrg defines the organization which is used in the sampleconfig
# of the fabric.git development environment
Name: Org1MSP
# ID to load the MSP definition as
ID: Org1MSP
# MSPDir is the filesystem path which contains the MSP configuration
#########################################################################
# FIXME: this path needs to be fixed to point to the actual location of #
# the project 'fabric-sdk-node' in the file system #
#########################################################################
MSPDir: /Users/jimzhang/workspace/fabric-sdk-node/test/fixtures/channel/crypto-config/peerOrganizations/peerOrg1/msp/
# BCCSP (Blockchain crypto provider): Select which crypto implementation or
# library to use
BCCSP:
Default: SW
SW:
Hash: SHA2
Security: 256
# Location of Key Store. If this is unset, a location will
# be chosen using 'MSPDir'/keystore
FileKeyStore:
KeyStore:
AnchorPeers:
# AnchorPeers defines the location of peers which can be used
# for cross org gossip communication. Note, this value is only
# encoded in the genesis block in the Application section context
- Host: localhost
Port: 7051
- Host: localhost
Port: 7056
- &Org1
# DefaultOrg defines the organization which is used in the sampleconfig
# of the fabric.git development environment
Name: Org2MSP
# ID to load the MSP definition as
ID: Org2MSP
# MSPDir is the filesystem path which contains the MSP configuration
#########################################################################
# FIXME: this path needs to be fixed to point to the actual location of #
# the project 'fabric-sdk-node' in the file system #
#########################################################################
MSPDir: /Users/jimzhang/workspace/fabric-sdk-node/test/fixtures/channel/crypto-config/peerOrganizations/peerOrg2/msp/
# BCCSP (Blockchain crypto provider): Select which crypto implementation or
# library to use
BCCSP:
Default: SW
SW:
Hash: SHA2
Security: 256
# Location of Key Store. If this is unset, a location will
# be chosen using 'MSPDir'/keystore
FileKeyStore:
KeyStore:
AnchorPeers:
# AnchorPeers defines the location of peers which can be used
# for cross org gossip communication. Note, this value is only
# encoded in the genesis block in the Application section context
- Host: localhost
Port: 8051
- Host: localhost
Port: 8056
```
jyellick (Wed, 08 Mar 2017 16:37:18 GMT):
(Looking)
jyellick (Wed, 08 Mar 2017 16:40:10 GMT):
Thanks @jimthematrix this is a bug but a simple one line fix
jyellick (Wed, 08 Mar 2017 16:40:21 GMT):
Do you have a JIRA issue, or should I create one?
jimthematrix (Wed, 08 Mar 2017 16:40:43 GMT):
haven't created one, so please go ahead
jyellick (Wed, 08 Mar 2017 16:52:12 GMT):
@jimthematrix https://gerrit.hyperledger.org/r/#/c/7035/
jimthematrix (Wed, 08 Mar 2017 16:53:33 GMT):
thanks Jason, will try that
mffrench (Wed, 08 Mar 2017 17:17:56 GMT):
seems to me bddtests generated protobuf py files are not sync with last fabric proto definitions ... it would be great to manage such protobuf python files generation on the makefile (the protos target on the makefile works for go only as far as I understand)
tulioribeiro (Wed, 08 Mar 2017 17:18:55 GMT):
Has joined the channel.
tulioribeiro (Wed, 08 Mar 2017 17:21:14 GMT):
Hi guys, could someone help to figure out how to solve this issue:
Error: Error endorsing chaincode: rpc error: code = 2 desc = Illegal file mode detected for file src/github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02/chaincode_example02: 100755
tulioribeiro (Wed, 08 Mar 2017 17:21:27 GMT):
Thanks in advance
jeffgarratt (Wed, 08 Mar 2017 17:30:38 GMT):
@mffrench this is not currently done so we can understand the changes prior to modification of py code. In general the developer should have re-generated the proto files prior to checkin of go code. We are out of sync at the moment.
jimthematrix (Wed, 08 Mar 2017 17:31:27 GMT):
@rameshthoomu latest fabric verify job is failing (preventing 7035 from being verified):
```17:21:19 cd unit-test && docker-compose up --abort-on-container-exit --force-recreate && docker-compose down
17:21:19 The TEST_PKGS variable is not set. Defaulting to a blank string.
17:21:19 Creating unittest_vp_1
17:21:19 Creating couchdb
17:21:23 Creating unittest_unit-tests_1
17:21:30
17:21:30 ERROR: for unit-tests Cannot start service unit-tests: Cannot link to a non running container: /unittest_vp_1 AS /unittest_unit-tests_1/unittest_vp_1
17:21:30 Encountered errors while bringing up the project.
17:21:31 Makefile:117: recipe for target 'unit-test' failed
17:21:31 make: *** [unit-test] Error 1
17:21:31 Build step 'Execute shell' marked build as failure
```
rameshthoomu (Wed, 08 Mar 2017 17:31:27 GMT):
Has joined the channel.
jeffgarratt (Wed, 08 Mar 2017 17:31:28 GMT):
@tulioribeiro this is a windows file system issue
jeffgarratt (Wed, 08 Mar 2017 17:31:45 GMT):
simple fix for you env only.. meaning, I would not check it in...
rameshthoomu (Wed, 08 Mar 2017 17:31:59 GMT):
looking into this..
jimthematrix (Wed, 08 Mar 2017 17:32:05 GMT):
thanks
jeffgarratt (Wed, 08 Mar 2017 17:32:21 GMT):
@tulioribeiro @@ -145,9 +145,9 @@ func (goPlatform *Platform) ValidateDeploymentSpec(cds *pb.ChaincodeDeploymentSp
//
// Anything else is suspect in this context and will be rejected
// --------------------------------------------------------------------------------------
- if header.Mode&^0100666 != 0 {
- return fmt.Errorf("Illegal file mode detected for file %s: %o", header.Name, header.Mode)
- }
+ //if header.Mode&^0100666 != 0 {
+ // return fmt.Errorf("Illegal file mode detected for file %s: %o", header.Name, header.Mode)
+ //}
}
jeffgarratt (Wed, 08 Mar 2017 17:32:41 GMT):
@tulioribeiro sorry... missed a bit...
jeffgarratt (Wed, 08 Mar 2017 17:32:42 GMT):
--- a/core/chaincode/platforms/golang/platform.go
+++ b/core/chaincode/platforms/golang/platform.go
@@ -145,9 +145,9 @@ func (goPlatform *Platform) ValidateDeploymentSpec(cds *pb.ChaincodeDeploymentSp
//
// Anything else is suspect in this context and will be rejected
// --------------------------------------------------------------------------------------
- if header.Mode&^0100666 != 0 {
- return fmt.Errorf("Illegal file mode detected for file %s: %o", header.Name, header.Mode)
- }
+ //if header.Mode&^0100666 != 0 {
+ // return fmt.Errorf("Illegal file mode detected for file %s: %o", header.Name, header.Mode)
+ //}
}
return nil
jeffgarratt (Wed, 08 Mar 2017 17:33:01 GMT):
this will allow you to run just fine on windows 'dev' environment
jeffgarratt (Wed, 08 Mar 2017 17:33:35 GMT):
of course use caution with respect to product
tulioribeiro (Wed, 08 Mar 2017 17:52:46 GMT):
@jeffgarratt I'm not using windows, I'm trying running outside of vagrant. I'm using Linux Mint 18. Thanks again.
tulioribeiro (Wed, 08 Mar 2017 17:53:45 GMT):
I've rebuild my vagrant machine, I'll verify if the issue continues there.
jeffgarratt (Wed, 08 Mar 2017 18:23:48 GMT):
understood
jeffgarratt (Wed, 08 Mar 2017 18:24:28 GMT):
@tulioribeiro basically make sure nothing is executable that goes into deployment
mffrench (Wed, 08 Mar 2017 21:00:35 GMT):
@jeffgarratt and for the some interested on my behave venture on current dev fabric : I did some progress from step 22 to step 25 :)
mffrench (Wed, 08 Mar 2017 21:02:11 GMT):
you can follow my changes here : https://github.com/hyperledger/fabric/compare/master...mffrench:behave_py2
mffrench (Wed, 08 Mar 2017 21:03:07 GMT):
current error :
```
Then user "dev0Org0" should get a delivery "genesisBlockForMyNewChannel" from "orderer0" of "1" blocks with "1" messages within "1" seconds # steps/bootstrap_impl.py:247 0.001s
Assertion Failed: Expected 1 blocks, received 0
```
mffrench (Wed, 08 Mar 2017 21:04:32 GMT):
on the ordered side I can see these logs :
```
2017-03-08 20:55:58.148 UTC [orderer/common/broadcast] Handle -> DEBU 0c2 Broadcast is filtering message for channel 939dbc2b044111e7b11c3c18a00389c0
2017-03-08 20:55:58.148 UTC [common/policies] GetPolicy -> DEBU 0c3 Returning policy Writers for evaluation
2017-03-08 20:55:58.148 UTC [orderer/common/sigfilter] Apply -> DEBU 0c4 Rejecting because of err: Failed to reach implicit threshold of 1 sub-policies, required 1 remaining
2017-03-08 20:55:58.148 UTC [orderer/common/broadcast] Handle -> DEBU 0c5 Rejecting broadcast message : Rejected by rule: *sigfilter.sigFilter
```
mffrench (Wed, 08 Mar 2017 21:05:34 GMT):
Will dig this later !
ManjeetGambhir (Thu, 09 Mar 2017 00:05:47 GMT):
Thanks @muralisr @rickr @weeds @simsc for all support provided in block event processing...Now we have proposalrequest, proposal response and validity of transaction of sample code..thanks ..will use now internal chaincode and see the progress
simsc (Thu, 09 Mar 2017 00:05:47 GMT):
Has joined the channel.
xiangyw (Thu, 09 Mar 2017 01:38:45 GMT):
Has joined the channel.
bkvellanki (Thu, 09 Mar 2017 03:16:21 GMT):
Hi Manjeet..can you please share the sample code..
bkvellanki (Thu, 09 Mar 2017 03:16:27 GMT):
appreciate your help
steigensonne (Thu, 09 Mar 2017 09:45:33 GMT):
Has joined the channel.
aberfou (Thu, 09 Mar 2017 13:48:40 GMT):
Has joined the channel.
weeds (Thu, 09 Mar 2017 17:14:32 GMT):
@ManjeetGambhir VERY COOL!
mffrench (Thu, 09 Mar 2017 17:45:36 GMT):
Hi there
mffrench (Thu, 09 Mar 2017 17:46:39 GMT):
still on the behave tests and I'm now facing error on the endorser install proposal step
mffrench (Thu, 09 Mar 2017 17:49:20 GMT):
```
And user "dev0Org0" using cert alias "dev0Org0App1" creates a install proposal "installProposal1" for channel "com.acme.blockchain.jdoe.Channel1" using chaincode spec "cc_spec" # steps/endorser_impl.py:41 0.004s
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/behave/model.py", line 1456, in run
match.run(runner.context)
File "/usr/local/lib/python2.7/dist-packages/behave/model.py", line 1903, in run
self.func(context, *args, **kwargs)
File "steps/endorser_impl.py", line 49, in step_impl
ccDeploymentSpec = endorser_util.createDeploymentSpec(context=context, ccSpec=ccSpec)
File "/home/mffrench/.echinopsii/go_workspace/src/github.com/hyperledger/fabric/bddtests/steps/endorser_util.py", line 157, in createDeploymentSpec
_createDeploymentSpecAsFile(ccSpec=ccSpec, outputPath=outputPath)
File "/home/mffrench/.echinopsii/go_workspace/src/github.com/hyperledger/fabric/bddtests/steps/endorser_util.py", line 145, in _createDeploymentSpecAsFile
bdd_test_util.cli_call(["peer","chaincode","package"] + nameArgs + ctorArgs + pathArgs + versionArgs + [outputPath], expect_success=True, env=myEnv)
File "/home/mffrench/.echinopsii/go_workspace/src/github.com/hyperledger/fabric/bddtests/steps/bdd_test_util.py", line 38, in cli_call
raise e
OSError: [Errno 2] No such file or directory
```
mffrench (Thu, 09 Mar 2017 17:50:21 GMT):
because the compiled peer binary is not in the path
(
executed command is :
```
['peer', 'chaincode', 'package', '-n', u'example02', '-c', '{"Args": ["init", "a", "100", "b", "200"]}', '-p', u'github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02', '-v', u'test', 'tmp/a19eecde04e811e7a1993c18a00389c0/deploymentspec-golang-github-com-hyperledger-fabric-examples-chaincode-go-chaincode-example02-example02']
```
)
mffrench (Thu, 09 Mar 2017 17:53:37 GMT):
then when I add build/bin to my path I get following error :
```
Error Message:
panic: Fatal error when setting up MSP from directory ./../msp/sampleConfig: err Could not load a valid signer certificate from directory ../msp/sampleConfig/signcerts, err Could not read directory open ../msp/sampleConfig/signcerts: no such file or directory, err ../msp/sampleConfig/signcerts
```
mffrench (Thu, 09 Mar 2017 17:55:19 GMT):
so i'd like to know if I should generate this MSP setup myself or if this is some static configuration which should be in the git repo already ?
jeffgarratt (Thu, 09 Mar 2017 21:50:17 GMT):
@mffrench quick change, or you can repull master. This is fixed :)
jeffgarratt (Thu, 09 Mar 2017 22:02:09 GMT):
(behave_venv) vagrant@hyperledger-devenv:v0.3.0-7134cad:/opt/gopath/src/github.com/hyperledger/fabric/bddtests$ docker inspect a0d45c6bfb8e | grep peer
"sleep 2; peer node start --peer-defaultchain=false"
jeffgarratt (Thu, 09 Mar 2017 22:20:49 GMT):
@mffrench all of the MSP setup is automatic.
ruslan.kryukov (Fri, 10 Mar 2017 04:06:45 GMT):
Has joined the channel.
AlanLee (Fri, 10 Mar 2017 04:17:48 GMT):
Has joined the channel.
SyneBlockChainTeam (Fri, 10 Mar 2017 05:09:34 GMT):
While running "make dist-all clean" as mentioned on 'Building the fabric' ( http://hyperledger-fabric.readthedocs.io/en/latest/dev-setup/build.html),
we are receive various errors e.g.
Makefile:258: recipe for target 'ccenv-docker-clean' failed
make: [ccenv-docker-clean] Error 123 (ignored)
Makefile:258: recipe for target 'javaenv-docker-clean' failed
make: [javaenv-docker-clean] Error 123 (ignored)
Makefile:180: recipe for target 'build/bin/peer' failed
make: *** [build/bin/peer] Error 2
Below is the complete log, for detailed information:
Please let us know, how to resolve this or let us know where to this query.
Thanks in advance.
SyneBlockChainTeam (Fri, 10 Mar 2017 05:11:50 GMT):
test
SyneBlockChainTeam (Fri, 10 Mar 2017 05:13:17 GMT):
Message Attachments
SyneBlockChainTeam (Fri, 10 Mar 2017 05:13:17 GMT):
While running "make dist-all clean" as mentioned on 'Building the fabric' ( http://hyperledger-fabric.readthedocs.io/en/latest/dev-setup/build.html),
we are receiving various errors e.g.
Makefile:258: recipe for target 'ccenv-docker-clean' failed
make: [ccenv-docker-clean] Error 123 (ignored)
...
...
Makefile:258: recipe for target 'javaenv-docker-clean' failed
make: [javaenv-docker-clean] Error 123 (ignored)
...
...
Makefile:180: recipe for target 'build/bin/peer' failed
make: *** [build/bin/peer] Error 2
(We have attached the complete log, for reference)
Please let us know, how to resolve this or let us know where to post this query.
Thanks in advance.
Message Attachments
SyneBlockChainTeam (Fri, 10 Mar 2017 05:13:17 GMT):
While running "make dist-all clean" as mentioned on 'Building the fabric' ( http://hyperledger-fabric.readthedocs.io/en/latest/dev-setup/build.html),
we are receive various errors e.g.
Makefile:258: recipe for target 'ccenv-docker-clean' failed
make: [ccenv-docker-clean] Error 123 (ignored)
...
...
Makefile:258: recipe for target 'javaenv-docker-clean' failed
make: [javaenv-docker-clean] Error 123 (ignored)
...
...
Makefile:180: recipe for target 'build/bin/peer' failed
make: *** [build/bin/peer] Error 2
(We have attached the complete log, for reference)
Please let us know, how to resolve this or let us know where to this query.
Thanks in advance.
Message Attachments
muralisr (Fri, 10 Mar 2017 13:00:56 GMT):
@SyneBlockChainTeam let me copy this to fabric too
JatinderBali (Fri, 10 Mar 2017 15:45:04 GMT):
Has joined the channel.
mffrench (Fri, 10 Mar 2017 15:46:36 GMT):
@jeffgarratt : great ! Will look on this and report other issues if any :)
jeffgarratt (Fri, 10 Mar 2017 15:46:56 GMT):
@mffrench sounds good!
mffrench (Fri, 10 Mar 2017 16:31:36 GMT):
:)
```
1 feature passed, 0 failed, 2 skipped
1 scenario passed, 0 failed, 24 skipped
61 steps passed, 0 failed, 211 skipped, 0 undefined
Took 1m5.161s
```
mffrench (Fri, 10 Mar 2017 16:32:07 GMT):
just a last little diff to make it work on my env :
mffrench (Fri, 10 Mar 2017 16:33:44 GMT):
```
152a153
> fabric_go_root_path = myEnv['GOPATH'] + "/src/github.com/hyperledger/fabric"
159c160
< bdd_test_util.cli_call(["peer","chaincode","package"] + nameArgs + ctorArgs + pathArgs + versionArgs + [outputPath], expect_success=True, env=myEnv)
---
> bdd_test_util.cli_call([fabric_go_root_path + "/build/bin/peer","chaincode","package"] + nameArgs + ctorArgs + pathArgs + versionArgs + [outputPath], expect_success=True, env=myEnv)
```
mffrench (Fri, 10 Mar 2017 16:34:12 GMT):
then you don't need to update your PATH to find the fresh compiled peer binary
jeffgarratt (Fri, 10 Mar 2017 16:54:08 GMT):
awesome!!
jeffgarratt (Fri, 10 Mar 2017 16:55:17 GMT):
@mffrench subsequent runs should be faster if you use the cache for deployment spec flag
jeffgarratt (Fri, 10 Mar 2017 16:55:42 GMT):
also, you can turn off the doNotDecompose flag if you wish to keep your system around (which I always do, as I use for dev)
jeffgarratt (Fri, 10 Mar 2017 16:56:03 GMT):
each run is compartmenalized and will NOT collide
jeffgarratt (Fri, 10 Mar 2017 16:56:42 GMT):
just remember to clean up (the networks as well ) :)
jeffgarratt (Fri, 10 Mar 2017 16:56:52 GMT):
i run the following post run...
jeffgarratt (Fri, 10 Mar 2017 16:57:06 GMT):
docker kill $(docker ps -qa)
docker rm $(docker ps -qa)
docker network rm $(docker network ls -q)
mffrench (Fri, 10 Mar 2017 16:59:57 GMT):
I wrotte a little script to reinit the bddtests as I've several docker containers I don't want to remove
mffrench (Fri, 10 Mar 2017 17:00:00 GMT):
=> https://github.com/mffrench/fabric/blob/behave_py2/bddtests/scripts/reinit.sh
jeffgarratt (Fri, 10 Mar 2017 17:00:53 GMT):
remember, this is not required between runs
jeffgarratt (Fri, 10 Mar 2017 17:01:03 GMT):
you can keep multiple runs up all the time
jeffgarratt (Fri, 10 Mar 2017 17:01:06 GMT):
to compare
jeffgarratt (Fri, 10 Mar 2017 17:01:18 GMT):
they will not collide, even at chaincode level
mffrench (Fri, 10 Mar 2017 17:03:01 GMT):
yeah sure : this just to help cleaning docker stuffs... I reached more than hundred fabric containers and maybe 30 docker networks last monday ;)
jeffgarratt (Fri, 10 Mar 2017 17:03:15 GMT):
you are limited to 39 networks :)
jeffgarratt (Fri, 10 Mar 2017 17:03:24 GMT):
then bang!!
jeffgarratt (Fri, 10 Mar 2017 17:03:26 GMT):
no more
jeffgarratt (Fri, 10 Mar 2017 17:03:48 GMT):
also, you can use the report to verify stuff
DannyWong (Fri, 10 Mar 2017 17:04:10 GMT):
how much memory your machine got!?
jeffgarratt (Fri, 10 Mar 2017 17:04:15 GMT):
16GB
DannyWong (Fri, 10 Mar 2017 17:04:17 GMT):
100+ docker!
jeffgarratt (Fri, 10 Mar 2017 17:04:50 GMT):
here is another one to help clean your images
jeffgarratt (Fri, 10 Mar 2017 17:05:00 GMT):
docker rmi $(docker images | grep "\-vp[0-9]*\-" | tr -s ' ' | cut -d ' ' -f 1 | less)
jeffgarratt (Fri, 10 Mar 2017 17:05:14 GMT):
that will remove the chaincoide images crerated over time
jeffgarratt (Fri, 10 Mar 2017 17:05:20 GMT):
which add up fast
jeffgarratt (Fri, 10 Mar 2017 17:05:27 GMT):
stop system first to get all of them
mffrench (Fri, 10 Mar 2017 17:08:22 GMT):
@DannyWong : 16GB. Many of them where not running any more (there were the results of previous failing bddtests) but yeah this could be considered as a resource leak in some way and should be monitored...
jeffgarratt (Fri, 10 Mar 2017 17:09:02 GMT):
the latest feature file has the doNotDecompose tag commented out
jeffgarratt (Fri, 10 Mar 2017 17:09:12 GMT):
this will cleaup your system post run
jeffgarratt (Fri, 10 Mar 2017 17:09:28 GMT):
as we use this in CI
mffrench (Fri, 10 Mar 2017 17:09:29 GMT):
yep I see this change this week :)
jeffgarratt (Fri, 10 Mar 2017 17:09:49 GMT):
don't forget there is a report created per run
jeffgarratt (Fri, 10 Mar 2017 17:10:19 GMT):
if you have docGenerate on
mffrench (Fri, 10 Mar 2017 17:10:47 GMT):
yep ! I will look closer to each steps now (and probably continue my python3 port through)
jeffgarratt (Fri, 10 Mar 2017 17:11:06 GMT):
good luck!!
mffrench (Fri, 10 Mar 2017 17:11:49 GMT):
thank you :)
AlanLee (Fri, 10 Mar 2017 23:52:01 GMT):
Question: Hi, we used to use v0.6 and intend to migrate to use v1.0. We are new to touch v1.0. Membership service seems to be gone and replaced by COPS? or endorser? (Sorry, would you kindly explain a bit what is endorser or if it is related to membership ?) Thank you.
muralisr (Sat, 11 Mar 2017 00:17:45 GMT):
@AlanLee the equivalent of "membership service" in 0.6 is "fabric-ca" in 1.0. In 0.6, the peer used to interact with membership service directly while in 1.0 peer does not directly interact with the fabric-ca. Membership information is specified to the peers for each channel it participates with. That information is used for validating requests coming in on a channel (say from SDK based apps). So it is the application (using the SDK) that would interact directly with fabric-ca to get the credentials to send to the peer for executing those requests. The peer executes the request using a chaincode and if succeful endorses it with its signature. Hence, in that role, the peer is called an endorser.
muralisr (Sat, 11 Mar 2017 00:17:45 GMT):
@AlanLee the equivalent of "membership service" in 0.6 is "fabric-ca" in 1.0. In 0.6, the peer used to interact with membership service directly while in 1.0 peer does not directly interact with the fabric-ca. Membership information is specified to the peers for each channel it participates with. That information is used for validating requests coming in on a channel (say from SDK based apps). So it is the application (using the SDK) that would interact directly with fabric-ca to get the credentials so it can send requests using those credentials to the peer for execution. The peer executes the request using a chaincode and if succeful endorses it with its signature. Hence, in that role, the peer is called an endorser.
AlanLee (Sat, 11 Mar 2017 00:23:38 GMT):
Thanks @muralisr . Great thanks for your explanation. Do we have installation steps (on Documentation) on how we can use it (or migrate / try)? Previously, we have troubles connecting the peer(the endorser) to the "COPS" before (we haven't tried out fabric-ca yet). Thank you.
muralisr (Sat, 11 Mar 2017 00:25:16 GMT):
@AlanLee i would check in fabric-ca and fabric-sdk-node. I think the READMEs in both projects are good place to start
muralisr (Sat, 11 Mar 2017 00:25:53 GMT):
let me know if you need links to both
AlanLee (Sat, 11 Mar 2017 00:25:53 GMT):
By the way, we need to convert the previous chain-code to use fabric-sdk-node now?
muralisr (Sat, 11 Mar 2017 00:26:25 GMT):
there have been some changes to the API but for most part should be painless
muralisr (Sat, 11 Mar 2017 00:27:20 GMT):
for example, `Invoke(...) ([]byte, error)` is now `Invoke(...) Response`
muralisr (Sat, 11 Mar 2017 00:27:30 GMT):
changes of that magnitude
muralisr (Sat, 11 Mar 2017 00:29:02 GMT):
the biggest changes to chaincode are in ACL ... this is still a work in progress. If you are using ACL in chaincode, refer questions in fabric-crypto please
evafo (Sat, 11 Mar 2017 07:12:39 GMT):
Do you p Know can developers mutual insurance on Hyperledger ?
dRand (Sat, 11 Mar 2017 11:28:14 GMT):
Has joined the channel.
mastersingh24 (Sat, 11 Mar 2017 12:09:57 GMT):
@evafo - not sure I understand the question?
mastersingh24 (Sat, 11 Mar 2017 15:05:23 GMT):
@binhn @muralisr I'm working on trying to get the e2e_cli working with TLS enabled
muralisr (Sat, 11 Mar 2017 15:11:44 GMT):
one thing @mastersingh24 ...can you check this code out please..this is the peer trying to setup an orderer client
muralisr (Sat, 11 Mar 2017 15:11:56 GMT):
```func NewDeliverService(gossip blocksprovider.GossipServiceAdapter, endpoints []string, mcs api.MessageCryptoService) (DeliverService, error) {
indices := rand.Perm(len(endpoints))
for _, idx := range indices {
logger.Infof("Creating delivery service to get blocks from the ordering service, %s", endpoints[idx])
dialOpts := []grpc.DialOption{grpc.WithTimeout(3 * time.Second), grpc.WithBlock()}
if comm.TLSEnabled() {
dialOpts = append(dialOpts, grpc.WithTransportCredentials(comm.InitTLSForPeer()))
} else {
dialOpts = append(dialOpts, grpc.WithInsecure())
}
conn, err := grpc.Dial(endpoints[idx], dialOpts...)
if err != nil {
logger.Errorf("Cannot dial to %s, because of %s", endpoints[idx], err)
continue
}
return NewFactoryDeliverService(gossip, &blocksDelivererFactoryImpl{conn}, conn, mcs), nil
}
return nil, fmt.Errorf("Wasn't able to connect to any of ordering service endpoints %s", endpoints)
}```
mastersingh24 (Sat, 11 Mar 2017 15:13:41 GMT):
yeah - I saw that - but that does not seem to be the issue
mastersingh24 (Sat, 11 Mar 2017 15:13:54 GMT):
I was just able to join channel actually with TLS enabled!
mastersingh24 (Sat, 11 Mar 2017 15:14:05 GMT):
now to figure out what the hell I did ;)
muralisr (Sat, 11 Mar 2017 15:27:04 GMT):
:-)
muralisr (Sat, 11 Mar 2017 15:27:07 GMT):
good del
muralisr (Sat, 11 Mar 2017 15:27:11 GMT):
deal
muralisr (Sat, 11 Mar 2017 15:29:52 GMT):
the code itself is good... I was not sure about the using the same peer side TLS certs (serverhostoverride etc) for the orderer client as well
binhn (Sat, 11 Mar 2017 16:32:20 GMT):
@muralisr @mastersingh24 @jimthematrix @kostas @jyellick @weeds @jeffgarratt @C0rWin @yacovm @Asara @bmos299 @simsc
I created https://jira.hyperledger.org/browse/FAB-2744 to capture TLS config and setup that all may share and document later
Asara (Sat, 11 Mar 2017 16:32:20 GMT):
Has joined the channel.
bmos299 (Sat, 11 Mar 2017 16:32:20 GMT):
Has joined the channel.
kostas (Sat, 11 Mar 2017 16:32:20 GMT):
Has joined the channel.
binhn (Sat, 11 Mar 2017 16:34:16 GMT):
i put ratnakar's there as a subtask with attachments that you might want to start with
binhn (Sat, 11 Mar 2017 16:34:40 GMT):
gari and murali, please post yours there as well
mastersingh24 (Sat, 11 Mar 2017 17:07:09 GMT):
will do - current status:
1) Join Channel working
2) Install chaincode working
3) working on instantiate ....
binhn (Sat, 11 Mar 2017 17:11:12 GMT):
when i use cryptoGen tool, it creates this a long key filename `eac3b216abe966b113053c880ff8bf7e08167a4dc2056c06e43232c77646815e_sk` that I thought we no longer need -- @vpaprots ?
vpaprots (Sat, 11 Mar 2017 17:11:12 GMT):
Has joined the channel.
mastersingh24 (Sat, 11 Mar 2017 17:27:34 GMT):
yeah - when I built the tool, I used bccsp which generates names like that
mastersingh24 (Sat, 11 Mar 2017 17:27:53 GMT):
I believe we do actually support random names as well
jimthematrix (Sat, 11 Mar 2017 18:43:59 GMT):
@mastersingh24 In your status above, how are you testing? Bdd or cli or sdk? I'd say until you can connection from a different language (bdd or sdk) we can't claim a pass
jeffgarratt (Sat, 11 Mar 2017 18:47:57 GMT):
I am wondering if the ecdsa key usage is causing problem with the SSL negotiation?
jeffgarratt (Sat, 11 Mar 2017 18:48:05 GMT):
@jimthematrix ^^^
jeffgarratt (Sat, 11 Mar 2017 18:48:37 GMT):
I verified that no issue connecting between python nodes using RSA key based certs
mastersingh24 (Sat, 11 Mar 2017 19:21:59 GMT):
@jimthematrix - currently I've been trying to get the e2e_cli scenario working
mastersingh24 (Sat, 11 Mar 2017 19:22:12 GMT):
but I was also able to connect via openssl as well
mastersingh24 (Sat, 11 Mar 2017 19:22:56 GMT):
I think I have the last "fix" in place to get through instantiate
jimthematrix (Sat, 11 Mar 2017 19:25:56 GMT):
@mastersingh24 ok i'll try updating openssl as you suggested and give it a try again
jimthematrix (Sat, 11 Mar 2017 19:29:31 GMT):
@jeffgarratt wow that's interesting, the errors i've been seeing (connecting from sdk or openssl s_client) ranged from "wrong version number" or "unknown protocol" or "tlsv1 alert protocol version", were you seeing any of these?
jeffgarratt (Sat, 11 Mar 2017 19:32:10 GMT):
@jimthematrix @mastersingh24 should we upgrade openssl in our environments?
jeffgarratt (Sat, 11 Mar 2017 19:32:16 GMT):
if so, to what version?
mastersingh24 (Sat, 11 Mar 2017 19:33:20 GMT):
it's really only a problem running native on OSX - which uses patched version of openssl 0.9.8
mastersingh24 (Sat, 11 Mar 2017 19:33:39 GMT):
all of the Linux-based env look to have openssl 1.0.2
mastersingh24 (Sat, 11 Mar 2017 19:34:00 GMT):
here's my WIP on updating the e2e_cli to work
mastersingh24 (Sat, 11 Mar 2017 19:34:03 GMT):
https://gerrit.hyperledger.org/r/#/c/7141/
mastersingh24 (Sat, 11 Mar 2017 19:35:24 GMT):
not sure if chaincode deployment will work yet or not but you shoud be able to get all the way through create channel, join channel and install chaincode. Oh - and no TLS for the orderer yet - working on that
mastersingh24 (Sat, 11 Mar 2017 19:35:31 GMT):
need to step out for a bit tho
muralisr (Sat, 11 Mar 2017 20:06:26 GMT):
@mastersingh24 I am trying something similar to the fix in platforms.go. It currently assumes self-signed certs I think (at least current UT works with "peer.tls.cert.file") so using "peer.tls.root.file" could break that... experimenting with it.
mastersingh24 (Sat, 11 Mar 2017 20:23:13 GMT):
on the plus side, I was able to instantiate chaincode on a single peer ;)
mastersingh24 (Sat, 11 Mar 2017 20:23:21 GMT):
I think I'm failing on the orderer now
mastersingh24 (Sat, 11 Mar 2017 20:23:27 GMT):
will get on that in a bit
mastersingh24 (Sat, 11 Mar 2017 21:12:43 GMT):
@muralisr - I think I have a fix to make sure the test passes (just set the tls.rootcert to the same value as the tls.cert). I'm thinking that we should probably use rootcert if it exists and fallback to tls.cert if not
muralisr (Sat, 11 Mar 2017 21:13:22 GMT):
right. That's what I was trying too
muralisr (Sat, 11 Mar 2017 21:13:35 GMT):
but I didn't have luck with that
muralisr (Sat, 11 Mar 2017 21:13:41 GMT):
so will take what you got :-)
muralisr (Sat, 11 Mar 2017 21:13:49 GMT):
do you want me to try your patch ?
muralisr (Sat, 11 Mar 2017 21:14:02 GMT):
oh
muralisr (Sat, 11 Mar 2017 21:14:13 GMT):
`just set the tls.rootcert to the same value as the tls.cert`
muralisr (Sat, 11 Mar 2017 21:14:17 GMT):
I didn't do that part
muralisr (Sat, 11 Mar 2017 21:14:26 GMT):
let me try that
mastersingh24 (Sat, 11 Mar 2017 21:14:48 GMT):
I'm running the chaincode tests right now to see if they'll pass
muralisr (Sat, 11 Mar 2017 21:14:54 GMT):
ok
mastersingh24 (Sat, 11 Mar 2017 21:15:16 GMT):
next step is on to the orderer ;)
yacovm (Sat, 11 Mar 2017 21:15:18 GMT):
This all or nothing TLS is crazy, we should've used different listeners and ports :(
mastersingh24 (Sat, 11 Mar 2017 21:15:29 GMT):
that was the fallback
mastersingh24 (Sat, 11 Mar 2017 21:15:31 GMT):
;)
muralisr (Sat, 11 Mar 2017 21:20:31 GMT):
shouldn't be too difficult to separate out peer from orderer for TLS so we have 4 combinations (beginning to sound like a broken record, I know :-) )
mastersingh24 (Sat, 11 Mar 2017 21:36:35 GMT):
the good news is that I elminated the need for serverhostoverride for for the CLI container and for chaincode in the e2e_cli setup
mastersingh24 (Sat, 11 Mar 2017 21:36:49 GMT):
(I'm tricky like that ;) )
mastersingh24 (Sat, 11 Mar 2017 21:42:32 GMT):
@muralisr
```
func getPeerTLSCert() ([]byte, error) {
if viper.GetBool("peer.tls.enabled") == false {
// no need for certificates if TLS is not enabled
return nil, nil
}
var path string
// first we check for the rootcert
path = viper.GetString("peer.tls.rootcert.file")
if path == "" {
// check for tls cert
path = viper.GetString("peer.tls.cert.file")
}
// this should not happen if the peer is running with TLS enabled
if _, err := os.Stat(path); err != nil {
return nil, err
}
// FIXME: FAB-2037 - ensure we sanely resolve relative paths specified in the yaml
return ioutil.ReadFile(path)
}
```
muralisr (Sat, 11 Mar 2017 21:43:54 GMT):
that'd make the UT pass for sure
mastersingh24 (Sat, 11 Mar 2017 21:44:02 GMT):
(BTW - the previous code in there would actually fail if there was nothing in the peer.tls.cert.file setting
muralisr (Sat, 11 Mar 2017 21:44:14 GMT):
it works with e2e too ?
mastersingh24 (Sat, 11 Mar 2017 21:44:24 GMT):
the logic was kinda backwards
mastersingh24 (Sat, 11 Mar 2017 21:44:31 GMT):
I got chaincode to deploy in e2e
muralisr (Sat, 11 Mar 2017 21:44:36 GMT):
ok
mastersingh24 (Sat, 11 Mar 2017 21:44:45 GMT):
on 1 peer
muralisr (Sat, 11 Mar 2017 21:44:48 GMT):
I could have sworn I tried the above
muralisr (Sat, 11 Mar 2017 21:45:49 GMT):
could have easily done something wrong though... I was trying different things
mastersingh24 (Sat, 11 Mar 2017 21:46:18 GMT):
`CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE=e2ecli_default` is the other trick to eliminate the need for serverhost override
mastersingh24 (Sat, 11 Mar 2017 21:46:47 GMT):
this deploys chaincode on the same bridge network as the peers so hostname (e.g. peer0) works
mastersingh24 (Sat, 11 Mar 2017 21:48:18 GMT):
`CORE_PEER_ADDRESS=peer0:7051` - which as you know is what chaincode will use if set ;)
muralisr (Sat, 11 Mar 2017 21:49:00 GMT):
what is `e2ecli_default` ?
mastersingh24 (Sat, 11 Mar 2017 21:51:21 GMT):
ah
mastersingh24 (Sat, 11 Mar 2017 21:51:26 GMT):
well - good question
mastersingh24 (Sat, 11 Mar 2017 21:51:59 GMT):
so with docker-compose, it will create a bridge network - and it names it `{folder}_default`
mastersingh24 (Sat, 11 Mar 2017 21:52:16 GMT):
hence `e2ecli_default`
mastersingh24 (Sat, 11 Mar 2017 21:52:32 GMT):
so basically I tell the chaincode containers to join the e2ecli_default network
mastersingh24 (Sat, 11 Mar 2017 21:52:55 GMT):
and all works like a charm since containers can use hostnames when on the same network
mastersingh24 (Sat, 11 Mar 2017 21:54:45 GMT):
with the above change, chaincode tests are passing :clap:
weeds (Sat, 11 Mar 2017 21:56:29 GMT):
Thanks @binhn
weeds (Sat, 11 Mar 2017 21:56:49 GMT):
@Ratnakar @latitiah
latitiah (Sat, 11 Mar 2017 21:56:49 GMT):
Has joined the channel.
muralisr (Sat, 11 Mar 2017 21:59:26 GMT):
so @mastersingh24 let me summarize and you can correct me (I'm betting on that :-) )
muralisr (Sat, 11 Mar 2017 21:59:36 GMT):
(for my own understanding...)
muralisr (Sat, 11 Mar 2017 22:00:18 GMT):
1) the fix to getPeerTLSCert fixes UT (we basically keep using `path = viper.GetString("peer.tls.cert.file")` in UT)
muralisr (Sat, 11 Mar 2017 22:02:22 GMT):
2) the fix to use `path = viper.GetString("peer.tls.rootcert.file")` in getPeerTLSCert together with `CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE=e2ecli_default` fixes CLI -> peer (and CLI -> Orderer too ?)
mastersingh24 (Sat, 11 Mar 2017 22:02:47 GMT):
it does not fix the orderer (yet)
muralisr (Sat, 11 Mar 2017 22:02:58 GMT):
ah
muralisr (Sat, 11 Mar 2017 22:03:00 GMT):
ok
mastersingh24 (Sat, 11 Mar 2017 22:03:20 GMT):
but it puts us on a path to avoid the serverhostoverride stuff which can create problems
muralisr (Sat, 11 Mar 2017 22:03:27 GMT):
right
muralisr (Sat, 11 Mar 2017 22:03:31 GMT):
understood
mastersingh24 (Sat, 11 Mar 2017 22:05:01 GMT):
the key thing was figuring out how to get the chaincode to communicate with the peer using the hostname(s) (peerX) which are in the certificates. I also needed to change to the rootcert since this were not self-signed certs
muralisr (Sat, 11 Mar 2017 22:06:58 GMT):
right ...I had to continue to fight using serverhostoverride.. this should help get to the next step for sure
muralisr (Sat, 11 Mar 2017 22:07:23 GMT):
I was able to talk TLS with orderer and peer with a simpler setup
muralisr (Sat, 11 Mar 2017 22:07:35 GMT):
let me see if I can use your trick to get to next level
muralisr (Sat, 11 Mar 2017 22:07:51 GMT):
will pull the CR and try
mastersingh24 (Sat, 11 Mar 2017 22:47:13 GMT):
https://gerrit.hyperledger.org/r/#/c/7141/ - just posted an update
mastersingh24 (Sat, 11 Mar 2017 22:47:36 GMT):
with this, you can get all the way to instantiating chaincode on a single peer
mastersingh24 (Sat, 11 Mar 2017 22:48:00 GMT):
NOTE: I don't execute the script in the CLI container right now
mastersingh24 (Sat, 11 Mar 2017 22:48:41 GMT):
so after you run `docker-compose up -d` you can run `docker exec -it cli /bin/bash` and then run `./scripts/script/sh`
AbhilekhSingh (Sun, 12 Mar 2017 06:08:29 GMT):
Has joined the channel.
muralisr (Sun, 12 Mar 2017 13:57:04 GMT):
@mastersingh24 will pull and try
mastersingh24 (Sun, 12 Mar 2017 14:01:21 GMT):
I updated the JIRA as well, but I now have the orderer configured for TLS and am able to create channels and also issue commands from the CLI. I believe the last issue is to properly connect the peer delivery client to the TLS-enabled orderer
muralisr (Sun, 12 Mar 2017 14:10:42 GMT):
I think with all the changes in the delivery part shouldn't be close no ? Like you said - just hook up the root cas from MSP to the client connection ?
mastersingh24 (Sun, 12 Mar 2017 14:24:42 GMT):
we are close ;)
binhn (Sun, 12 Mar 2017 15:02:29 GMT):
:fingers_crossed:
mastersingh24 (Sun, 12 Mar 2017 18:30:10 GMT):
well folks, e2e is now working with TLS enabled throught the entire system (well it worked 3 times in a row on my machine)
mastersingh24 (Sun, 12 Mar 2017 18:30:12 GMT):
https://gerrit.hyperledger.org/r/#/c/7141/
mastersingh24 (Sun, 12 Mar 2017 18:30:43 GMT):
same instructions for running e2e - I added back automatically running the script in the CLI container
mastersingh24 (Sun, 12 Mar 2017 18:32:05 GMT):
@binhn @muralisr @jyellick @yacovm @jimthematrix ^^^^^
binhn (Sun, 12 Mar 2017 18:33:01 GMT):
:clap:
muralisr (Sun, 12 Mar 2017 18:33:14 GMT):
@mastersingh24 checking right away :-)
binhn (Sun, 12 Mar 2017 18:33:14 GMT):
i will try now
binhn (Sun, 12 Mar 2017 18:33:29 GMT):
thanks for all the hard work
mastersingh24 (Sun, 12 Mar 2017 18:48:15 GMT):
hopefully this is not a "it works on my machine" thing
muralisr (Sun, 12 Mar 2017 18:48:38 GMT):
one suggestion @mastersingh24 (and I can tell how much work has gone into this so don't shoot me :-) )
mastersingh24 (Sun, 12 Mar 2017 18:48:53 GMT):
enough work to get it working ;)
mastersingh24 (Sun, 12 Mar 2017 18:48:59 GMT):
no more no less
muralisr (Sun, 12 Mar 2017 18:49:12 GMT):
instead of -cafile, can we add a section to to core.yaml ?
muralisr (Sun, 12 Mar 2017 18:49:18 GMT):
orderer: ca
muralisr (Sun, 12 Mar 2017 18:49:33 GMT):
(upto you ...)
mastersingh24 (Sun, 12 Mar 2017 18:50:14 GMT):
I thought about that, but since we just removed any orderer config from core.yaml, I figured using flags was the way to go
muralisr (Sun, 12 Mar 2017 18:50:46 GMT):
we did but that was for "starting orderer"
muralisr (Sun, 12 Mar 2017 18:50:54 GMT):
but this is more about connecting with it
mastersingh24 (Sun, 12 Mar 2017 18:51:02 GMT):
also even for communicating with it
mastersingh24 (Sun, 12 Mar 2017 18:51:13 GMT):
you need to pass in -o now?
muralisr (Sun, 12 Mar 2017 18:51:16 GMT):
and it'll make the docker config uniform with ENV usages
mastersingh24 (Sun, 12 Mar 2017 18:51:26 GMT):
Oh
mastersingh24 (Sun, 12 Mar 2017 18:51:32 GMT):
WELL
mastersingh24 (Sun, 12 Mar 2017 18:51:45 GMT):
we don't need those certs except for the CLI
muralisr (Sun, 12 Mar 2017 18:51:54 GMT):
right
muralisr (Sun, 12 Mar 2017 18:51:58 GMT):
that's true
muralisr (Sun, 12 Mar 2017 18:52:18 GMT):
ok
mastersingh24 (Sun, 12 Mar 2017 18:52:22 GMT):
I figured it was more obvious that we need them to put them in as flags
muralisr (Sun, 12 Mar 2017 18:52:26 GMT):
let's leave the way
muralisr (Sun, 12 Mar 2017 18:52:26 GMT):
let's leave the way it is
binhn (Sun, 12 Mar 2017 18:52:37 GMT):
```
2017-03-12 18:50:44.948 UTC [main] main -> INFO 006 Exiting.....
===================== Query on PEER3 on channel 'mychannel' is successful =====================
===================== All GOOD, End-2-End execution completed =====================
```
binhn (Sun, 12 Mar 2017 18:53:09 GMT):
@muralisr i thnk we should address that when we separate cli from peer
mastersingh24 (Sun, 12 Mar 2017 18:53:10 GMT):
```All GOOD, End-2-End execution completed```
mastersingh24 (Sun, 12 Mar 2017 18:53:29 GMT):
sad that I have been waching for this magic words all day ;)
mastersingh24 (Sun, 12 Mar 2017 18:53:29 GMT):
sad that I have been watching for this magic words all day ;)
mastersingh24 (Sun, 12 Mar 2017 18:53:29 GMT):
sad that I have been watching for those magic words all day ;)
muralisr (Sun, 12 Mar 2017 18:54:03 GMT):
I'm going to try from CLI without the benefeit of CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE
muralisr (Sun, 12 Mar 2017 18:54:06 GMT):
:-)
muralisr (Sun, 12 Mar 2017 18:54:09 GMT):
indeed
binhn (Sun, 12 Mar 2017 18:54:16 GMT):
:wink:
binhn (Sun, 12 Mar 2017 18:54:47 GMT):
now it is working , let's review the cr and merge
mastersingh24 (Sun, 12 Mar 2017 18:55:11 GMT):
(I admit I am missing some tests) ;)
binhn (Sun, 12 Mar 2017 18:55:45 GMT):
asking jeff to give his bdd a spin with this cr
mastersingh24 (Sun, 12 Mar 2017 19:28:44 GMT):
cool. I'll be away for about an hour or so
jimthematrix (Sun, 12 Mar 2017 21:18:47 GMT):
thanks @mastersingh24, I'm modifying the fabric-sdk-node e2e to use the new code (and crypto materials), will update on the result. my tests will also include fabric-ca (that signs user ecerts) in the mix
jimthematrix (Sun, 12 Mar 2017 21:26:50 GMT):
guess i'll start with the existing crypto materials since they are shared b/w localmsp and tls
jimthematrix (Sun, 12 Mar 2017 21:26:50 GMT):
guess i'll start with the existing crypto materials since they are shared b/w localmsp and tls now with 7141
muralisr (Sun, 12 Mar 2017 23:06:03 GMT):
@mastersingh24 @binhn I tested against non-docker env from CLI as well
muralisr (Sun, 12 Mar 2017 23:06:27 GMT):
after a few user errors, got it to work
muralisr (Sun, 12 Mar 2017 23:06:27 GMT):
after a few user errors, got it to work.. the simplest out of the box scenario can use TLS with the canned msp/sampleconfig
muralisr (Mon, 13 Mar 2017 00:56:51 GMT):
Message Attachments
jimthematrix (Mon, 13 Mar 2017 04:10:11 GMT):
node sdk still getting the same error (after updating openssl in mac to 1.0.2k, and using latest 7141 CR):
```jimzhang:fabric-sdk-node jimzhang$ node test/integration/e2e/create-channel.js
info: Returning a new winston logger with default configurations
TAP version 13
#
***** End-to-end flow: create channel *****
info: [crypto_ecdsa_aes]: This class requires a CryptoKeyStore to save keys, using the store: {"opts":{"path":"/Users/jimzhang/.hfc-key-store"}}
info: [Client.js]: Successfully loaded user "admin" from local key value store
ok 1 Successfully loaded member from persistence
ok 2 Successfully enrolled user 'admin'
ok 3 Successfully read file
E0312 23:09:44.429632000 123145312870400 ssl_transport_security.c:947] Handshake failed with fatal error SSL_ERROR_SSL: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number.
E0312 23:09:44.431319000 123145312870400 ssl_transport_security.c:947] Handshake failed with fatal error SSL_ERROR_SSL: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number.
error: [Orderer.js]: sendBroadcast - on error: "Error: Connect Failed\n at ClientDuplexStream._emitStatusIfDone (/Users/jimzhang/workspace/fabric-sdk-node/node_modules/grpc/src/node/src/client.js:201:19)\n at ClientDuplexStream._readsDone (/Users/jimzhang/workspace/fabric-sdk-node/node_modules/grpc/src/node/src/client.js:169:8)\n at readCallback (/Users/jimzhang/workspace/fabric-sdk-node/node_modules/grpc/src/node/src/client.js:229:12)"
not ok 4 Error: SERVICE_UNAVAILABLE at ClientDuplexStream.
jimthematrix (Mon, 13 Mar 2017 04:10:59 GMT):
if anybody have successfully connected a node.js program to a golang program running inside docker via TLS, I could use some help
jimthematrix (Mon, 13 Mar 2017 04:12:00 GMT):
the latest code I'm experimenting has been uploaded with https://gerrit.hyperledger.org/r/#/c/7135/
mastersingh24 (Mon, 13 Mar 2017 11:33:22 GMT):
@jimthematrix - I responsed over in the node sdk channel
mastersingh24 (Mon, 13 Mar 2017 11:33:22 GMT):
@jimthematrix - I responded over in the node sdk channel
mffrench (Mon, 13 Mar 2017 11:52:13 GMT):
Hi everyone
mffrench (Mon, 13 Mar 2017 11:53:05 GMT):
here's my diffs to make work bddtests both on python 2 and python 3 env : https://github.com/hyperledger/fabric/compare/master...mffrench:behave_py3
mffrench (Mon, 13 Mar 2017 11:53:49 GMT):
```
(fabric_behave_venv_py3) ╭─mffrench@dekatonmac ~/.echinopsii/go_workspace/src/github.com/hyperledger/fabric/bddtests ‹behave_py3›
╰─$ pip -V
pip 9.0.1 from /home/mffrench/.python_envs/fabric_behave_venv_py3/lib/python3.4/site-packages (python 3.4)
(fabric_behave_venv_py3) ╭─mffrench@dekatonmac ~/.echinopsii/go_workspace/src/github.com/hyperledger/fabric/bddtests ‹behave_py3›
╰─$ behave -k -D cache-deployment-spec
@bootstrap
Feature: Bootstrap # features/bootstrap.feature:10
...
context.failed = False
1 feature passed, 0 failed, 2 skipped
1 scenario passed, 0 failed, 24 skipped
61 steps passed, 0 failed, 211 skipped, 0 undefined
Took 1m12.154s
(fabric_behave_venv_py2) ╭─mffrench@dekatonmac ~/.echinopsii/go_workspace/src/github.com/hyperledger/fabric/bddtests ‹behave_py3›
╰─$ pip -V
pip 9.0.1 from /home/mffrench/.python_envs/fabric_behave_venv_py2/local/lib/python2.7/site-packages (python 2.7)
(fabric_behave_venv_py2) ╭─mffrench@dekatonmac ~/.echinopsii/go_workspace/src/github.com/hyperledger/fabric/bddtests ‹behave_py3›
╰─$ behave -k -D cache-deployment-spec
@bootstrap
Feature: Bootstrap # features/bootstrap.feature:10
...
context.failed = False
1 feature passed, 0 failed, 2 skipped
1 scenario passed, 0 failed, 24 skipped
61 steps passed, 0 failed, 211 skipped, 0 undefined
Took 1m5.687s
```
mffrench (Mon, 13 Mar 2017 11:53:54 GMT):
:)
mffrench (Mon, 13 Mar 2017 11:54:07 GMT):
let me know if you have any feedbacks
davidkel (Mon, 13 Mar 2017 17:26:13 GMT):
Is there a timeout on a chaincode instantiate INIT call ? We have chaincode that can take 2 minutes for the INIT to run and it fails with some strange errors
```
Error: [80914958]No ledger context for GetState. Sending ERROR
```
If that is the case is this timeout applicable to Invoke as well ?
Asara (Mon, 13 Mar 2017 17:33:42 GMT):
:q
muralisr (Mon, 13 Mar 2017 18:01:06 GMT):
@davidkel theres a timeout of 30 secs. I think you are running into the situation where the requester cleaned up the context and returned error back. When the chaincode requested GetState, the context was no longer there (and you get the above error). We need to remove the hardcoded timeout and return...would you mind open a JIRA item for that please ?
muralisr (Mon, 13 Mar 2017 18:01:06 GMT):
@davidkel theres a timeout of 30 secs. I think you are running into the situation where the requester cleaned up the context and returned error back. When the chaincode called GetState, the context was no longer there (and you get the above error). We need to remove the hardcoded timeout and return...would you mind open a JIRA item for that please ?
muralisr (Mon, 13 Mar 2017 18:01:06 GMT):
@davidkel theres a timeout of 30 secs. I think you are running into the situation where the requester cleaned up the context and returned error back. When the chaincode called GetState, the context was no longer there (and you get the above error). We need to remove the hardcoded timeout and allow timeout to be specified via a property...would you mind open a JIRA item for that please ?
davidkel (Mon, 13 Mar 2017 18:44:18 GMT):
@muralisr thanks for the quick response. I can open a jira for that.
davidkel (Mon, 13 Mar 2017 18:48:38 GMT):
@muralisr fyi: https://jira.hyperledger.org/browse/FAB-2767
muralisr (Mon, 13 Mar 2017 19:02:43 GMT):
@davidkel do you need this at highest priority ?
davidkel (Mon, 13 Mar 2017 19:04:03 GMT):
@muralisr It does stop our system tests from passing unfortunately and don't know of any other way round it
davidkel (Mon, 13 Mar 2017 19:05:34 GMT):
Without this it really does stop any meaningful Fabric Composer business network from being deployed onto V1
muralisr (Mon, 13 Mar 2017 19:24:09 GMT):
@davidkel ok.. if you want to quickly unblock you can change this line `timeout := time.Duration(30000) * time.Millisecond` in core/chaincode/exectransaction.go and rebuild. Not ideal but may unblock while waiting for the fix
muralisr (Mon, 13 Mar 2017 19:25:33 GMT):
the reason for the hardcoding was the hope to not make it a system wide param but a chaincode specific one which would need more work
muralisr (Mon, 13 Mar 2017 19:25:54 GMT):
but clearly we could as well have made the 30000 a param
jeffgarratt (Mon, 13 Mar 2017 21:25:17 GMT):
@binhn @muralisr @mastersingh24 @jimthematrix have worked through most of the issues wrt TLS certs and the behave system. Down to trusted roots for the chaincode to allow connect back to associated peer
jimthematrix (Tue, 14 Mar 2017 00:45:44 GMT):
@jeffgarratt on the node sdk front we have a breakthrough, @mastersingh24 got me to realize that why node sdk client was terminating the session after successful handshake ( got both @bmos299 and @ashutosh_kumar to scratch their heads when they saw this behavior in wiresharks trace), was because it saw the server cert and didn't like it due to hostname mismatch (CN=orderer0 but I was setting hostnameoverride to `localhost`), should've looked more closely at the server certs
ashutosh_kumar (Tue, 14 Mar 2017 00:45:44 GMT):
Has joined the channel.
jeffgarratt (Tue, 14 Mar 2017 00:54:41 GMT):
good deal
jeffgarratt (Tue, 14 Mar 2017 00:54:51 GMT):
I still had an issue even with proper hostnames and overrides
ashutosh_kumar (Tue, 14 Mar 2017 01:25:45 GMT):
that did not click my mind @jimthematrix . So stupid , I was like always.:cry:
ashutosh_kumar (Tue, 14 Mar 2017 01:25:49 GMT):
:cry:
binhn (Tue, 14 Mar 2017 01:27:21 GMT):
so on nodejs, even with hostnameoverride, it still reject of the cert contain different host, right?
ashutosh_kumar (Tue, 14 Mar 2017 02:06:34 GMT):
@binhn , I think hostnameoverride is TLS client setting. @jimthematrix must have changed the code to do hostnameverifition on Node js to match server cert.
ashutosh_kumar (Tue, 14 Mar 2017 02:06:34 GMT):
@binhn , I think hostnameoverride is TLS client setting. @jimthematrix must have changed the node code to do hostnameverifition on Node js to match server cert.
ashutosh_kumar (Tue, 14 Mar 2017 02:06:34 GMT):
@binhn , I think hostnameoverride is TLS client setting. @jimthematrix must have changed the code to do hostnameverifition on Node js to match server cert.
jimthematrix (Tue, 14 Mar 2017 02:34:41 GMT):
@binhn @ashutosh_kumar (this is only relevant in testing environments) the sdk needs to set the hostnameoverride in grpc call options to match the server cert on a per-endpoint basis, the API design already accommodates this (Remote.js class), and it'll be able to connect to all the different orderer/peer nodes
jimthematrix (Tue, 14 Mar 2017 02:34:41 GMT):
@binhn @ashutosh_kumar the sdk needs to set the hostnameoverride in grpc call options to match the server cert on a per-endpoint basis, the API design already accommodates this (Remote.js class), and it'll be able to connect to all the different orderer/peer nodes (this is only needed in testing environments)
ashutosh_kumar (Tue, 14 Mar 2017 02:36:49 GMT):
@jimthematrix , have you implemented SNI ?
ashutosh_kumar (Tue, 14 Mar 2017 02:38:04 GMT):
we can talk about that tomorrow as there is always tomorrow.:grin:
ashutosh_kumar (Tue, 14 Mar 2017 02:38:09 GMT):
:grimacing:
jimthematrix (Tue, 14 Mar 2017 02:39:22 GMT):
i don't believe we have that implemented
ashutosh_kumar (Tue, 14 Mar 2017 02:49:27 GMT):
with wild card certs in vogue , that is good feature to be implemented.
krupabathia (Tue, 14 Mar 2017 12:40:02 GMT):
Has joined the channel.
bmos299 (Tue, 14 Mar 2017 13:11:57 GMT):
@jimthematrix @ashutosh_kumar @binhn we implemented sni in bluemix with wildcards and had great success. I am sure at some point this will be a requirement for us...not sure when..but at somepoint. It can make like life pretty easy as the server is told what cert to send in the handshake.
bmos299 (Tue, 14 Mar 2017 13:11:57 GMT):
@jimthematrix @ashutosh_kumar @binhn we implemented sni in bluemix with wildcards and had great success. I am sure at some point this will be a requirement for us...not sure when..but at somepoint. It can make l life pretty easy as ash points out as the server is told what cert to send in the handshake.
wwendy (Tue, 14 Mar 2017 13:48:33 GMT):
Has joined the channel.
jimthematrix (Tue, 14 Mar 2017 15:25:16 GMT):
anybody know what might be causing this error? I have the hyperledger/fabric-ccenv image.
```peer0 | 2017-03-14 15:21:25.566 UTC [dockercontroller] deployImage -> ERRO 03a Error building images: Failed to generate platform-specific docker build: Error creating container: no such image
peer0 | 2017-03-14 15:21:25.566 UTC [dockercontroller] deployImage -> ERRO 03b Image Output:
peer0 | ********************
peer0 |
peer0 | ********************
peer0 | 2017-03-14 15:21:25.566 UTC [chaincode] Launch -> ERRO 03c launchAndWaitForRegister failed Error starting container: Failed to generate platform-specific docker build: Error creating container: no such image```
jimthematrix (Tue, 14 Mar 2017 15:27:56 GMT):
@binhn @muralisr @greg.haskins @mastersingh24
muralisr (Tue, 14 Mar 2017 15:29:26 GMT):
@jimthematrix anything in the logs before that ?
muralisr (Tue, 14 Mar 2017 15:29:39 GMT):
(with debug on ?)
jimthematrix (Tue, 14 Mar 2017 15:34:22 GMT):
no other log entries that seem relevant, but i didn't have debug turned on
jimthematrix (Tue, 14 Mar 2017 15:34:45 GMT):
just rebuilt everything and trying again, will let you know if still a problem
C0rWin (Tue, 14 Mar 2017 15:36:50 GMT):
@jimthematrix when did you get this error?
C0rWin (Tue, 14 Mar 2017 15:37:00 GMT):
While querying or instantiating a CC?
jimthematrix (Tue, 14 Mar 2017 15:37:07 GMT):
instantiate cc
C0rWin (Tue, 14 Mar 2017 15:37:31 GMT):
ok, can you please show the output of `docker images | grep fabric`?
jimthematrix (Tue, 14 Mar 2017 15:38:36 GMT):
```hyperledger/fabric-couchdb latest b7eab3772a46 6 minutes ago 1.51 GB
hyperledger/fabric-couchdb x86_64-0.7.0-snapshot-6e9229b b7eab3772a46 6 minutes ago 1.51 GB
hyperledger/fabric-kafka latest f260e40e4ac1 8 minutes ago 1.3 GB
hyperledger/fabric-kafka x86_64-0.7.0-snapshot-6e9229b f260e40e4ac1 8 minutes ago 1.3 GB
hyperledger/fabric-zookeeper latest 6329119d15bb 8 minutes ago 1.31 GB
hyperledger/fabric-zookeeper x86_64-0.7.0-snapshot-6e9229b 6329119d15bb 8 minutes ago 1.31 GB
hyperledger/fabric-testenv latest b969ee1eec5e 8 minutes ago 1.4 GB
hyperledger/fabric-testenv x86_64-0.7.0-snapshot-6e9229b b969ee1eec5e 8 minutes ago 1.4 GB
hyperledger/fabric-buildenv latest 092111efcfa8 8 minutes ago 1.31 GB
hyperledger/fabric-buildenv x86_64-0.7.0-snapshot-6e9229b 092111efcfa8 8 minutes ago 1.31 GB
hyperledger/fabric-orderer latest f93ef44ca0ef 8 minutes ago 182 MB
hyperledger/fabric-orderer x86_64-0.7.0-snapshot-6e9229b f93ef44ca0ef 8 minutes ago 182 MB
hyperledger/fabric-peer latest 94286f4b2319 9 minutes ago 184 MB
hyperledger/fabric-peer x86_64-0.7.0-snapshot-6e9229b 94286f4b2319 9 minutes ago 184 MB
hyperledger/fabric-javaenv latest a973117e487c 9 minutes ago 1.42 GB
hyperledger/fabric-javaenv x86_64-0.7.0-snapshot-6e9229b a973117e487c 9 minutes ago 1.42 GB
hyperledger/fabric-ccenv latest d8205e3947ce 11 minutes ago 1.29 GB
hyperledger/fabric-ccenv x86_64-0.7.0-snapshot-6e9229b d8205e3947ce 11 minutes ago 1.29 GB
hyperledger/fabric-ca latest d074213e7091 2 hours ago 239 MB
hyperledger/fabric-ca x86_64-0.7.0-snapshot-3b8932a d074213e7091 2 hours ago 239 MB
hyperledger/fabric-baseimage x86_64-0.3.0 f4751a503f02 6 weeks ago 1.27 GB
hyperledger/fabric-baseos x86_64-0.3.0 c3a4cf3b3350 6 weeks ago 161 MB
```
C0rWin (Tue, 14 Mar 2017 15:39:46 GMT):
I saw this message recently, but I was trying to run peer on rasberry pi device
C0rWin (Tue, 14 Mar 2017 15:41:36 GMT):
I figured out that while you instantiate a CC it actually build container from scratch
jimthematrix (Tue, 14 Mar 2017 15:41:42 GMT):
here's the error again with debug on:
```2017-03-14 15:37:23.647 UTC [chaincode] launchAndWaitForRegister -> DEBU 38b start container: end2end:v0(networkid:dev,peerid:peer0)
2017-03-14 15:37:23.647 UTC [chaincode] launchAndWaitForRegister -> DEBU 38c start container with args: chaincode -peer.address=peer0:7051
2017-03-14 15:37:23.647 UTC [chaincode] launchAndWaitForRegister -> DEBU 38d start container with env:
CORE_CHAINCODE_ID_NAME=end2end:v0
CORE_PEER_TLS_ENABLED=true
CORE_CHAINCODE_LOGLEVEL=WARNING
CORE_CHAINCODE_LOGFORMAT=%{color}%{time:2006-01-02 15:04:05.000 MST} [%{module}] %{shortfunc} -> %{level:.4s} %{id:03x}%{color:reset} %{message}
2017-03-14 15:37:23.647 UTC [container] lockContainer -> DEBU 38e waiting for container(dev-peer0-end2end-v0) lock
2017-03-14 15:37:23.647 UTC [container] lockContainer -> DEBU 38f got container (dev-peer0-end2end-v0) lock
2017-03-14 15:37:23.648 UTC [dockercontroller] Start -> DEBU 390 Cleanup container dev-peer0-end2end-v0
2017-03-14 15:37:23.649 UTC [dockercontroller] stopInternal -> DEBU 391 Stop container dev-peer0-end2end-v0(No such container: dev-peer0-end2end-v0)
2017-03-14 15:37:23.650 UTC [dockercontroller] stopInternal -> DEBU 392 Kill container dev-peer0-end2end-v0 (No such container: dev-peer0-end2end-v0)
2017-03-14 15:37:23.651 UTC [dockercontroller] stopInternal -> DEBU 393 Remove container dev-peer0-end2end-v0 (No such container: dev-peer0-end2end-v0)
2017-03-14 15:37:23.651 UTC [dockercontroller] Start -> DEBU 394 Start container dev-peer0-end2end-v0
2017-03-14 15:37:23.652 UTC [dockercontroller] getDockerHostConfig -> DEBU 395 docker container hostconfig NetworkMode: fixtures_default
2017-03-14 15:37:23.655 UTC [dockercontroller] createContainer -> DEBU 396 Create container: dev-peer0-end2end-v0
2017-03-14 15:37:23.671 UTC [dockercontroller] Start -> DEBU 397 start-could not find image ...attempt to recreate image no such image
2017-03-14 15:37:23.675 UTC [chaincode-platform] generateDockerfile -> DEBU 398
FROM hyperledger/fabric-baseos:x86_64-0.3.0
ADD binpackage.tar /usr/local/bin
LABEL org.hyperledger.fabric.chaincode.id.name="end2end" \
org.hyperledger.fabric.chaincode.id.version="v0" \
org.hyperledger.fabric.chaincode.type="GOLANG" \
org.hyperledger.fabric.version="0.7.0-snapshot-6e9229b" \
org.hyperledger.fabric.base.version="0.3.0"
ENV CORE_PEER_TLS_ROOTCERT_FILE=/etc/hyperledger/fabric/peer.crt
COPY peer.crt /etc/hyperledger/fabric/peer.crt
```
C0rWin (Tue, 14 Mar 2017 15:42:03 GMT):
and uses ```buf = append(buf, "FROM "+cutil.GetDockerfileFromConfig("chaincode.golang.runtime"))```
C0rWin (Tue, 14 Mar 2017 15:42:15 GMT):
to reference to the platform specific base image
jimthematrix (Tue, 14 Mar 2017 15:42:26 GMT):
```2017-03-14 15:37:31.992 UTC [chaincode-platform] func1 -> ERRO 39a Failed to generate platform-specific docker build: Error returned from build: 2 "# github.com/hyperledger/fabric/vendor/google.golang.org/grpc
opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/call.go:69: dopts.copts.StatsHandler undefined (type transport.ConnectOptions has no field or method StatsHandler)
opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/call.go:85: dopts.copts.StatsHandler undefined (type transport.ConnectOptions has no field or method StatsHandler)
opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/call.go:115: dopts.copts.StatsHandler undefined (type transport.ConnectOptions has no field or method StatsHandler)
opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/call.go:127: dopts.copts.StatsHandler undefined (type transport.ConnectOptions has no field or method StatsHandler)
opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/call.go:185: cc.dopts.copts.StatsHandler undefined (type transport.ConnectOptions has no field or method StatsHandler)
opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/call.go:257: undefined: transport.ErrStreamDrain
opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/call.go:271: undefined: transport.ErrStreamDrain
opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/clientconn.go:234: cannot use func literal (type func("github.com/hyperledger/fabric/vendor/golang.org/x/net/context".Context, string) (net.Conn, error)) as type func(string, time.Duration) (net.Conn, error) in assignment
opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/clientconn.go:242: o.copts.StatsHandler undefined (type transport.ConnectOptions has no field or method StatsHandler)
opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/clientconn.go:253: o.copts.FailOnNonTempDialError undefined (type transport.ConnectOptions has no field or method FailOnNonTempDialError)
opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/clientconn.go:253: too many errors
"
2017-03-14 15:37:31.992 UTC [dockercontroller] deployImage -> ERRO 39b Error building images: Failed to generate platform-specific docker build: Error returned from build: 2 "# github.com/hyperledger/fabric/vendor/google.golang.org/grpc
opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/call.go:69: dopts.copts.StatsHandler undefined (type transport.ConnectOptions has no field or method StatsHandler)
opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/call.go:85: dopts.copts.StatsHandler undefined (type transport.ConnectOptions has no field or method StatsHandler)
opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/call.go:115: dopts.copts.StatsHandler undefined (type transport.ConnectOptions has no field or method StatsHandler)
opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/call.go:127: dopts.copts.StatsHandler undefined (type transport.ConnectOptions has no field or method StatsHandler)
opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/call.go:185: cc.dopts.copts.StatsHandler undefined (type transport.ConnectOptions has no field or method StatsHandler)
opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/call.go:257: undefined: transport.ErrStreamDrain
opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/call.go:271: undefined: transport.ErrStreamDrain
opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/clientconn.go:234: cannot use func literal (type func("github.com/hyperledger/fabric/vendor/golang.org/x/net/context".Context, string) (net.Conn, error)) as type func(string, time.Duration) (net.Conn, error) in assignment
opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/clientconn.go:242: o.copts.StatsHandler undefined (type transport.ConnectOptions has no field or method StatsHandler)
opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/clientconn.go:253: o.copts.FailOnNonTempDialError undefined (type transport.ConnectOptions has no field or method FailOnNonTempDialError)
opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/clientconn.go:253: too many errors
"
```
jimthematrix (Tue, 14 Mar 2017 15:42:40 GMT):
```2017-03-14 15:37:31.992 UTC [dockercontroller] deployImage -> ERRO 39c Image Output:
********************
********************
2017-03-14 15:37:31.992 UTC [container] unlockContainer -> DEBU 39d container lock deleted(dev-peer0-end2end-v0)
2017-03-14 15:37:31.992 UTC [chaincode] Launch -> ERRO 39e launchAndWaitForRegister failed Error starting container: Failed to generate platform-specific docker build: Error returned from build: 2 "# github.com/hyperledger/fabric/vendor/google.golang.org/grpc
opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/call.go:69: dopts.copts.StatsHandler undefined (type transport.ConnectOptions has no field or method StatsHandler)
opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/call.go:85: dopts.copts.StatsHandler undefined (type transport.ConnectOptions has no field or method StatsHandler)
opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/call.go:115: dopts.copts.StatsHandler undefined (type transport.ConnectOptions has no field or method StatsHandler)
opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/call.go:127: dopts.copts.StatsHandler undefined (type transport.ConnectOptions has no field or method StatsHandler)
opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/call.go:185: cc.dopts.copts.StatsHandler undefined (type transport.ConnectOptions has no field or method StatsHandler)
opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/call.go:257: undefined: transport.ErrStreamDrain
opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/call.go:271: undefined: transport.ErrStreamDrain
opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/clientconn.go:234: cannot use func literal (type func("github.com/hyperledger/fabric/vendor/golang.org/x/net/context".Context, string) (net.Conn, error)) as type func(string, time.Duration) (net.Conn, error) in assignment
opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/clientconn.go:242: o.copts.StatsHandler undefined (type transport.ConnectOptions has no field or method StatsHandler)
opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/clientconn.go:253: o.copts.FailOnNonTempDialError undefined (type transport.ConnectOptions has no field or method FailOnNonTempDialError)
opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/clientconn.go:253: too many errors
"
```
C0rWin (Tue, 14 Mar 2017 15:44:38 GMT):
```FROM hyperledger/fabric-baseos:x86_64-0.3.0
ADD binpackage.tar /usr/local/bin
LABEL org.hyperledger.fabric.chaincode.id.name="end2end" \
org.hyperledger.fabric.chaincode.id.version="v0" \
org.hyperledger.fabric.chaincode.type="GOLANG" \
org.hyperledger.fabric.version="0.7.0-snapshot-6e9229b" \
org.hyperledger.fabric.base.version="0.3.0"
ENV CORE_PEER_TLS_ROOTCERT_FILE=/etc/hyperledger/fabric/peer.crt
COPY peer.crt /etc/hyperledger/fabric/peer.crt```
C0rWin (Tue, 14 Mar 2017 15:45:12 GMT):
this pretty straightforward dockerfile, also you have hyperledger/fabric-baseos:x86_64-0.3.0 available
C0rWin (Tue, 14 Mar 2017 15:45:38 GMT):
next you show compilation errors during the docker build
C0rWin (Tue, 14 Mar 2017 15:45:54 GMT):
and I'm not 100% sure where it comes from
jimthematrix (Tue, 14 Mar 2017 15:47:56 GMT):
is the `- CORE_NEXT=true` env variable still in effect? i didn't have that in docker-compose but maybe that's needed to get the builder to use the right level of golang?
muralisr (Tue, 14 Mar 2017 15:54:11 GMT):
CORE_NEXT is not used I believe @jimthematrix
muralisr (Tue, 14 Mar 2017 15:54:25 GMT):
does `go build` directly in the chaincode on your host work ?
jimthematrix (Tue, 14 Mar 2017 16:00:08 GMT):
it's my environment, for some reason $GOPATH was null'ed out
muralisr (Tue, 14 Mar 2017 16:17:23 GMT):
whew, alls well that ends well :-)
jimthematrix (Tue, 14 Mar 2017 16:26:53 GMT):
yeah false alarm although it's kind of funny that `make docker` was successful even though first thing it complained about was not being able to find chaincode shim ;-)
lignyxg (Tue, 14 Mar 2017 17:36:11 GMT):
Has joined the channel.
mychewcents (Wed, 15 Mar 2017 12:30:41 GMT):
Has joined the channel.
balashevich (Wed, 15 Mar 2017 12:36:35 GMT):
Has joined the channel.
bkvellanki (Wed, 15 Mar 2017 23:30:32 GMT):
Is there config document that shows how to setup a new Org/Peer starting with MSP
tulioribeiro (Thu, 16 Mar 2017 13:36:05 GMT):
Take a look into fabric/examples/e2e_cli/ I think could be useful for you. : )
divyank (Thu, 16 Mar 2017 14:56:48 GMT):
Chaincode installation fails if there are executable files on the GOPATH:
```Error: Error endorsing chaincode: rpc error: code = 2 desc = Illegal file mode detected for file src/github.com/hyperledger/fabric-sdk-node/node_modules/arr-flatten/package.json: 100744```
divyank (Thu, 16 Mar 2017 14:57:08 GMT):
(This is using the peer CLI)
mastersingh24 (Thu, 16 Mar 2017 17:31:55 GMT):
@divyank - yes - this is terrible. I believe that there is a CR out there which should help with this. In the meantime, there are 2 options:
1) run the CLI from within a Docker container
2) create a special GOPATH for your chaincode project
mastersingh24 (Thu, 16 Mar 2017 17:32:00 GMT):
I've done both
binhn (Thu, 16 Mar 2017 21:45:35 GMT):
@bkvellanki https://github.com/hyperledger/fabric/blob/master/docs/source/configtxgen.rst
bkvellanki (Thu, 16 Mar 2017 21:46:22 GMT):
Thanks @binhn
binhn (Thu, 16 Mar 2017 21:49:08 GMT):
@bkvellanki you might also want to look at the bdd feature https://github.com/hyperledger/fabric/blob/master/bddtests/features/bootstrap.feature and run it then look at the document that it generates, which contains step-by-step to set up bootstrap
bkvellanki (Thu, 16 Mar 2017 21:51:16 GMT):
Ok.. I will do that first
RahulBagaria (Fri, 17 Mar 2017 04:03:02 GMT):
Has joined the channel.
tuand (Fri, 17 Mar 2017 20:44:43 GMT):
I'm getting an error on invoke CC `failed to obtain cds for example_cc.go - transaction not found example_cc.go/mychannel` ?
tuand (Fri, 17 Mar 2017 20:45:02 GMT):
install/instantiate CC worked fine.
tuand (Fri, 17 Mar 2017 20:45:33 GMT):
I'm using the setup from e2e_cli docker-compose , sending proposals to all 4 peers
muralisr (Fri, 17 Mar 2017 20:47:12 GMT):
@tuand that typically means that the instantiate's commit did not go through
muralisr (Fri, 17 Mar 2017 20:47:29 GMT):
or you have not waited enough
tuand (Fri, 17 Mar 2017 20:48:23 GMT):
thanks @muralisr ... I'll put in a sleep(5s) and see what happens
muralisr (Fri, 17 Mar 2017 21:00:34 GMT):
or 10 ;-) till orderer defaults to less than 10secs
jimthematrix (Sat, 18 Mar 2017 16:28:58 GMT):
@tuand are you listening to the events from the instantiate transaction? that'll allow you to know with certainty when its committed
tuand (Sat, 18 Mar 2017 18:06:33 GMT):
i ( well, the code ) has received the event for the instantiate ... I'm getting the error on the subsequent invoke proposal randomly on some subset of the peers I send the proposal to
tuand (Sat, 18 Mar 2017 18:07:17 GMT):
which makes me suspect that the cc container hasn't completely come up yet on some peer
tuand (Sat, 18 Mar 2017 18:08:01 GMT):
I'm working around this for now ... trying to get the rest of the scenario up and running
latitiah (Sat, 18 Mar 2017 21:37:26 GMT):
@tuand: I'm getting the same chaincode error on queries as you see above
latitiah (Sat, 18 Mar 2017 21:37:52 GMT):
I instantiated and waited for a few minutes before the query
latitiah (Sat, 18 Mar 2017 21:40:00 GMT):
So I definitely waited long enough
latitiah (Sat, 18 Mar 2017 21:41:33 GMT):
The log shows that the chaincode was instantiated and I see the container running
tuand (Sat, 18 Mar 2017 21:41:58 GMT):
hi @latitiah ... I think it's because one of the (not anchor) peers did not get the block delivered ... reading through logs now ... more details later
latitiah (Sat, 18 Mar 2017 21:42:17 GMT):
cool! Thx!
latitiah (Sat, 18 Mar 2017 21:55:43 GMT):
Yes, the cc container never starts on the other peer... I'm getting some strange error in the log (itzmine is both the channel and chaincodeID):
```
[lccc] Invoke -> ERRO 005[0m ChaincodeId: itzmine does not exist on channel: itzmine(err:chaincode not found itzmine)
```
tuand (Sat, 18 Mar 2017 22:18:41 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=wfqn6gPbod6tDiebx) recapping after going through debug logs today ( excuse my wordiness )
tuand (Sat, 18 Mar 2017 22:19:48 GMT):
environment is 2orgs, 2 peers per org, 1 orderer running solo, client is java sdk, same setup as e2e_cli
tuand (Sat, 18 Mar 2017 22:19:48 GMT):
environment is 2orgs, 2 peers per org, 1 orderer running solo, client is java sdk, same setup as e2e_cli, anchor peers are [peer0Org1, peer2Org2]
tuand (Sat, 18 Mar 2017 22:21:45 GMT):
scenario is : use id Org1.admin, install cc on 4 peers, instantiate proposal on 4 peers, instantiate tx to orderer, invoke proposal to 4 peers.
tuand (Sat, 18 Mar 2017 22:23:18 GMT):
on the last step, peer3Org2 ( and *only* that peer ) responds with `Invoke -> ERRO 41d[0m ChaincodeId: example_cc.go does not exist on channel: mychannel(err:chaincode not found example_cc.go)`
tuand (Sat, 18 Mar 2017 22:25:25 GMT):
when I look at the logs for the anchor peers, I see for the instantiate tx :
tuand (Sat, 18 Mar 2017 22:29:06 GMT):
``` [36m2017-03-18 21:16:44.783 UTC [gossip/comm#-1] sendToEndpoint -> DEBU 572[0m Exiting
[36m2017-03-18 21:16:44.784 UTC [kvledger] indexBlock -> DEBU 573[0m Indexing block [blockNum=1, blockHash=[]byte{0xa8, 0xec, 0x90, 0xfd, 0xdf, 0x5a, 0x7d, 0xda, 0xb0, 0x7e, 0xa8, 0x35, 0x1f, 0x2d, 0x1c, 0xb, 0x50, 0x88, 0x46, 0x7d, 0x97, 0x7d, 0xb8, 0x80, 0x7c, 0xd8, 0xab, 0xb8, 0xcc, 0x5d, 0xd9, 0xa} txOffsets=
txId=4d018fb2783591d87fa87238d3a9e4e4190a8019a26d2b18e07439616bf8d6ce locPointer=offset=70, bytesLength=5495
]
[36m2017-03-18 21:16:44.784 UTC [kvledger] indexBlock -> DEBU 574[0m Adding txLoc [fileSuffixNum=0, offset=13752, bytesLength=5495] for tx ID: [4d018fb2783591d87fa87238d3a9e4e4190a8019a26d2b18e07439616bf8d6ce] to index
[36m2017-03-18 21:16:44.784 UTC [kvledger] indexBlock -> DEBU 575[0m Adding txLoc [fileSuffixNum=0, offset=13752, bytesLength=5495] for tx number:[1] ID: [4d018fb2783591d87fa87238d3a9e4e4190a8019a26d2b18e07439616bf8d6ce] to blockNumTranNum index
[36m2017-03-18 21:16:44.784 UTC [kvledger] updateCheckpoint -> DEBU 576[0m Broadcasting about update checkpointInfo: latestFileChunkSuffixNum=[0], latestFileChunksize=[21044], isChainEmpty=[false], lastBlockNumber=[1]
2017-03-18 21:16:44.784 UTC [kvledger] Commit -> INFO 577[0m Channel [mychannel]: Created block [1] with 1 transaction(s)
[36m2017-03-18 21:16:44.784 UTC [kvledger] Commit -> DEBU 578[0m Channel [mychannel]: Committing block [1] transactions to state database ```
tuand (Sat, 18 Mar 2017 22:30:02 GMT):
and I see on the non-anchor peer1Org1 that it also gets the block and writes it to its ledger
tuand (Sat, 18 Mar 2017 22:31:10 GMT):
*but* the org2 non anchor peer peer3Org2 never gets the block and never writes it to its ledger
tuand (Sat, 18 Mar 2017 22:32:55 GMT):
Also, between the Org2 peers, there's hardly any gossip messages, e.g no learnExistingMembers() calls at all
tuand (Sat, 18 Mar 2017 22:34:12 GMT):
it's probable that I haven't set some config option correctly in my docker-compose but any pointers appreciated
tuand (Sat, 18 Mar 2017 22:34:56 GMT):
docker-compose for peer3Org2 :
tuand (Sat, 18 Mar 2017 22:35:29 GMT):
``` peer3:
container_name: peer3
image: hyperledger/fabric-peer
environment:
- CORE_LOGGING_LEVEL=DEBUG
- CORE_NEXT=true
- CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
- CORE_PEER_ID=peer3
- CORE_PEER_ENDORSER_ENABLED=true
- CORE_PEER_LOCALMSPID=Org2MSP
- CORE_PEER_MSPCONFIGPATH=/etc/hyperledger/msp/peer/
- CORE_PEER_GOSSIP_ORGLEADER=false
- CORE_PEER_ADDRESS=peer3:7051
- CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer3:7051
- CORE_PEER_TLS_ENABLED=false
- CORE_PEER_TLS_KEY_FILE=/etc/hyperledger/tls/key.pem
- CORE_PEER_TLS_CERT_FILE=/etc/hyperledger/tls/cert.pem
- CORE_PEER_TLS_ROOTCERT_FILE=/etc/hyperledger/tls/ca-cert.pem
- CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE=src_default
working_dir: /opt/gopath/src/github.com/hyperledger/fabric
command: peer node start --peer-defaultchain=false
ports:
- 8056:7051
- 8058:7053 ```
yacovm (Sat, 18 Mar 2017 23:25:37 GMT):
@tuand what's the value of CORE_PEER_GOSSIP_LEADER_ELECTION in both peers, and what's the value of CORE_PEER_GOSSIP_ORGLEADER in peer2?
yacovm (Sat, 18 Mar 2017 23:27:20 GMT):
also what's org2? You're not using the example/e2e_cli ? orgs start from 0 there
yacovm (Sat, 18 Mar 2017 23:28:31 GMT):
another thing- if the peers are in debug, and you say there is hardly any gossip messages in the orgs- it smells to me like the anchor peer of the org isn't set correctly in the configtx.yaml
tuand (Sun, 19 Mar 2017 00:00:47 GMT):
hi @yacovm ... peer2Org2 CORE_PEER_GOSSIP_ORGLEADER=true ... CORE_PEER_GOSSIP_USERLEADERELECTION(?) is from core.yaml
tuand (Sun, 19 Mar 2017 00:02:43 GMT):
Message Attachments
tuand (Sun, 19 Mar 2017 00:07:37 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=ntpqrikMQ4ggMTvrm) @yacovm I take that back, I'm actually using a copy of the sdk-node e2e-2Orgs setup , had assumed it was the same as e2e-cli
tuand (Sun, 19 Mar 2017 00:10:31 GMT):
back in a bit, familial duties call
tuand (Sun, 19 Mar 2017 02:16:58 GMT):
You are correct @yacovm , the problem was in `configtx.yaml` . I'm running all peers/orderer/fabric-ca in vagrant and sdk-java locally. The port for the Org2 anchor peer was set to the mapped vagrant port instead of the normal peer `7051` port. Gossip msgs are flowing and all peers are updating their ledgers now. happy, happy
DannyWong (Sun, 19 Mar 2017 15:54:58 GMT):
@here anyone trying to deploy v1.0 (Fabric-CA, CA-DB/LDAP, Peers, Orderer, Kafka, Zookeeper) to Docker Swarm?
hycind (Sun, 19 Mar 2017 19:50:55 GMT):
Has joined the channel.
Willson (Mon, 20 Mar 2017 02:02:33 GMT):
Has joined the channel.
GeorgeSamman (Mon, 20 Mar 2017 03:50:41 GMT):
Has joined the channel.
Xiao (Mon, 20 Mar 2017 07:12:21 GMT):
Has joined the channel.
jacksoom (Tue, 21 Mar 2017 08:26:20 GMT):
Has joined the channel.
SyneBlockChainTeam (Tue, 21 Mar 2017 12:37:14 GMT):
"Endorser related Issue"
While referring video "V1 Chaincode install and instentiate" from "https://www.youtube.com/watch?v=itn2Ps8sarE", all worked fine but we are facing one issue during the following "query" command:
CORE_PEER_ADDRESS=peer0:7051 peer chaincode query -C myc -n mycc -v v0 -c '{"Args":["query ","a"]}' -o orderer:5005
Error: "Error endorsing query: rpc error: code = 2 desc = failed to obtain cds for mycc - transaction not found mycc/myc"
Any clue please?
Thanks.
muralisr (Tue, 21 Mar 2017 15:17:30 GMT):
@syb
muralisr (Tue, 21 Mar 2017 15:19:49 GMT):
@SyneBlockChainTeam since that video there have been a few changes. The error basically says trasanctions aren't getting committed. Try adding "-o orderer:7050" to the instantiate and invoke commands please
shanlusun (Wed, 22 Mar 2017 01:34:49 GMT):
Has joined the channel.
SyneBlockChainTeam (Wed, 22 Mar 2017 04:29:33 GMT):
@muralisr , we tried adding orderer to instantiate command but we are getting --- Error: Error getting broadcast client: Error connecting to orderer:7051 due to grpc: timed out when dialing
SyneBlockChainTeam (Wed, 22 Mar 2017 04:29:33 GMT):
@muralisr , We are using docker-compose channel.yml file from docs/source folder. Here orderer is configured on 5005 so hence we used CORE_PEER_ADDRESS=peer0:7051 peer chaincode query -C myc -n mycc -v v0 -c '{"Args":["query ","a"]}' -o orderer:5005 for instantiate and invoke as well. We dont get any error during install and instantiate commands.
For your reference below are commands we are running - T1
-----------------------------------------------------------------------------------------------------
cd ~/work/src/github.com/hyperledger/fabric/docs/source
docker-compose -f docker-compose-channel.yml up
T2 -
-----------------------------------------------------------------------------------------------------
docker exec -it cli bash
peer channel create -c myc -o orderer:5005
CORE_PEER_ADDRESS=peer0:7051 peer channel join -b myc.block
-----------------------------------------------------------------------------------------------------
T3 -
docker exec -e GOPATH=/opt/gopath -it peer0 bash
peer chaincode install -n mycc -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 -v v0
------------------------------------------------------------------------------------------------------
T4 -
docker exec -it cli bash
CORE_PEER_ADDRESS=peer0:7051 peer chaincode instantiate -C myc -n mycc -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 -v v0 -c '{"Args":["init","a","100","b","200"]}' -o orderer:5005
SyneBlockChainTeam (Wed, 22 Mar 2017 04:29:33 GMT):
@muralisr , We are using docker-compose channel.yml file from docs/source folder. Here orderer is configured on 5005 so hence we used CORE_PEER_ADDRESS=peer0:7051 peer chaincode query -C myc -n mycc -v v0 -c '{"Args":["query ","a"]}' -o orderer:5005 for instantiate and invoke as well. We dont get any error during install and instantiate commands.
For your reference below are commands we are running -
T1
-----------------------------------------------------------------------------------------------------
cd ~/work/src/github.com/hyperledger/fabric/docs/source
docker-compose -f docker-compose-channel.yml up
T2 -
-----------------------------------------------------------------------------------------------------
docker exec -it cli bash
peer channel create -c myc -o orderer:5005
CORE_PEER_ADDRESS=peer0:7051 peer channel join -b myc.block
-----------------------------------------------------------------------------------------------------
T3 -
docker exec -e GOPATH=/opt/gopath -it peer0 bash
peer chaincode install -n mycc -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 -v v0
------------------------------------------------------------------------------------------------------
T4 -
docker exec -it cli bash
CORE_PEER_ADDRESS=peer0:7051 peer chaincode instantiate -C myc -n mycc -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 -v v0 -c '{"Args":["init","a","100","b","200"]}' -o orderer:5005
CORE_PEER_ADDRESS=peer0:7051 peer chaincode query -C myc -n mycc -v v0 -c '{"Args":["query ","a"]}' -o orderer:5005
Error: "Error endorsing query: rpc error: code = 2 desc = failed to obtain cds for mycc - transaction not found mycc/myc"
ersudiplama (Wed, 22 Mar 2017 04:58:18 GMT):
Has joined the channel.
mjkong (Wed, 22 Mar 2017 08:26:59 GMT):
Has joined the channel.
muralisr (Wed, 22 Mar 2017 14:07:42 GMT):
@SyneBlockChainTeam in step T4 after the the instantiate, I'd wait for a bit for the commit to take place on peer0. you should see a "Commit" log on peer0
muralisr (Wed, 22 Mar 2017 14:10:44 GMT):
I'm assuming you are using docker-2peer.yml ? id make sure CORE_PEER_GOSSIP_ORGLEADER=true is set
SyneBlockChainTeam (Thu, 23 Mar 2017 06:27:11 GMT):
@muralisr - still we are getting same error - "Error endorsing query: rpc error: code = 2 desc = failed to obtain cds for mycc - transaction not found mycc/myc"
SyneBlockChainTeam (Thu, 23 Mar 2017 06:27:11 GMT):
@muralisr - CORE_PEER_GOSSIP_ORGLEADER=true is already there in docker-compose-channel.yml. We tried using docker-2peer.yml as well.
Still we are getting same error - "Error endorsing query: rpc error: code = 2 desc = failed to obtain cds for mycc - transaction not found mycc/myc"
2017-03-23 06:54:19.397 UTC [lccc] Invoke -> ERRO 03a ChaincodeId: mycc does not exist on channel: myc(err:chaincode not found mycc)
SyneBlockChainTeam (Thu, 23 Mar 2017 06:27:11 GMT):
@muralisr - still we are getting same error - "Error endorsing query: rpc error: code = 2 desc = failed to obtain cds for mycc - transaction not found mycc/myc"
2017-03-23 06:54:19.397 UTC [lccc] Invoke -> ERRO 03a ChaincodeId: mycc does not exist on channel: myc(err:chaincode not found mycc)
matanyahu (Thu, 23 Mar 2017 10:55:24 GMT):
Has joined the channel.
muralisr (Thu, 23 Mar 2017 19:56:39 GMT):
@SyneBlockChainTeam I'll try the above steps soon and see what I get
muralisr (Thu, 23 Mar 2017 20:38:08 GMT):
@here https://jira.hyperledger.org/browse/FAB-2859 attempts to address packaging of chaincode to address security and chaincode ownership concerns. please take a look and provide feedback
grapebaba (Fri, 24 Mar 2017 01:58:32 GMT):
hi guys
grapebaba (Fri, 24 Mar 2017 01:59:16 GMT):
i thought could we enhance peer channel join command
grapebaba (Fri, 24 Mar 2017 02:00:09 GMT):
such as peer channel join $channel_name
grapebaba (Fri, 24 Mar 2017 02:01:06 GMT):
first it check if channel exist, if exist just join, if not create channel first
grapebaba (Fri, 24 Mar 2017 02:01:52 GMT):
that will remove channel.tx, channel_name.block files
grapebaba (Fri, 24 Mar 2017 02:11:58 GMT):
hi murali
muralisr (Fri, 24 Mar 2017 02:13:05 GMT):
@grapebaba one might argue in the spirit of being "minimal" interface, a few simple separate commands may be ok ....
muralisr (Fri, 24 Mar 2017 02:13:49 GMT):
better to use SDKs when we can
grapebaba (Fri, 24 Mar 2017 02:16:41 GMT):
ok
grapebaba (Fri, 24 Mar 2017 02:33:25 GMT):
@muralisr if i create a blockchain admin tool, i am not sure responsibility of channel management own by admin tool or by user app
grapebaba (Fri, 24 Mar 2017 02:34:31 GMT):
you said better to use SDKs , I assume it is more like the responsibility of user app
grapebaba (Fri, 24 Mar 2017 02:35:58 GMT):
however my previous thoughts was that a admin user just write a yaml include peers, orgs, orders, channels, and execute one command
grapebaba (Fri, 24 Mar 2017 02:36:19 GMT):
we can create well-defined blockchain network for him
grapebaba (Fri, 24 Mar 2017 02:37:33 GMT):
if using SDK, admin tools seems must provide a UI interface to operate
grapebaba (Fri, 24 Mar 2017 02:38:19 GMT):
however i want a command interface as well
anik (Fri, 24 Mar 2017 05:49:42 GMT):
Has joined the channel.
SyneBlockChainTeam (Fri, 24 Mar 2017 13:49:40 GMT):
@muralisr , we are waiting for your reply...
joe-alewine (Fri, 24 Mar 2017 13:58:44 GMT):
Has joined the channel.
muralisr (Fri, 24 Mar 2017 15:59:21 GMT):
@SyneBlockChainTeam trying now...
muralisr (Fri, 24 Mar 2017 19:45:48 GMT):
@SyneBlockChainTeam the default value in common/configtx/tools/configtx.yaml will have to be changed
muralisr (Fri, 24 Mar 2017 19:45:55 GMT):
```Orderer: &OrdererDefaults
# Orderer Type: The orderer implementation to start.
# Available types are "solo" and "kafka".
OrdererType: solo
Addresses:
- orderer:5005``
muralisr (Fri, 24 Mar 2017 19:45:55 GMT):
```Orderer: &OrdererDefaults
# Orderer Type: The orderer implementation to start.
# Available types are "solo" and "kafka".
OrdererType: solo
Addresses:
- orderer:5005```
muralisr (Fri, 24 Mar 2017 19:47:18 GMT):
you'd have to create the peer images to refresh that change ... `make clean;make peer;make peer-docker;make orderer-docker`
muralisr (Fri, 24 Mar 2017 19:48:13 GMT):
the peer was attempting to create a connection to orderer at `127.0.0.1:7050`
Amjadnz (Sat, 25 Mar 2017 11:24:43 GMT):
Has joined the channel.
Amjadnz (Sat, 25 Mar 2017 11:25:14 GMT):
Hi guys - I'm starting with the hyperledger 1.0 stuffs - run in to some problems.
Amjadnz (Sat, 25 Mar 2017 11:25:19 GMT):
Can somebody help me with it.
Amjadnz (Sat, 25 Mar 2017 11:26:10 GMT):
peer0 | panic: Fatal error when setting up MSP from directory /etc/hyperledger/fabric/msp/sampleconfig: err Could not load a valid ca certificate from directory /etc/hyperledger/fabric/msp/sampleconfig/cacerts, err Could not read directory open /etc/hyperledger/fabric/msp/sampleconfig/cacerts: no such file or directory, err /etc/hyperledger/fabric/msp/sampleconfig/cacerts
peer1 | panic: Fatal error when setting up MSP from directory /etc/hyperledger/fabric/msp/sampleconfig: err Could not load a valid ca certificate from directory /etc/hyperledger/fabric/msp/sampleconfig/cacerts, err Could not read directory open /etc/hyperledger/fabric/msp/sampleconfig/cacerts: no such file or directory, err /etc/hyperledger/fabric/msp/sampleconfig/cacerts
peer2 | panic: Fatal error when setting up MSP from directory /etc/hyperledger/fabric/msp/sampleconfig: err Could not load a valid ca certificate from directory /etc/hyperledger/fabric/msp/sampleconfig/cacerts, err Could not read directory open /etc/hyperledger/fabric/msp/sampleconfig/cacerts: no such file or directory, err /etc/hyperledger/fabric/msp/sampleconfig/cacerts
Amjadnz (Sat, 25 Mar 2017 11:26:35 GMT):
I guess we have a working directory of the GOPATH setup in compose.yaml like below
Amjadnz (Sat, 25 Mar 2017 11:27:09 GMT):
`working_dir: /opt/gopath/src/github.com/hyperledger/fabric/peer`
Amjadnz (Sat, 25 Mar 2017 11:27:35 GMT):
i'm using the `docker` version
Amjadnz (Sat, 25 Mar 2017 11:28:28 GMT):
this is my `docker images` output
Amjadnz (Sat, 25 Mar 2017 11:28:32 GMT):
`REPOSITORY TAG IMAGE ID CREATED SIZE
sfhackfest22017/fabric-ca x86_64-0.7.0-snapshot-6294c57 e9f3e1aff06c 7 weeks ago 183.6 MB
sfhackfest22017/fabric-orderer x86_64-0.7.0-snapshot-c7b3fe0 b04fb9d5e225 7 weeks ago 178.6 MB
sfhackfest22017/fabric-peer x86_64-0.7.0-snapshot-c7b3fe0 7d7c9807412d 7 weeks ago 182.5 MB
hyperledger/fabric-ccenv latest 05dbf5bc5701 7 weeks ago 1.294 GB
hyperledger/fabric-ccenv x86_64-0.7.0-snapshot-c7b3fe0 05dbf5bc5701 7 weeks ago 1.294 GB
sfhackfest22017/fabric-ccenv x86_64-0.7.0-snapshot-c7b3fe0 05dbf5bc5701 7 weeks ago 1.294 GB`
Amjadnz (Sat, 25 Mar 2017 11:30:07 GMT):
currently my Go is 1.6
Amjadnz (Sat, 25 Mar 2017 11:30:23 GMT):
I'm upgrading the `go 1.8` now on my Mac Book Pro
Amjadnz (Sat, 25 Mar 2017 11:30:42 GMT):
would test and confirm - if any clues to solve this that would be great
Amjadnz (Sat, 25 Mar 2017 11:44:55 GMT):
the same issue appears in the go 1.8 as well after I rebuild
Amjadnz (Sat, 25 Mar 2017 11:47:18 GMT):
```orderer | 2017-03-25 11:37:23.140 UTC [msp] getPemMaterialFromDir -> INFO 006 Reading directory /etc/hyperledger/fabric/msp/sampleconfig/signcerts
peer0 | panic: Fatal error when setting up MSP from directory /etc/hyperledger/fabric/msp/sampleconfig: err Could not load a valid ca certificate from directory /etc/hyperledger/fabric/msp/sampleconfig/cacerts, err Could not read directory open /etc/hyperledger/fabric/msp/sampleconfig/cacerts: no such file or directory, err /etc/hyperledger/fabric/msp/sampleconfig/cacerts
peer2 | 2017-03-25 11:37:23.763 UTC [msp] getPemMaterialFromDir -> INFO 001 Reading directory /etc/hyperledger/fabric/msp/sampleconfig/cacerts
peer1 | panic: Fatal error when setting up MSP from directory /etc/hyperledger/fabric/msp/sampleconfig: err Could not load a valid ca certificate from directory /etc/hyperledger/fabric/msp/sampleconfig/cacerts, err Could not read directory open /etc/hyperledger/fabric/msp/sampleconfig/cacerts: no such file or directory, err /etc/hyperledger/fabric/msp/sampleconfig/cacerts
peer0 |
orderer | 2017-03-25 11:37:23.140 UTC [msp] getPemMaterialFromDir -> INFO 007 Inspecting file /etc/hyperledger/fabric/msp/sampleconfig/signcerts/peer.pem
peer0 |
peer1 |
orderer | 2017-03-25 11:37:23.140 UTC [msp] getPemMaterialFromDir -> INFO 008 Reading directory /etc/hyperledger/fabric/msp/sampleconfig/admincerts
peer1 |
peer2 | panic: Fatal error when setting up MSP from directory /etc/hyperledger/fabric/msp/sampleconfig: err Could not load a valid ca certificate from directory /etc/hyperledger/fabric/msp/sampleconfig/cacerts, err Could not read directory open /etc/hyperledger/fabric/msp/sampleconfig/cacerts: no such file or directory, err /etc/hyperledger/fabric/msp/sampleconfig/cacerts
orderer | 2017-03-25 11:37:23.141 UTC [msp] getPemMaterialFromDir -> INFO 009 Inspecting file /etc/hyperledger/fabric/msp/sampleconfig/admincerts/admincert.pem
orderer | 2017-03-25 11:37:23.141 UTC [msp] getPemMaterialFromDir -> INFO 00a Reading directory /etc/hyperledger/fabric/msp/sampleconfig/keystore
orderer | 2017-03-25 11:37:23.141 UTC [msp] getPemMaterialFromDir -> INFO 00b Inspecting file /etc/hyperledger/fabric/msp/sampleconfig/keystore/key.pem
peer2 |
orderer | 2017-03-25 11:37:23.141 UTC [msp] NewBccspMsp -> INFO 00c Creating BCCSP-based MSP instance
peer2 |
peer1 | goroutine 1 [running]:
orderer | 2017-03-25 11:37:23.142 UTC [peer] GetLocalMSP -> INFO 00d Created new local MSP
orderer | 2017-03-25 11:37:23.144 UTC [msp] Setup -> INFO 00e Setting up MSP instance DEFAULT
peer0 | goroutine 1 [running]:
orderer | 2017-03-25 11:37:23.147 UTC [msp] newIdentity -> INFO 00f Creating identity instance for ID &{DEFAULT IDENTITY}
orderer | 2017-03-25 11:37:23.147 UTC [msp] newIdentity -> INFO 010 Creating identity instance for ID &{DEFAULT IDENTITY}
orderer | 2017-03-25 11:37:23.148 UTC [msp] newIdentity -> INFO 011 Creating identity instance for ID &{DEFAULT IDENTITY}
peer2 | goroutine 1 [running]:
peer0 | panic(0xb4cb80, 0xc4201d39c0)
peer1 | panic(0xb4cb80, 0xc4201d39c0)
peer2 | panic(0xb4cb80, 0xc4201cd9b0)
peer0 | /opt/go/src/runtime/panic.go:500 +0x1a1
peer1 | /opt/go/src/runtime/panic.go:500 +0x1a1
peer0 | main.main()
peer0 | /opt/gopath/src/github.com/hyperledger/fabric/peer/main.go:108 +0x627
peer2 | /opt/go/src/runtime/panic.go:500 +0x1a1
peer1 | main.main()
peer2 | main.main()
peer2 | /opt/gopath/src/github.com/hyperledger/fabric/peer/main.go:108 +0x627
peer1 | /opt/gopath/src/github.com/hyperledger/fabric/peer/main.go:108 +0x627
ccenv_snapshot exited with code 0
peer1 exited with code 2
peer0 exited with code 2
peer2 exited with code 2
```
mastersingh24 (Sun, 26 Mar 2017 14:56:00 GMT):
@Amjadnz - what exactly are you running? you might just want to pull down the 1.0.0-alpha images from Dockerhub and run with those in your compose file
SyneBlockChainTeam (Mon, 27 Mar 2017 05:58:56 GMT):
@muralisr - We followed same steps mentioned by you but getting same error for query - "Error: Error endorsing query: rpc error: code = 2 desc = failed to obtain cds for mycc - transaction not found mycc/myc"
Amjadnz (Mon, 27 Mar 2017 06:32:09 GMT):
@mastersingh24 I got this working after I removed the hackfest and re-downloaded it
Amjadnz (Mon, 27 Mar 2017 06:33:55 GMT):
Thanks and I have another question for you on fabric channel. If you are spare some time there - I would appreciate that. This is regarding CouchDB and Fabric (for state database). Parameters set in docker.yaml file are not getting set in PEER\core.yaml file - I guess so I always get the "connection refused - no route to host issue".
muralisr (Mon, 27 Mar 2017 12:14:48 GMT):
@SyneBlockChainTeam I did get it working after I made the changes outlined above... it is important to make sure the the images are bulit afresh after the address change `orderer:5005`
SyneBlockChainTeam (Mon, 27 Mar 2017 14:07:57 GMT):
@muralisr It would be great if you can send us entire steps you followed... We tried same steps but we are getting error...
muralisr (Mon, 27 Mar 2017 16:05:00 GMT):
@SyneBlockChainTeam I just followed the steps you listed
muralisr (Mon, 27 Mar 2017 16:05:29 GMT):
and added the extra change to configtx.yaml along with the cleanup
muralisr (Mon, 27 Mar 2017 16:06:19 GMT):
one thing after the instantiate you should wait for a "Commit" message to show up in the peer logs before you try the query
muralisr (Mon, 27 Mar 2017 16:06:37 GMT):
if no "Commit" message shows up then we have a problem
muralisr (Mon, 27 Mar 2017 16:45:16 GMT):
@SyneBlockChainTeam let me try again to make sure I didn't add anything inadvertantly
muralisr (Mon, 27 Mar 2017 17:26:22 GMT):
@SyneBlockChainTeam generating images with `orderer:5005` in configtx.yaml, steps you outlined worked without change
dave.enyeart (Mon, 27 Mar 2017 17:29:48 GMT):
@Amjadnz Docker compose yaml properties will not update core.yaml directly. Rather it overrides core.yaml properties at runtime. For a docker compose yaml that is known to work with couchdb, see: https://github.com/hyperledger/fabric/blob/master/examples/e2e_cli/docker-compose.yaml
dave.enyeart (Mon, 27 Mar 2017 17:30:19 GMT):
You would need to uncomment that couchdb properties as described in the instructions for Using CouchDB: https://github.com/hyperledger/fabric/blob/master/examples/e2e_cli/end-to-end.rst
dave.enyeart (Mon, 27 Mar 2017 17:40:14 GMT):
@garisingh I read your answer at: http://stackoverflow.com/questions/43017514/roles-readwrite-in-hyperledger/43030473#43030473:
>Additionally, if you don't have access to write to a channel, you cannot send endorsement proposals to peers for chaincode which is deployed on channel you don't have write permission for.
Seems that read permission should allow you to call chaincode read-only functions (e.g. queries). I guess this would be a good reason to re-introduce Query at chaincode level in the future (@muralisr)? Then if you have read-only permissions you could call chaincode Query functions but not Invoke. Or would you rather expose the query functions outside of chaincode in the future? (i missed this channel permissions aspect last time we discussed). Will the ACL enhancements under discussion allow us lockdown such queries outside of chaincode in the future?
dave.enyeart (Mon, 27 Mar 2017 17:40:14 GMT):
@mastersingh24 I read your answer at: http://stackoverflow.com/questions/43017514/roles-readwrite-in-hyperledger/43030473#43030473:
>Additionally, if you don't have access to write to a channel, you cannot send endorsement proposals to peers for chaincode which is deployed on channel you don't have write permission for.
Seems that read permission should allow you to call chaincode read-only functions (e.g. queries). I guess this would be a good reason to re-introduce Query at chaincode level in the future ( @muralisr )? Then if you have read-only permissions you could call chaincode Query functions but not Invoke. Or would you rather expose the query functions outside of chaincode in the future? (i missed this channel permissions aspect last time we discussed). Will the ACL enhancements under discussion allow us lockdown such queries outside of chaincode in the future?
joe-alewine (Mon, 27 Mar 2017 19:42:25 GMT):
I asked this in #fabric-questions but it's also a relevant question for here. How is it determined how a transaction (as submitted by the client through their SDK) falls under the specific endorsement policy that governs it?
Does the client/SDK decide which endorsement policy is relevant? Does a specific endorser (or group of endorsers) decide? Is there a smart contract that determines it?
muralisr (Tue, 28 Mar 2017 13:38:50 GMT):
@dave.enyeart (sorry for the late reply...a bit sick and not able to think clearly is my excuse :-) ) ... we could reintroduce the notion of "query" where change to the chaincode state won't be allowed and that way we can just require a weak "read" permission on the caller. However, for now - IIUC - the "read" capability refers to queries that don't involve chaincode such as those provided by the "block" query functions in QSCC
dave.enyeart (Tue, 28 Mar 2017 13:46:43 GMT):
ok, so eventually I think we'll either want to expose state db queries to QSCC, or re-introduce Query on chaincode for these queries (and have an associated role for Query vs Invoke). We were going down the path of the former before people raised concerns and we therefore pulled that out of v1. Can somebody explain the vision for ACL? Would ACL be applied to things like QSCC queries? That will likely help us make a decision (most likely post v1). @muralisr @mastersingh24
mgk (Wed, 29 Mar 2017 09:26:46 GMT):
Hi @dave.enyeart can you explain what was pulled out of V1? Are you saying that Direct DB Application Queries (via the SDK) have been removed or is it something else?
SyneBlockChainTeam (Wed, 29 Mar 2017 10:21:36 GMT):
@muralisr - Its working now....thank you for your help. You owe a treat from us...:-)
dave.enyeart (Wed, 29 Mar 2017 11:15:21 GMT):
@mgk Currently you have to do queries such as GetStateByRange and GetQueryResult from within chaincode. There was discussion of exposing these types of queries directly to SDK via Query System Chaincode (QSCC). However there was some concern over access control, which future ACL enhancements may resolve.
passkit (Thu, 30 Mar 2017 12:06:46 GMT):
Has joined the channel.
passkit (Thu, 30 Mar 2017 12:06:50 GMT):
`Failed to generate platform-specific docker build: Error creating container: no such image`. Does Docker and the cc image need to be available on the Peer? I tried with the Docker image pulled down to the machine hosting the peer, but get the same message when trying to instantiate cc
raj (Thu, 30 Mar 2017 12:41:58 GMT):
Has joined the channel.
passkit (Thu, 30 Mar 2017 13:49:03 GMT):
Found that the missing image was the fabric-ccenv for the latest snapshot (not yet on docker hub). Required additional logging to dump variables to be able to determine which image was unavailable. So may help others if the logs (and documentation) could be more specific.
openspylin (Sun, 02 Apr 2017 12:41:11 GMT):
Has joined the channel.
aybekbuka (Sun, 02 Apr 2017 15:13:58 GMT):
Has joined the channel.
debrajo (Mon, 03 Apr 2017 12:52:22 GMT):
Has joined the channel.
SyneBlockChainTeam (Tue, 04 Apr 2017 10:18:55 GMT):
Can we modify configtx.yml file to add more organizations in it? If anyone could provide us with example code would be great. Thanks in advance.
yacovm (Tue, 04 Apr 2017 12:11:09 GMT):
@muralisr @binhn Can you take a look at https://gerrit.hyperledger.org/r/#/c/7647/ ?
Ratnakar (Tue, 04 Apr 2017 18:34:39 GMT):
@SyneBlockChainTeam There is an example here https://github.com/hyperledger/fabric/tree/master/examples/e2e_cli/
you can refer the one here https://github.com/hyperledger/fabric/blob/master/examples/e2e_cli/configtx.yaml
For more details, there is a doc here https://github.com/hyperledger/fabric/blob/master/docs/source/configtxgen.rst
SyneBlockChainTeam (Wed, 05 Apr 2017 04:23:47 GMT):
@Ratnakar - Thank you :-)
SyneBlockChainTeam (Wed, 05 Apr 2017 12:29:45 GMT):
To explore Ordering service (fabric v1.0), please could you suggest example to follow. Thanks.
SyneBlockChainTeam (Wed, 05 Apr 2017 12:31:38 GMT):
@Ratnakar, @muralisr : To explore Ordering service (fabric v1.0), please could you suggest example to follow. Thanks.
AmberZhang (Thu, 06 Apr 2017 07:15:27 GMT):
Has joined the channel.
lizhih (Thu, 06 Apr 2017 09:47:22 GMT):
Has joined the channel.
zemtsov (Thu, 06 Apr 2017 19:34:39 GMT):
Has joined the channel.
scottz (Thu, 06 Apr 2017 20:23:13 GMT):
Has joined the channel.
scottz (Thu, 06 Apr 2017 20:56:48 GMT):
Hi. Where could someone go to find an overview of Events, for a user to learn what and how they work in hyperledger-fabric, with examples? If someone wanted to hook up a monitor process/tool to register for all events to count and summarize them by category, could they do it? What is the interface? etc...
muralisr (Thu, 06 Apr 2017 23:38:43 GMT):
@scottz one place would be examples/event/block-listener (it has a read me as well).. for using events from SDK please check in fabric-sdk-node
scottz (Fri, 07 Apr 2017 00:24:46 GMT):
thanks, but that directory has an example from v0.6, using pbft, discover-root-node, etc. When's the last time you used it? An operations user could really use a better readme and example to desribe more about events- Any objections if I create a jira for improving that readme and maybe adding a section in the new v1.0 documentation pages?
muralisr (Fri, 07 Apr 2017 02:28:38 GMT):
@scottz please do. the block-listener.go was updated for 1.0 but you are right... the README needs to be updated
steigensonne (Fri, 07 Apr 2017 07:39:49 GMT):
I have a quick question on "Channel". How many channel can I create? Is it ok to create 10,000 channel? How many channels can I create? Is there any limitation or restriction? Thanks.
mychewcents (Fri, 07 Apr 2017 07:41:28 GMT):
Has left the channel.
steigensonne (Fri, 07 Apr 2017 07:51:47 GMT):
I have a question on performance of Fabric such as TPS.
Can I have any data or information on the performance of Fabric TPS when the Fabric is applied to the actual business models like supply chain, order management?
scottz (Fri, 07 Apr 2017 13:24:12 GMT):
@steigensonne There is no theoretical limit that I am aware of, but of course there will be practical limits based on your hardware and configuration. The size and complexity of your business logic in your chaincode and policies, database and world state, and participants in the channel, will all impact the TPS numbers.
SyneBlockChainTeam (Fri, 07 Apr 2017 14:08:26 GMT):
@muralisr:
We are referring instructions given in github.com/hyperledger/fabric/examples/e2e_cli/end-to-end.rst file, but getting following error:
root@7899e896ea03:/opt/gopath/src/github.com/hyperledger/fabric/peer# peer channel create -o orderer0:7050 -c mychannel -f crypto/orderer/channel.tx --tls $CORE_PEER_TLS_ENABLED --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/orderer/localMspConfig/cacerts/ordererOrg0.pem
2017-04-07 14:03:14.106 UTC [logging] InitFromViper -> DEBU 001 Setting default logging level to DEBUG for command 'channel'
2017-04-07 14:03:14.106 UTC [msp] GetLocalMSP -> DEBU 002 Returning existing local MSP
2017-04-07 14:03:14.106 UTC [msp] GetDefaultSigningIdentity -> DEBU 003 Obtaining default signing identity
Error connecting: rpc error: code = 14 desc = grpc: RPC failed fast due to transport failure
Error: rpc error: code = 14 desc = grpc: RPC failed fast due to transport failure
Usage:
peer channel create [flags]
Global Flags:
-b, --blockpath string Path to file containing genesis block
--cafile string Path to file containing PEM-encoded trusted certificate(s) for the ordering endpoint
-c, --chain string In case of a newChain command, the chain ID to create.
-f, --file string Configuration transaction file generated by a tool such as configtxgen for submitting to orderer
--logging-level string Default logging level and overrides, see core.yaml for full syntax
-o, --orderer string Ordering service endpoint
--test.coverprofile string Done (default "coverage.cov")
--tls Use TLS when communicating with the orderer endpoint
-v, --version Display current version of fabric peer server
Please suggest if we are missing something...
Thanks
muralisr (Fri, 07 Apr 2017 15:31:17 GMT):
@SyneBlockChainTeam can do `docker ps` and make sure `orderer` container is running ?
jimthematrix (Sat, 08 Apr 2017 19:35:31 GMT):
@binhn @muralisr question on events. so I'm working on adding signature check to event registration (https://jira.hyperledger.org/browse/FAB-1738), as discussed with @adc and @aso on Monday, since at the moment the registration is channel-agnostic, will need to use local MSP to validate Creator and verify signature on the Peer side.
jimthematrix (Sat, 08 Apr 2017 19:35:31 GMT):
@binhn @muralisr @mastersingh24 question on events. so I'm working on adding signature check to event registration (https://jira.hyperledger.org/browse/FAB-1738), as discussed with @adc and @aso on Monday, since at the moment the registration is channel-agnostic, will need to use local MSP to validate Creator and verify signature on the Peer side.
jimthematrix (Sat, 08 Apr 2017 19:37:26 GMT):
but my question is this: if we are doing the above then it means an app can only register with peers in their own org. this can be a problem. because it was nice before to be able to monitor events on all the participating peers in the channel to be ensured that the transaction has been successfully committed in all peers, such that the app can now safely send the next transaction that requires a previous transaction to have been committed
jimthematrix (Sat, 08 Apr 2017 19:37:46 GMT):
if we are doing local MSP based checks during registration, the above won't be possible any longer.
jimthematrix (Sat, 08 Apr 2017 19:38:39 GMT):
as a result, an application can not be sure if it's OK to send a transaction that depends on the previous transaction to have been committed in all endorsing peers
jimthematrix (Sat, 08 Apr 2017 19:38:48 GMT):
any thoughts?
jimthematrix (Sat, 08 Apr 2017 19:41:30 GMT):
one idea is to require channel ID on the registration, so the peer can use channel MSPs to validate Creator, that'll allow the app to monitor on all peers on a per channel basis. but it'll be more work to support per-channel eventing. it can be done but just more than what we originally discussed for v1.0 scope
binhn (Sat, 08 Apr 2017 20:15:36 GMT):
@jimthematrix I would reason this way: Since a peer knows the channels that it has joined, the verification of event registration signature on the peer side should be against all channel MSPs. A bit more work than local MSP, but it would help resolve the problem @adc @aso thoughts?
jimthematrix (Sat, 08 Apr 2017 20:16:57 GMT):
hmm interesting, logically the idea is sound
troyronda (Sat, 08 Apr 2017 21:29:36 GMT):
@binhn @jimthematrix - shouldn't assume that an app can only register with peers in their own org.
binhn (Sun, 09 Apr 2017 02:48:22 GMT):
@troyronda right, so if an app registers with an ID belong some other MSP than the peer local MSP, the peer would have to look for the channels that the ID belongs to and only delivers events from those channels. I think that's safe.
jimthematrix (Sun, 09 Apr 2017 13:29:17 GMT):
@troyronda definitely agree, that's why I brought this up here for discussion. @binhn @adc @aso unless there are objections I'll start modifying my CR to work in that direction
yacovm (Sun, 09 Apr 2017 13:30:32 GMT):
Once channel reconfigurations are implemented, though- an org could be evicted from the channel, and if no checks will be made in the event-hub server - a security hole will be created.
jimthematrix (Sun, 09 Apr 2017 13:30:33 GMT):
also @yacovm brought up a different point regarding config changes
jimthematrix (Sun, 09 Apr 2017 13:30:42 GMT):
;-)
yacovm (Sun, 09 Apr 2017 13:30:43 GMT):
I read your mind, Jim ;)
jimthematrix (Sun, 09 Apr 2017 13:31:28 GMT):
:handshake:
jimthematrix (Sun, 09 Apr 2017 13:32:31 GMT):
I'd like to get the initial registration security in first, and use a separate CR to handle config changes where an existing org has been evicted from the channel
jimthematrix (Sun, 09 Apr 2017 13:32:31 GMT):
I'd like to get the initial registration security in first, and use a separate CR to handle config changes where an existing org gets evicted from the channel
jimthematrix (Sun, 09 Apr 2017 13:32:52 GMT):
note that at the moment the SDKs still don't have config change support
jimthematrix (Sun, 09 Apr 2017 13:33:29 GMT):
not sure how robust the backend support for config changes are right now, but I believe that's a v1.0 item for the next sprint correct?
yacovm (Sun, 09 Apr 2017 13:39:04 GMT):
From what I know- there is no code that makes a block fetched from the ordering service to reach CSCC.
binhn (Sun, 09 Apr 2017 13:57:10 GMT):
@yacovm Artem is working on that as he and I discussed this last week @C0rWin
yacovm (Sun, 09 Apr 2017 13:57:22 GMT):
ah cool
binhn (Sun, 09 Apr 2017 13:57:44 GMT):
@jimthematrix we need FAB-1678 to complete the backend handling of config update
C0rWin (Sun, 09 Apr 2017 13:58:36 GMT):
Just to confirm @binhn message, started to work it, still WIP as was on travel this weekend
C0rWin (Sun, 09 Apr 2017 13:59:15 GMT):
Will provide CR to make missing connection for CSCC part for config update
binhn (Sun, 09 Apr 2017 13:59:39 GMT):
@C0rWin :thumbsup:
yacovm (Sun, 09 Apr 2017 14:02:50 GMT):
So - if Artem is doing it, then IMO it would be needed to extend the signature of the event helper https://github.com/hyperledger/fabric/blob/master/events/producer/eventhelper.go#L35
with a boolean that says whether this block is a config block or not.
If it is- then all active subscriptions to the event hub would be needed to be re-validated because an org might be evicted from the channel.
SyneBlockChainTeam (Mon, 10 Apr 2017 10:14:46 GMT):
@muralisr - We are trying to execute e2e_cli example but we are getting error ¨Error: Error getting endorser client channel: PEER_CONNECTIONERROR - Error trying to connect to local peer: grpc: timed out when dialing¨ . We have modified docker-compose file which is in e2e_cli folder. Following are the changes - under cli /home/username/work/src/github.com/hyperledger/fabric/examples/:/opt/gopath/src/github.com/hyperledger/fabric/examples/
/home/username/work/src/github.com/hyperledger/fabric/examples/chaincode/go/:/opt/gopath/src/github.com/hyperledger/fabric/examples/chaincode/go Is this correct modification? Till last week we were able to connect to peer0 and peer1 with same changes. Please help us to resolve this issue. Thank you.
SyneBlockChainTeam (Mon, 10 Apr 2017 12:00:26 GMT):
@Vadim
(We are following "end-to-end.rst" file for testing "examples/e2e_cli")
On executing command "CORE_PEER_COMMITTER_LEDGER_ORDERER=orderer:7050 CORE_PEER_ADDRESS=peer0:7051 peer channel join -b mychannel.block", we are encountering error "Error: Error getting endorser client channel: PEER_CONNECTIONERROR - Error trying to connect to local peer: grpc: timed out when dialing".
Log:
root@76bb83ca70f9:/opt/gopath/src/github.com/hyperledger/fabric/peer# CORE_PEER_COMMITTER_LEDGER_ORDERER=orderer:7050 CORE_PEER_ADDRESS=peer0:7051 peer channel join -b mychannel.block
2017-04-10 11:54:04.252 UTC [logging] InitFromViper -> DEBU 001 Setting default logging level to DEBUG for command 'channel'
2017-04-10 11:54:04.252 UTC [msp] GetLocalMSP -> DEBU 002 Returning existing local MSP
2017-04-10 11:54:04.252 UTC [msp] GetDefaultSigningIdentity -> DEBU 003 Obtaining default signing identity
2017-04-10 11:54:07.254 UTC [logging] GetModuleLevel -> DEBU 004 Module 'error' logger enabled for log level: DEBUG
Error: Error getting endorser client channel: PEER_CONNECTIONERROR - Error trying to connect to local peer: grpc: timed out when dialing
/opt/gopath/src/github.com/hyperledger/fabric/peer/common/common.go:84 github.com/hyperledger/fabric/peer/common.GetEndorserClient
/opt/gopath/src/github.com/hyperledger/fabric/peer/channel/channel.go:112 github.com/hyperledger/fabric/peer/channel.InitCmdFactory
/opt/gopath/src/github.com/hyperledger/fabric/peer/channel/join.go:133 github.com/hyperledger/fabric/peer/channel.join
/opt/gopath/src/github.com/hyperledger/fabric/peer/channel/join.go:42 github.com/hyperledger/fabric/peer/channel.joinCmd.func1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:599 github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).execute
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:689 github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).ExecuteC
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:648 github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).Execute
/opt/gopath/src/github.com/hyperledger/fabric/peer/main.go:111 main.main
/opt/go/src/runtime/proc.go:192 runtime.main
/opt/go/src/runtime/asm_amd64.s:2087 runtime.goexit
Usage:
peer channel join [flags]
Global Flags:
-b, --blockpath string Path to file containing genesis block
--cafile string Path to file containing PEM-encoded trusted certificate(s) for the ordering endpoint
-c, --chain string In case of a newChain command, the chain ID to create.
-f, --file string Configuration transaction file generated by a tool such as configtxgen for submitting to orderer
--logging-level string Default logging level and overrides, see core.yaml for full syntax
-o, --orderer string Ordering service endpoint
--test.coverprofile string Done (default "coverage.cov")
--tls Use TLS when communicating with the orderer endpoint
-v, --version Display current version of fabric peer server
Looking forward for your help.
Kind Regards
Vadim (Mon, 10 Apr 2017 12:00:26 GMT):
Has joined the channel.
Senthil1 (Mon, 10 Apr 2017 17:15:06 GMT):
Has joined the channel.
jimthematrix (Tue, 11 Apr 2017 02:50:25 GMT):
@binhn @adc @aso not sure if you guys have seen the discussions b/w @yacovm and myself in https://gerrit.hyperledger.org/r/#/c/7905/ (still WIP), but Yacov pointed out a security hole in the current approach which I agree: using all channels to check for identity-based permission does not work well when the registration request is made to a peer in a different org
jimthematrix (Tue, 11 Apr 2017 02:53:47 GMT):
we can be certain that an app has rights to all channels when it attempts to listen on a peer in its own org. But a peer in a different org may have channels that the requesting app is not part of. yet as long as the requesting app is part of one of the channels, the registration is allowed and as a result blocks from all channels will be sent to the app.
jimthematrix (Tue, 11 Apr 2017 02:55:04 GMT):
hence the security hole, which Yacov pointed out
jimthematrix (Tue, 11 Apr 2017 02:58:06 GMT):
I had thought that channel-specific eventing can be done separately from the registration security. but looks like that's not possible due to the above
jimthematrix (Tue, 11 Apr 2017 02:58:31 GMT):
I'll start adding that to 7905
mffrench (Tue, 11 Apr 2017 19:15:44 GMT):
@jimthematrix : that's good to know. reading your comments on gerrit, my understanding is, until channel-specific events impl (post-v1.0), we have to take care on peer functional split across orgs (ie: be sure a peer is installed through orgs for exactly the same channels and final apps) to avoid this kind of sec hole. can you confirm ?
Lin-YiTang (Tue, 11 Apr 2017 21:18:11 GMT):
Has joined the channel.
mastersingh24 (Tue, 11 Apr 2017 23:29:20 GMT):
@jimthematrix - I thought that we were going to go with an approach that the eventhub was locked down to the "localMSP" of the peer?
troyronda (Wed, 12 Apr 2017 00:38:46 GMT):
@mastersingh24 - can't assume that clients are in the same org as the peer.
jimthematrix (Wed, 12 Apr 2017 03:51:20 GMT):
@mastersingh24 see my comments from last Saturday about this: https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=NHdnCLPGq5drQWQBn
jimthematrix (Wed, 12 Apr 2017 03:55:34 GMT):
if that's what we are going with the code is pretty easy (patch 1), but it'll make it difficult for apps to coordinate among endorsers to submit transactions that act on output of previous transaction(s)
jimthematrix (Wed, 12 Apr 2017 13:10:40 GMT):
@aleksandar.likic yes what you said is logically correct but difficult to implement because the peers would have to send transactions in events as opposed to blocks. not that it's impossible but just non-trivial work to support another kind of event payload at this point
muralisr (Wed, 12 Apr 2017 13:22:13 GMT):
@jimthematrix my 2c... all other apis at a peer level, ie across channels (such as via the query scc) allow access on certain conditions
muralisr (Wed, 12 Apr 2017 13:22:49 GMT):
will be good to make sure there isn't another path (via events) that violates that
weeds (Wed, 12 Apr 2017 13:36:06 GMT):
Feel free to join us for the peer scrum- 1-888-426-6840 / 33682113
weeds (Wed, 12 Apr 2017 13:36:22 GMT):
that is starting now and may last for 10 minutes. I will take notes here for what happens in the conversation
weeds (Wed, 12 Apr 2017 13:38:54 GMT):
Ledger- The Jira board updated for ledger, we have good idea of what defects we think need to be addressed
weeds (Wed, 12 Apr 2017 13:39:13 GMT):
I also cleaned up fabric-peer and endorser to help Murali- i cleaned up 40% of those that were outdated and invalid and I assigned to some other components.
weeds (Wed, 12 Apr 2017 13:39:50 GMT):
For fabric-peer/fabric-endorser there is still a lot out of it- i need help to figure out what is 1.0 and 1.1, maybe @binhn could help with that given Murali not able to look at it right now.
weeds (Wed, 12 Apr 2017 13:40:11 GMT):
in ledger- there is less than 10 defects, for endorser for 10, in fabric- peer therre were about 30, but probably should be deferred but need help from Binh
weeds (Wed, 12 Apr 2017 13:41:27 GMT):
since Murali is traveling
weeds (Wed, 12 Apr 2017 13:42:02 GMT):
We would like to really get all coding done by next Friday-- ie finishing out some of the pieces that community thought we need to complete. Ie these are final touches and code was "mostly" done already
weeds (Wed, 12 Apr 2017 13:42:21 GMT):
really primary focus is bugs and quality and stabilizing
weeds (Wed, 12 Apr 2017 13:44:54 GMT):
Murali did indicate that he has to look at the comments from chaincode packaging- but if everyone reviews that once they are addressed... it would help him. Binh commented- the base one Chris is asking for the test on that. part 1 of the 2 parts above that uses a lot of panic, and I'm concerned and I do have a question. Murali indicated he will explain why the panics are ok. I will put the responses there and we can decide next step.
weeds (Wed, 12 Apr 2017 13:45:56 GMT):
Will- I want to figure out what we are thinking about error handling framework- i have 2 changesets out there- 1 functional and 1 documentation. If we want to make that into v1- we need to get that reviewed if everyone is going to use this. Binh really wants to get that in to address serviceability and code hardening that makes the fabric more useable.
weeds (Wed, 12 Apr 2017 13:47:35 GMT):
Will asking that 2 maintainers to look at the change sets - it's on review list in maintainer list 7745 and 7845.
weeds (Wed, 12 Apr 2017 13:48:36 GMT):
Do we have time to adjust our code for error handling? don't we need to catch where we have an error and surround it with this code from Will? yes, the intention is that each developer will look at this as part of development and bring it in - but it can NOT be a breaking change. But serviceability is really important.
weeds (Wed, 12 Apr 2017 13:49:00 GMT):
We should start with the most important and common errors in.
weeds (Wed, 12 Apr 2017 13:51:02 GMT):
Yacov- my 2 changes - the peer is reconnecting to ordering service- or the ordering service- it does a failover. I'm also working on gossip security hardening.
weeds (Wed, 12 Apr 2017 13:51:30 GMT):
Jira has been updated and cleaned up on Sunday/Monday, the backlog has been gone through- there are still a couple of bugs that got opened.
weeds (Wed, 12 Apr 2017 13:52:15 GMT):
Artem- (this is gossip squad with Yacov/Artem)-
weeds (Wed, 12 Apr 2017 13:53:14 GMT):
My primary focus right now is to focus on document for side db-- the gossip part of that- for overall design. That is post 1.0, but we have to at least look at it for now to see if any implications moving forward.
weeds (Wed, 12 Apr 2017 13:53:41 GMT):
Gennedy- I have 3 gerrit changesets waiting - 2 of them are reviewed by Yacov/Artem.
weeds (Wed, 12 Apr 2017 13:53:52 GMT):
1 of them was reviewed by Murali and everything was addressed in comments.
weeds (Wed, 12 Apr 2017 13:54:11 GMT):
This is expiration of the message- Murali said was fine, but it's not what I had in mind, but we can talk about it.
weeds (Wed, 12 Apr 2017 13:54:23 GMT):
Gennedy said I'm waiting for your comments- Murali will do that
weeds (Wed, 12 Apr 2017 13:55:06 GMT):
Orderer squad- most of team not on today, but Jeff did said he is sifting through configgen tool.
weeds (Wed, 12 Apr 2017 13:55:38 GMT):
we are proceeding with the change- we need to coordinate
weeds (Wed, 12 Apr 2017 13:56:17 GMT):
with the community further on this one
weeds (Wed, 12 Apr 2017 13:57:02 GMT):
The orderer config, channels config, and then SDK support for channel config has to be coordinated
weeds (Wed, 12 Apr 2017 13:57:43 GMT):
Gari does support this, but it has to be well coordinated
weeds (Wed, 12 Apr 2017 13:59:01 GMT):
Security- Angelo is devoting energy to access control- Ale/Angelo looking at new tools to understand if system chaincode is invoked by external proposal or something that comes internal to peer itself. this gives us granularity the proper access control for each function.
weeds (Wed, 12 Apr 2017 14:00:20 GMT):
Binh reviewed his changes yesterday- I know you have responded to some, but I've asked Murali to respond to 1 of the questions. Angelo did indicate we have to wait, because there is a change that Ale has to submit. We have to wait, and I need function that tells me if invocation from peer itself especially for sscc- I don't know how to do this otherwise. this system chaincode does not understand who is invoking and that could be a problem. For now, do not merge.
weeds (Wed, 12 Apr 2017 14:00:49 GMT):
Ale- Binh did review the CRs with a couple of comments.. there is a to do so it's been -2ed until addressed.
weeds (Wed, 12 Apr 2017 14:00:52 GMT):
(Ale is out today)
weeds (Wed, 12 Apr 2017 14:02:16 GMT):
For access control- once that is in place- my understanding is that this enforces policies that have been specified. is that right? yes absolutely, it's that but in certain places i just figured out in certain places in code- where we should not enforce any access control if a certain code is coming from peer itself- so if peer invoking system chaincode to be able to execute certain function.. this is what the hold up is.
weeds (Wed, 12 Apr 2017 14:02:42 GMT):
What is impact to other areas? since specification of the policies is in place- your work would not require any components to react- the policies that are already in place are the only ones that we need, that's correct
weeds (Wed, 12 Apr 2017 14:04:03 GMT):
Matthias- one thing that I found- when you deploy chaincode, what you do first is an install, install version 1, instantiate version 1, install version 2 and upgrade to version 2- but what the upgrade command does is that it checks whether the chaincode that you specify when you upgrade whether the version you supplied is the same as the one instantiated. so i instantiated to version 2 and specify version #2- it won't let me, but I can go back and do an upgrade to version 1- tracking back. that has to be fixed.
weeds (Wed, 12 Apr 2017 14:06:46 GMT):
we do need to think what does it mean if you want to revert back to original cloud- we should discuss this in the channels on what to do here
weeds (Wed, 12 Apr 2017 14:06:56 GMT):
open a JIRA
weeds (Wed, 12 Apr 2017 14:08:19 GMT):
2931- chaincode instantiation- there is multiple options to validate this- we should discuss and settle on one in terms of what we want to implement. If we don't do a policy here- we may have to do additional checks for this function.
weeds (Wed, 12 Apr 2017 14:10:24 GMT):
the other thing is the check that the orderers on genesis block for MSP configuration- we have created JIRA item for Kostas and whether we consider important for feature or bug- the orderers when they receive channel creation- they have to do a check on MSP configuration- that the MSP id maps to the system channel for that particular MSP. That's the orderer's organization. Is that correct? Can't anyone create channels? they might not joined by any peers if the peer disapproves the channel.. only someone in orderer in org create channels? orderer has to decide whether they create the channel- don't we want to bind the MSP id configuration- but of course that is the case what you said- if I approve the channel, i'm not going to ask peers to join the channel-
weeds (Wed, 12 Apr 2017 14:11:07 GMT):
how does this impact the application? as of now- anyone can create the channel- anyone can propose a channel, but this channel is useless unless your partners have joined- so anyone can propose a channel and call the create channel- if we change that design- we need to talk to the maintainers about that
weeds (Wed, 12 Apr 2017 14:12:00 GMT):
Binh- somehow we really need kostas/gari on this call. the channel creation policy on the orderer system channel- Elli- are you saying we have no checks there even though we have that policy? We don't have a check to ensure that MSP that is related to freshly created channel have the same configuration . Let's open a bug and discuss there then.
weeds (Wed, 12 Apr 2017 14:12:06 GMT):
there is a policy for channel creation
weeds (Wed, 12 Apr 2017 14:12:29 GMT):
it's up to the founders of network to decide-yes? yes it's part of the bootstrap
weeds (Wed, 12 Apr 2017 14:12:48 GMT):
it's also part of the series of the configuration crs that we have been talking about that deals with consortium
weeds (Wed, 12 Apr 2017 14:13:43 GMT):
Kostas- there is a question- given that on the orderer there is a channel creation policy- is there a security check on that today? Binh suggesting we should create a defect for that. (this is regardless of recent changes.. also got question from Keith in community on that) I can double check on this and I will create defect for this if it's open to all.
weeds (Wed, 12 Apr 2017 14:13:52 GMT):
Current config tx tool does accept all for now
weeds (Wed, 12 Apr 2017 14:14:06 GMT):
But that is accept all given the MSP list which is zero identity for now
weeds (Wed, 12 Apr 2017 14:14:17 GMT):
as long as we still allow policy based- we are ok
weeds (Wed, 12 Apr 2017 14:14:30 GMT):
Jeff is offering to help on this
weeds (Wed, 12 Apr 2017 14:15:51 GMT):
Elli- i have a question on events- i see you posted CR for event access control- Jim said this is work in progress. ever since i tried to support registration with different org- there is a lot of security issues that we should hash through. having said that- what is your concern?
weeds (Wed, 12 Apr 2017 14:16:48 GMT):
Elli has 2 main comments- so you do some signature checks at event message using an MSP of the chain? one could use some function Angelo has already built that can be done faster/smoother. When peers does a channel- do you want us to help you Jim? yes, that would be ideal.
weeds (Wed, 12 Apr 2017 14:17:08 GMT):
Jim said there is discussion on scope of work, so let's talk on chat after the call on this
weeds (Wed, 12 Apr 2017 14:17:13 GMT):
Jim on SDK side:
weeds (Wed, 12 Apr 2017 14:18:01 GMT):
Node- there are 2 pieces of work going on. Brett working on supporting channel creation policy from SDK so you don't have to rely on configx tool. It also has benefit of full control of all the configs you can do through the api versus generating a lot of config contents as defaults. That's coming along
weeds (Wed, 12 Apr 2017 14:18:45 GMT):
Jim said he's been working on the event piece and it took an interesting turn. in beginning- check with local msp- listner can only register peer from their own org, but then that exposes a pretty serious limitation and i wanted to allow cross org registration, and that may turn out more work than what we want to do with version 1.0 and I need input from the maintainers
weeds (Wed, 12 Apr 2017 14:19:55 GMT):
Rick- for Java- there are 2 things I want to point out. I have a work item that is initaiated to do the read/write set- i've started to work on that.. i'm getting to the part where i'm supposed to see read/write set and I can't figure out what is going on there is fab26789 (number?). I can't introduce this if we don't do this in the event hub. I need a decision on that.
weeds (Wed, 12 Apr 2017 14:20:10 GMT):
someone in community is really pressing hard on that- 2679 is the number
weeds (Wed, 12 Apr 2017 14:20:29 GMT):
this is one that was assigned to Will- but clayton/him felt this was not a requirement and we addressed in a different way. That's why this was put on 1.1
weeds (Wed, 12 Apr 2017 14:20:39 GMT):
We might want to circle back to the person in the community on this.
weeds (Wed, 12 Apr 2017 14:20:53 GMT):
they felt they needed this to be there, but if there is a workaround we need to discuss what that was suggested.
weeds (Wed, 12 Apr 2017 14:21:19 GMT):
they want read/write set as part of the event was the original request, but at least some point in discussion, we thought they should try the return result instead- they felt this was more appropriate and not relying on read/write set.
weeds (Wed, 12 Apr 2017 14:22:09 GMT):
because of concern on performance and network impact- Gari had at one point suggested to have 2 different kind of events. the client can register knowing what asking for- one would be event including everything and one that we currently have
weeds (Wed, 12 Apr 2017 14:23:40 GMT):
ok- so I'm going to mark it 1.1 then.
weeds (Wed, 12 Apr 2017 14:25:04 GMT):
Rick just got the latest fabric server code- and I'm sending stuff to orderer and I'm not seeing any errors- but I'm not seeing events come back- this was passing, and now they are failing- something got introduced that is a breaking change. we need to investigate this...
weeds (Wed, 12 Apr 2017 14:26:37 GMT):
security team scrubbed defect backlog and JIRa boards completed
weeds (Wed, 12 Apr 2017 14:26:45 GMT):
Rick feels he completed this as well on defect backlog and JIRa boards
weeds (Wed, 12 Apr 2017 14:27:34 GMT):
Scrum ended
troyronda (Wed, 12 Apr 2017 15:12:18 GMT):
@jimthematrix @aleksandar.likic - there should be additional restrictions so that the client might only know that *their* transaction *id* has been committed and not see the block itself - they should be able to do this against peers in the channel. it can be none of the client's business what is in blocks.
troyronda (Wed, 12 Apr 2017 15:12:18 GMT):
@jimthematrix @aleksandar.likic - there should be additional restrictions so that the client might only know that *their* transaction *id* has been committed and not see the block itself - they should be able to do this against peers in the channel (beyond their own org). it can be none of the client's business what is in blocks.
troyronda (Wed, 12 Apr 2017 15:12:18 GMT):
@jimthematrix @aleksandar.likic - there should be additional restrictions so that the client might only know that *their* transaction *id* has been committed and not see the block itself - they should be able to do this against peers in the channel (beyond their own org). there are situations where it can be none of the client's business what is in blocks.
troyronda (Wed, 12 Apr 2017 15:12:18 GMT):
@jimthematrix @aleksandar.likic - there should be additional restrictions so that the client might only know that *their* transaction *id* has been committed and not see the block itself - they should be able to do this against peers in the channel (beyond their own org). there are situations where it can be none of the client's business what is in blocks but they still want to know the status of *their* transaction.
troyronda (Wed, 12 Apr 2017 15:12:18 GMT):
@jimthematrix @aleksandar.likic - there should be additional restrictions so that the client might only know that *their* transaction *id* has been committed and not see the block itself - they should be able to do this against peers in the channel (beyond their own org). there are situations where it can be none of the client's business what is in blocks but they still want to be notified of the *status* of *their* transaction.
dbshah (Wed, 12 Apr 2017 15:46:16 GMT):
Has joined the channel.
binhn (Wed, 12 Apr 2017 17:39:26 GMT):
@troyronda @jimthematrix @aleksandar.likic that all makes sense and a complex thing to tackle. Currently we are looking at a very simple solution for 1.0 so that we can address quickly and provide a useful infrastructure for putting in the detail later on (post 1.0). The key restriction at this point is that the event listener must be in the same organization (MSP) as the peer that it is subscribing with. This allows delivering events in a secured way.
mastersingh24 (Wed, 12 Apr 2017 19:33:24 GMT):
we really are not set up to do per client events
mastersingh24 (Wed, 12 Apr 2017 19:33:59 GMT):
we need to think long and hard about this
mastersingh24 (Wed, 12 Apr 2017 19:34:56 GMT):
to date, we have been fairly strong in terms of not making event hub into a total pub/sub engine based on all kinds of criteria
troyronda (Wed, 12 Apr 2017 20:55:34 GMT):
@mastersingh24 - knowing about the status of a transaction is rather more basic than a total pub/sub engine
troyronda (Wed, 12 Apr 2017 20:55:34 GMT):
@mastersingh24 - being notified about the status of a transaction at organizations seems rather more basic than a total pub/sub engine
troyronda (Wed, 12 Apr 2017 20:55:34 GMT):
@mastersingh24 - being notified about the status of a transaction at a peer seems rather more basic than a total pub/sub engine
troyronda (Wed, 12 Apr 2017 20:55:34 GMT):
@mastersingh24 - i hear you :) ... being notified about the status of a transaction at a peer seems rather more basic than a total pub/sub engine
yacovm (Wed, 12 Apr 2017 20:59:53 GMT):
The flow of the event channel is:
a client connects, and sends a registration descriptor.
You're asking that the peer would know based on that descriptor, to publish a transaction status to the client, while the TxId isn't passed.
Currently from what I know- the event infrastructure doesn't even support channels.
More work is needed there.
yacovm (Wed, 12 Apr 2017 20:59:53 GMT):
The flow of the event channel is:
a client connects, and sends a registration descriptor.
The peer sends events when blocks are committed.
You're asking that the peer would know based on that descriptor, to publish a transaction status to the client, while the TxId isn't passed.
Currently from what I know- the event infrastructure doesn't even support channels.
More work is needed there.
troyronda (Thu, 13 Apr 2017 00:18:53 GMT):
Commented on https://jira.hyperledger.org/browse/FAB-2679 - There should be a way to restrict what's being sent back to clients. i.e., so that they only find out that their transaction has been committed.
And the SDKs shouldn't be depending on having this amount of information.
troyronda (Thu, 13 Apr 2017 00:18:53 GMT):
Commented on https://jira.hyperledger.org/browse/FAB-2679 - There should be a way to restrict what's being sent back to clients. i.e., so that they only find out that their transaction has been committed.
And the SDKs shouldn't be depending on having this amount of information. Confidentiality is important and client should be considered less trusted.
troyronda (Thu, 13 Apr 2017 00:18:53 GMT):
Commented on https://jira.hyperledger.org/browse/FAB-2679 and also created https://jira.hyperledger.org/browse/FAB-3134 - There should be a way to restrict what's being sent back to clients. i.e., so that they only find out that their transaction has been committed.
And the SDKs shouldn't be depending on having this amount of information. Confidentiality is important and client should be considered less trusted.
troyronda (Thu, 13 Apr 2017 00:20:32 GMT):
(There wasn't a use case in that ticket)
steigensonne (Thu, 13 Apr 2017 04:41:34 GMT):
I have a question on example of "e2e_cli". When I follow up the "Getting Started", I have a problem --> Error: Error connecting to orderer0:7050 due to grpc: timed out when dialing. I hope anyone could share your wisdom to solve this problem.
muralisr (Thu, 13 Apr 2017 06:25:54 GMT):
@steigensonne this link from @gre
muralisr (Thu, 13 Apr 2017 06:25:54 GMT):
@steigensonne this link from @greg.haskins maybe relevant
muralisr (Thu, 13 Apr 2017 06:26:19 GMT):
https://chat.hyperledger.org/channel/fabric?msg=hKdyTRjCpSCuE2dij
muralisr (Thu, 13 Apr 2017 06:26:41 GMT):
https://chat.hyperledger.org/channel/fabric?msg=RWPLTbbmHHCwjLvEN
muralisr (Thu, 13 Apr 2017 06:28:09 GMT):
there's a whole discussion on it on April, 10
troyronda (Thu, 13 Apr 2017 13:47:55 GMT):
https://jira.hyperledger.org/browse/FAB-3138 - there seems to be an assumption that clients are on a different MSP than peers
troyronda (Thu, 13 Apr 2017 13:47:55 GMT):
https://jira.hyperledger.org/browse/FAB-3138 - there seems to be an assumption that clients are on a different MSP than peers - see earlier discussion on eventHub
troyronda (Thu, 13 Apr 2017 13:47:55 GMT):
https://jira.hyperledger.org/browse/FAB-3138 - there seems to be an assumption that clients are on a different MSP than peers? - see earlier discussion on eventHub
troyronda (Thu, 13 Apr 2017 13:47:55 GMT):
https://jira.hyperledger.org/browse/FAB-3138 - there seems to be an assumption that clients are on a different MSP than peers as the mechanism to prevent clients from joining gossip as peers? ... but see earlier discussion on eventHub
troyronda (Thu, 13 Apr 2017 13:49:11 GMT):
( @binhn @mastersingh24)
gdhh (Thu, 13 Apr 2017 14:22:17 GMT):
Has joined the channel.
mastersingh24 (Thu, 13 Apr 2017 14:42:14 GMT):
@troyronda - Not really. Currently all access is basically channel-scoped by organization (and each organization has their own MSP credentials). We don't differentiate peer organizations from client-only organizations and organizations have read and/or write access to channels (we also don't differentiate peer identities from client identities). While we can add the concept of "roles" (e.g. add an attribute to certificates), without having a central authority who issues these there is really no way to ensure that a peer is really a peer and a client is really a client (i.e. if an org has it's own CA it can issue peer and client certificates as it sees fit). Even with a central issuing authority it would have to be trusted as well but at least there would be one place that is accountable (I guess you could still hold individual CAs accountable as well but it makes it harder to enforce proper issuance).
I'll save discussion on options for locking this down more, but suffice it to say we can do things such as create separate endpoints for endorsement, gossip and possible even chaincode, leverage a combination of mutual TLS and/or roles to lock down communication on the gossip channel, etc
troyronda (Thu, 13 Apr 2017 14:45:27 GMT):
So in 1.0 - can a client that was issued a certificate join a gossip channel?
yacovm (Thu, 13 Apr 2017 14:45:41 GMT):
1) Gossip currently supports mutual TLS
2) I think that such discussions are more suitable for the #fabric-crypto channel
yacovm (Thu, 13 Apr 2017 14:45:41 GMT):
1) Gossip currently supports mutual TLS
2) I think that such discussions are more suitable for the #fabric-crypto channel
3) Indeed if we just run the gRPC server that gossip binds to on a different port- the problem can be solved with firewalls
yacovm (Thu, 13 Apr 2017 14:52:44 GMT):
> So in 1.0 - can a client that was issued a certificate join a gossip channel?
If you have the peer binary and you just give it a client's credentials (private key + certificate) - the answer would be- if the peer's MSP can validate that certificate , then I'd say yes.
Now, if the peer can validate the certificate of a client - that depends on the MSP that is used and also on the certificate.
Maybe @elli-androulaki can shed some light on the subject.
yacovm (Thu, 13 Apr 2017 14:58:46 GMT):
Now, if we had mutual TLS then that'd mean that the client (dressed as a peer) would need a valid TLS cert to connect to a peer
mastersingh24 (Thu, 13 Apr 2017 15:00:51 GMT):
[ Yes - this is possible today](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=WxBgWQjkHwESKaCs6) @troyronda
troyronda (Thu, 13 Apr 2017 15:01:13 GMT):
and still join eventhub
troyronda (Thu, 13 Apr 2017 15:01:32 GMT):
That's not good though
elli-androulaki (Thu, 13 Apr 2017 16:09:44 GMT):
> So in 1.0 - can a client that was issued a certificate join a gossip channel?
Yes!
elli-androulaki (Thu, 13 Apr 2017 16:09:44 GMT):
> So in 1.0 - can a client that was issued a certificate join a gossip channel?
Yes, but unless the client belongs to an organization that have access to a channel (read) it is not able to receive messages that are channel-scoped for that channel.
yacovm (Thu, 13 Apr 2017 18:12:51 GMT):
@troyronda can you explain the *confidentiality/security* concern behind taking a client's cert and using it to start a peer? As Elli said- since the client came from the same org as the peer, that _ fake _ peer can only get the information (channel-wise) that he could have gotten as a client, not anything more.
troyronda (Thu, 13 Apr 2017 18:13:15 GMT):
The client isn't authorized to see blocks or RW sets
troyronda (Thu, 13 Apr 2017 18:13:31 GMT):
this absolutely breaks confidentiality
yacovm (Thu, 13 Apr 2017 18:13:57 GMT):
aha
yacovm (Thu, 13 Apr 2017 18:14:07 GMT):
got it
troyronda (Thu, 13 Apr 2017 18:16:33 GMT):
i would imagine there are security concerns as well, with the client able to interrupt the network behavior
troyronda (Thu, 13 Apr 2017 18:17:02 GMT):
(as an attacker who steals the client's certificate as client certs are typically less protected than peer certificates)
troyronda (Thu, 13 Apr 2017 18:17:02 GMT):
(by an attacker who steals the client's certificate, as client certs are typically less protected than peer certificates)
yacovm (Thu, 13 Apr 2017 18:17:22 GMT):
ok
Jay (Fri, 14 Apr 2017 05:14:02 GMT):
Has joined the channel.
elli-androulaki (Fri, 14 Apr 2017 09:29:05 GMT):
So, would the clients still be running a fabric-client? that is, submitting tx-s directly to the blockchain?
elli-androulaki (Fri, 14 Apr 2017 09:30:06 GMT):
If so, one could give clients write access to the chain, but no read access. Then there can be a chaincode that checks the transaction status that the clients can query to check of whether their transaction has been validated/included to the ledger.
elli-androulaki (Fri, 14 Apr 2017 09:30:18 GMT):
However, this would require the clients to poll
simsc (Mon, 17 Apr 2017 13:35:10 GMT):
Here is the call in for the peer scrum (1-888-426-6840 / 33682113)
weeds (Mon, 17 Apr 2017 13:36:26 GMT):
I'm taking notes
weeds (Mon, 17 Apr 2017 13:36:55 GMT):
If you look at defect backlog- on April 6th we were at 273- we are now down to 186. This is really due to "clean up"
weeds (Mon, 17 Apr 2017 13:37:14 GMT):
Thank you to Chris Ferris helping as well beyond the team.
weeds (Mon, 17 Apr 2017 13:38:30 GMT):
STart with gossip- i'm looking at your backlog
weeds (Mon, 17 Apr 2017 13:39:17 GMT):
is your backlog in JIRA is accurate? is this what you are working on? yes
weeds (Mon, 17 Apr 2017 13:39:39 GMT):
the only capability is 1845- gossip message timley experation- and everything is really a defect.
weeds (Mon, 17 Apr 2017 13:40:38 GMT):
we still have 4 or 5 outstanding to get reviewed so we can get reviewed by end of day... so they can be merged potentially based on commetns?
weeds (Mon, 17 Apr 2017 13:41:31 GMT):
3199- is also one that we are working on
weeds (Mon, 17 Apr 2017 13:41:46 GMT):
this is typed bug- is it a bug or is it a feature?
weeds (Mon, 17 Apr 2017 13:41:53 GMT):
this is really a bug
weeds (Mon, 17 Apr 2017 13:42:26 GMT):
Be careful not to misuse bugs- don't use bug type to get feature request in- please follow spirit for what it is intended for.
weeds (Mon, 17 Apr 2017 13:42:37 GMT):
(not directed to gossip squad- but general comment to all)
weeds (Mon, 17 Apr 2017 13:42:49 GMT):
LEDGER
weeds (Mon, 17 Apr 2017 13:43:05 GMT):
Dave Enyeart- are your JIRa boards up to date? Yes,.. everything we are working on in the JIRA board.
weeds (Mon, 17 Apr 2017 13:43:30 GMT):
Any feature we think won't complete? There are some things like tasks for system type testing and logging framework we hven't rolled in-
weeds (Mon, 17 Apr 2017 13:44:15 GMT):
I do need to talk to Murali to see if there is anything on upgrade functionality- we need to do 1 validation, this story is quick if there is anything to do, but I need more information before I know I have to do that work. otherwise, looking good.
weeds (Mon, 17 Apr 2017 13:44:17 GMT):
SDK
weeds (Mon, 17 Apr 2017 13:44:25 GMT):
The boards are up to date.
weeds (Mon, 17 Apr 2017 13:44:55 GMT):
The major work is to finish the channel creation support using JSON- so applications do not have to rely on command line tool. The changeset is being reviewed but does need more work before merging.
weeds (Mon, 17 Apr 2017 13:49:27 GMT):
(sorry blipped- so may have missed a few things)
weeds (Mon, 17 Apr 2017 13:50:03 GMT):
Eventing security, channel creation support and channel update are all needed for nodejs.sdk
weeds (Mon, 17 Apr 2017 13:50:25 GMT):
we have some networking issues for nodejs.sdk
weeds (Mon, 17 Apr 2017 13:50:56 GMT):
channel update support is unknown- we don't think big impact to sdk
weeds (Mon, 17 Apr 2017 13:51:25 GMT):
Jira boards are up to date
weeds (Mon, 17 Apr 2017 13:51:36 GMT):
we are going to rereview the SDK boards to check after this call.
weeds (Mon, 17 Apr 2017 13:52:15 GMT):
Rick says sprint 16 for JAVA sdk is up to date, but feel that he will go into sprint 17 to finish up... so need to validate we tag it in sprint 17 correctly
weeds (Mon, 17 Apr 2017 13:52:26 GMT):
CRYPTO
weeds (Mon, 17 Apr 2017 13:52:47 GMT):
Jira boards are up to date
weeds (Mon, 17 Apr 2017 13:53:40 GMT):
Binh to reach out to Elli
weeds (Mon, 17 Apr 2017 13:54:24 GMT):
The JIRA number at risk that needs to be discussed- 3155 is at risk and has an overlap with 2091.
weeds (Mon, 17 Apr 2017 13:54:37 GMT):
3155 should be moved to feature instead of defect
weeds (Mon, 17 Apr 2017 13:54:48 GMT):
Elli is changing right now to feature
weeds (Mon, 17 Apr 2017 13:55:15 GMT):
Upgrade of chaincode- security work has to be combined with installation security work.
weeds (Mon, 17 Apr 2017 13:56:09 GMT):
Pre- endorsement is also related to the installation/instantiation to ensure consistency of simulation across endorsers
weeds (Mon, 17 Apr 2017 13:56:36 GMT):
all of the work is listed in sprint 16 on jira board
weeds (Mon, 17 Apr 2017 13:56:52 GMT):
ORDERER
weeds (Mon, 17 Apr 2017 13:57:31 GMT):
the JIRA board is up to date and all work is hardening/polishing except 2989- this is added by elli which is interaction between orderer and msp to check with consistency. I will look at this tomorrow and do our best, but may be off by a couple of days
weeds (Mon, 17 Apr 2017 13:57:45 GMT):
right now 2989 is under fabric-crypto right now
weeds (Mon, 17 Apr 2017 13:58:00 GMT):
All the review for consortium- it's a matter of merging the code
weeds (Mon, 17 Apr 2017 13:58:23 GMT):
no blockers
weeds (Mon, 17 Apr 2017 13:58:43 GMT):
FABRIC-CA
weeds (Mon, 17 Apr 2017 13:58:57 GMT):
we have things in review that are progressing, jira boards are up to date...
weeds (Mon, 17 Apr 2017 13:59:05 GMT):
we will contain all in sprint 16 which ends friday
weeds (Mon, 17 Apr 2017 13:59:16 GMT):
We are focused on defect backlog
weeds (Mon, 17 Apr 2017 14:02:09 GMT):
Please make sure things are in the JIRA boards -- they won't get checked in if they are not there as too hard for the maintainers.
weeds (Mon, 17 Apr 2017 14:02:10 GMT):
HSM
weeds (Mon, 17 Apr 2017 14:02:59 GMT):
Vlad has been trying to cleanup the JIRA boards- HSM is feature complete- but he's trying to do testing.. he has checked in 2 big fixes (these may be more than bug fixes for PKCS11)
weeds (Mon, 17 Apr 2017 14:03:48 GMT):
I have not gotten to the end to end HSM end to end running- i'm able to sign things and peers/orderers communicating, I just don't know until i get end to end running to see if there is more to do -- i'm in bringup and until this is completed,... I won't know for sure.
weeds (Mon, 17 Apr 2017 14:04:29 GMT):
what do you think is plan for HSM Java sdk support? I have not had time to look at it at all .. i know how to fix, but need to finish bringup first.
weeds (Mon, 17 Apr 2017 14:05:02 GMT):
JCE does not seem to support the malleability feature- I need to see if we build a custom JCE feature- or recalculate in golang... i just have to look
weeds (Mon, 17 Apr 2017 14:05:46 GMT):
The HSM support for JAva requires some work, but it does not require full implementation for node- it needs clean up of interface so does not require private keys. I've asked someone to help out here.. we'll see if we can do some more work here.
weeds (Mon, 17 Apr 2017 14:06:29 GMT):
Config tx is also needed in Java sdk.
weeds (Mon, 17 Apr 2017 14:07:27 GMT):
for create channel, config tx- it's currently tracking for java sdk- they will have to do cli
weeds (Mon, 17 Apr 2017 14:08:55 GMT):
Ability to config transaction to orderer- we can do that in Java SDK and have sample working and and you have to build the binary protobuf
weeds (Mon, 17 Apr 2017 14:09:29 GMT):
there is ability to use GRPC or they can use node sdk to implement the admin and use java to do the regular user apps.
weeds (Mon, 17 Apr 2017 14:10:25 GMT):
this needs to be discussed on the maintainers channel
weeds (Mon, 17 Apr 2017 14:12:05 GMT):
Binh said ACL related to chaincode is not completed- they have gone through a number of reviews- but I looked at CRs today and there are outstanding questions, a few people are on holiday, but I'm hoping that will be settled early this week.
weeds (Mon, 17 Apr 2017 14:12:36 GMT):
Binh brought up config update- I'd like to be able to complete our work and that means to have some support from the SDK and the BDD available for folks to review and we tee that up.
weeds (Mon, 17 Apr 2017 14:13:38 GMT):
Binh brought up documentation- one document I'm working on with a draft from Murali is related to the chaincode lifecycle and meaning of chaincode and what the chaincode is used for. i need the developers to look at the document. we have so many entries but almost all of them are work in progress- they are 1 to 2 paragraphs and we need to fill that out for this release- this is part of work that we have to continue to do
weeds (Mon, 17 Apr 2017 14:13:47 GMT):
this is all part of the quality of release we have to address
weeds (Mon, 17 Apr 2017 14:14:40 GMT):
WE need to walk through config update with Elli- what Keith brought up- this is the revocation of the certificate- we are now on verge of merging config update and we have to walk through so to be able to clearly communicate this.
weeds (Mon, 17 Apr 2017 14:15:02 GMT):
Keith- we do make one config update to orderer- and the orderer broadcast that to all channels- is that correct?
weeds (Mon, 17 Apr 2017 14:15:05 GMT):
Yes
weeds (Mon, 17 Apr 2017 14:15:16 GMT):
ON receiver side- it knows how to filter out
weeds (Mon, 17 Apr 2017 14:15:40 GMT):
the channel side- the bug artem working on, but eventually config update end up in cscc and call in MSP to update- and then MSP update to validate whether it's validated or not
weeds (Mon, 17 Apr 2017 14:15:58 GMT):
And if each MSP has the variable to keep track of the certificate.
weeds (Mon, 17 Apr 2017 14:16:36 GMT):
Keith- if you have an MSP that is a member of 2 channels- and they know the CRL entry only needs to go on one channel- it's going to end up going on both.
weeds (Mon, 17 Apr 2017 14:17:02 GMT):
again- if there is a revoked entry- a crl with a revoked cert that needs to go onto the list- it may not really gon on all channels associated with that entity.
weeds (Mon, 17 Apr 2017 14:17:41 GMT):
if we do broadcast- a crl list from one participant is going to go onto all channels- where is the control?
weeds (Mon, 17 Apr 2017 14:18:11 GMT):
the certificate revoked A and B- both A and B channels needs to be aware. IT's safe to say a revoked identity related to update needs to go to all channels
weeds (Mon, 17 Apr 2017 14:18:54 GMT):
because otherwise you say this identity does not have channel C- the access policy sits on top of the MSP and is configured independently from the MSP-
weeds (Mon, 17 Apr 2017 14:19:18 GMT):
i suspect there needs to be different design where MSP - if some client has cert revoked needs to sent to subset of channels-
weeds (Mon, 17 Apr 2017 14:20:04 GMT):
Elli- they won't to control where update goes to- or they want to be automated?
weeds (Mon, 17 Apr 2017 14:20:49 GMT):
they want to control where update goes,.. but not their job to automate- ours
weeds (Mon, 17 Apr 2017 14:21:19 GMT):
we could potentially do some optimization on orderer...
weeds (Mon, 17 Apr 2017 14:21:45 GMT):
but this seems post 1.0
weeds (Mon, 17 Apr 2017 14:23:54 GMT):
Will the crl update for every certificate - is it accompanies with MSP ID? I thought MSP ID corresponding with cert is out of band knowledge isn't it? The MSP ID is out of band knowledge that the invoker of the CRL needs to know? yes... it needs to send along with the cert with the update request. I'ts a configuration request associated with that MSP item. and then the orderer take it and validates it against the application administrator policy according to branch,.. and then create config block merging the change with the previous config block and submit all together
weeds (Mon, 17 Apr 2017 14:25:41 GMT):
when CRL is updated through orderer, a new block will be created- when that arrives on the peer, the client needs to be notified and update the corresponding MSP config in the client.
weeds (Mon, 17 Apr 2017 14:27:27 GMT):
typically each organization may have their own application- if 1 participant submits crl request- the other application and other orgs have to be notified of the change. Does thte SDK not get a config block update today? yes,.. it does .. crl and other channel update has to be reflected in application layer
weeds (Mon, 17 Apr 2017 14:27:47 GMT):
MSP is just one component of config update- wouldn't it get it for free without having to do anything? yes, think so
weeds (Mon, 17 Apr 2017 14:30:04 GMT):
OU support (organizational unit support- ability to support endorsement policy with OU field) -
weeds (Mon, 17 Apr 2017 14:30:18 GMT):
As of today- neither java/node support ou-- our endosrement policy is only based on roles
weeds (Mon, 17 Apr 2017 14:30:26 GMT):
if OU needs to be supported- that's new features for SDK
weeds (Mon, 17 Apr 2017 14:31:22 GMT):
since sdk does not have to evaluate endorsement policy- if sdk has to know different structure- se treat it as a string from SDK perspective- any time we update policy- it's only change to orderer ... the msp code itself- that's a suggestion.
weeds (Mon, 17 Apr 2017 14:31:37 GMT):
could we do the OU ? it's easy to add for the sdk to pass a string through
weeds (Mon, 17 Apr 2017 14:34:45 GMT):
@jimthematrix @elli-androulaki I need you guys to post some of this more on the channel on the ou discussion
dhuseby (Mon, 17 Apr 2017 14:37:52 GMT):
Has joined the channel.
weeds (Mon, 17 Apr 2017 14:38:29 GMT):
@smithbk ^^
smithbk (Mon, 17 Apr 2017 14:38:29 GMT):
Has joined the channel.
weeds (Mon, 17 Apr 2017 14:39:28 GMT):
Vlad- I'm not sure if anyone knows we are building our executable in docker with static flag- Greg Haskins added that but this is a lot of problem with PKCS11 libraries
weeds (Mon, 17 Apr 2017 14:39:39 GMT):
I'll ping you on slack about it specifically
weeds (Mon, 17 Apr 2017 14:40:47 GMT):
I mentioned to Yacov- the PKCS11 as I wrote a script where you can generate an end to end test case of sizes of peers and orgs and generate crypto and oderer blog- and I checked under work
weeds (Mon, 17 Apr 2017 14:41:02 GMT):
please get in touch with @bmos299
weeds (Mon, 17 Apr 2017 14:41:24 GMT):
there is confusion why the CI scripts aren't used- asking Barry and Ramesh to get with Vlad
weeds (Mon, 17 Apr 2017 14:42:58 GMT):
There is a jira 1875- we need everything recorded there on some of the crypto discussion
jimthematrix (Mon, 17 Apr 2017 17:41:56 GMT):
@weeds thanks Sharon for posting the discussion. regarding the discussions on OrganizationUnit support, @elli-androulaki has posted on the #fabric-crypto channel
muralisr (Mon, 17 Apr 2017 19:51:50 GMT):
@weeds @elli-androulaki `Upgrade of chaincode- security work has to be combined with installation security work.` - we have to be careful with terminology....there are two ways to get a chaincode onto a channel (1) install and then instantiate (2) install and then upgrade. The "install" part is now chaincode packaging and is common to both to the instantiate and upgrade work flows. In other words any security work for the upgrade should be identical to the instantiate and shoukd be common code (for example, linking the installed CC with the instantiation/upgraded CC)
muralisr (Mon, 17 Apr 2017 19:54:39 GMT):
(BTW, talking of upgrade ... https://gerrit.hyperledger.org/r/#/c/7831 should be reviewed. @jiangyaoguo has completed the changes requested from previous review... I'll complete my review today)
muralisr (Mon, 17 Apr 2017 20:04:38 GMT):
will comment on https://jira.hyperledger.org/browse/FAB-3155
muralisr (Mon, 17 Apr 2017 20:13:55 GMT):
@weeds thanks so much for the above update btw. Really helps!
achraf17 (Tue, 18 Apr 2017 10:19:35 GMT):
Has joined the channel.
davidkel (Wed, 19 Apr 2017 08:54:31 GMT):
Is there a way to remove running chaincode containers/docker images/install packages from the peer that owns and generated the environment ? I am assuming not at the moment as I can't find anything but I might have missed something. Is that something that is coming in the future ?
akshay.lawange (Wed, 19 Apr 2017 11:11:09 GMT):
Has joined the channel.
akshay.lawange (Wed, 19 Apr 2017 11:15:04 GMT):
hi...
i have got this error while creating the channel
Error connecting: rpc error: code = 14 desc = grpc: RPC failed fast due to transport failure
Error: rpc error: code = 14 desc = grpc: RPC failed fast due to transport failure
any ideas?
weeds (Wed, 19 Apr 2017 13:01:29 GMT):
please note that we will have scrum call at 9:30 AM EST 1-888-426-6840 / 33682113)
weeds (Wed, 19 Apr 2017 13:27:48 GMT):
i'm going to be taking notes of the scrum team today- but please feel free to join us on the call.
weeds (Wed, 19 Apr 2017 13:33:56 GMT):
we are trying to get the host code- so starting now
weeds (Wed, 19 Apr 2017 13:36:05 GMT):
we are going to focus this call on what remains in sprint 16 (to end this friday)
weeds (Wed, 19 Apr 2017 13:36:23 GMT):
We are going one by one into the JIRa and help make call where we stand to get input from the maintainers hopefully on Monday at the hackfest
weeds (Wed, 19 Apr 2017 13:36:43 GMT):
We are going to go through each item individually... Binh tried to take a quick look at his own view of it and we'll start with that position and get input from other maintainers
weeds (Wed, 19 Apr 2017 13:36:56 GMT):
Keith we will go through the following:
weeds (Wed, 19 Apr 2017 13:37:17 GMT):
CA FAB-2836Enhance readthedocs for revocation Documentation must do
CA FAB-3010Update fabric CA README Documentation must do
CA FAB-1463 Add TLS support to fabric-ca-server's LDAP client Hardening, usability, serviceability, load, operability and stress test review
CA FAB-2597 Remove /api/v1/cfssl prefix on fabric-ca-server endpoints Hardening, usability, serviceability, load, operability and stress test review
CA FAB-2896Enhance fabric-ca-server to support multiple CAs Hardening, usability, serviceability, load, operability and stress test review
CA FAB-2110Complete BCCSP integration for of fabric-ca HSM
CA FAB-946 TCert Crypto operations should be based on BCCSP HSM defer
weeds (Wed, 19 Apr 2017 13:37:59 GMT):
From Keith- 946 should be changed- not doing for this release, it's targetted Version 1.1, but needs to be removed out of sprint bakclog- drop below the line
weeds (Wed, 19 Apr 2017 13:38:24 GMT):
2907--> that is a bug... 2909-> that's a bug... all bugs we can still work on post sprint 16 as long as not features
weeds (Wed, 19 Apr 2017 13:40:27 GMT):
2836 this is already in review; 3010- this is already in review; 1463- this is already in review; 2597- this is already in review; 2896- this is already in review; 2110- this is already in review;
weeds (Wed, 19 Apr 2017 13:40:52 GMT):
From CA perspetive- all is in review ... only thing left is the defect backlog
weeds (Wed, 19 Apr 2017 13:41:04 GMT):
Thank you Keith on planning on Sprint 16
weeds (Wed, 19 Apr 2017 13:41:08 GMT):
Jim Zhang- SDK (which is running hot)
weeds (Wed, 19 Apr 2017 13:41:25 GMT):
FAB-2914 SDK needs to support channel creation and modification
FAB-966 Create and update channel config
FAB-2816 v1.0 Documentation
FAB-2967 Sample web app
FAB-896 Events support for new nodejs sdk (es6)
FAB-3164 Add optional secret to registration request
FAB-2843 Handling networking issues
FAB-2555 queryBlock data is not fully decoded in fabric-client
FAB-3202 MSP implementation always returns true when validating identities
FAB-287 Add tests for chaincode-invoke-chaincode scenario
FAB-623 Test node sdk on zLinux
weeds (Wed, 19 Apr 2017 13:42:15 GMT):
2914- channel creation- creation does not rely on config gx - first part is merged, 2nd part is in review. updating channel is being worked on right now--> Bret just started working on this- expect early next week ETA
weeds (Wed, 19 Apr 2017 13:42:38 GMT):
This is a required capability and needs to go into next week
weeds (Wed, 19 Apr 2017 13:42:58 GMT):
966- this is same as 2914 (one should be duped to the other)- these go hand in hand
weeds (Wed, 19 Apr 2017 13:43:10 GMT):
2816- documentation is ongoing and must do and will go past 16
weeds (Wed, 19 Apr 2017 13:43:26 GMT):
2967- Ratnakar is working on it and at any point will be reviewed and merged
weeds (Wed, 19 Apr 2017 13:43:43 GMT):
3164- we have not started on this- by end of Friday this should be merged as not a big change
weeds (Wed, 19 Apr 2017 13:44:59 GMT):
2843- this may carry into next week, because we need to work on channel update first.. that blocks this. not clear when we can get into this- this one is really hard to debug. 3 layers of problems we need to work. we are trying to figure out how to handle on the TCP part of it. Gari has some ideas on this... and need some input from him @mastersingh24
weeds (Wed, 19 Apr 2017 13:45:17 GMT):
2555- the only thing left is read/write set that just became available- that is 1 day worth of work and should be done by Friday
weeds (Wed, 19 Apr 2017 13:45:31 GMT):
3202- Jim working on now and done by friday
weeds (Wed, 19 Apr 2017 13:45:36 GMT):
287- in review
weeds (Wed, 19 Apr 2017 13:46:18 GMT):
sorry mistake 287 is a to do- This is not in the sprint... it's ongoing tests for test coverage and will go past 16 as a result
weeds (Wed, 19 Apr 2017 13:46:38 GMT):
623- again ongoing tests
weeds (Wed, 19 Apr 2017 13:47:34 GMT):
896- server side was just merged earlier this morning- the client side is in review, but must be rebased,.. there is a breakage due to fabric- ca.. we have to add a property in the config (Keith said- hey jim let's talk about this.. another guy merged it this morning)
weeds (Wed, 19 Apr 2017 13:48:49 GMT):
Networking one is the biggest one that is really unknown where i marked Gari on it. all should be done by Sunday
weeds (Wed, 19 Apr 2017 13:48:52 GMT):
For JAVA SDK
weeds (Wed, 19 Apr 2017 13:49:06 GMT):
FAB-3209 Update Java example_cc for fabric 82ecbeaf
FAB-1402 V1.0 Support developer mode
FAB-648 Publish Artifacts to maven repository
FAB-3104 BLOCKED V1.0 Update Eventhub to sign register request.
FAB-2681 V1.0 BlockEvent return proposal, read write set and result
FAB-2564 V1.0 Allow for different crypto strengths for Peer Orderer and Fabric CA
weeds (Wed, 19 Apr 2017 13:49:25 GMT):
3209- done.. it is in merge for review
weeds (Wed, 19 Apr 2017 13:49:41 GMT):
the only thing about it- the last I've heard is that java chaincode is still not running, but I looked through it- but impossible to test right now
weeds (Wed, 19 Apr 2017 13:49:49 GMT):
(not an SDK issue though)
weeds (Wed, 19 Apr 2017 13:50:35 GMT):
1402- we took that out,... we can do this from go side . Luis needs to document how to do that. this needs to be put under documentation no coding to be done
weeds (Wed, 19 Apr 2017 13:51:25 GMT):
648- that's being handled by Ramesh- he's been able to do manually- he needs work from Ry jones @rjones ... we need help from Ry to do this-- Ry any help you can give us?
rjones (Wed, 19 Apr 2017 13:51:25 GMT):
Has joined the channel.
weeds (Wed, 19 Apr 2017 13:51:35 GMT):
there is no source code change
weeds (Wed, 19 Apr 2017 13:52:38 GMT):
3104- this is the code we need to do signing from event hub,.. and that was just merged 1/2 hour ago, so SDK work can start now-- what is the ETA for this? I should have it done by end of day today as it is straight forward- i have the code for it already- but I need to retest and make sure functional and revise a little
weeds (Wed, 19 Apr 2017 13:53:02 GMT):
2681- we have work in progress and taking more time than expected- i'll have it by Friday in merge
weeds (Wed, 19 Apr 2017 13:53:28 GMT):
2564- that one is really hard-- this is Sunday/monday time frame.
weeds (Wed, 19 Apr 2017 13:54:03 GMT):
do we really think 2564 is must have? Jim said there is one must have- hash algorithim on per channel basis that must done. that is the minimum requirement... maybe this is what we need to do versus the bigger piece- Jim/Rick to talk about this afterwards
weeds (Wed, 19 Apr 2017 13:55:10 GMT):
There is always a question Java HSM support... i think we do want this, but it's a chunk of work that has not been investigated.. what is the view from maintainers? @mastersingh @binh Vlad thought he might be able to do this..
weeds (Wed, 19 Apr 2017 13:56:12 GMT):
@mastersingh24
weeds (Wed, 19 Apr 2017 13:56:21 GMT):
@binhn
weeds (Wed, 19 Apr 2017 13:56:55 GMT):
Jim feels this can come in 1.1---
weeds (Wed, 19 Apr 2017 13:57:09 GMT):
but need opinion from the community
weeds (Wed, 19 Apr 2017 13:57:52 GMT):
@ry- you might want to talk to Ramesh on the one above and Jim zhang
weeds (Wed, 19 Apr 2017 13:57:57 GMT):
@rjones
rjones (Wed, 19 Apr 2017 13:57:58 GMT):
@weeds FAB-648 is under discussion. We (LF) usually publish with disconnected signatures
weeds (Wed, 19 Apr 2017 13:58:30 GMT):
3137 is HSM for Java SDK
rjones (Wed, 19 Apr 2017 13:58:56 GMT):
@weeds I was discussing FAB-648 yesterday in our release engineering meeting, so I expect progress next week
weeds (Wed, 19 Apr 2017 13:59:04 GMT):
The general things about document , bug, and test will certainly go for release candidate- improvements need to continue.
weeds (Wed, 19 Apr 2017 13:59:45 GMT):
@rameshthoomu see above
weeds (Wed, 19 Apr 2017 13:59:51 GMT):
from Ry
weeds (Wed, 19 Apr 2017 13:59:55 GMT):
Gossip TEAM
weeds (Wed, 19 Apr 2017 14:00:19 GMT):
FAB-1845 Gossip MessageStore timely expiration
- under review
weeds (Wed, 19 Apr 2017 14:00:45 GMT):
it consistes of several subtasks- one of them is in review, and one is ETA by tomorrow evening for review
weeds (Wed, 19 Apr 2017 14:01:22 GMT):
the task that is work in progress is 3114
weeds (Wed, 19 Apr 2017 14:01:29 GMT):
that will be completed tomorrow
weeds (Wed, 19 Apr 2017 14:01:40 GMT):
the only thing remaining is defects/documentation
weeds (Wed, 19 Apr 2017 14:02:01 GMT):
FAB-2980 Use protobuf for chaincode shim QueryResults to keep it language agnostic
FAB-2662 Introduce fabric-couchdb docker image default config (with security settings)
FAB-2897 Transaction index within block should start at 0, not 1
FAB-2676 Need to atomically createLedger and commit genesis block
FAB-1684Resolve ledger code TODOsdger rework
FAB-2025 Ledger serviceability - Finalize error handlng, logging, tracing for v1
FAB-1309 Ledger performance system test: LevelDB
FAB-1310 Ledger performance system test: CouchDB
FAB-3017 Finalize ledger backup/restore guidance
FAB-444 Ledger recoverability system test: I want the ledger to be in a consistent state if the peer crashes in the middle of transaction commit
FAB-198 Ledger chaincode upgrade: Ledger support for upgraded chaincode
FAB-1817Use different folders in ledger tests.
weeds (Wed, 19 Apr 2017 14:02:03 GMT):
LEDGER
weeds (Wed, 19 Apr 2017 14:02:18 GMT):
2980, 2662, 2897, 2676- all in review
weeds (Wed, 19 Apr 2017 14:02:44 GMT):
1684- in progress, cleaning up to do's in code- we don't have to finish in release but working on most important one this week and will defer the rest
weeds (Wed, 19 Apr 2017 14:03:24 GMT):
2025- this will go post sprint 16, we are waiting for Will and company to publish the logging guidelines
weeds (Wed, 19 Apr 2017 14:04:09 GMT):
all the teams need to do this-- surprised ledger is only one @claytonsims need to open jiras for all of them to do this for consistency of logging
weeds (Wed, 19 Apr 2017 14:04:22 GMT):
it take a week fo rteams to do this once the guidelines are published
weeds (Wed, 19 Apr 2017 14:05:08 GMT):
Will does mention- Murali did series of code reviews and we are bout ready to go unless Binh has further comments- need binh to go look again for anything further and we will send e-mail to hyperledger fabric list to make sure that it's available- make sure to inform and ask for feedback.
weeds (Wed, 19 Apr 2017 14:05:43 GMT):
Will in car and will get back to CR number @Clayton Sims please add here after scrum call
weeds (Wed, 19 Apr 2017 14:05:46 GMT):
1309- under review
weeds (Wed, 19 Apr 2017 14:06:04 GMT):
1310- this is for performance/system test and will continue given this is testing- this isn't really feature- this is stress testing
weeds (Wed, 19 Apr 2017 14:06:23 GMT):
3017- this is really doc and test
weeds (Wed, 19 Apr 2017 14:06:40 GMT):
not a 'feature" we are thinking
weeds (Wed, 19 Apr 2017 14:06:48 GMT):
done this week
weeds (Wed, 19 Apr 2017 14:07:05 GMT):
444- recoverability- we have done a lot of this, but there is really just testing here that we are doing
weeds (Wed, 19 Apr 2017 14:07:07 GMT):
no feature work
weeds (Wed, 19 Apr 2017 14:08:30 GMT):
198- this is our only true story- this is around supporting upgrade and validating that chaincode vesion is same when transaction executed- we are going through comments from Binh/Murali on what we need to do here. We think discussion is rapping up... Binh did have comments on chaincode upgrade on comitter side- developer from Huawei- but I need to go through this.. if Murali is on call today or on rocket chat, we may need to try to discuss this. we want to get this in and maybe enahancement later, but we need to discuss this more completely
weeds (Wed, 19 Apr 2017 14:09:23 GMT):
this one is moving slower. so this is because they are in China- so it's a little tougher.. this will go past sprint 16
weeds (Wed, 19 Apr 2017 14:09:35 GMT):
Binh said let's see what we can do on ledger side to help... but I need to have discussion with Murali and team on this
weeds (Wed, 19 Apr 2017 14:09:54 GMT):
1817- that's unit test clean up, no feature
weeds (Wed, 19 Apr 2017 14:10:27 GMT):
CONSENSUS
weeds (Wed, 19 Apr 2017 14:10:28 GMT):
FAB-1302 Add config inspection validation on chain creation transaction
FAB-2937 Fix minor issues in localconfig
FAB-3025 Update ledger defaults
FAB-1678 As an admin and developer, I need a way to inspect and create configuration transactions
FAB-2772 Lock down channel creation by consortium
weeds (Wed, 19 Apr 2017 14:10:34 GMT):
1302- in review
weeds (Wed, 19 Apr 2017 14:10:54 GMT):
2937- in review
weeds (Wed, 19 Apr 2017 14:11:26 GMT):
3025- this is not completed yet... what is ETA? very simploe, done for review by Friday
weeds (Wed, 19 Apr 2017 14:11:40 GMT):
1678- this one is in review
weeds (Wed, 19 Apr 2017 14:11:43 GMT):
2772- in review
weeds (Wed, 19 Apr 2017 14:12:02 GMT):
anything that is feature we should discuss? we are pretty much done.. we are working on harening and polishing now
weeds (Wed, 19 Apr 2017 14:12:15 GMT):
ENDORSER
weeds (Wed, 19 Apr 2017 14:12:16 GMT):
FAB-183 As an authorized user, I want to upgrade chaincode
FAB-815 Add support for endorsement of configuration transactions
FAB-2972Add query API support for Java chaincode
FAB-820 Admin GRPC API
weeds (Wed, 19 Apr 2017 14:12:21 GMT):
183 under review
weeds (Wed, 19 Apr 2017 14:12:41 GMT):
Binh you are suggesting that we delay 815-- are we ready to make that call? or anybody else on call
weeds (Wed, 19 Apr 2017 14:12:49 GMT):
@muralisr
weeds (Wed, 19 Apr 2017 14:13:26 GMT):
Binh's recommendation is to defer- because we don't have a mechanism or tool to allow members to sign a config transaction... Behave does that... it's a behave test.
weeds (Wed, 19 Apr 2017 14:13:57 GMT):
We don't have something that a customer - customer would have to do it themselves- they would have to build the tool themselves as part of admin tool. instead of embarking on tool to do this, we should defer it..
weeds (Wed, 19 Apr 2017 14:14:09 GMT):
@mastesingh24 do you agree with that @binhn
weeds (Wed, 19 Apr 2017 14:14:47 GMT):
We should also put in comments what jeff mentioned- people can use the BDD as an example to build their admin tool to do this.. because the mechanics are in place. but they have to know how to collect signatures to put in protobuf
weeds (Wed, 19 Apr 2017 14:15:30 GMT):
NODEsdk has enough API so that you get the raw protobuf bytes and you send it to anybody and they can take a sig on it and send sig and we have tool to take sig and integrate into protobuf to send in config 9from Jim zhang) that is all we need- this is discussion with Varad in how we do for our own implementation.
weeds (Wed, 19 Apr 2017 14:15:52 GMT):
The same api can be used easily for admin type applications to do the same thing- send byte array around and collect the signature
weeds (Wed, 19 Apr 2017 14:16:04 GMT):
i don't think more is needed- it won't be there for Java, but Node sdk will have it
weeds (Wed, 19 Apr 2017 14:16:18 GMT):
we should put these comments in JIRA @jeffgarratt
weeds (Wed, 19 Apr 2017 14:16:24 GMT):
in 815
weeds (Wed, 19 Apr 2017 14:17:00 GMT):
2972- add query api support for java chaincode- is this something we have to have since Murali isn't on right now?
weeds (Wed, 19 Apr 2017 14:17:23 GMT):
This is java chaincode query so we have to do this-- Binh said this would fall into similar to java support in general
weeds (Wed, 19 Apr 2017 14:17:28 GMT):
it's lagging behind the other languages
weeds (Wed, 19 Apr 2017 14:17:50 GMT):
so we need to keep working on this after sprint 16
weeds (Wed, 19 Apr 2017 14:17:59 GMT):
Maybe Luis is working on this already given Murali is out?
weeds (Wed, 19 Apr 2017 14:18:29 GMT):
Do we know if anyone is using javachaincode- we know they are using Java SDK but we don't know anyone using java chaincode
weeds (Wed, 19 Apr 2017 14:18:46 GMT):
people do want it- people are asking for it in community
weeds (Wed, 19 Apr 2017 14:18:48 GMT):
to be clear
weeds (Wed, 19 Apr 2017 14:19:10 GMT):
@claytonsims please post ETA for this one on 2972 from Luis- we feel this is important to contain, but need to checkpoint with Luis on this
weeds (Wed, 19 Apr 2017 14:19:27 GMT):
820 admin grpc APi- Binh is suggesting this to be deferred
weeds (Wed, 19 Apr 2017 14:19:36 GMT):
@mastersingh24 do you have an opinion on this?
weeds (Wed, 19 Apr 2017 14:19:48 GMT):
deferred meaning to post 1.0
weeds (Wed, 19 Apr 2017 14:21:06 GMT):
Here's the thing- we have a set of admin apis from version 0.6 and they have no security whatsoever in the structure in these apis- the apis being used by peer and node and peer login... peer node start or peer node login and you turn on different log in and so forth- from CLI- it will call into these apis.. in the new way to do this- in order to take advantage the security infrastructure in place and thought for this item and to convert this into system chaincode, but i think we do not have bandwidth to do this,.. and feel we should live with what we have now
weeds (Wed, 19 Apr 2017 14:21:30 GMT):
Aren't those APIs controlled by TLS? Oh but that just gives you TLS- i thinkwe have to document with this. Jeff agrees with this
weeds (Wed, 19 Apr 2017 14:22:02 GMT):
SECURITY
weeds (Wed, 19 Apr 2017 14:22:03 GMT):
FAB-2103 As an infrastructure developer I need to to ensure proper chain access rights of invokers in CC to CC case
FAB-2969 As a infrastructure developer I want access control at system chiancode
FAB-2400 Allow OUs to be contained in MSP description
FAB-47 Chaincode code upgrade review
FAB-3155 LCCC chaincode instantiation security checks at validation time
FAB-2091 As an infrastructure developer I need to decide on LCCC endorsement/invocation access policy and way to pass this policy to LCCC
FAB-2067 Add documentation for "good practice for use of MSPs" in MSPs document
FAB-2094 As an infrastructure developer I need to document MSP-related assumptions & best practices
FAB-637 As a fabric developer I want to document a secure ACL design for chains/ chain events
FAB-1934 CSCC Join Channel request to be authenticated with the peer local MSP admin
FAB-2362 As an infrastructure developer I need to make hashes used throughout fabric configurable
FAB-2421 CRL setup optimization
FAB-2088 As an infrastructure developer I want to be able to perform proper access control on event registration upon received requests
FAB-2989 Ensure orderers check MSP config consistency at channel genesis time
weeds (Wed, 19 Apr 2017 14:22:18 GMT):
2103- this is under review- 6279 is the CR
weeds (Wed, 19 Apr 2017 14:22:49 GMT):
This is a good time to remind everyone- for any of your CRs - we are not all making sure that any time you submit CR that you put th eJIRA item in your CR so we can see the state of it- we will stop approving if we can not map it to JIRa/CR
weeds (Wed, 19 Apr 2017 14:23:54 GMT):
2969- this is under review.. there are a couple of pending CRs related. one has been merged... but there are 2 more of Angelo that are pending listed in the JIRa
weeds (Wed, 19 Apr 2017 14:24:42 GMT):
2400- Ale's item, and we had discussion on this and he said he has a couple of hours of work left- will land in sprint 16
weeds (Wed, 19 Apr 2017 14:26:02 GMT):
47- a review item to remind us that we review the upgrade process in parallell with 3155 and 2932 by Matthias - we are essentially reviewing security aspects of chaincode upgrade within channel- Matthias found some issues around it and we created a bug in bug log that we will tackle next week.. this isn't a feature code- but really reviewing to make sure it's secure.... so really only logging as we do deep security review
weeds (Wed, 19 Apr 2017 14:26:42 GMT):
2091- in review.. we have listed CR 6421 and needs to be reviewed. most recent update few hours ago. Elli about to review after CI verifies
weeds (Wed, 19 Apr 2017 14:27:07 GMT):
2067- that is documentation- duplicate of 2094.. elli is suppose to create first version of doc tonight
weeds (Wed, 19 Apr 2017 14:27:22 GMT):
i talked with @nickgaski she will send doc to him directly so he will edit it-
weeds (Wed, 19 Apr 2017 14:27:49 GMT):
637- this is documentation work- i have not been able to progress, we have version on google doc but we have to convert and we have to update with most recent configuration mechanism and coordinate with Kostas on- so this will be next week
weeds (Wed, 19 Apr 2017 14:28:26 GMT):
1934- in review.. that is CR 7651
weeds (Wed, 19 Apr 2017 14:28:38 GMT):
2362- this one is also under review
weeds (Wed, 19 Apr 2017 14:29:21 GMT):
2421- this is not done yet, it's a crl setup optimization, we were talking about with Ale- this may be optimization for next week.. it's not a feature, it's how we do validation of identity more efficiently
weeds (Wed, 19 Apr 2017 14:29:27 GMT):
will this risk destabilize? Ale?
weeds (Wed, 19 Apr 2017 14:29:37 GMT):
it's very small changes and would effect only tests that exercise revocation
weeds (Wed, 19 Apr 2017 14:29:49 GMT):
Binh or @mastersingh24 with this?
weeds (Wed, 19 Apr 2017 14:30:59 GMT):
Binh feels that we do need to clean the plate monday next week, because monday we have hackfest and we want to talk with community that we are ready to go through test/documentation .. remaining work needs to be just quality when we with community to decide to release. we do not want too many things open at this point unless they are absolutely critical unless defects. if we can not address this- it seems this is something we should postpone to 1.1
weeds (Wed, 19 Apr 2017 14:31:15 GMT):
i suggest this two other items to defer- 3165 and 2989
weeds (Wed, 19 Apr 2017 14:31:26 GMT):
because the list of items is very long
weeds (Wed, 19 Apr 2017 14:31:54 GMT):
if we can not get this item in 2421- we should move it out.
weeds (Wed, 19 Apr 2017 14:33:02 GMT):
sorry it was 3155- Elli indicated not just a review- it's work related to validation to transactions associated with chaincode instnatiation and upgrade- I already submitted a CR for which i listed here and for this item there is a CR on endorsement phase- so it's security work we discussed with Murali- we have to get it in as there is an exposure.
weeds (Wed, 19 Apr 2017 14:33:08 GMT):
we can have CRs ready and done by tomorrow.
weeds (Wed, 19 Apr 2017 14:33:19 GMT):
(not 3165,.. 3155)
weeds (Wed, 19 Apr 2017 14:33:29 GMT):
well, if you hvae a CR submit for merge this week- i'm ok then
weeds (Wed, 19 Apr 2017 14:33:36 GMT):
as well as given security hole
weeds (Wed, 19 Apr 2017 14:34:11 GMT):
Ale? on 2931 there is another change set that matthias is working one. on 3155 there is one more changeset fromMatthias, but on my side we can get this done this week
weeds (Wed, 19 Apr 2017 14:35:17 GMT):
ale wants to push in now- but i'm trying to keep the changesets small for reviewers so need to factor that in
weeds (Wed, 19 Apr 2017 14:35:52 GMT):
if we have something that depends on Murali at this point- this is probably in jeapordy- lscc is important to secure otherwise people can modify entries associated with cc...
weeds (Wed, 19 Apr 2017 14:36:13 GMT):
Binh feels that this isn't a hole that has to be closed, @mastersingh24?
weeds (Wed, 19 Apr 2017 14:38:01 GMT):
i see a lot of risk here and number of items and number of dependencies- there are 2 days- and we have time for review... and we are also lack of maintainers given different circumstances.. so feel there is a lot of risk to sprint 16 to make some of this this weekend for merge
weeds (Wed, 19 Apr 2017 14:38:26 GMT):
@muralisr Elli might need some help here, but she did feel security work can be reviewed.
weeds (Wed, 19 Apr 2017 14:38:38 GMT):
We all think that these chainsets are important from security perspective and
weeds (Wed, 19 Apr 2017 14:39:04 GMT):
Binh's recommendation- CR that we have in for 2091 and 3155 I have not reviewed these yet, but I will go more deeply into review, but maybe we should defer the rest?
weeds (Wed, 19 Apr 2017 14:39:17 GMT):
and defer 2989 and 2421?
weeds (Wed, 19 Apr 2017 14:39:33 GMT):
2989 has been put on backlog- and this can be deferred (from Elli)
weeds (Wed, 19 Apr 2017 14:39:43 GMT):
2421- i already moved to backlog to be deferred (from Elli0
weeds (Wed, 19 Apr 2017 14:40:05 GMT):
so we can put 3155, 2091 after i review with current crs that are submitted, but remaining items, but create new jira issues and move to backlog
weeds (Wed, 19 Apr 2017 14:40:08 GMT):
Elli agreed
weeds (Wed, 19 Apr 2017 14:40:22 GMT):
is everyone ok with that? @mastersingh24 ?
weeds (Wed, 19 Apr 2017 14:41:09 GMT):
is it considered a security issue that a chaincode can modify another chaincode namespace without target chaincode endorsement policy not being checked/
weeds (Wed, 19 Apr 2017 14:41:15 GMT):
Elli feels this is a big problem
weeds (Wed, 19 Apr 2017 14:41:36 GMT):
yes- I wrote about that in fabric that we discussed in community when we implemented chaincode calling chaincode that it is something we can document
weeds (Wed, 19 Apr 2017 14:42:05 GMT):
again, there is stuff from security point of view we have to document and to make sure people understand and know what the shortcomings and our roadmap to cover them post 1.0- do not believe all will be addressed.
weeds (Wed, 19 Apr 2017 14:42:39 GMT):
deployment of 1.0 today is within the control of some set of companies- it's not an open network that any chaincode can call any chaincode
weeds (Wed, 19 Apr 2017 14:42:56 GMT):
issue that i see- i'm just an org in channel, and I will get and deploy my own chaincode by my own org.
weeds (Wed, 19 Apr 2017 14:43:06 GMT):
my peer and i can collude to write in ledger an dwill not be stopped in any way
weeds (Wed, 19 Apr 2017 14:43:33 GMT):
so a peer is supposed to be trusted by other organizations- the whole trust model is based on CFT
weeds (Wed, 19 Apr 2017 14:43:43 GMT):
because the orderer is everywhere
weeds (Wed, 19 Apr 2017 14:44:01 GMT):
let's document it and is very clear and transparent and move to solve in next post 1.0 release
weeds (Wed, 19 Apr 2017 14:44:40 GMT):
regardless of this- security check needs to take place at commitment side when it comes to evaluate a transaction- we need to validate transaction changes the state of only invoked chaincode- otherwise one client has been compromised and can mess everything up
weeds (Wed, 19 Apr 2017 14:44:55 GMT):
I could try potentially say that i invoke chaincode i never invoked and --
weeds (Wed, 19 Apr 2017 14:45:00 GMT):
what chaincode?
weeds (Wed, 19 Apr 2017 14:45:30 GMT):
i'm referring to invoking single chaincode- without endorsing policy of changing state to other chaincodes- i'm able to do so right now
weeds (Wed, 19 Apr 2017 14:45:40 GMT):
issue is bigger- endorsement policy means nothing- i create endorsement- everyone should sign
weeds (Wed, 19 Apr 2017 14:45:52 GMT):
but another chaincode on channel that requires one channel and can bypass the other endorsement policy
weeds (Wed, 19 Apr 2017 14:46:13 GMT):
who deployed the other chaindoes that someone else deployed? remember that it is the CFT- it is not byzantine and network is controlled by someone
weeds (Wed, 19 Apr 2017 14:46:31 GMT):
Let's take this offline
weeds (Wed, 19 Apr 2017 14:46:42 GMT):
we need to get Gari involved on this one please and maybe some other maintainers
weeds (Wed, 19 Apr 2017 14:46:52 GMT):
Are you trying to say the item we should defer we should not?
weeds (Wed, 19 Apr 2017 14:47:05 GMT):
this is separate thing that we might list as bug if it's important and do it next week-
weeds (Wed, 19 Apr 2017 14:47:14 GMT):
the recommended fix is easy really
weeds (Wed, 19 Apr 2017 14:47:54 GMT):
we just need to ensure in the end to have committing peer and look and ensure that at least the chaincode whose state being touched have same endorsement policy is satisified- we only allow chaincode to chaincode that is within the same trust domain- it's the easy way to fix this. it's not something we realized until this morning.
weeds (Wed, 19 Apr 2017 14:48:05 GMT):
this is conversations spawning from David/manish--
weeds (Wed, 19 Apr 2017 14:48:11 GMT):
Ale realzied this today and reported it
weeds (Wed, 19 Apr 2017 14:49:14 GMT):
problem becomes bigger if you have chaincode to chaincode and modify chaincode state. we can of course claim the trust model is we don't allow for byzantine peers, but we do consider byzantine peers- for example in gossip- a peer has to authenticate another peer from same org before state or messages,etc,.. so this is an easy fix in our opinion
weeds (Wed, 19 Apr 2017 14:49:23 GMT):
we can claim to "some" extent byzantine peers- binh asking to take off line.
weeds (Wed, 19 Apr 2017 14:49:50 GMT):
We've gone through each COMPONENT backlog
weeds (Wed, 19 Apr 2017 14:50:02 GMT):
is there any other feature not reflected in backlog?
weeds (Wed, 19 Apr 2017 14:50:07 GMT):
2862 from Jeff Garrat
weeds (Wed, 19 Apr 2017 14:50:20 GMT):
this is BDD work that Binh has been pointing to for the new config changes
weeds (Wed, 19 Apr 2017 14:50:40 GMT):
the reason is that this was created in preparation for config coming in or not
weeds (Wed, 19 Apr 2017 14:50:53 GMT):
we need to coordinate to merge these- there are 3 outstanding items
weeds (Wed, 19 Apr 2017 14:50:58 GMT):
1 is this BDD
weeds (Wed, 19 Apr 2017 14:51:11 GMT):
the other one is the SDK (can't remember the number)
weeds (Wed, 19 Apr 2017 14:51:32 GMT):
there is another item on SDK and must be done by end of this week- cant remember the number
weeds (Wed, 19 Apr 2017 14:51:46 GMT):
Jeff- should i go ahead and add sprint 16 for 2862- i am trying to contain by friday
weeds (Wed, 19 Apr 2017 14:52:14 GMT):
so- the one that jeff has and 2914 which is on node sdk we need
weeds (Wed, 19 Apr 2017 14:52:27 GMT):
and then the whole series cr's from consensus
weeds (Wed, 19 Apr 2017 14:52:36 GMT):
Jeff is working with Kostas on these- these must go in
weeds (Wed, 19 Apr 2017 14:52:56 GMT):
we just found an issue that jeff is talking with Kostas
weeds (Wed, 19 Apr 2017 14:53:14 GMT):
2914- he was doubtful done this week- claiming early next week and must be contained
weeds (Wed, 19 Apr 2017 14:53:22 GMT):
was from earlier in the call
ZionTam (Wed, 19 Apr 2017 14:53:22 GMT):
Has joined the channel.
weeds (Wed, 19 Apr 2017 14:53:59 GMT):
Brett has been working on this as top priority
weeds (Wed, 19 Apr 2017 14:55:00 GMT):
Jeff/Jim is it possible to break into phases because we don't want to break things- yes i'm trying to get orderer - i've been able to get the orderer up but sometimes fails with submission of config, but when I try to remove msp for application group- but it panics... so I'm asking kostas for his help in navigating this
weeds (Wed, 19 Apr 2017 14:55:23 GMT):
there might be bugs we found
weeds (Wed, 19 Apr 2017 14:55:36 GMT):
Jim- first step is to update proto- so is it updated? yes, it's done binh said
weeds (Wed, 19 Apr 2017 14:56:01 GMT):
we update that and so we can do the end to end which takes the binary input to create channel to make that work when you regenerate the config tx gen yaml to regenerate the channel config- that is first step
weeds (Wed, 19 Apr 2017 14:56:09 GMT):
next step is to update json create channel support and do the proper update
weeds (Wed, 19 Apr 2017 14:56:33 GMT):
what is the progress on that Jim? I need to tie out with Brett and I can find out @jimthematrix post here please what you find out
weeds (Wed, 19 Apr 2017 14:56:41 GMT):
jeff said i'm working with kostas already
weeds (Wed, 19 Apr 2017 14:56:57 GMT):
i will know by end of day where we really are
weeds (Wed, 19 Apr 2017 14:57:20 GMT):
btw, any way we know why we are skipping behave and e2e test on our CI?
weeds (Wed, 19 Apr 2017 14:57:59 GMT):
They fail with high probability... do we think this is infrastructure or a code change that cause fragility?
weeds (Wed, 19 Apr 2017 14:58:19 GMT):
packaging for instantiate has exploded- it "seems"
weeds (Wed, 19 Apr 2017 14:58:30 GMT):
in gossip before we +1 or +2 we always check end to end works
weeds (Wed, 19 Apr 2017 14:58:53 GMT):
we need to reinstate once the config is changed
weeds (Wed, 19 Apr 2017 14:59:31 GMT):
jeff said- i see intermittent failures due to timing more recently in last day or two- but i have not switched to master since working with Jason/Kostas.
weeds (Wed, 19 Apr 2017 14:59:51 GMT):
Do you want me to add sprint tag to 2862 - yes for sprint 16
weeds (Wed, 19 Apr 2017 15:00:02 GMT):
Will -- 2351 on logging
weeds (Wed, 19 Apr 2017 15:01:01 GMT):
this is one i have 2 crs and merged and reviewed up to this point- it will make it easier to set gossip/ledger to different log levels to default and allow you up and running to set components wiht one line call instead of having to lop through all the modules- it will touch a lot of files with a logger- but it will be a one character change so it uses my new method to start up the logger so we can keep track of it and update accordingly, and i will have out for review if all goes according to plan
weeds (Wed, 19 Apr 2017 15:01:23 GMT):
Binh- sooner we get merged the better provided gets past the code reviews
weeds (Wed, 19 Apr 2017 15:01:39 GMT):
put a note on the review channel on that so folks know
weeds (Wed, 19 Apr 2017 15:03:23 GMT):
on the ci- we can easily fail the verify if the maintainers want that. When they look at the PR all the information and the jenkins link show the failure. The e2e failing could be if any of the sdk's have an issue, so that is worth discussing, if one sdk is busted to we want to fail the verify. If the behave fails, we can def enable the verify the -1. Is there someone in particular that is interested? Whatever Binh want. There have been a recent run of issues and Ramesh still opens issues Jira Bugs on the failures (from Barry)--- Binh is going to reach out to Barry
mastersingh24 (Wed, 19 Apr 2017 15:54:59 GMT):
[ I thought we were deferring anything having to do with channel config/update transaction other than supporting sending the output generated by configtxgen](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=ZjhCBpGAME6TeT6ow) @weeds
mastersingh24 (Wed, 19 Apr 2017 15:57:45 GMT):
[ Is there a JIRA for this?](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=9CSrJTHHhJ7Kxooqr) @weeds
elli-androulaki (Wed, 19 Apr 2017 16:00:18 GMT):
Hi @mastersingh24 there is no jira item/bug related to this. @aso is about to create one.
mastersingh24 (Wed, 19 Apr 2017 16:01:53 GMT):
ok - figured that was the case as I could not find it. I assume the issue here is that we are not checking the endorsement policy for the called chaincode at commit time? (i.e. we only checked the endorsement policy for the calling in chaincode)?
mastersingh24 (Wed, 19 Apr 2017 16:02:01 GMT):
but I'll read the JIRA in any case
elli-androulaki (Wed, 19 Apr 2017 16:03:07 GMT):
yes
elli-androulaki (Wed, 19 Apr 2017 16:04:12 GMT):
and this goes even worse, cause from the moment an attacker is able to instantiate its chaincode (which now anyone can do) with its own endorsement policy, it can use this "gap" to push changes to other chaincodes in the chain without satisfying their endorsement policy
elli-androulaki (Wed, 19 Apr 2017 16:04:40 GMT):
@aso can give you more info on this.
aso (Wed, 19 Apr 2017 16:06:18 GMT):
basically it somehow voids the protection afforded by endorsement policies - you'd think that the namespace of a cc can only be changed with enough endorsements for *that* chaincode, but in reality, enough endorsements for *any* chaincode in the channel can write anywhere in the channel
weeds (Wed, 19 Apr 2017 16:10:18 GMT):
I asked Jim to comment on eventing security channel creation support and channel update for nodejs.sdk- i do recall that discussion gari
weeds (Wed, 19 Apr 2017 16:10:42 GMT):
or maybe it was in reference to java sdk
jimthematrix (Wed, 19 Apr 2017 16:10:56 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=o6C7w68fQyDEPE6aT) @mastersingh24 you signed off on having the node SDK but not java SDK support channel creation without relying on the configtxgen tool, @weeds and @rickr were witnessing that phone call ;-)
jimthematrix (Wed, 19 Apr 2017 16:10:56 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=o6C7w68fQyDEPE6aT) @mastersingh24 you supported the proposal to have the node SDK but not java SDK support channel creation without relying on the configtxgen tool, @weeds and @rickr were witnessing that phone call ;-)
yacovm (Wed, 19 Apr 2017 16:11:20 GMT):
In my opinion the whole CC2CC endorsement thing is a bug
yacovm (Wed, 19 Apr 2017 16:11:24 GMT):
not a feature
weeds (Wed, 19 Apr 2017 16:11:27 GMT):
yes, agree Jim- unless there is a change
weeds (Wed, 19 Apr 2017 16:11:58 GMT):
i have to go with what you/Gari and other maintainers suggest here
yacovm (Wed, 19 Apr 2017 16:12:11 GMT):
(I mean, of course- that although we have said that we do not merge features, this should be considered as an acute bug)
aso (Wed, 19 Apr 2017 16:18:38 GMT):
agreed - and it's a security bug, and so it's a vulnerability and not just a bug imho
elli-androulaki (Wed, 19 Apr 2017 16:20:05 GMT):
agreed too
binhn (Wed, 19 Apr 2017 16:25:41 GMT):
you are making some big assumptions here
1) somehow the network is open that anyone can deploy chaincodes -- this is wrong and can be locked down
2) assumed #1, would someone be such malicious and put his ID on the private member-only network?
so I do agree that it's worth fixing if we can get to it; otherwise doc it
binhn (Wed, 19 Apr 2017 16:25:41 GMT):
you are making some big assumptions here
1) somehow the network is open that anyone can deploy chaincodes -- the lscc can be locked down
2) assumed #1, would someone be such malicious and put his ID on the private member-only network?
so I do agree that it's worth fixing if we can get to it; otherwise doc it
angelnu (Wed, 19 Apr 2017 16:26:12 GMT):
Has joined the channel.
weeds (Wed, 19 Apr 2017 16:27:35 GMT):
@binhn side topic- i got this weird suggestion that we move to use the newer golang 1.7+. i don't think that was planned for version 1.0 nor was it checked in- unless I missed it- correct?
yacovm (Wed, 19 Apr 2017 16:32:08 GMT):
@binhn I think a more likely scenario is not someone who is malicious, but someone who is un-informed or doesn't understand how things work - writes a chaincode that has an endorsement policy of "anyone can do anything" - and that chaincode receives chaincode names as input or something
mastersingh24 (Wed, 19 Apr 2017 16:34:38 GMT):
[ I'm very confused here - unless I don't understand the bug. If I call a chaincode from another chaincode within the same channel and we don't validate the endorsements for each chaincode against it's policy, then we have a security hole based on the model. ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=e2nAJLRinTKQEw9ro) @binhn
aso (Wed, 19 Apr 2017 16:37:14 GMT):
that's my understanding too @mastersingh24
elli-androulaki (Wed, 19 Apr 2017 16:48:05 GMT):
So, if i understand what @binhn is saying is that if we allow chaincode deployment within a restricted set of users that are trusted (lscc locked down) then we can say we trust them to pick endorsement policies approprietly for chaincodes that invoke other chaincodes. But currently now we do not have such lock down of LCCC (with Matthias' change the only thing that we allow is the chaincode instantiation policy that is defined by its creator that could be "also faked" to be satisfied by the attacker's certificate.
The creator of course can be set accountable for its deeds due to the signature check, if the signature was checked by endorsement policy but endorsement policy can be also "accept all".
elli-androulaki (Wed, 19 Apr 2017 16:48:05 GMT):
So, if i understand what @binhn is saying is that if we allow chaincode deployment within a restricted set of users that are trusted (lscc locked down) then we can say we trust them to pick endorsement policies approprietly for chaincodes that invoke other chaincodes. But currently now we do not have such lock down of LCCC (with Matthias' change the only thing that we allow is the chaincode instantiation policy that is defined by its creator that could be "also faked" to be satisfied by the attacker's certificate). New (attacker) chaincodes can specify a convenient endorsement policy for the attacker, that can use this to modify any chaincode's state.
elli-androulaki (Wed, 19 Apr 2017 16:51:10 GMT):
W.r.t. accountability, it is true the signatures of the invoker, and of the instantiator of the chaincode would be there. And any of them upon inspection of the chain can be set accountable. But in the mean time this state changes may have triggered other changes to other chains (that use cahincode to chaincode queries) that is hard to trace...
elli-androulaki (Wed, 19 Apr 2017 16:51:45 GMT):
Maybe easier to fix it and be safe from this headache ...
binhn (Wed, 19 Apr 2017 16:58:50 GMT):
@mastersingh24 it is a security issue as discussed on the call but can be managed with a modified lscc acl
aso (Wed, 19 Apr 2017 17:07:20 GMT):
I'm not sure it can though.. sure, if you lockdown lscc you can't have just anyone pull this attack
aso (Wed, 19 Apr 2017 17:07:55 GMT):
but you can still circumvent endorsement policies
aso (Wed, 19 Apr 2017 17:08:29 GMT):
e.g. with the endorsement policy of cc1 I get to change cc2's state (bypassing cc2's endorsment policy checks)
mastersingh24 (Wed, 19 Apr 2017 17:22:59 GMT):
Here's my suggestion(s):
1) Create a JIRA item explaining the issue
2) Within the JIRA issue write up the "proper" solution
3) Assess the invasiveness of the work - e.g. will we have to change any of the underlying structures (i.e. I have not looked deeply at the code but it does not look like things are as straightforward as one might hope)
4) If structures do need to change and we don't think we can be backward compatible with the changes (e.g. parsing events, etc), the best decision is to fix it
5) If the fix could be made later without breaking things, assess the seriousness of the vulnerability and decide if this can be deferred to a patch release (e.g. 1.0.1)
SotirisAlfonsos (Wed, 19 Apr 2017 21:20:41 GMT):
Has joined the channel.
SotirisAlfonsos (Thu, 20 Apr 2017 10:37:58 GMT):
I have an issue with endorsement of transactions in the e2e example. I hope this is the right section for it. I have 4 peers( 2 in Org0, 2 in Org1 ) 1 orderer and one client. I have my chaincode installed in all of them and instantiate it on peer0 with peer chaincode instantiate -o orderer0:7050 --tls $CORE_PEER_TLS_ENABLED --cafile $GOPATH/src/github.com/hyperledger/fabric/peer/crypto/orderer/localMspConfig/cacerts/ordererOrg0.pem -C mychannel -n mycc -v 1.0 -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 -c '{"Args":["init","a", "100", "b","200"]}' -P "OR ('Org0MSP.member','Org1MSP.member')"
SotirisAlfonsos (Thu, 20 Apr 2017 10:37:58 GMT):
I have an issue with endorsement of transactions in the e2e example. I hope this is the right section for it. I have 4 peers( 2 in Org0, 2 in Org1 ) 1 orderer and one client. I have my chaincode installed in all of them and instantiate it on peer0 with
peer chaincode instantiate -o orderer0:7050 --tls $CORE_PEER_TLS_ENABLED --cafile $GOPATH/src/github.com/hyperledger/fabric/peer/crypto/orderer/localMspConfig/cacerts/ordererOrg0.pem -C mychannel -n mycc -v 1.0 -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 -c '{"Args":["init","a", "100", "b","200"]}' -P "AND ('Org0MSP.member','Org1MSP.member')"
However it never gets endorsed because of the policy. Is there a way to solve this without the SDK?
SotirisAlfonsos (Thu, 20 Apr 2017 10:37:58 GMT):
I have an issue with endorsement of transactions in the e2e example. I hope this is the right section for it. I have 4 peers( 2 in Org0, 2 in Org1 ) 1 orderer and one client. I have my chaincode installed in all of them and instantiate it on peer0 with
peer chaincode instantiate -o orderer0:7050 --tls $CORE_PEER_TLS_ENABLED --cafile $GOPATH/src/github.com/hyperledger/fabric/peer/crypto/orderer/localMspConfig/cacerts/ordererOrg0.pem -C mychannel -n mycc -v 1.0 -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 -c '{"Args":["init","a", "100", "b","200"]}' -P "AND ('Org0MSP.member','Org1MSP.member')"
However when i invoke a transaction it never gets endorsed because of the policy. Is there a way to solve this without the SDK?
mastersingh24 (Thu, 20 Apr 2017 11:32:56 GMT):
@SotirisAlfonsos - how are you invoking the transaction? Via the CLI? I think you'll have an issue doing that because your policy requires endorsement from both Org0 and Org1
mastersingh24 (Thu, 20 Apr 2017 11:32:56 GMT):
@SotirisAlfonsos - how are you invoking the transaction? Via the CLI? I think you'll have an issue doing that because your policy requires endorsement from both Org0 and Org1 and I think the CLI will only communicate with a single endorser
aso (Thu, 20 Apr 2017 11:33:05 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=xeHCHk3rYujmRxDMK) @mastersingh24 I've created a jira for this, https://jira.hyperledger.org/browse/FAB-3269
aso (Thu, 20 Apr 2017 11:33:39 GMT):
@elli-androulaki @adc @binhn @muralisr pls weigh in
SyneBlockChainTeam (Thu, 20 Apr 2017 11:36:53 GMT):
Message Attachments
SyneBlockChainTeam (Thu, 20 Apr 2017 11:36:53 GMT):
we have followed e2e_cli example for v1.0. we are able to test it with Peers 0 and 1 joined to organization Org0MSP.
We tried joining Peer3 to Org0MSP with modifications in files [configtx.yaml] and [docker-compose.yaml] files but its giving error:
root@06ad3d89fca4:/opt/gopath/src/github.com/hyperledger/fabric/peer# CORE_PEER_COMMITTER_LEDGER_ORDERER=orderer0:7050 CORE_PEER_ADDRESS=peer2:7051 peer channel join -b mychannel.block
2017-04-20 11:34:06.750 UTC [msp] GetLocalMSP -> DEBU 001 Returning existing local MSP
2017-04-20 11:34:06.750 UTC [msp] GetDefaultSigningIdentity -> DEBU 002 Obtaining default signing identity
2017-04-20 11:34:09.751 UTC [flogging] GetModuleLevel -> DEBU 003 Module 'error' logger set to 'DEBUG' log level
Error: Error getting endorser client channel: PEER_CONNECTIONERROR - Error trying to connect to local peer: grpc: timed out when dialing
/opt/gopath/src/github.com/hyperledger/fabric/peer/common/common.go:84 github.com/hyperledger/fabric/peer/common.GetEndorserClient
/opt/gopath/src/github.com/hyperledger/fabric/peer/channel/channel.go:112 github.com/hyperledger/fabric/peer/channel.InitCmdFactory
/opt/gopath/src/github.com/hyperledger/fabric/peer/channel/join.go:133 github.com/hyperledger/fabric/peer/channel.join
/opt/gopath/src/github.com/hyperledger/fabric/peer/channel/join.go:42 github.com/hyperledger/fabric/peer/channel.joinCmd.func1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:599 github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).execute
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:689 github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).ExecuteC
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:648 github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).Execute
/opt/gopath/src/github.com/hyperledger/fabric/peer/main.go:110 main.main
/opt/go/src/runtime/proc.go:192 runtime.main
/opt/go/src/runtime/asm_amd64.s:2087 runtime.goexit
Please let us know if any other file needs to be modified apart from configtx.yaml and docker-compose.yaml. Or any other reason ?
- Thanks
Message Attachments
SyneBlockChainTeam (Thu, 20 Apr 2017 11:36:53 GMT):
@mastersingh24, @muralisr
we have followed e2e_cli example for v1.0. we are able to test it with Peers 0 and 1 joined to organization Org0MSP.
We tried joining Peer3 to Org0MSP with modifications in files [configtx.yaml] and [docker-compose.yaml] files but its giving error:
root@06ad3d89fca4:/opt/gopath/src/github.com/hyperledger/fabric/peer# CORE_PEER_COMMITTER_LEDGER_ORDERER=orderer0:7050 CORE_PEER_ADDRESS=peer2:7051 peer channel join -b mychannel.block
2017-04-20 11:34:06.750 UTC [msp] GetLocalMSP -> DEBU 001 Returning existing local MSP
2017-04-20 11:34:06.750 UTC [msp] GetDefaultSigningIdentity -> DEBU 002 Obtaining default signing identity
2017-04-20 11:34:09.751 UTC [flogging] GetModuleLevel -> DEBU 003 Module 'error' logger set to 'DEBUG' log level
Error: Error getting endorser client channel: PEER_CONNECTIONERROR - Error trying to connect to local peer: grpc: timed out when dialing
/opt/gopath/src/github.com/hyperledger/fabric/peer/common/common.go:84 github.com/hyperledger/fabric/peer/common.GetEndorserClient
/opt/gopath/src/github.com/hyperledger/fabric/peer/channel/channel.go:112 github.com/hyperledger/fabric/peer/channel.InitCmdFactory
/opt/gopath/src/github.com/hyperledger/fabric/peer/channel/join.go:133 github.com/hyperledger/fabric/peer/channel.join
/opt/gopath/src/github.com/hyperledger/fabric/peer/channel/join.go:42 github.com/hyperledger/fabric/peer/channel.joinCmd.func1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:599 github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).execute
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:689 github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).ExecuteC
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:648 github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).Execute
/opt/gopath/src/github.com/hyperledger/fabric/peer/main.go:110 main.main
/opt/go/src/runtime/proc.go:192 runtime.main
/opt/go/src/runtime/asm_amd64.s:2087 runtime.goexit
Please let us know if any other file needs to be modified apart from configtx.yaml and docker-compose.yaml. Or any other reason ?
- Thanks
Message Attachments
SyneBlockChainTeam (Thu, 20 Apr 2017 11:36:58 GMT):
we have followed e2e_cli example for v1.0. we are able to test it with Peers 0 and 1 joined to organization Org0MSP.
We tried joining Peer3 to Org0MSP with modifications in files [configtx.yaml] and [docker-compose.yaml] files but its giving error:
root@06ad3d89fca4:/opt/gopath/src/github.com/hyperledger/fabric/peer# CORE_PEER_COMMITTER_LEDGER_ORDERER=orderer0:7050 CORE_PEER_ADDRESS=peer2:7051 peer channel join -b mychannel.block
2017-04-20 11:34:06.750 UTC [msp] GetLocalMSP -> DEBU 001 Returning existing local MSP
2017-04-20 11:34:06.750 UTC [msp] GetDefaultSigningIdentity -> DEBU 002 Obtaining default signing identity
2017-04-20 11:34:09.751 UTC [flogging] GetModuleLevel -> DEBU 003 Module 'error' logger set to 'DEBUG' log level
Error: Error getting endorser client channel: PEER_CONNECTIONERROR - Error trying to connect to local peer: grpc: timed out when dialing
/opt/gopath/src/github.com/hyperledger/fabric/peer/common/common.go:84 github.com/hyperledger/fabric/peer/common.GetEndorserClient
/opt/gopath/src/github.com/hyperledger/fabric/peer/channel/channel.go:112 github.com/hyperledger/fabric/peer/channel.InitCmdFactory
/opt/gopath/src/github.com/hyperledger/fabric/peer/channel/join.go:133 github.com/hyperledger/fabric/peer/channel.join
/opt/gopath/src/github.com/hyperledger/fabric/peer/channel/join.go:42 github.com/hyperledger/fabric/peer/channel.joinCmd.func1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:599 github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).execute
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:689 github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).ExecuteC
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:648 github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).Execute
/opt/gopath/src/github.com/hyperledger/fabric/peer/main.go:110 main.main
/opt/go/src/runtime/proc.go:192 runtime.main
/opt/go/src/runtime/asm_amd64.s:2087 runtime.goexit
Please let us know if any other file needs to be modified apart from configtx.yaml and docker-compose.yaml. Or any other reason ?
- Thanks
SotirisAlfonsos (Thu, 20 Apr 2017 11:45:26 GMT):
Thank you for the clarification @mastersingh24 . Yes i am doing it via the client, sending the invoke command to one peer, peer0 lets say. I thought maybe there was a way to send the same chaincode invoke to different peers. I will install the sdk then, i think it will solve my problem.
mastersingh24 (Thu, 20 Apr 2017 11:47:48 GMT):
yeah - I think that will be easiest because the transaction which gets sent to the orderer actually is a wrapper around the endorsement returned from the peer. The SDK handles this case but the CLI will not
rahulhegde (Thu, 20 Apr 2017 13:18:28 GMT):
@Ratnakar @rameshthoomu @bmos299 @mastersingh24 @wlahti @muralisr
Hello - I am getting following error during instantiation using PEER CLI
```
054FDFA2DE49ECF780F1A9551CFDE73F16FDDFF56067539731427245CB004FFF
Error: Error endorsing chaincode: rpc error: code = 2 desc = Transaction returned with failure: Failed extracting proposal fields. [Could not extract the channel header from the proposal: UnmarshalChannelHeader failed, err proto: bad wiretype for field common.ChannelHeader.Type: got wiretype 2, want 0]
Usage:
peer chaincode instantiate [flags]
Global Flags:
--cafile string Path to file containing PEM-encoded trusted certificate(s) for the ordering endpoint
-C, --chainID string The chain on which this command should be executed (default "testchainid")
```
Verified using peer -v; and the CLI and Peer are on the same version.
rahulhegde (Thu, 20 Apr 2017 13:18:28 GMT):
@Ratnakar @rameshthoomu @bmos299 @mastersingh24 @wlahti @muralisr
Hello - I am getting following error during instantiation using PEER CLI
```
054FDFA2DE49ECF780F1A9551CFDE73F16FDDFF56067539731427245CB004FFF
Error: Error endorsing chaincode: rpc error: code = 2 desc = Transaction returned with failure: Failed extracting proposal fields. [Could not extract the channel header from the proposal: UnmarshalChannelHeader failed, err proto: bad wiretype for field common.ChannelHeader.Type: got wiretype 2, want 0]
Usage:
peer chaincode instantiate [flags]
Global Flags:
--cafile string Path to file containing PEM-encoded trusted certificate(s) for the ordering endpoint
-C, --chainID string The chain on which this command should be executed (default "testchainid")
```
Verified using peer -v; and the CLI and Peer are on the same version.
Peer Logs
rahulhegde (Thu, 20 Apr 2017 13:18:28 GMT):
@Ratnakar @rameshthoomu @bmos299 @mastersingh24 @wlahti @muralisr
Hello - I am getting following error during instantiation using PEER CLI
```
054FDFA2DE49ECF780F1A9551CFDE73F16FDDFF56067539731427245CB004FFF
Error: Error endorsing chaincode: rpc error: code = 2 desc = Transaction returned with failure: Failed extracting proposal fields. [Could not extract the channel header from the proposal: UnmarshalChannelHeader failed, err proto: bad wiretype for field common.ChannelHeader.Type: got wiretype 2, want 0]
Usage:
peer chaincode instantiate [flags]
Global Flags:
--cafile string Path to file containing PEM-encoded trusted certificate(s) for the ordering endpoint
-C, --chainID string The chain on which this command should be executed (default "testchainid")
```
Verified using peer -v; and the CLI and Peer are on the same version.
Peer Logs
```
^[[36m2017-04-20 06:39:56.692 UTC [chaincode] processStream -> DEBU 3416^[[0m [d207681d]Received message ERROR from shim
^[[36m2017-04-20 06:39:56.692 UTC [cauthdsl] func2 -> DEBU 3417^[[0m Principal evaluation fails: (&{%!s(int32=0)})%!(EXTRA []bool=[false])
^[[31m2017-04-20 06:39:56.692 UTC [chaincode] processStream -> ERRO 3418^[[0m Got error: Failed extracting proposal fields. [Could not extract the channel header from the proposal: UnmarshalChannelHeader failed, err proto: bad wiretype for field common.ChannelHeader.Type: got wiretype 2, want 0]
^[[36m2017-04-20 06:39:56.692 UTC [cauthdsl] func1 -> DEBU 3419^[[0m Gate evaluation fails: (&{n:1 policies:
rmohta (Thu, 20 Apr 2017 13:28:33 GMT):
Has joined the channel.
rmohta (Thu, 20 Apr 2017 13:31:07 GMT):
In Fabric 1.0, do we need to have Root Peer (Peer 0) along with client Peer (Peer 1)?
rmohta (Thu, 20 Apr 2017 14:56:05 GMT):
Is there any reference as to, what do *peer chaincode package* do?
muralisr (Thu, 20 Apr 2017 14:57:17 GMT):
@rmohta there's some doc in docs/source/cc-packaging-and-signing.rst
rmohta (Thu, 20 Apr 2017 17:09:38 GMT):
Thank You @muralisr. One more question
rmohta (Thu, 20 Apr 2017 17:10:08 GMT):
If we use CouchDB with Peer, does Peer store state and both ledger database in CouchDB?
ankursam (Thu, 20 Apr 2017 18:20:09 GMT):
Has joined the channel.
toddinpal (Thu, 20 Apr 2017 21:11:17 GMT):
@rmohta As far as I know, there is only the file store for the ledger.
mastersingh24 (Thu, 20 Apr 2017 21:38:34 GMT):
@rmohta -
`peer chaincode package` - TLDR - it packages up you chaincode for installation on peers. You can find details here - http://hyperledger-fabric.readthedocs.io/en/latest/cc-packaging-and-signing.html?highlight=package
the blocks are stored in a file-based ledger and the current value of any key is stored in either leveldb or couchdb.
troyronda (Thu, 20 Apr 2017 21:51:19 GMT):
Docker open source -> Moby: https://github.com/moby/moby/pull/32691
akshay.lawange (Fri, 21 Apr 2017 12:30:25 GMT):
has anyone come across this one..
akshay.lawange (Fri, 21 Apr 2017 12:30:26 GMT):
Error: Error endorsing chaincode: rpc error: code = 2 desc = Error starting container: Failed to generate platform-specific docker build: Error returned from build: 1 "can't load package: package github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02: no buildable Go source files in /chaincode/input/src/github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02
simsc (Fri, 21 Apr 2017 13:03:57 GMT):
Here's is call in number for Peer scrum starting at 9:30. All are welcome
simsc (Fri, 21 Apr 2017 13:03:59 GMT):
peer scrum (1-888-426-6840 / 33682113)
simsc (Fri, 21 Apr 2017 13:05:15 GMT):
here are some dashboards we will look at
simsc (Fri, 21 Apr 2017 13:05:16 GMT):
https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10404
simsc (Fri, 21 Apr 2017 13:05:35 GMT):
https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10104
simsc (Fri, 21 Apr 2017 13:06:27 GMT):
https://jenkins.hyperledger.org/view/fabric/job/fabric-merge-x86_64/1549/cobertura/
rmohta (Fri, 21 Apr 2017 14:06:00 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=xHjwsZiF2gYEDfBzo) @mastersingh24 I don't see that option when I do *peer chaincode package --help*. Community docker image not updated maybe?
simsc (Fri, 21 Apr 2017 14:38:04 GMT):
summary of scrum for those who could not attend. all comments welcome
simsc (Fri, 21 Apr 2017 14:38:29 GMT):
Dave from Composer team raised Jira 3301 as a blocker. Assigned to Jim Z
simsc (Fri, 21 Apr 2017 14:39:30 GMT):
CI is failing - needs to be fixed, impacting everyone. Enyeart pinging Ramesh
simsc (Fri, 21 Apr 2017 14:40:07 GMT):
reviewed Chris Ferris dashboard for defect backlog Left column, Second row
simsc (Fri, 21 Apr 2017 14:41:44 GMT):
reviewed Claytons sprint 16 dashboard. stepped through anything not in review or not done
simsc (Fri, 21 Apr 2017 14:44:26 GMT):
Node SDK - 1293 test item, 2555, sprint 16, 2816 is doc, 2843 2914 sprint 17, 2967 is close and is a sample, sprint 16
simsc (Fri, 21 Apr 2017 14:45:41 GMT):
Endorser 183 is murali's, 1348 done, 2942 3218 sprint 17 followup with luis
simsc (Fri, 21 Apr 2017 14:46:29 GMT):
Ledger 449, 1310, 1871 all test, 2025 sprint 17 this is logging we agreed all components need to do this and will continue to next week
simsc (Fri, 21 Apr 2017 14:47:26 GMT):
Java SDK - 648 maven needs ramesh, 1402 no feature work only doc, 2564 move to v1.1
simsc (Fri, 21 Apr 2017 14:47:51 GMT):
Java SDK - 2681 eta monday can't defer
simsc (Fri, 21 Apr 2017 14:48:30 GMT):
Wills logging CR - sprint 16
simsc (Fri, 21 Apr 2017 14:48:49 GMT):
Concesnus 3025 need to follow up with kostats
simsc (Fri, 21 Apr 2017 14:49:47 GMT):
Crypto - 2996 defer to v1.1
simsc (Fri, 21 Apr 2017 14:49:57 GMT):
Quality - jeff sprint 16
simsc (Fri, 21 Apr 2017 14:50:32 GMT):
Quality 2862 - jeff sprint 16
muralisr (Fri, 21 Apr 2017 14:55:56 GMT):
@simsc `CI is failing` - I see chaincode UT times creeping up again from 300 too 900+ and some UTs fail with timeout
muralisr (Fri, 21 Apr 2017 14:55:56 GMT):
not sure if its consistent
muralisr (Fri, 21 Apr 2017 15:01:15 GMT):
@simsc `Endorser 183 is murali's` I will work with @jiangyaoguo to complete remaining tasks
simsc (Fri, 21 Apr 2017 15:06:59 GMT):
also discussed Jenkins UT coverage report - fabric core
simsc (Fri, 21 Apr 2017 15:07:14 GMT):
bccsp/util - angelo will look to increase
simsc (Fri, 21 Apr 2017 15:07:23 GMT):
config/msp - ali to help increase
simsc (Fri, 21 Apr 2017 15:08:07 GMT):
txvalidator - allí to help
simsc (Fri, 21 Apr 2017 15:09:03 GMT):
discussed does it make sense to report coverage on test items such as configtxgen tool, bddtests, test utils etc
simsc (Fri, 21 Apr 2017 15:09:55 GMT):
at one time bdds could be run and generate cumulative results which demonstrate much higher coverage
wlahti (Fri, 21 Apr 2017 16:06:13 GMT):
Hi all, we've had a number of people expressing a desire to suppress certain log modules within their peer docker containers. For environments similar to the one created using `./network_setup.sh up`, I recommend the following:
1. connect to the CLI container `docker exec -it cli bash`
2. run the setlevel command with the CORE_PEER_ADDRESS environment variable provided to specify which peer you'd like to run the command against and the module name you would like to update: for example, `CORE_PEER_ADDRESS=peer1:7051 peer logging setlevel gossip/discovery#peer1:7051 warning` (making sure to update the peer address in the environment variable (and, for gossip-related modules, in the module name as well) to the value for your environment). Note: the key for now is to specify the module name exactly as it appears in your logs. Very soon, updating the log levels via regular expressions will be enabled and it will no longer take a long series of commands to dynamically update levels.
wlahti (Fri, 21 Apr 2017 16:06:13 GMT):
Hi all, I've noticed a number of people expressing a desire to suppress certain log modules within their peer docker containers. For environments similar to the one created using `./network_setup.sh up`, I recommend the following:
1. connect to the CLI container `docker exec -it cli bash`
2. run the setlevel command with the CORE_PEER_ADDRESS environment variable provided to specify which peer you'd like to run the command against and the module name you would like to update: for example, `CORE_PEER_ADDRESS=peer1:7051 peer logging setlevel gossip/discovery#peer1:7051 warning` (making sure to update the peer address in the environment variable (and, for gossip-related modules, in the module name as well) to the value for your environment). Note: the key for now is to specify the module name exactly as it appears in your logs. Very soon, updating the log levels via regular expressions will be enabled and it will no longer take a long series of commands to dynamically update levels.
simsc (Fri, 21 Apr 2017 18:13:44 GMT):
Follow up from Luis's Jira items today's scrum
simsc (Fri, 21 Apr 2017 18:13:54 GMT):
2942 target Saturday
simsc (Fri, 21 Apr 2017 18:14:07 GMT):
3218 moved to review just now
rmohta (Fri, 21 Apr 2017 21:33:10 GMT):
Does anyone know what's the exact command to run for upgrading chaincode? I tried `peer chaincode upgrade -n marbles -p github.com/marbles -v 2.0 -o orderer0:7050` and it threw me an error as ```
rmohta (Fri, 21 Apr 2017 21:33:10 GMT):
Does anyone know what's the exact command to run for upgrading chaincode? I tried `peer chaincode upgrade -n marbles -p github.com/marbles -v 2.0 -o orderer0:7050` and it threw me an error as below. Is there any extra argument to passed for upgrade that we *don't* pass for install?
rmohta (Fri, 21 Apr 2017 21:33:27 GMT):
```2017-04-21 21:05:38.251 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 004 Using default escc
2017-04-21 21:05:38.251 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 005 Using default vscc
Error: Empty JSON chaincode parameters must contain the following keys: 'Args' or 'Function' and 'Args'
Usage:
peer chaincode upgrade [flags]
```
muralisr (Fri, 21 Apr 2017 23:12:29 GMT):
@rmohta "upgrade" is equivalent to "instantiate". First you "install" version 2.0 and then you upgrade a previously instantiated version 1.0 on a channel to 2.0. So just like "instantiate", "upgrade" command takes a -c parameter which will be used to call the Init method of the 2.0 version of the chaincode on that channel. It gives you the opportunuity to do any upgrade tasks
muralisr (Fri, 21 Apr 2017 23:13:32 GMT):
@rmohta soon there shoukd be a doc on that
dave.enyeart (Sun, 23 Apr 2017 14:32:26 GMT):
@wlahti @muralisr Before this weekend, when I ran `go test -v` for verbose mode, it would dump out all the debug statements from the code during the test. This was very helpful for test development and debug. Now when I run `go test -v` it does not print out the debug. Is this related to the recent logging enhancements? How to get debug during test execution now?
yacovm (Sun, 23 Apr 2017 16:39:07 GMT):
@dave.enyeart now I think the default level is INFO
yacovm (Sun, 23 Apr 2017 16:39:43 GMT):
did you try to set the logging to debug with the `CORE_LOGGING_LEVEL=DEBUG` ?
dave.enyeart (Sun, 23 Apr 2017 16:39:58 GMT):
will try
dave.enyeart (Sun, 23 Apr 2017 16:41:22 GMT):
still dont see it with `CORE_LOGGING_LEVEL=DEBUG go test -v`
yacovm (Sun, 23 Apr 2017 16:43:33 GMT):
oh well, seems like it doesn't work for UTs
yacovm (Sun, 23 Apr 2017 16:43:57 GMT):
I think it's because the peer's initialization path does something that UTs don't
yacovm (Sun, 23 Apr 2017 16:43:57 GMT):
I think it's because the peer's initialization path does something with flogging that UTs don't
dave.enyeart (Sun, 23 Apr 2017 16:47:44 GMT):
ledger tests typically load core.yaml into viper, so i also tried changing default from info to debug in core.yaml. but still no luck. I'm not sure how go testing works with loggers. @wlahti could you investigate further?
dave.enyeart (Sun, 23 Apr 2017 16:47:44 GMT):
ledger tests typically load core.yaml into viper, so i also tried changing default from `info` to `debug` in core.yaml. but still no luck. I'm not sure how go testing works with loggers. @wlahti could you investigate further?
rmohta (Mon, 24 Apr 2017 14:17:03 GMT):
Do we have any document which lists how to generate certificate for the Peer and Orderer and what goes into the localMSPConfig folder?
smallant (Mon, 24 Apr 2017 17:44:57 GMT):
Has joined the channel.
kelly_ (Mon, 24 Apr 2017 19:46:13 GMT):
Has joined the channel.
padmaja (Tue, 25 Apr 2017 10:15:46 GMT):
Has joined the channel.
dbshah (Tue, 25 Apr 2017 13:18:31 GMT):
Any ideas on when do we see this error
```2017-04-25 13:12:23.371 UTC [blocksProvider] DeliverBlocks -> ERRO 03e Error verifying block with sequnce number 1, due to Failed to reach implicit threshold of 1 sub-policies, required 1 remaining
2017-04-25 13:12:23.371 UTC [blocksProvider] DeliverBlocks -> ERRO 03f Error verifying block with sequnce number 2, due to Failed to reach implicit threshold of 1 sub-policies, required 1 remaining
```
dbshah (Tue, 25 Apr 2017 13:19:57 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=ESdQcyLK9T6QqWbfY) @rmohta there is a tool to generate certs https://github.com/hyperledger/fabric/tree/master/common/tools/cryptogen, it that helps
mrshah-ibm (Tue, 25 Apr 2017 13:21:26 GMT):
Has joined the channel.
rmohta (Tue, 25 Apr 2017 15:28:21 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=Gd4m4HWRq6r4SNQMY) @dbshah This helps. Thank You. Dumb question - do the certs generated by cryptogen signed by fabric-ca certs? Or that's not required?
dbshah (Tue, 25 Apr 2017 15:29:48 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=5Bv8yeHt8vc9NabR8) @rmohta Nope they are not signed by fabric-ca, this certs are self-signed and generated using openssl library i assume.
dbshah (Tue, 25 Apr 2017 15:30:42 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=sfsyHGKfyTv8ZNBf2) @dbshah This was an error on my end, this happened when i created the same channel on two orderers before they could communicate and thus network was in bad shape
rmohta (Tue, 25 Apr 2017 15:31:33 GMT):
cool thank you ^^
rmohta (Wed, 26 Apr 2017 03:22:44 GMT):
@muralisr @here Can someone help me understand configtx.yaml a bit more? Use of Application section. Location of MSPDir in the yaml file.
rangak (Wed, 26 Apr 2017 04:08:05 GMT):
Has joined the channel.
manish-sethi (Wed, 26 Apr 2017 06:59:53 GMT):
Has joined the channel.
weeds (Wed, 26 Apr 2017 13:32:31 GMT):
we are going to start scrum at 9:30 EST- 1-888-426-6840 / 33682113
weeds (Wed, 26 Apr 2017 13:32:38 GMT):
I will take notes here based on discussion
weeds (Wed, 26 Apr 2017 13:35:15 GMT):
Composer is a project on top of fabric, so we want to ask if they have any input on Version 1.0 fabric at this point- any defects?
weeds (Wed, 26 Apr 2017 13:35:38 GMT):
We can't seem to use a different directory from .hc.key.store JIRA 2940
weeds (Wed, 26 Apr 2017 13:35:51 GMT):
Caroline Daughtry is working-
weeds (Wed, 26 Apr 2017 13:36:14 GMT):
Jim indicated talking to users about this- but the API is difficult... so design needs to be improved. will add details in the JIRA
weeds (Wed, 26 Apr 2017 13:36:48 GMT):
The other is the large message when he responds in send proposal- JIRA 3301
weeds (Wed, 26 Apr 2017 13:37:30 GMT):
Let's look at Sprint 16 dashboard- we want to get to feature complete.
weeds (Wed, 26 Apr 2017 13:37:48 GMT):
https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10404
weeds (Wed, 26 Apr 2017 13:38:04 GMT):
we were at 8 yesterday and we have 10
weeds (Wed, 26 Apr 2017 13:38:10 GMT):
so let's setp through the details
weeds (Wed, 26 Apr 2017 13:38:30 GMT):
SDK node-
weeds (Wed, 26 Apr 2017 13:39:12 GMT):
2843- networking issues- the difficulty is hard to reproduce-- you have to have some weird networking devices in between...
weeds (Wed, 26 Apr 2017 13:39:42 GMT):
Barry's team is trying to set up multihost environment-- we need to somehow insert Firewall-
weeds (Wed, 26 Apr 2017 13:40:15 GMT):
we need to beef this up with GRPC and TCP- but it's very hard to reproduce and verify the problem
weeds (Wed, 26 Apr 2017 13:40:34 GMT):
One of the Users in community- Gari was putting in enhancement to see if it takes care of the issue since that's the most reliable environment.
weeds (Wed, 26 Apr 2017 13:40:58 GMT):
@mastersingh24 need to ask when you will be able to work on this particular aspect
weeds (Wed, 26 Apr 2017 13:41:22 GMT):
2967- Sample app- the code is uploaded,,.. it's a list of 7 CRs
weeds (Wed, 26 Apr 2017 13:41:43 GMT):
i've been reviewing them along the way before they are uploaded- i think they can merge them by end of today
weeds (Wed, 26 Apr 2017 13:41:53 GMT):
this is all test code
weeds (Wed, 26 Apr 2017 13:42:50 GMT):
3164- add optional secret registration request-- this got moved from done to to do... there is no comment why this was done.. but Jim Zhang said he checked in code and merged-
weeds (Wed, 26 Apr 2017 13:43:14 GMT):
we believe Dong Pan made some error in Jira accidentally- no comments were added.
weeds (Wed, 26 Apr 2017 13:43:18 GMT):
we are moving back to done
weeds (Wed, 26 Apr 2017 13:43:26 GMT):
SDK Node-
weeds (Wed, 26 Apr 2017 13:43:46 GMT):
SDK JAva-
weeds (Wed, 26 Apr 2017 13:44:15 GMT):
6480 publish artifacts to maven repository- @rjones has not given any updates yet .. what is the update for this?
weeds (Wed, 26 Apr 2017 13:44:26 GMT):
Any outlook Ry?
weeds (Wed, 26 Apr 2017 13:44:46 GMT):
The team is really dependent on this.
weeds (Wed, 26 Apr 2017 13:45:17 GMT):
1402- V1 support developer mode- this is documentation... we think this is not feature work since only doc, moving out of sprint 16 dashboard.
weeds (Wed, 26 Apr 2017 13:46:23 GMT):
Jim indicated there are subtasks of feature stories in fabric-- so fabric enhanced access control policies- until SDK are done- it's not done
weeds (Wed, 26 Apr 2017 13:46:44 GMT):
i created subtasks to those stories- Rick has two of them across 5 different API calls --> When do you think that will get done per Rick?
weeds (Wed, 26 Apr 2017 13:47:05 GMT):
I have a real problem that i can't merge the private key with the utilitiy- it's probably not going to be until Friday.
weeds (Wed, 26 Apr 2017 13:47:18 GMT):
We need to find right api with the light library
weeds (Wed, 26 Apr 2017 13:50:01 GMT):
Fabric_CA 2597 it's a small piece of work- changing of api prefix urls.. if this changeset was merged- it would allow/ with no prefix and / api/v1, but it would not support all 3... or it could support all 3. with cffsl. What i'm trying to not break anyone, but to go ahead and get in support so all those calling fabric /ca can call the right one,.. and then i can remove the urls that we no longer support. What I can do-- i pushed this over a week ago- i will update merge set to support all three.. no way it could break anyone. it's already merged... so need to move to done
weeds (Wed, 26 Apr 2017 13:50:26 GMT):
Endorser-- 183
weeds (Wed, 26 Apr 2017 13:51:41 GMT):
seems like this is within a day of being submitted
weeds (Wed, 26 Apr 2017 13:53:22 GMT):
Fabric ledger- 3398-- this is really quality
weeds (Wed, 26 Apr 2017 13:53:29 GMT):
so not a "feature"
weeds (Wed, 26 Apr 2017 13:54:00 GMT):
Fabric- peer- fine tune log levels 2351-- is there anything left for this or just code enabling to use code?
weeds (Wed, 26 Apr 2017 13:54:22 GMT):
Will everything is in and enabled now. but I'm going to go through and do a couple to set ledger at peer startup and Yacov had request for couple of ones-- everything there and working
weeds (Wed, 26 Apr 2017 13:54:35 GMT):
It's all merged
weeds (Wed, 26 Apr 2017 13:54:45 GMT):
we just need to set different components
weeds (Wed, 26 Apr 2017 13:56:25 GMT):
this should be moved to quality
weeds (Wed, 26 Apr 2017 13:56:52 GMT):
2862 from Jeff Garrat-
weeds (Wed, 26 Apr 2017 13:57:08 GMT):
This is Kostas'- he's doing a rebase
weeds (Wed, 26 Apr 2017 13:57:19 GMT):
it was fixed late last night and it's done and green in CI and +2
weeds (Wed, 26 Apr 2017 13:57:32 GMT):
this should go into review.. but we have a document that we have to get done first
weeds (Wed, 26 Apr 2017 13:57:37 GMT):
before it can get in
weeds (Wed, 26 Apr 2017 13:58:00 GMT):
the document is completely orthogonal- it does not even account for Greg's config changes
weeds (Wed, 26 Apr 2017 13:58:32 GMT):
2 things- if you look at Nick's documentation last night- he refers to environment variable path we use
weeds (Wed, 26 Apr 2017 13:58:37 GMT):
we only use fabric_ che now
weeds (Wed, 26 Apr 2017 13:59:00 GMT):
This release tar file that we are putting out there and instructing users to download using curl- will also have code that is not using consortium and outdated with configtx yaml files
weeds (Wed, 26 Apr 2017 13:59:23 GMT):
we can merge this without the document, yes? We have to give folks out there document that belongs to the old code, so when they go to getting started it will work with them with the alpha level code.
weeds (Wed, 26 Apr 2017 13:59:35 GMT):
We can merge consortium and documentation later on-
weeds (Wed, 26 Apr 2017 14:00:13 GMT):
Getting started doc in code tell people to clone the repo and build from the repo. so if we merge the new stuff and they try to clone and build it would not work- meaning that the config tx would not work- so we need to divert them from cloning first
weeds (Wed, 26 Apr 2017 14:01:05 GMT):
@nickgaski Where are we in checking in the documentation? what is the ETA? we would like in 1/2 hour.
weeds (Wed, 26 Apr 2017 14:03:05 GMT):
Are there ANY OTHER FEATURES to be added?
weeds (Wed, 26 Apr 2017 14:03:19 GMT):
There are a few CR's that are pending in review since a week ago-- they have been reviewed and there are some changes.
weeds (Wed, 26 Apr 2017 14:03:28 GMT):
they are ready to be merged-
weeds (Wed, 26 Apr 2017 14:05:07 GMT):
Jim Zhang- indicated he missed coding setting of transient data in NODE SDK---> we'll get it done by today
weeds (Wed, 26 Apr 2017 14:05:29 GMT):
Besides HSM - all SDK stuff will be done
weeds (Wed, 26 Apr 2017 14:05:37 GMT):
HSM for Java specifically
weeds (Wed, 26 Apr 2017 14:05:40 GMT):
by Monday
weeds (Wed, 26 Apr 2017 14:06:06 GMT):
Do we have agreement whether we want node.sdk to support channel update? I thought we needed this- but the merge was holding on node sdk to support that
weeds (Wed, 26 Apr 2017 14:06:45 GMT):
yes, Binh feels we need to support that - i thought you and @mastersingh24 had discussion- maybe we just "push" the data through- the app would set up the config update and give it to the SDK and the SDK would "push it through" , and we would not provide specific api level at sdk level.
weeds (Wed, 26 Apr 2017 14:07:07 GMT):
we are buildling on top of JSON support-- and now for update- you have to use external tool, and I'm confused by this.
weeds (Wed, 26 Apr 2017 14:07:29 GMT):
@jimthematrix needs to discuss with @mastersingh24 on this topic as there is confusion
weeds (Wed, 26 Apr 2017 14:08:11 GMT):
The api we have is a level 1 api, and if we start adding more things and we discover there are changes... we should keep it minimum and not have any dependencies. Certain apis we allow users to use JSON and some we are stating you are on your own- so there are some inconsistencies
weeds (Wed, 26 Apr 2017 14:08:27 GMT):
We are living with inconsistency so we don't overexpose our APIs
weeds (Wed, 26 Apr 2017 14:08:58 GMT):
We will adjust the CR to do this
weeds (Wed, 26 Apr 2017 14:09:19 GMT):
if we have everything coded already- then might as well do the appropriate action, but if there is still area that we need to do- maybe we should defer?
weeds (Wed, 26 Apr 2017 14:09:41 GMT):
That CR is the first step,.. and there is a separate CR to support the consoritum- so it is not ready to go yet.
weeds (Wed, 26 Apr 2017 14:09:51 GMT):
Any other component leads that need to raise something that is not a feature?
weeds (Wed, 26 Apr 2017 14:10:55 GMT):
UNIT TEST- We are tracking this every day- I'm taking snapshots every day and tracking progress- since Monday we only went from 61% to 62%.
weeds (Wed, 26 Apr 2017 14:11:18 GMT):
We need to make much more progress here... and scorecard by squad showing the coverage.
weeds (Wed, 26 Apr 2017 14:12:03 GMT):
There is general agreement for test files- like bdd files- those can be removed from this list
weeds (Wed, 26 Apr 2017 14:12:30 GMT):
The protos- the pd.go files can be exlcuded but any other files must have full test coverage
weeds (Wed, 26 Apr 2017 14:14:46 GMT):
I want to move the tests into test directory- we need to get our code organized properly- test code does not need to be in prod code
weeds (Wed, 26 Apr 2017 14:14:56 GMT):
from CI reporting point of view- we can then exclude the directories
weeds (Wed, 26 Apr 2017 14:15:06 GMT):
i'm asking the exclusion of bdd tests.
weeds (Wed, 26 Apr 2017 14:16:12 GMT):
We have too many directories- we have a package that has one file in it- and sometimes no test in that file- because it's an interface- we should organize our code
weeds (Wed, 26 Apr 2017 14:16:38 GMT):
I have not seen any feedback on e-mail.. and Chris has agreed.
weeds (Wed, 26 Apr 2017 14:16:42 GMT):
what are folks thoughts on that?
weeds (Wed, 26 Apr 2017 14:16:57 GMT):
Jim zhang does feel we need to do that- the interdependencies it's not going to be done by end of today
weeds (Wed, 26 Apr 2017 14:17:20 GMT):
at least the first cut of this is to rename all our directories- some of us call test util, some mock test,.. can we consistently to mocks please.
weeds (Wed, 26 Apr 2017 14:17:50 GMT):
2nd iteration- move all the code from prod code-- functions that call mocks test data that is a function in product code module.. so we need to move all of that out of the product code to the package that it belongs to,.
weeds (Wed, 26 Apr 2017 14:18:01 GMT):
last iteration- consolidate mocks directory into a location that is easier to exclude
weeds (Wed, 26 Apr 2017 14:18:21 GMT):
We need to talk to Ramesh whether we can exclude top level directory yet
weeds (Wed, 26 Apr 2017 14:19:52 GMT):
for the report for what is appropriate and what is not
weeds (Wed, 26 Apr 2017 14:21:04 GMT):
we are going to use mocks_testutils
weeds (Wed, 26 Apr 2017 14:21:23 GMT):
AT hackfest- we are very very keen to get 85% + on test coverage
nhrishi (Wed, 26 Apr 2017 19:18:01 GMT):
Has joined the channel.
nhrishi (Wed, 26 Apr 2017 19:18:19 GMT):
Hi, Can someone pls help clarify endorsement policy and how end users can approve/reject the transaction. Let's say there 2 peers for 2 different bank (Bank A and B ). Bank A initiate a transaction on chaincode X using Bank A client app. It has endorsement policy that says Bank B.Member should sign. The transaction hits endorsement peer of B, it creates R/W, validates transaction and sign of peer A. It then forwards a endorsement to client app which waits for a Bank B member to sign the transaction. Once Bank B users signs the transaction (by approve/reject on UI), its forward back to Bank B Peer which in turn sends endorsment to Bank A client app. Client A app collects endorsment and submits to orderer. Orderer orders and creates a block and sends it to commiting peer to update the state and ledger. Can someone pls confirm this is correct flow.
rohitbordia (Thu, 27 Apr 2017 00:08:24 GMT):
Has joined the channel.
rohitbordia (Thu, 27 Apr 2017 00:25:26 GMT):
HI, does any one deployed fabric-peer on a swarm cluster
ansonlau3 (Thu, 27 Apr 2017 06:41:55 GMT):
Has joined the channel.
LoveshHarchandani (Thu, 27 Apr 2017 06:45:24 GMT):
Has joined the channel.
ZionTam (Fri, 28 Apr 2017 02:12:49 GMT):
can anyone explain the Anchor Peers?
as the new example code in e2e_cli,the script add `updateAnchorPeers` function
```
https://github.com/hyperledger/fabric/blob/master/examples/e2e_cli/scripts/script.sh
```
what the Anchor Peers exactly is?the anchor peer is also endorser peer?just a little confused
muralisr (Fri, 28 Apr 2017 03:38:29 GMT):
@ZionTam docs/source/glossary.rst has a definition of it
muralisr (Fri, 28 Apr 2017 03:38:45 GMT):
channels.rst configtx.rst reference it
muralisr (Fri, 28 Apr 2017 03:38:51 GMT):
hope that helps
HubertYoung (Fri, 28 Apr 2017 05:50:28 GMT):
Has joined the channel.
HubertYoung (Fri, 28 Apr 2017 05:55:11 GMT):
Hi!I submit 20 transactions at the same time.But only one transaction commit successfully.Any ideas?Here is the log.
2017-04-28 03:08:16.005 UTC [kvledger] Commit -> INFO 19f Channel [foo]: Created block [29] with 10 transaction(s)
2017-04-28 03:08:18.271 UTC [statevalidator] ValidateAndPrepareBatch -> WARN 1a0 Block [30] Transaction index [1] TxId [d38ae316767f61502417ea2681c2c7d7fbf3898897bac14edcab2cd5df28362f] marked as invalid by state validator. Reason code [11]
2017-04-28 03:08:18.272 UTC [statevalidator] ValidateAndPrepareBatch -> WARN 1a1 Block [30] Transaction index [2] TxId [8aad508c2a92a093fc471ef9424a27dee8055eb72947a40296e03a31c0d262e6] marked as invalid by state validator. Reason code [11]
2017-04-28 03:08:18.272 UTC [statevalidator] ValidateAndPrepareBatch -> WARN 1a2 Block [30] Transaction index [3] TxId [aa0382a5a8021d35f871a7367ccc67e4771665066843f8a5eaa7365155ace1c3] marked as invalid by state validator. Reason code [11]
wsh_bob (Fri, 28 Apr 2017 09:02:28 GMT):
Has joined the channel.
SyneBlockChainTeam (Fri, 28 Apr 2017 11:12:15 GMT):
@dave.enyeart ```3. Description:
Joining Peer 2 on channel with orderer0
Syntax:
CORE_PEER_COMMITTER_LEDGER_ORDERER=orderer0:7050 CORE_PEER_ADDRESS=peer2:7051 peer channel join -b mychannel.block
Issue:
Error: Error getting endorser client channel: PEER_CONNECTIONERROR - Error trying to connect to local peer: grpc: timed out when dialing
/opt/gopath/src/github.com/hyperledger/fabric/peer/common/common.go:84 github.com/hyperledger/fabric/peer/common.GetEndorserClient
/opt/gopath/src/github.com/hyperledger/fabric/peer/channel/channel.go:112 github.com/hyperledger/fabric/peer/channel.InitCmdFactory
/opt/gopath/src/github.com/hyperledger/fabric/peer/channel/join.go:133 github.com/hyperledger/fabric/peer/channel.join
/opt/gopath/src/github.com/hyperledger/fabric/peer/channel/join.go:42 github.com/hyperledger/fabric/peer/channel.joinCmd.func1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/Description.go:599 github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Description).execute
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/Description.go:689 github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Description).ExecuteC
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/Description.go:648 github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Description).Execute
/opt/gopath/src/github.com/hyperledger/fabric/peer/main.go:111 main.main
/opt/go/src/runtime/proc.go:192 runtime.main
/opt/go/src/runtime/asm_amd64.s:2087 runtime.goexit```
SyneBlockChainTeam (Fri, 28 Apr 2017 11:12:15 GMT):
@dave.enyeart ```3. Description:
Joining Peer 2 on channel with orderer0
Syntax:
CORE_PEER_COMMITTER_LEDGER_ORDERER=orderer0:7050 CORE_PEER_ADDRESS=peer2:7051 peer channel join -b mychannel.block
Issue:
Error: Error getting endorser client channel: PEER_CONNECTIONERROR - Error trying to connect to local peer: grpc: timed out when dialing
/opt/gopath/src/github.com/hyperledger/fabric/peer/common/common.go:84 github.com/hyperledger/fabric/peer/common.GetEndorserClient
/opt/gopath/src/github.com/hyperledger/fabric/peer/channel/channel.go:112 github.com/hyperledger/fabric/peer/channel.InitCmdFactory
/opt/gopath/src/github.com/hyperledger/fabric/peer/channel/join.go:133 github.com/hyperledger/fabric/peer/channel.join
/opt/gopath/src/github.com/hyperledger/fabric/peer/channel/join.go:42 github.com/hyperledger/fabric/peer/channel.joinCmd.func1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/Description.go:599 github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Description).execute
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/Description.go:689 github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Description).ExecuteC
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/Description.go:648 github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Description).Execute
/opt/gopath/src/github.com/hyperledger/fabric/peer/main.go:111 main.main
/opt/go/src/runtime/proc.go:192 runtime.main
/opt/go/src/runtime/asm_amd64.s:2087 runtime.goexit'''
SyneBlockChainTeam (Fri, 28 Apr 2017 11:12:15 GMT):
@dave.enyeart ```3. Description:
Joining Peer 2 on channel with orderer0
Syntax:
CORE_PEER_COMMITTER_LEDGER_ORDERER=orderer0:7050 CORE_PEER_ADDRESS=peer2:7051 peer channel join -b mychannel.block
Issue:
Error: Error getting endorser client channel: PEER_CONNECTIONERROR - Error trying to connect to local peer: grpc: timed out when dialing
/opt/gopath/src/github.com/hyperledger/fabric/peer/common/common.go:84 github.com/hyperledger/fabric/peer/common.GetEndorserClient
/opt/gopath/src/github.com/hyperledger/fabric/peer/channel/channel.go:112 github.com/hyperledger/fabric/peer/channel.InitCmdFactory
/opt/gopath/src/github.com/hyperledger/fabric/peer/channel/join.go:133 github.com/hyperledger/fabric/peer/channel.join
/opt/gopath/src/github.com/hyperledger/fabric/peer/channel/join.go:42 github.com/hyperledger/fabric/peer/channel.joinCmd.func1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/Description.go:599 github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Description).execute
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/Description.go:689 github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Description).ExecuteC
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/Description.go:648 github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Description).Execute
/opt/gopath/src/github.com/hyperledger/fabric/peer/main.go:111 main.main
/opt/go/src/runtime/proc.go:192 runtime.main
/opt/go/src/runtime/asm_amd64.s:2087 runtime.goexit ```
SyneBlockChainTeam (Fri, 28 Apr 2017 11:12:15 GMT):
@dave.enyeart ``` Description:
Joining Peer 2 on channel with orderer0
Syntax:
CORE_PEER_COMMITTER_LEDGER_ORDERER=orderer0:7050 CORE_PEER_ADDRESS=peer2:7051 peer channel join -b mychannel.block
Issue:
Error: Error getting endorser client channel: PEER_CONNECTIONERROR - Error trying to connect to local peer: grpc: timed out when dialing
/opt/gopath/src/github.com/hyperledger/fabric/peer/common/common.go:84 github.com/hyperledger/fabric/peer/common.GetEndorserClient
/opt/gopath/src/github.com/hyperledger/fabric/peer/channel/channel.go:112 github.com/hyperledger/fabric/peer/channel.InitCmdFactory
/opt/gopath/src/github.com/hyperledger/fabric/peer/channel/join.go:133 github.com/hyperledger/fabric/peer/channel.join
/opt/gopath/src/github.com/hyperledger/fabric/peer/channel/join.go:42 github.com/hyperledger/fabric/peer/channel.joinCmd.func1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/Description.go:599 github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Description).execute
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/Description.go:689 github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Description).ExecuteC
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/Description.go:648 github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Description).Execute
/opt/gopath/src/github.com/hyperledger/fabric/peer/main.go:111 main.main
/opt/go/src/runtime/proc.go:192 runtime.main
/opt/go/src/runtime/asm_amd64.s:2087 runtime.goexit ```
SyneBlockChainTeam (Fri, 28 Apr 2017 11:12:15 GMT):
@dave.enyeart ```
Description:
Joining Peer 2 on channel with orderer0
Syntax:
CORE_PEER_COMMITTER_LEDGER_ORDERER=orderer0:7050 CORE_PEER_ADDRESS=peer2:7051 peer channel join -b mychannel.block
Issue:
Error: Error getting endorser client channel: PEER_CONNECTIONERROR - Error trying to connect to local peer: grpc: timed out when dialing
/opt/gopath/src/github.com/hyperledger/fabric/peer/common/common.go:84 github.com/hyperledger/fabric/peer/common.GetEndorserClient
/opt/gopath/src/github.com/hyperledger/fabric/peer/channel/channel.go:112 github.com/hyperledger/fabric/peer/channel.InitCmdFactory
/opt/gopath/src/github.com/hyperledger/fabric/peer/channel/join.go:133 github.com/hyperledger/fabric/peer/channel.join
/opt/gopath/src/github.com/hyperledger/fabric/peer/channel/join.go:42 github.com/hyperledger/fabric/peer/channel.joinCmd.func1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/Description.go:599 github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Description).execute
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/Description.go:689 github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Description).ExecuteC
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/Description.go:648 github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Description).Execute
/opt/gopath/src/github.com/hyperledger/fabric/peer/main.go:111 main.main
/opt/go/src/runtime/proc.go:192 runtime.main
/opt/go/src/runtime/asm_amd64.s:2087 runtime.goexit ```
SyneBlockChainTeam (Fri, 28 Apr 2017 11:12:15 GMT):
@dave.enyeart
```Description:
Joining Peer 2 on channel with orderer0
Syntax:
CORE_PEER_COMMITTER_LEDGER_ORDERER=orderer0:7050 CORE_PEER_ADDRESS=peer2:7051 peer channel join -b mychannel.block
Issue:
Error: Error getting endorser client channel: PEER_CONNECTIONERROR - Error trying to connect to local peer: grpc: timed out when dialing
/opt/gopath/src/github.com/hyperledger/fabric/peer/common/common.go:84 github.com/hyperledger/fabric/peer/common.GetEndorserClient
/opt/gopath/src/github.com/hyperledger/fabric/peer/channel/channel.go:112 github.com/hyperledger/fabric/peer/channel.InitCmdFactory
/opt/gopath/src/github.com/hyperledger/fabric/peer/channel/join.go:133 github.com/hyperledger/fabric/peer/channel.join
/opt/gopath/src/github.com/hyperledger/fabric/peer/channel/join.go:42 github.com/hyperledger/fabric/peer/channel.joinCmd.func1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/Description.go:599 github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Description).execute
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/Description.go:689 github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Description).ExecuteC
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/Description.go:648 github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Description).Execute
/opt/gopath/src/github.com/hyperledger/fabric/peer/main.go:111 main.main
/opt/go/src/runtime/proc.go:192 runtime.main
/opt/go/src/runtime/asm_amd64.s:2087 runtime.goexit ```
muralisr (Fri, 28 Apr 2017 11:21:09 GMT):
that's saying peer2 is not running
SyneBlockChainTeam (Fri, 28 Apr 2017 11:56:32 GMT):
@muralisr - how we will make sure that peer2 is running?
muralisr (Fri, 28 Apr 2017 12:00:34 GMT):
@SyneBlockChainTeam `docker ps` should show peer2 container running
SyneBlockChainTeam (Fri, 28 Apr 2017 12:04:22 GMT):
Message Attachments
SyneBlockChainTeam (Fri, 28 Apr 2017 12:04:37 GMT):
@muralisr - Peer2 is running
mffrench (Fri, 28 Apr 2017 13:35:43 GMT):
Hi,
```
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0xaadd06]
goroutine 1 [running]:
panic(0xc70aa0, 0xc420010060)
/opt/go/src/runtime/panic.go:500 +0x1a1
github.com/hyperledger/fabric/core/ledger/util/couchdb.(*CouchInstance).handleRequest(0xc4201319a0, 0xd53b79, 0x3, 0xc420226480, 0x17, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/util/couchdb/couchdb.go:1265 +0xad6
github.com/hyperledger/fabric/core/ledger/util/couchdb.(*CouchInstance).VerifyConnection(0xc4201319a0, 0x0, 0x0, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/util/couchdb/couchdb.go:337 +0x15d
github.com/hyperledger/fabric/core/ledger/util/couchdb.CreateCouchInstance(0xc42000c06f, 0xf, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xc4201ce9f0, ...)
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/util/couchdb/couchdbutil.go:44 +0x245
github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/statedb/statecouchdb.NewVersionedDBProvider(0xc4201ce9f0, 0xc4202064d0, 0x1)
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/statedb/statecouchdb/statecouchdb.go:59 +0xc1
github.com/hyperledger/fabric/core/ledger/kvledger.NewProvider(0xc689e0, 0x0, 0xc42021f4d0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/kvledger/kv_ledger_provider.go:90 +0x2bf
github.com/hyperledger/fabric/core/ledger/ledgermgmt.initialize()
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/ledgermgmt/ledger_mgmt.go:59 +0x14e
github.com/hyperledger/fabric/core/ledger/ledgermgmt.Initialize.func1()
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/ledgermgmt/ledger_mgmt.go:49 +0x14
sync.(*Once).Do(0x13b4dd0, 0xdd76a8)
/opt/go/src/sync/once.go:44 +0xdb
github.com/hyperledger/fabric/core/ledger/ledgermgmt.Initialize()
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/ledgermgmt/ledger_mgmt.go:50 +0x39
github.com/hyperledger/fabric/peer/node.serve(0xc4202366c0, 0x0, 0x1, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/peer/node/start.go:95 +0x74
github.com/hyperledger/fabric/peer/node.glob..func1(0x135d900, 0xc4202366c0, 0x0, 0x1, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/peer/node/start.go:83 +0x3f
github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).execute(0x135d900, 0xc4202366a0, 0x1, 0x1, 0x135d900, 0xc4202366a0)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:599 +0x234
github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0x135e180, 0xf, 0xc4200120f5, 0x4)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:689 +0x367
github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).Execute(0x135e180, 0x2b, 0xc4200120f5)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:648 +0x2b
main.main()
/opt/gopath/src/github.com/hyperledger/fabric/peer/main.go:110 +0x545
```
I just catched some SIGSEGV from peer (git rev `b2a2b3b11481438639bf27ed10b99e490dd23b8c`) with CouchDB connection.
mffrench (Fri, 28 Apr 2017 13:35:43 GMT):
Hi,
```
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0xaadd06]
goroutine 1 [running]:
panic(0xc70aa0, 0xc420010060)
/opt/go/src/runtime/panic.go:500 +0x1a1
github.com/hyperledger/fabric/core/ledger/util/couchdb.(*CouchInstance).handleRequest(0xc4201319a0, 0xd53b79, 0x3, 0xc420226480, 0x17, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/util/couchdb/couchdb.go:1265 +0xad6
github.com/hyperledger/fabric/core/ledger/util/couchdb.(*CouchInstance).VerifyConnection(0xc4201319a0, 0x0, 0x0, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/util/couchdb/couchdb.go:337 +0x15d
github.com/hyperledger/fabric/core/ledger/util/couchdb.CreateCouchInstance(0xc42000c06f, 0xf, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xc4201ce9f0, ...)
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/util/couchdb/couchdbutil.go:44 +0x245
github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/statedb/statecouchdb.NewVersionedDBProvider(0xc4201ce9f0, 0xc4202064d0, 0x1)
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/statedb/statecouchdb/statecouchdb.go:59 +0xc1
github.com/hyperledger/fabric/core/ledger/kvledger.NewProvider(0xc689e0, 0x0, 0xc42021f4d0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/kvledger/kv_ledger_provider.go:90 +0x2bf
github.com/hyperledger/fabric/core/ledger/ledgermgmt.initialize()
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/ledgermgmt/ledger_mgmt.go:59 +0x14e
github.com/hyperledger/fabric/core/ledger/ledgermgmt.Initialize.func1()
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/ledgermgmt/ledger_mgmt.go:49 +0x14
sync.(*Once).Do(0x13b4dd0, 0xdd76a8)
/opt/go/src/sync/once.go:44 +0xdb
github.com/hyperledger/fabric/core/ledger/ledgermgmt.Initialize()
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/ledgermgmt/ledger_mgmt.go:50 +0x39
github.com/hyperledger/fabric/peer/node.serve(0xc4202366c0, 0x0, 0x1, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/peer/node/start.go:95 +0x74
github.com/hyperledger/fabric/peer/node.glob..func1(0x135d900, 0xc4202366c0, 0x0, 0x1, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/peer/node/start.go:83 +0x3f
github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).execute(0x135d900, 0xc4202366a0, 0x1, 0x1, 0x135d900, 0xc4202366a0)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:599 +0x234
github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0x135e180, 0xf, 0xc4200120f5, 0x4)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:689 +0x367
github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).Execute(0x135e180, 0x2b, 0xc4200120f5)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:648 +0x2b
main.main()
/opt/gopath/src/github.com/hyperledger/fabric/peer/main.go:110 +0x545
```
I just catched some SIGSEGV from peer (git rev `b2a2b3b11481438639bf27ed10b99e490dd23b8c`) with CouchDB connection.
mffrench (Fri, 28 Apr 2017 13:35:43 GMT):
Hi,
```
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0xaadd06]
goroutine 1 [running]:
panic(0xc70aa0, 0xc420010060)
/opt/go/src/runtime/panic.go:500 +0x1a1
github.com/hyperledger/fabric/core/ledger/util/couchdb.(*CouchInstance).handleRequest(0xc4201319a0, 0xd53b79, 0x3, 0xc420226480, 0x17, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/util/couchdb/couchdb.go:1265 +0xad6
github.com/hyperledger/fabric/core/ledger/util/couchdb.(*CouchInstance).VerifyConnection(0xc4201319a0, 0x0, 0x0, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/util/couchdb/couchdb.go:337 +0x15d
github.com/hyperledger/fabric/core/ledger/util/couchdb.CreateCouchInstance(0xc42000c06f, 0xf, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xc4201ce9f0, ...)
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/util/couchdb/couchdbutil.go:44 +0x245
github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/statedb/statecouchdb.NewVersionedDBProvider(0xc4201ce9f0, 0xc4202064d0, 0x1)
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/statedb/statecouchdb/statecouchdb.go:59 +0xc1
github.com/hyperledger/fabric/core/ledger/kvledger.NewProvider(0xc689e0, 0x0, 0xc42021f4d0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/kvledger/kv_ledger_provider.go:90 +0x2bf
github.com/hyperledger/fabric/core/ledger/ledgermgmt.initialize()
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/ledgermgmt/ledger_mgmt.go:59 +0x14e
github.com/hyperledger/fabric/core/ledger/ledgermgmt.Initialize.func1()
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/ledgermgmt/ledger_mgmt.go:49 +0x14
sync.(*Once).Do(0x13b4dd0, 0xdd76a8)
/opt/go/src/sync/once.go:44 +0xdb
github.com/hyperledger/fabric/core/ledger/ledgermgmt.Initialize()
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/ledgermgmt/ledger_mgmt.go:50 +0x39
github.com/hyperledger/fabric/peer/node.serve(0xc4202366c0, 0x0, 0x1, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/peer/node/start.go:95 +0x74
github.com/hyperledger/fabric/peer/node.glob..func1(0x135d900, 0xc4202366c0, 0x0, 0x1, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/peer/node/start.go:83 +0x3f
github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).execute(0x135d900, 0xc4202366a0, 0x1, 0x1, 0x135d900, 0xc4202366a0)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:599 +0x234
github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0x135e180, 0xf, 0xc4200120f5, 0x4)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:689 +0x367
github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).Execute(0x135e180, 0x2b, 0xc4200120f5)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:648 +0x2b
main.main()
/opt/gopath/src/github.com/hyperledger/fabric/peer/main.go:110 +0x545
```
I just catched some SIGSEGV from peer (git rev `b2a2b3b11481438639bf27ed10b99e490dd23b8c`) with CouchDB connection.
mffrench (Fri, 28 Apr 2017 13:37:08 GMT):
Would like to know if you were already aware of this issue (and if yes if there is some correction on some other revision) or if I need to raise some bug on Jira ?
muralisr (Fri, 28 Apr 2017 13:37:57 GMT):
@mffrench can you also post in fabric-ledger please ?
mffrench (Fri, 28 Apr 2017 13:38:19 GMT):
@muralisr yep !
simsc (Fri, 28 Apr 2017 14:06:16 GMT):
Here's summary of peer scrum meeting
simsc (Fri, 28 Apr 2017 14:06:36 GMT):
Dave (Composer) - raised issue on rocket chat its on alpha node sdk, related to grpc version, david to raise Jira
Unit test coverage
- Crypto up 3.5% nice work
- Crypto - Change set pending and should raise coverage to 85%+
- Resources added Endorser, Orderer to improve coverage
- Gossip - Change set pending and should raise coverage to 90%+
- Binh working on how to restructure protos files
- We want meaning UT, NOT just for increasing numbers. Stressed this point
Features
2843 - Gari looking at NW, Mult host set up in lab using vlaunch, need to reproduce, really should be a defect, there is no feature work, its a extremely complex problem to solve
2967 - Examples; 4 of 5 complete. Eta for the 5th one is eod
648 - maven, no real update here. need LF
2914 - update config, this is 'in review' but needs work because of fabric changes. ETA EOD
muralisr (Fri, 28 Apr 2017 14:08:09 GMT):
@simsc I'm working on shim/ test coverage. a bit of refactoring needed given some history behind it
pvrbharg (Sat, 29 Apr 2017 23:40:03 GMT):
Has joined the channel.
passkit (Sun, 30 Apr 2017 12:33:56 GMT):
Have an issue installing chaincode on the latest build. Peer fails with the following:
```
2017-04-30 12:27:43.834 UTC [ccprovider] NewCCContext -> DEBU 3af NewCCCC (chain=,chaincode=lscc,version=1.0.0-snapshot-8f7bfc3,txid=5dbfdd549aae2cdac278adfdaf4f47690693b4feca69a16c79c898db7b2ad026,syscc=true,proposal=0xc4225ab1d0,canname=lscc:1.0.0-snapshot-8f7bfc3
2017-04-30 12:27:43.834 UTC [chaincode] ExecuteChaincode -> ERRO 3b0 Error executing chaincode: a syscc should be running (it cannot be launched) lscc:1.0.0-snapshot-8f7bfc3
```
passkit (Sun, 30 Apr 2017 12:35:52 GMT):
Does the peer need to have a copy of a 1.0.0-snapshot-8f7bfc3 image? Was working flawlessly before the changes with consortiums were pushed
muralisr (Sun, 30 Apr 2017 14:05:00 GMT):
@passkit a possibility is that the image version does not match 1.0.0-snapshot-8f7bfc3
yacovm (Sun, 30 Apr 2017 14:28:56 GMT):
Hello all.
There is a bug I think we would want to fix for V1.0 that makes the peer's startup time linear with the size of its chains
https://jira.hyperledger.org/browse/FAB-3525
passkit (Sun, 30 Apr 2017 16:29:48 GMT):
@muralisr I have manually updated the image on that server and even after it is available, I get the following:
```
2017-04-30 16:25:27.966 UTC [protoutils] ValidateProposalMessage -> DEBU 2f0 ValidateProposalMessage starts for signed proposal 0xc4216bf7a0
2017-04-30 16:25:27.969 UTC [protoutils] validateChannelHeader -> DEBU 2f1 validateChannelHeader info: header type 3
2017-04-30 16:25:27.969 UTC [protoutils] checkSignatureFromCreator -> DEBU 2f2 checkSignatureFromCreator starts
2017-04-30 16:25:27.970 UTC [protoutils] checkSignatureFromCreator -> DEBU 2f3 checkSignatureFromCreator info: creator is &{PASSKIT c12e6da319ddc75a03a485c6ebbfed98ff6a5595d7e0c9b11ee98b181a53a5aa}
2017-04-30 16:25:27.970 UTC [protoutils] checkSignatureFromCreator -> DEBU 2f4 checkSignatureFromCreator info: creator is valid
2017-04-30 16:25:27.986 UTC [protoutils] checkSignatureFromCreator -> DEBU 2f5 checkSignatureFromCreator exists successfully
2017-04-30 16:25:27.986 UTC [protoutils] validateChaincodeProposalMessage -> DEBU 2f6 validateChaincodeProposalMessage starts for proposal 0xc420236e10, header 0xc421656000
2017-04-30 16:25:27.986 UTC [protoutils] validateChaincodeProposalMessage -> DEBU 2f7 validateChaincodeProposalMessage info: header extension references chaincode name:"lscc"
2017-04-30 16:25:27.992 UTC [ccprovider] NewCCContext -> DEBU 2f8 NewCCCC (chain=,chaincode=lscc,version=1.0.0-snapshot-8f7bfc3,txid=a0f7acde983206bf114cd4ae09729ececfca90cbf627200ea8e5b00219ec1bac,syscc=true,proposal=0xc420236e10,canname=lscc:1.0.0-snapshot-8f7bfc3
2017-04-30 16:25:27.992 UTC [chaincode] ExecuteChaincode -> ERRO 2f9 Error executing chaincode: a syscc should be running (it cannot be launched) lscc:1.0.0-snapshot-8f7bfc3
```
passkit (Sun, 30 Apr 2017 16:31:20 GMT):
This is with the marbles02 chaincode, and a freshly flushed ledger.
passkit (Sun, 30 Apr 2017 16:52:53 GMT):
@muralisr which image exactly should match. The snapshot version is embedded in the peer binary at compile time, and I am using the fabric-ccenv image from the same build. Looking at the code, it is not obvious precisely what image it is looking for to run syscc. Can anyone point me in the right direction?
mastersingh24 (Sun, 30 Apr 2017 21:33:32 GMT):
@passkit - what are you using to install the chaincode?
passkit (Sun, 30 Apr 2017 21:35:15 GMT):
The CLI - same as the e2e
passkit (Mon, 01 May 2017 03:50:11 GMT):
`peer chaincode install -n marbles2 -v 0 -p github.com/hyperledger/fabric/examples/chaincode/go/marbles02`
jimthematrix (Mon, 01 May 2017 04:10:43 GMT):
getting the following errors, seems to be in TLS handshake:
```orderer0 | 2017/05/01 04:00:22 grpc: Server.Serve failed to complete security handshake from "172.20.0.7:40032": EOF
orderer0 | 2017/05/01 04:00:22 grpc: Server.Serve failed to complete security handshake from "172.20.0.6:59462": EOF
orderer0 | 2017/05/01 04:00:23 grpc: Server.Serve failed to complete security handshake from "172.20.0.7:40036": EOF
orderer0 | 2017/05/01 04:00:24 grpc: Server.Serve failed to complete security handshake from "172.20.0.6:59466": EOF
orderer0 | 2017/05/01 04:00:24 grpc: Server.Serve failed to complete security handshake from "172.20.0.7:40040": EOF
peer0 | 2017-05-01 04:00:24.944 UTC [ConnProducer] NewConnection -> ERRO 036 Failed connecting to orderer0:7050 , error: grpc: timed out when dialing
peer0 | 2017-05-01 04:00:24.944 UTC [deliveryClient] connect -> ERRO 037 Failed obtaining connection: Could not connect to any of the endpoints: [orderer0:7050]
peer2 | 2017-05-01 04:00:25.018 UTC [ConnProducer] NewConnection -> ERRO 036 Failed connecting to orderer0:7050 , error: grpc: timed out when dialing
peer2 | 2017-05-01 04:00:25.018 UTC [deliveryClient] connect -> ERRO 037 Failed obtaining connection: Could not connect to any of the endpoints: [orderer0:7050]
jimthematrix (Mon, 01 May 2017 04:11:36 GMT):
any idea what might be causing it or how to go about investigating? @mastersingh24 @bmos299
jimthematrix (Mon, 01 May 2017 04:48:28 GMT):
FWIW i've tried adding GRPC_TRACE=all and GRPC_VERBOSITY=DEBUG to docker-compose.yaml but they don't seem to have any effect
jimthematrix (Mon, 01 May 2017 05:21:12 GMT):
here's the wireshark capture, I'm no TCP experts but it looks fine to me (as far as TLS handshake is concerned)?
jimthematrix (Mon, 01 May 2017 05:21:23 GMT):
Message Attachments
mastersingh24 (Mon, 01 May 2017 11:07:42 GMT):
@jimthematrix - which setup are you running?
weeds (Mon, 01 May 2017 13:05:28 GMT):
Peer scrum will start at 9:30 using the following phone number: peer scrum (1-888-426-6840 / 33682113)
bmos299 (Mon, 01 May 2017 13:11:17 GMT):
@jimthematrix Hi Jim, do you have the raw .pcap? I can format it out and give you some information.
jimthematrix (Mon, 01 May 2017 13:30:11 GMT):
@mastersingh24 I'm using the set up for node sdk e2e in fabric-sdk-node/test/fixtures/docker-compose.yaml. I've made some updates to eliminate using the separate tls keys and certs as part of gerrit 8389 but the same behavior is observed with or without that update
jimthematrix (Mon, 01 May 2017 13:31:02 GMT):
@bmos299 I'll send it to you in a minute
weeds (Mon, 01 May 2017 13:32:54 GMT):
Scrum call starting
weeds (Mon, 01 May 2017 13:36:07 GMT):
Feature complete--> We still have 1 outstanding feature FAB 648--> @bmos299 can you post the outlook of discussion with Ramesh here as well as add to FAB 648
weeds (Mon, 01 May 2017 13:37:03 GMT):
FOR SDK- he said we have addressed api changes,.. but the build is still failing due to communication issue between orderer and peers.. the peers can not reach the orderer.... he compared ci to SDK-- >
weeds (Mon, 01 May 2017 13:37:22 GMT):
He sent wire shark capture to Barry Mosakowski, but there is no failure that is reported on wire shark on TCP level
mastersingh24 (Mon, 01 May 2017 13:37:34 GMT):
@jimthematrix - does it run locally and just not in CI?
weeds (Mon, 01 May 2017 13:37:47 GMT):
FAB-3459 (Node SDK) FAB-3378 (Java SDK) ---defects opened
jimthematrix (Mon, 01 May 2017 13:38:04 GMT):
@mastersingh24 same problem when running locally
weeds (Mon, 01 May 2017 13:38:18 GMT):
Somebody create a single docker compose config that we use for testing with node sdk, java sdk, and the e2e cli
weeds (Mon, 01 May 2017 13:39:11 GMT):
Everyone needs to work against the same fabric
weeds (Mon, 01 May 2017 13:40:48 GMT):
This is being assigned to @jimthematrix @bmoss299 @binhn
weeds (Mon, 01 May 2017 13:41:21 GMT):
@bmos299
weeds (Mon, 01 May 2017 13:42:11 GMT):
For unit test-> Luis/Kostas working together for consensus @kostas Anil is going to go help @muralisr
jimthematrix (Mon, 01 May 2017 13:42:35 GMT):
Message Attachments
jimthematrix (Mon, 01 May 2017 13:42:42 GMT):
@bmos299 see above
weeds (Mon, 01 May 2017 13:42:53 GMT):
Gossip team is going to go help @muralisr---> Gari did agree their unit test is looking good.
weeds (Mon, 01 May 2017 13:44:21 GMT):
Defects--> Everyone needs to triage their defects- they need to make sure the list really applies to version 1.0
weeds (Mon, 01 May 2017 13:45:27 GMT):
They also need to "prioritize" the defects appropriately-- the right version,.. and making sure highest priority.
weeds (Mon, 01 May 2017 13:45:49 GMT):
Ledger-> he's tagged the ones to 1.0,.. but he needs to put future to future, and will scrub priority today
weeds (Mon, 01 May 2017 13:46:51 GMT):
SDK-> Jim scrubbed on Friday- majority of defects are the ones that are outstanding...he does feel they have the right priorities on them- he did that on the dashboard.. we need to use the priority field.
weeds (Mon, 01 May 2017 13:46:55 GMT):
he will update that
weeds (Mon, 01 May 2017 13:47:10 GMT):
highest, high,etc,.. don't use the dashboard.
weeds (Mon, 01 May 2017 13:47:58 GMT):
CR is going to come in- have JIRA attached to it,.. look at the JIRA,.. and make sure you put the priority - highest, high,etc,.
weeds (Mon, 01 May 2017 13:48:35 GMT):
CA-> Keith,.. it's been several days since he's scrubbed, so he will redo and will add priority in.
weeds (Mon, 01 May 2017 13:48:47 GMT):
Saad/Keith comfortable to get defects down as well as unit test increase
weeds (Mon, 01 May 2017 13:49:26 GMT):
Crypto-> Angelo - we are almost done for test coverage... we have all change sets and everything under review.
weeds (Mon, 01 May 2017 13:49:36 GMT):
we need help on reviewing
weeds (Mon, 01 May 2017 13:49:50 GMT):
We have not triaged our defect backlog, but we will get that done and put priorities in.
weeds (Mon, 01 May 2017 13:49:58 GMT):
it may have to happen tomorrow
weeds (Mon, 01 May 2017 13:50:19 GMT):
scratch that last comment- Elli has done this work per Gari (Elli is out today)
weeds (Mon, 01 May 2017 13:50:27 GMT):
Consensus-> Have to check with Kostas off line
weeds (Mon, 01 May 2017 13:50:39 GMT):
May ask Dave to help on Murali's stuff.
weeds (Mon, 01 May 2017 13:51:18 GMT):
@simsc to get with Barry and team to make sure no defects against enterprise quality team.
weeds (Mon, 01 May 2017 13:51:24 GMT):
on defects,etc,.
weeds (Mon, 01 May 2017 13:52:28 GMT):
Defects were opened against each component for logging
weeds (Mon, 01 May 2017 13:52:41 GMT):
that need to be addressed
weeds (Mon, 01 May 2017 13:53:40 GMT):
Will plans to send some information on Hyperledger-fabric emailing list on guidance on this
weeds (Mon, 01 May 2017 13:53:49 GMT):
When you return error- we should log a corresponding logging statement in the log
weeds (Mon, 01 May 2017 13:53:57 GMT):
so you can correlate what client received and what happened on server side.
weeds (Mon, 01 May 2017 13:54:10 GMT):
Sometimes we are getting client log- but no indication of when it happens and when.
weeds (Mon, 01 May 2017 13:54:24 GMT):
The framework will help generate the call stack based on error received
weeds (Mon, 01 May 2017 13:54:32 GMT):
IF everybody follows the new approach.
weeds (Mon, 01 May 2017 13:54:39 GMT):
We still need to LOG the error- this is part of the guidance
weeds (Mon, 01 May 2017 13:54:52 GMT):
Any time create an error- put a warning or error message.
weeds (Mon, 01 May 2017 13:55:05 GMT):
Will may update the example and clarify this in the document
weeds (Mon, 01 May 2017 13:55:12 GMT):
Every error is returning a call stack.
weeds (Mon, 01 May 2017 13:55:44 GMT):
Keith worried this may not be non-standard-- so like unexpected errors,.. but the framework gives you option wiht callstack and without.
weeds (Mon, 01 May 2017 14:00:22 GMT):
make sure we are writing solid code (we should be done with features at this point unless it's serviceability), get good test coverage and do the right thing- tests should be covering both positive and negative testing... don't race to the end...
weeds (Mon, 01 May 2017 14:00:44 GMT):
it's more important to stop, do the right thing and do the right test coverage- versus adding test coverage to increase the percentages.
jimthematrix (Mon, 01 May 2017 14:03:16 GMT):
@mastersingh24 in that setup, genesis block for the orderer and channel config to create channel were generated with this file using the latest fabric as of this morning
jimthematrix (Mon, 01 May 2017 14:04:27 GMT):
Message Attachments
weeds (Mon, 01 May 2017 14:06:59 GMT):
Jim, Barry, Ratnakar, and Binh after the scrum call are talking about the 1 docker image as well as debugging the issue on the SDK.
weeds (Mon, 01 May 2017 14:07:09 GMT):
I'm going to take notes here for community awareness as a result
weeds (Mon, 01 May 2017 14:08:55 GMT):
Jim is suggesting- we should take initial step of configtx gen output...
weeds (Mon, 01 May 2017 14:09:30 GMT):
this is fabric sample config- configtxgen uses
weeds (Mon, 01 May 2017 14:09:56 GMT):
do you clone this in your repo? yes, i did a get pull 50 minutes ago...
weeds (Mon, 01 May 2017 14:10:27 GMT):
And then I do tweek something-> I tweek configtx.yaml which gets you orderer, channels genesis block.
weeds (Mon, 01 May 2017 14:11:14 GMT):
there is a failure right now- orderer failing to complete security handshake. from peer side it's a time out.
weeds (Mon, 01 May 2017 14:12:13 GMT):
they are looking at orderer-peer-tls-failure-pcping.txt
weeds (Mon, 01 May 2017 14:13:55 GMT):
Barry thinks this looks like a cyber suite issue.
weeds (Mon, 01 May 2017 14:16:35 GMT):
In his- Client said 2B was his 2nd choice... but the first one is rsa for server
weeds (Mon, 01 May 2017 14:16:46 GMT):
the common name in the cert must match the host name in the http header.
weeds (Mon, 01 May 2017 14:17:22 GMT):
wait- this is between peer and orderer
weeds (Mon, 01 May 2017 14:17:30 GMT):
the sending was from the peer and the other is from orderer
weeds (Mon, 01 May 2017 14:19:28 GMT):
Barry is thinking- maybe it has to do with the name?
weeds (Mon, 01 May 2017 14:19:31 GMT):
they agreed on cipher suite
weeds (Mon, 01 May 2017 14:19:43 GMT):
The cert says- example peer zero.org 1. com
weeds (Mon, 01 May 2017 14:19:46 GMT):
but the host name is peer zerio
weeds (Mon, 01 May 2017 14:19:53 GMT):
how do we do the override from the peer side?
jimthematrix (Mon, 01 May 2017 14:21:09 GMT):
hi @mastersingh24 how to set the hostname override for TLS on the peer?
weeds (Mon, 01 May 2017 14:22:38 GMT):
you have to call the service name to match the host name
weeds (Mon, 01 May 2017 14:23:31 GMT):
Jim adding to see if that works
weeds (Mon, 01 May 2017 14:24:34 GMT):
so in this call- the peer is the client... it's the server name which is orderer that needs over-riding
weeds (Mon, 01 May 2017 14:31:01 GMT):
So Jim- put in docker compose when we set up the orderer- we had it be named- it has the same name as the cert from cryptogen
weeds (Mon, 01 May 2017 14:31:14 GMT):
Jim said this works--
weeds (Mon, 01 May 2017 14:31:27 GMT):
Ratnakar is indicating- we don't use cryptogen tool- we are using old certificates
weeds (Mon, 01 May 2017 14:31:31 GMT):
for the CLI
weeds (Mon, 01 May 2017 14:31:44 GMT):
we have to integrate what we did for DC hackfest to move to what Jim is doing
mastersingh24 (Mon, 01 May 2017 14:32:09 GMT):
basically, the service name in the compose file needs to match the CN in the certificate
weeds (Mon, 01 May 2017 14:32:25 GMT):
and the container name- yes?
mastersingh24 (Mon, 01 May 2017 14:32:30 GMT):
you can also use cryptogen to not add DNS suffix
jimthematrix (Mon, 01 May 2017 14:32:39 GMT):
yeah we just did that for the docker-compose.yaml in node sdk
weeds (Mon, 01 May 2017 14:32:40 GMT):
So the Nodesdk works with this change
weeds (Mon, 01 May 2017 14:32:41 GMT):
now
mastersingh24 (Mon, 01 May 2017 14:32:46 GMT):
well container name will equal the service name
jimthematrix (Mon, 01 May 2017 14:32:46 GMT):
and that got us past the issue
mastersingh24 (Mon, 01 May 2017 14:33:14 GMT):
we also modified cryptogen to se multiple SANs - need to merge that change though
weeds (Mon, 01 May 2017 14:33:45 GMT):
at grpc level- is there any way to percolate that error message somehow?
weeds (Mon, 01 May 2017 14:33:52 GMT):
because many people will run into this
weeds (Mon, 01 May 2017 14:34:17 GMT):
@mastersingh24 any ideas on how to generate error so we can help people in the future?
weeds (Mon, 01 May 2017 14:35:16 GMT):
1 Docker--> Binh feels we need to have a compose e2e cli,.. and we need another level for node and another level for java
weeds (Mon, 01 May 2017 14:36:18 GMT):
Jim feels he needs a nodesdk target that we need fabric and fabric ca... we need an e2e... should it be in fabric? or should it be somewhere lese? it should be in integration packet somewhere
weeds (Mon, 01 May 2017 14:36:51 GMT):
Say my compose has fabric ca in it? so we run a ci test that has this.. for node sdk- go start up and using that same compose image
weeds (Mon, 01 May 2017 14:37:07 GMT):
Let's consolidate this and optional components to turn on/off components like fabric ca
weeds (Mon, 01 May 2017 14:37:10 GMT):
or couchdb
weeds (Mon, 01 May 2017 14:37:26 GMT):
we know we start with docker compose- and we have to tweek environment variable and we know exactly
weeds (Mon, 01 May 2017 14:37:28 GMT):
what is happening
weeds (Mon, 01 May 2017 14:38:19 GMT):
We're going to start with the one in node sdk as it's more comprehenisve.
weeds (Mon, 01 May 2017 14:38:28 GMT):
it has 2 orgs, heach has it's own fabric ca
weeds (Mon, 01 May 2017 14:38:43 GMT):
we only have 1 peer- but we need to add another peer to utilize gossip.
weeds (Mon, 01 May 2017 14:39:45 GMT):
in DC hackfest- we have a local program that uses node as well as fabric-CA... it generates certificates and orderer block and creates channel,.. and the same docker compose file can be used by node sdk ..I just have to plug in the fabric ca parts.
weeds (Mon, 01 May 2017 14:39:59 GMT):
we can still include the fabric ca--- for cli piece too.
weeds (Mon, 01 May 2017 14:41:36 GMT):
For node sdk testing- As long as the files are generated in fabric- we can assume that the fabric repository will be sitting side by side. Node can use the file system itself. so if you could output to mounted folder.
weeds (Mon, 01 May 2017 14:42:23 GMT):
node engine should be 6.9 or later
weeds (Mon, 01 May 2017 14:45:00 GMT):
Ratnakar feels he can get this sometime tomorrow-- given work ahead
weeds (Mon, 01 May 2017 14:46:32 GMT):
to get to one compose file
mastersingh24 (Mon, 01 May 2017 14:47:34 GMT):
[ My take here is quite simple:
The base compose for all e2e should be the same - meaning we use IDENTICAL peer and orderer nodes.
If the SDKs want to add additional nodes (e.g. fabric-ca, couch, they can do do but the based compose should be the same with all the same crypto material.
](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=G5gRqjBEnFTityQKn) @weeds
bmos299 (Mon, 01 May 2017 14:57:16 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=weeQqxA9adgAZtCm6) @mastersingh24 @Ratnakar is on it.
zjb0807 (Mon, 01 May 2017 15:57:55 GMT):
Has joined the channel.
rjones (Mon, 01 May 2017 18:33:27 GMT):
Has left the channel.
albrandt (Mon, 01 May 2017 19:03:51 GMT):
Has joined the channel.
Ratnakar (Tue, 02 May 2017 03:00:35 GMT):
With fabric latest code base unable to Join the channel using crypto material generated using cryptogen, Following is the error
```
Error: proposal failed (err: rpc error: code = 2 desc = "JoinChain" request failed authorization check for channel [mychannel]: [Failed verifying that proposal's creator satisfies local MSP principal during channelless check policy with policy [Admins}: [This identity is not an admin]])
```
Ratnakar (Tue, 02 May 2017 03:00:54 GMT):
Gist of logs on the CLI container
```
===================== Channel "mychannel" is created successfully =====================
CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt
CORE_PEER_TLS_KEY_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/server.key
CORE_PEER_LOCALMSPID=Org0MSP
CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
CORE_PEER_TLS_CERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/server.crt
CORE_PEER_ADDRESSAUTODETECT=true
CORE_PEER_TLS_ENABLED=true
CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp
CORE_PEER_ID=cli
CORE_LOGGING_LEVEL=DEBUG
CORE_PEER_ADDRESS=peer0.org1.example.com:7051
CORE_PEER_ENDORSER_ENABLED=true
CORE_NEXT=true
2017-05-02 02:47:27.445 UTC [msp] getMspConfig -> INFO 001 intermidiate certs folder not found at [/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp/intermediatecerts]. Skipping.: [stat /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp/intermediatecerts: no such file or directory]
2017-05-02 02:47:27.445 UTC [msp] getMspConfig -> INFO 002 crls folder not found at [/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp/intermediatecerts]. Skipping.: [stat /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp/crls: no such file or directory]
2017-05-02 02:47:27.445 UTC [msp] getMspConfig -> INFO 003 MSP configuration file not found at [/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp/config.yaml]: [stat /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp/config.yaml: no such file or directory]
2017-05-02 02:47:27.477 UTC [msp] GetLocalMSP -> DEBU 004 Returning existing local MSP
2017-05-02 02:47:27.477 UTC [msp] GetDefaultSigningIdentity -> DEBU 005 Obtaining default signing identity
2017-05-02 02:47:27.482 UTC [msp] Sign -> DEBU 006 Sign: plaintext: 0AE3070A5C08011A0C08BFE69FC80510...345BB16E71721A080A000A000A000A00
2017-05-02 02:47:27.482 UTC [msp] Sign -> DEBU 007 Sign: digest: F3C3D55A3C2DBD5BDAEB9CBDEA1CA9263106A4BB34584FC3003561952D738CE3
Error: proposal failed (err: rpc error: code = 2 desc = "JoinChain" request failed authorization check for channel [mychannel]: [Failed verifying that proposal's creator satisfies local MSP principal during channelless check policy with policy [Admins}: [This identity is not an admin]])
Usage:
peer channel join [flags]
Global Flags:
-b, --blockpath string Path to file containing genesis block
--cafile string Path to file containing PEM-encoded trusted certificate(s) for the ordering endpoint
-c, --chain string In case of a newChain command, the chain ID to create.
-f, --file string Configuration transaction file generated by a tool such as configtxgen for submitting to orderer
--logging-level string Default logging level and overrides, see core.yaml for full syntax
-o, --orderer string Ordering service endpoint
--test.coverprofile string Done (default "coverage.cov")
--tls Use TLS when communicating with the orderer endpoint
-v, --version Display current version of fabric peer server
!!!!!!!!!!!!!!! After 1 attempts, PEER0 has failed to Join the Channel !!!!!!!!!!!!!!!!
================== ERROR !!! FAILED to execute End-2-End Scenario ==================
```
Ratnakar (Tue, 02 May 2017 03:02:37 GMT):
Don't see any thing suspicious in peer and orderer logs
Ratnakar (Tue, 02 May 2017 03:02:37 GMT):
Don't see anything suspicious in peer and orderer logs
HubertYoung (Tue, 02 May 2017 03:33:40 GMT):
Why the transactions marked as invalid?
HubertYoung (Tue, 02 May 2017 03:33:49 GMT):
Message Attachments
Lakshmipadmaja (Tue, 02 May 2017 05:00:31 GMT):
Has joined the channel.
jeffgarratt (Tue, 02 May 2017 13:36:59 GMT):
@HubertYoung the join channel requires the submitter have the admin role for the peer.
jeffgarratt (Tue, 02 May 2017 13:37:53 GMT):
this translates to either the cert of the signer is in the admincerts folder of the localmsp config of the peer, or their cert was signed by was one of the certs located there (or in the chain)
jeffgarratt (Tue, 02 May 2017 13:38:54 GMT):
not sure if there is an issue with e2e, or there is some config issue in your case
rahulhegde (Tue, 02 May 2017 14:08:35 GMT):
hello GM
I am running a Peer CLI command and the endorsement success provides following o/p
```
2017-05-02 13:47:20.607 UTC [chaincodeCmd] chaincodeInvokeOrQuery -> INFO 007 Invoke result: version:1 response:
rahulhegde (Tue, 02 May 2017 14:08:35 GMT):
hello GM
I am running a Peer CLI command and the endorsement success provides following o/p
```
2017-05-02 13:47:20.607 UTC [chaincodeCmd] chaincodeInvokeOrQuery -> INFO 007 Invoke result: version:1 response:
rahulhegde (Tue, 02 May 2017 14:08:35 GMT):
hello GM
I am running a Peer CLI command and the endorsement success provides following o/p
```
2017-05-02 13:47:20.607 UTC [chaincodeCmd] chaincodeInvokeOrQuery -> INFO 007 Invoke result: version:1 response:
rahulhegde (Tue, 02 May 2017 14:08:35 GMT):
hello GM
I am running a Peer CLI command and the endorsement success provides following o/p
```
2017-05-02 13:47:20.607 UTC [chaincodeCmd] chaincodeInvokeOrQuery -> INFO 007 Invoke result: version:1 response:
rahulhegde (Tue, 02 May 2017 14:08:35 GMT):
hello GM
I am running a Peer CLI command and the endorsement success provides following o/p
```
2017-05-02 13:47:20.607 UTC [chaincodeCmd] chaincodeInvokeOrQuery -> INFO 007 Invoke result: version:1 response:
ericmvaughn (Tue, 02 May 2017 20:24:24 GMT):
Has joined the channel.
aambati (Tue, 02 May 2017 20:46:03 GMT):
Has joined the channel.
simsc (Wed, 03 May 2017 13:24:18 GMT):
For 9;30 est call here's the structure
simsc (Wed, 03 May 2017 13:24:23 GMT):
1) CI Build Status
- If there is a failure, we discuss and assign the breaking defect. This defect will be the top priority for the team until resolved.
2) Defect status
- We will discuss defects with priority=highest and overall backlog by component
- https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10409
3) QA status. This will be any items from QA not covered already #1 and #2
4) Endgame items.
- We will review any outstanding items on the feature board. This should be priority items in review and waiting to be merged
- https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10404
- We will review end game items. E.G. serviability
- https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10410
5) Documenation status
- https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10406
6) After 1-5, engineers an stay on and discuss any follow up items.
simsc (Wed, 03 May 2017 13:25:00 GMT):
Here's call info peer scrum (1-888-426-6840 / 33682113)
simsc (Wed, 03 May 2017 13:25:05 GMT):
all are welcome
lehors (Wed, 03 May 2017 13:31:55 GMT):
hi, I'm on :-)
HubertYoung (Wed, 03 May 2017 15:18:45 GMT):
@jeffgarratt Thanks!I should have described more clearly.When i commit only one tx,it is ok.But in the upper case,i commit 20 txs,18 of them are marked invalid and the other two are sumbited to the blocks.All the txs are transfering from a to b with 1.I know it relates to the Concurrency Control Version Check.But i dont know how to make it right.
simsc (Wed, 03 May 2017 15:20:31 GMT):
summary of scrum
simsc (Wed, 03 May 2017 15:20:36 GMT):
CI update:
- Everything passed with exception of Java SDK. Bug 3378 This was expected based on recent Fabric changes that Java is catching up to
Bugs Priority Highest:
- 3550 - Ramesh to turn on logs for Jeff, Barry to follow up
- 3301 - Jim looking. Murali to help as well
- 3940 - working on it very difficult eta eow
- 3300 - being worked
- 3301 - gari working it
- 3037 - doc, clayton to alert Nick
- 2843 - most likely dup of 3301
Discussion on how user updates policy
- configtxgen generate binary with default policy
- does sdk read binary and update, or used txgen somehow do this
- Jeff's question how does user req get translated into a policy
- take discussion offline - Murali to lead
CRs in review from feature board
- we reviewed each
- decision to defer jira 2362,
Unit test coverage
- Anil working with Murali added some small items that will start increasing coverage
- Luis started and will check in CRs today
Serviceability
- Created features for each team for dashboard
- Each team to update status
jeffgarratt (Wed, 03 May 2017 15:22:42 GMT):
@HubertYoung are you doing this in parallel?
HubertYoung (Wed, 03 May 2017 15:22:59 GMT):
Yes
jeffgarratt (Wed, 03 May 2017 15:23:02 GMT):
ahhh
jeffgarratt (Wed, 03 May 2017 15:23:09 GMT):
that will be problematic with the MVCC info
jeffgarratt (Wed, 03 May 2017 15:23:21 GMT):
the RW sets will fail checks in this case
jeffgarratt (Wed, 03 May 2017 15:23:45 GMT):
if you serialize the input I assume this works for you?
jeffgarratt (Wed, 03 May 2017 15:24:16 GMT):
the issue is the RW sets are validated at the ledger
jeffgarratt (Wed, 03 May 2017 15:25:31 GMT):
the first through the orderer will succeed, and then a subsequent latter TX may happen to get the latest Read set and then also work. In your case, the first and last may always work
jeffgarratt (Wed, 03 May 2017 15:25:54 GMT):
but if all submitted too quicjly, only first will pass
jeffgarratt (Wed, 03 May 2017 15:26:39 GMT):
also, you have to wait for the peer to validate and commit the TX
jeffgarratt (Wed, 03 May 2017 15:26:54 GMT):
before sumbitting subsequent for endorsement to the same peer
jeffgarratt (Wed, 03 May 2017 15:27:15 GMT):
you should submit proposal, then TX, and then wait for event from peer saying committed, then proceed
jeffgarratt (Wed, 03 May 2017 15:27:21 GMT):
does that make sense?
HubertYoung (Wed, 03 May 2017 15:28:13 GMT):
Yes.But i would be too slow for the batch process
HubertYoung (Wed, 03 May 2017 15:28:13 GMT):
Yes.But it would be too slow for the batch process
jeffgarratt (Wed, 03 May 2017 15:28:59 GMT):
@muralisr do we currently support multiple proposals in our TXs?
jeffgarratt (Wed, 03 May 2017 15:29:19 GMT):
meaning, can @HubertYoung batch his proposal responses, and then submit in single TX?
muralisr (Wed, 03 May 2017 15:30:15 GMT):
@jeffgarratt @HubertYoung only one proposal/response is supported currently
jeffgarratt (Wed, 03 May 2017 15:30:57 GMT):
@HubertYoung if your network requires more than a single endorsement, then the flow you are discussing can be problematic either way
jeffgarratt (Wed, 03 May 2017 15:31:55 GMT):
basically you have a concurrency issue not unlike any DB faces
jeffgarratt (Wed, 03 May 2017 15:32:10 GMT):
except the blockchain requires slightly more moving parts
HubertYoung (Wed, 03 May 2017 15:32:21 GMT):
Dose it has something to do with the key?If the proposals have different keys,would it be alright?
jeffgarratt (Wed, 03 May 2017 15:32:26 GMT):
yes
jeffgarratt (Wed, 03 May 2017 15:32:47 GMT):
if each proposal touched a different key, should be fine
jeffgarratt (Wed, 03 May 2017 15:32:58 GMT):
I assume you are trying to perform basic perf testing?
HubertYoung (Wed, 03 May 2017 15:33:20 GMT):
Yes
jeffgarratt (Wed, 03 May 2017 15:33:23 GMT):
:)
jeffgarratt (Wed, 03 May 2017 15:33:51 GMT):
k, have each concurrent proposal operate on a separate key and you should not have concurrency issues
HubertYoung (Wed, 03 May 2017 15:33:53 GMT):
Thanks.It helps a lot
jeffgarratt (Wed, 03 May 2017 15:33:58 GMT):
good luck!!
jeffgarratt (Wed, 03 May 2017 15:34:17 GMT):
and I would also recommend integrating the number of endorsements you plan to actually have
jeffgarratt (Wed, 03 May 2017 15:34:56 GMT):
@HubertYoung as this will also affect your throughput, latency, etc.
jeffgarratt (Wed, 03 May 2017 15:35:28 GMT):
particularly because network and crypto are heavily involved
jeffgarratt (Wed, 03 May 2017 15:37:43 GMT):
@HubertYoung and also consider your storage choice (leve vs couchdb, etc.)
jeffgarratt (Wed, 03 May 2017 15:38:08 GMT):
default is level, assume couchdb may introduce overhead, but that is an 'assumption' :)
HubertYoung (Wed, 03 May 2017 15:38:23 GMT):
haha
HubertYoung (Wed, 03 May 2017 15:40:18 GMT):
Do you have any ideas about setting up a cluster?Is docker swarm a good choice?
HubertYoung (Wed, 03 May 2017 15:40:49 GMT):
The more peers,the better?
jeffgarratt (Wed, 03 May 2017 15:40:50 GMT):
I do
jeffgarratt (Wed, 03 May 2017 15:41:09 GMT):
https://github.com/hyperledger/fabric/tree/master/bddtests#welcome-to-the-behavioral-driven-development-bdd-subsytem-for-fabric
jeffgarratt (Wed, 03 May 2017 15:41:16 GMT):
that allow quick setup of various networks
jeffgarratt (Wed, 03 May 2017 15:41:18 GMT):
locally
HubertYoung (Wed, 03 May 2017 15:42:52 GMT):
Thanks a lot!
jeffgarratt (Wed, 03 May 2017 16:02:39 GMT):
yw
bbehlendorf (Thu, 04 May 2017 00:08:19 GMT):
Has joined the channel.
davidkel (Thu, 04 May 2017 12:50:21 GMT):
Reading the docs on endorsement policies regarding the policy if one is not specified, the docs say
```
NOTE - the default policy requires one signature from a member of the DEFAULT MSP
```
I can't find any description of what the default MSP is and how a proposal could be signed by this MSP. Anyone point me to some information ?
William.Z (Thu, 04 May 2017 13:05:30 GMT):
Has joined the channel.
yacovm (Thu, 04 May 2017 13:15:44 GMT):
ask in #fabric-crypto
yacovm (Thu, 04 May 2017 13:15:50 GMT):
@davidkel
davidkel (Thu, 04 May 2017 13:30:23 GMT):
@yacovm ok, will do thanks
simsc (Thu, 04 May 2017 14:21:55 GMT):
Here is notes from 9:30 scrum
simsc (Thu, 04 May 2017 14:22:03 GMT):
CI build status
- CI failed, e2e worked last night but not this morning
- root cause unknown
- defect being opened
Defects
https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10409
- 3550 jeff not on
- 3378 eta end of day
- 3310 gari working this
- 3301 eta eod
- 3300 eta tommorrow
- 3037 does not belong on list
- 2990 on its way to review
Composer team not on
QA
- CI e2e change, will be artifacts from ground up
- chris wants documented
- chris to review
- need to review with greg haskins
- eta eod?
Features 'in review'
https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10404
- 2681 - 3 changes eta eow
- 3236 - same as 2681
- 3632 - ready to go just need review
- 3291 - kostas needs to talk to jeff
- 3218 - 3 change sets, should be able to do today, luis to work w/jim
Unit test
- Anil pushed small change set to increase coverage
- Luis has small changes set to push
Scrum took 19 minutes: thanks for everyone's focus
simsc (Thu, 04 May 2017 14:22:59 GMT):
We do this daily at 9;30 scrum (1-888-426-6840 / 33682113). Any and all are welcome
tkuhrt (Thu, 04 May 2017 16:56:48 GMT):
Has joined the channel.
muralisr (Fri, 05 May 2017 13:29:11 GMT):
Hi everyone, peer (endorser/committer) scrum starting in a minute ... (1-888-426-6840 / 33682113)
weeds (Fri, 05 May 2017 13:29:21 GMT):
Murali- i can take some notes for you during the scrum.
muralisr (Fri, 05 May 2017 13:29:33 GMT):
thanks, Sharon ... appreciate it
weeds (Fri, 05 May 2017 13:29:34 GMT):
so you can focus on talking with those that have joined
muralisr (Fri, 05 May 2017 13:29:38 GMT):
ok
weeds (Fri, 05 May 2017 13:31:37 GMT):
The CI- any build breaks? We have a new CI - building binaries on the fly.. compiling cryptogen.
weeds (Fri, 05 May 2017 13:31:47 GMT):
We have one gossip test failing and the behave test failing- https://jira.hyperledger.org/browse/FAB-3550 (Behave tests failures)
weeds (Fri, 05 May 2017 13:32:06 GMT):
We have FAB-3550 opened against @jeffgarratt
weeds (Fri, 05 May 2017 13:33:05 GMT):
end to end CLI should pass and unit test should be passing-- so there is a bug @C0rWin
weeds (Fri, 05 May 2017 13:34:38 GMT):
Defect is FAB-3669 for the gossip problem- go tests are failing intermittently opened for @C04Win
weeds (Fri, 05 May 2017 13:35:13 GMT):
Murali to reach out to after call since not on scrum for FAB-3669
weeds (Fri, 05 May 2017 13:36:00 GMT):
FAB-3001 This is opened against @mastersingh24
weeds (Fri, 05 May 2017 13:37:44 GMT):
Defects
https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10409
- 3550 jeff not on- Murali to follow up after call
- 3300 eta tommorrow- default default chaincode policy-- completing it and waiting on CI.. almost ready to review/merge
- 3232- that is out for review for a couple of days- we need a couple of maintainers to look at it
weeds (Fri, 05 May 2017 13:38:47 GMT):
- 3301- in review per Jim Zhang
weeds (Fri, 05 May 2017 13:40:00 GMT):
Gari Apologize- the number was 3310 @mastersingh24
weeds (Fri, 05 May 2017 13:40:23 GMT):
End Game items- where we are reviewing outstanding items on feature board-
weeds (Fri, 05 May 2017 13:40:58 GMT):
2681- this has to be rebased, and people can start reviewing
weeds (Fri, 05 May 2017 13:41:36 GMT):
3236- this is in review and has already been rebased
weeds (Fri, 05 May 2017 13:42:05 GMT):
3291- Murali to follow up with Kostas afterwards
weeds (Fri, 05 May 2017 13:43:18 GMT):
3218- Murali to follow up with Luis afterwards
weeds (Fri, 05 May 2017 13:43:41 GMT):
1309- coding is done, but it's a matter of now where to put it per Dave enyeart
weeds (Fri, 05 May 2017 13:44:18 GMT):
For error handling-
weeds (Fri, 05 May 2017 13:45:18 GMT):
discussion to occur with @cbf @mastersingh24 -- error handling and how do you make use of componetization piece.-- there is question whether we should do or not?
weeds (Fri, 05 May 2017 13:47:03 GMT):
For documentation status from @nickgaski - instead of walking through all fabs- here's quick summary We don't have anything on configuration updates that is missing.. We need some stuff on using cryptogen tool and using the template. We plan to reshuffle getting started with new images making use of the new configuration that is needed for ordererer block and transactions. We have to really improve the login piece. We need event listener documentation for SDK as well as demos. there are JIRA items for all of those items.
weeds (Fri, 05 May 2017 13:47:36 GMT):
What Nick did- he added readme the refactored end to end code- We believe @cbf want it ported into getting started. For time being, I do need this merged so they can get end to end work for now.
weeds (Fri, 05 May 2017 13:48:14 GMT):
There is marbles documentation- which we think is good sample application for people to see- but we need the maintainers to make a decision having an application with a UI versus CLi in the terminal and would like some help merging @mastersing24
weeds (Fri, 05 May 2017 13:48:23 GMT):
@nickgaski can you post the #'s
weeds (Fri, 05 May 2017 13:49:38 GMT):
for merging requests on the fabric-pr review channel
nickgaski (Fri, 05 May 2017 13:49:46 GMT):
https://gerrit.hyperledger.org/r/#/c/8981/ - end to end
nickgaski (Fri, 05 May 2017 13:50:09 GMT):
https://gerrit.hyperledger.org/r/#/c/7997/ - marbles
weeds (Fri, 05 May 2017 13:50:36 GMT):
@mastersingh24 see request on merges from Nick on doc from maintainer
weeds (Fri, 05 May 2017 13:50:45 GMT):
@binhn see above
weeds (Fri, 05 May 2017 13:54:10 GMT):
FAB 2919- I need @binhn some input on this specifically
weeds (Fri, 05 May 2017 13:55:16 GMT):
FAB 3678- Elli requesting help for people to look- and comment on fabric-crypto. This is way we evaluate expiration of certificate and a bug we had and want some extra eyes on it... Keith has reviewed it already.
weeds (Fri, 05 May 2017 14:00:49 GMT):
Arnaud is suggesting --> We need to document what unit test should be and what unit test should not be. We should collect best practices and have contributer check list.
weeds (Fri, 05 May 2017 14:03:27 GMT):
Scrum call has ended
cbf (Fri, 05 May 2017 14:11:30 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=bGfboTnewxfYZKzp3) @weeds it is pretty simple - unit tests should be capable of being run without any external dependency from within the directory in which they reside
cbf (Fri, 05 May 2017 14:12:49 GMT):
as for end2end README vs Getting Started - I disagree that we should just merge this. It is confusing to have Getting Started when it is really end2end that is Getting Started and Getting Started is actually for code that is over 2 months old.
cbf (Fri, 05 May 2017 14:34:48 GMT):
"Unit testing is a software development process in which the smallest testable parts of an application, called units, are individually and independently scrutinized for proper operation. Unit testing can be done manually but is often automated."
cbf (Fri, 05 May 2017 14:34:55 GMT):
http://searchsoftwarequality.techtarget.com/definition/unit-testing
cbf (Fri, 05 May 2017 14:35:24 GMT):
key words here are "individually" and "independently"
cbf (Fri, 05 May 2017 14:36:36 GMT):
in a go project, one should be capable of running "go test" in the directory in which the code they are working on resides and it should run without any dependencies
weeds (Fri, 05 May 2017 19:13:51 GMT):
understand Chris- I don't know why Arnaud felt it needed to be documented and sent to the community
weeds (Fri, 05 May 2017 19:13:56 GMT):
@cbf
weeds (Fri, 05 May 2017 19:14:06 GMT):
I'll let you reach out to him-- as it's a pretty standard definition
lehors (Sat, 06 May 2017 08:36:12 GMT):
@weeds @cbf: @binhn made the point that people are adding unit tests against private methods and while it increases coverage it will create additional work later on when internals change, instead we should only have unit tests against the public APIs. All I'm saying is that if that's the agreement we need to document or people won't know and will continue doing the same.
lehors (Sat, 06 May 2017 08:42:17 GMT):
I think we have a lot of undocumented things like this that we ought to write down so it's easier for people to become contributors
lehors (Sat, 06 May 2017 08:42:17 GMT):
I think we have a lot of undocumented things like this that we ought to write down so it's easier for people to become effective contributors
muralisr (Sat, 06 May 2017 12:20:39 GMT):
@here for those interested in chaincode dev mode - doc was updated https://gerrit.hyperledger.org/r/#/c/8985/ (hope its ok to use `here` for such announcements...if not do let me know :-) )
weeds (Mon, 08 May 2017 12:12:09 GMT):
@muralisr we should really post also to the email list as not everyone is on rocket chat apprently
muralisr (Mon, 08 May 2017 12:12:47 GMT):
@weeds will do
weeds (Mon, 08 May 2017 12:16:06 GMT):
@here We hold a peer scrum Monday, Wednesday, Friday for Hyperledger-Fabric. The dial in for today at 9:30 EST is 1-888-426-6840 with passcode 33682113. We review what has passed or failed out of the daily build from CI, the highest priority bugs that must be addressed, CR's that need special attention from maintainers, unit test coverage, and serviceability. Also at the end of the call, developers sometimes talk about additional technical questions that should be addressed to stabilizing release where interlock needs to occur.
simsc (Mon, 08 May 2017 13:32:40 GMT):
Here's the format of the Peer scrum going forward. I want the keep them as short and focussed taking long discussions off line.
1) CI Build Status
- If there is a failure, we discuss and assign the breaking defect. This defect will be the top priority for the team until resolved.
2) Defect status
- We will discuss defects with priority=highest and overall backlog by component
- https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10409
3) QA status. This will be any items from QA not covered already #1 and #2
4) Endgame items.
- We will review any outstanding items on the feature board. This should be priority items in review and waiting to be merged
- https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10404
- We will review end game items. E.G. serviability
- https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10410
5) Documenation status
- https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10406
6) After 1-5, engineers an stay on and discuss any follow up items.
FenglianXu (Mon, 08 May 2017 13:34:56 GMT):
Has joined the channel.
JonathanLevi (Mon, 08 May 2017 13:36:17 GMT):
Has joined the channel.
JonathanLevi (Mon, 08 May 2017 14:07:27 GMT):
BTW: https://cwiki.apache.org/confluence/display/KAFKA/KIP-32+-+Add+timestamps+to+Kafka+message
JonathanLevi (Mon, 08 May 2017 14:07:27 GMT):
BTW: https://cwiki.apache.org/confluence/display/KAFKA/KIP-32+-+Add+timestamps+to+Kafka+message i what @yacovm mentioned.
JonathanLevi (Mon, 08 May 2017 14:08:23 GMT):
I tend to agree with @vukolic ^^^
vukolic (Mon, 08 May 2017 14:08:24 GMT):
Has joined the channel.
simsc (Mon, 08 May 2017 15:01:23 GMT):
Highlights of Monday 5/8 9;30 EST scrum
CI status
- Java and Node SDK failed defects 3690, 3550 opened
Hot Defects (Defects with priority highest)
- https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10409
- 3713 - Luis to discuss with Rick
- 3690 - ETA today
- 3550 - Ramesh provided logs, looks strange, Jeff to get with Ramesh
- 3301 - stuck behind the build break
- 2940 - ETA today, after build break fixed
- 3310 - Gari working this,
Alpha 2
- Binh and maintainers to discuss and decide items to include in alpha2
- Discuss this in release channel
- Binh will get send note to hyperledger list with summary and direction
- ETA 24 hours
Unit test - 71% coverage
- Anil submitted 4 change sets, once merged should help numbers
- Luis slow due to instability, Clayton to follow up off line
Feature board
- *We are feature frozen*
- https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10404
Open
648 - Ramesh still working with LF
3291 - This is test item, not a feature, will adjust tagging
In Review
2681 - large cs eta weds
3447 - easy was build is fixed
3218 - one small clean up cs eta today
1304 - this is not a feature this is QA, will adjust tagging
simsc (Mon, 08 May 2017 15:03:37 GMT):
Chris provided feedback on how to improve handling of Jira. Team to review and we will discuss tomorrow
simsc (Mon, 08 May 2017 15:04:10 GMT):
Technical discussion at end of meeting
- Elli brought up how to handle expiry
- Short discussion, agreed to discuss in the crypto channel
subbu165 (Mon, 08 May 2017 16:26:11 GMT):
Has joined the channel.
subbu165 (Mon, 08 May 2017 16:31:56 GMT):
Hi, If we have a lot of load coming in for a deployed chaincode/smartcontract, can we do load balancing to share the load. If so, how the topology should be? any documentation or info in this please?
nnao (Mon, 08 May 2017 18:22:06 GMT):
Has joined the channel.
jimthematrix (Mon, 08 May 2017 20:00:21 GMT):
@muralisr @binhn @mastersingh24 @jeffgarratt do you guys know what have changed recently that would break node SDK (and java SDK) e2e set up such that the peers are not able to connect to the orderers any longer?
```peer0.org1.example.com | 2017-05-08 19:57:57.145 UTC [grpc] Printf -> DEBU 390 grpc: addrConn.resetTransport failed to create client transport: connection error: desc = "transport: x509: certificate signed by unknown authority"; Reconnecting to {"orderer.example.com:7050"
muralisr (Mon, 08 May 2017 20:01:14 GMT):
@jimthematrix perhaps this from @mastersingh24 ?
muralisr (Mon, 08 May 2017 20:01:15 GMT):
https://chat.hyperledger.org/channel/fabric-maintainers?msg=LcrNDdfqi5NEfcrR8
jeffgarratt (Mon, 08 May 2017 20:14:43 GMT):
@jimthematrix I have seen a different issue, but have not rebased in last few hours
jimthematrix (Mon, 08 May 2017 20:24:07 GMT):
ha, that explained it ;-) I'm pretty sure that was the culprit, will download Gari's patch in 9103 to see. thanks @muralisr
jimthematrix (Mon, 08 May 2017 20:24:37 GMT):
@rickr ^^^ (likely the same issue you are seeing that we just chatted about)
jimthematrix (Mon, 08 May 2017 20:28:04 GMT):
confirmed that 9103 fixed the issue
jimthematrix (Mon, 08 May 2017 20:29:02 GMT):
just +2'ed
jimthematrix (Mon, 08 May 2017 20:35:21 GMT):
note that the end-2-end verify build caught the error but it was ignored: https://jenkins.hyperledger.org/job/fabric-verify-end-2-end-x86_64/2803/console
jimthematrix (Mon, 08 May 2017 20:35:21 GMT):
note that the end-2-end verify build caught the error but it was ignored/skipped: https://jenkins.hyperledger.org/job/fabric-verify-end-2-end-x86_64/2803/console
amber-zhang (Tue, 09 May 2017 00:54:47 GMT):
Has joined the channel.
binhn (Tue, 09 May 2017 03:44:30 GMT):
@jimthematrix thanks for verifying -- `note that the end-2-end verify build caught the error but it was ignored/skipped` we are too clever for our own good :-)
rock_martin (Tue, 09 May 2017 10:21:32 GMT):
Has joined the channel.
glotov (Tue, 09 May 2017 10:31:30 GMT):
Has joined the channel.
shivann (Tue, 09 May 2017 12:44:00 GMT):
Has joined the channel.
bsmita (Tue, 09 May 2017 13:14:15 GMT):
Has joined the channel.
SriramaSharma (Tue, 09 May 2017 13:14:32 GMT):
Has joined the channel.
rodger0514 (Wed, 10 May 2017 01:51:05 GMT):
Has joined the channel.
zhouhuangjing (Wed, 10 May 2017 04:22:41 GMT):
Has joined the channel.
weeds (Wed, 10 May 2017 13:06:35 GMT):
Scrum meeting will start at 9:30AM EST (in 25 minutes). Following is the dial in which is the same that we sent out in the Hyperledger e-mail:
weeds (Wed, 10 May 2017 13:06:37 GMT):
peer scrum (1-888-426-6840 / 33682113)
weeds (Wed, 10 May 2017 13:06:51 GMT):
we will be posting notces here on fabric-peer-endorser-committer channel
simsc (Wed, 10 May 2017 13:29:43 GMT):
1) CI Build Status
- If there is a failure, we discuss and assign the breaking defect. This defect will be the top priority for the team until resolved.
2) Defect status
- We will discuss defects with priority=highest and overall backlog by component
- https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10409
3) QA status. This will be any items from QA not covered already #1 and #2
4) Endgame items.
- We will review any outstanding items on the feature board. This should be priority items in review and waiting to be merged
- https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10404
- We will review end game items. E.G. serviability
- https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10410
5) Documenation status
- https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10406
6) After 1-5, engineers an stay on and discuss any follow up items.
JonathanLevi (Wed, 10 May 2017 14:08:52 GMT):
As suggested/request, I have just created https://jira.hyperledger.org/browse/FAB-3775 to document what we have just discussed on the call...
weeds (Wed, 10 May 2017 14:11:41 GMT):
What was discussed is guidance on how to handle JIra, what fields to fill out etc,..
weeds (Wed, 10 May 2017 14:12:17 GMT):
We've asked help from maintainers to get those best practices documented to share with new people joining community
weeds (Wed, 10 May 2017 14:13:11 GMT):
For CI- nodejs sdk and java sdk are failing- Jim/Rick are investigating with Ramesh. Bug fix did go in 3769 went in 3493 is where fix went in
weeds (Wed, 10 May 2017 14:15:19 GMT):
3768- node sdk test failed- assigned it back to Ramesh
weeds (Wed, 10 May 2017 14:16:25 GMT):
3669- still working on it- main problem is happens quite rarely-
weeds (Wed, 10 May 2017 14:16:49 GMT):
3493- Kostas in review; MERGED
weeds (Wed, 10 May 2017 14:17:18 GMT):
1929- Angelo took that one- working to submit tomorrow
weeds (Wed, 10 May 2017 14:18:00 GMT):
Alpha 2 list- removing/adding
weeds (Wed, 10 May 2017 14:22:04 GMT):
The drive is to try to get the completion of this list by noon tomorrow
weeds (Wed, 10 May 2017 14:22:28 GMT):
So far the progress is very good- we only have 1 more to do -- will talk to Gari to see if we need this item, rest we have CR's . the remaining are 4 and have been in review 4 times over
weeds (Wed, 10 May 2017 14:22:46 GMT):
if there are comments on this list- please get with the maintainers per request of Binh Nguyen
weeds (Wed, 10 May 2017 14:24:14 GMT):
Feature board--> Publish artifacts with Maven , working with Linux foundation--- 1678--> Tool... talked with Gari-- need to run it by Varad and Paul... and design... we need to post on e-mail thread to make sure the community knows about it.
weeds (Wed, 10 May 2017 14:24:41 GMT):
Fabric endorser- go lang stub interface-- not integrated for alpha 2- hold off
weeds (Wed, 10 May 2017 14:24:48 GMT):
This is for the Java Shim- not cirtical for alpha 2
weeds (Wed, 10 May 2017 14:26:33 GMT):
Elli has a question regarding 2 tasks that have been opened. One by Keith, one by Elli... conversations with Greg Haskins
weeds (Wed, 10 May 2017 14:28:15 GMT):
Binh is suggesting to work with Greg in JIRa item that we already have and discussion there.
weeds (Wed, 10 May 2017 14:33:07 GMT):
System channel is whatever name you want- by default it's test chain id.. we've done a lot of bad things relying on test id chain is existing. The name of it specifically. Murali is fairly certain that when I use test chain id as proper channel and do things- it does not work. Maybe it's Murali... And we can take decision if test chain id does not work at all- and maybe we don't need it
weeds (Wed, 10 May 2017 14:34:21 GMT):
Ordering system channel is required for orderers- it's not required for peer transactions for legacy sake- nothing but orderer should go through that. if you start peer, create a channel... start a pper and join test chain id- Murali thinks this does not work. I would not expect it to break (per Jason).. and if that's true- than noone using it. Then I will add a JIRA item--- @muralisr please add the JIRa channel
muralisr (Wed, 10 May 2017 14:52:02 GMT):
`Murali is fairly certain that when I use test chain id as proper channel and do things- it does not work. Maybe it's Murali... ` - right. I have a todo to make sure we understand `testchainid` behavior. It was used when in the pre-channel days as a means to use bootstrap the system and excercise end-2-end without having proper channel implementation
muralisr (Wed, 10 May 2017 14:52:02 GMT):
`Murali is fairly certain that when I use test chain id as proper channel and do things- it does not work. Maybe it's Murali... ` - right. It was used when in the pre-channel days as a means to use bootstrap the system and excercise end-2-end without having proper channel implementation
muralisr (Wed, 10 May 2017 14:54:41 GMT):
if it continues to work (and its just user error on my part) there is some value in keeping it (and documenting it ). If not there's an opportunity to remove using `testchainid` as a default channel for e2e.
muralisr (Wed, 10 May 2017 14:55:16 GMT):
I have a todo to make sure we if `testchainid` works - will update JIRA
toddinpal (Wed, 10 May 2017 15:40:04 GMT):
How many peers must a client access to get a proposed transaction endorsed?
jeffgarratt (Wed, 10 May 2017 15:57:45 GMT):
@toddinpal this is determined by the endorsement policy of the chaincode.
jeffgarratt (Wed, 10 May 2017 15:59:59 GMT):
the current bootstrap mechanism I believe use a N_of policy with 1 of the writers defined in the latest channel config
jeffgarratt (Wed, 10 May 2017 16:00:39 GMT):
if you wish that to require endorsement by all, then you can specify that during channel config
jeffgarratt (Wed, 10 May 2017 16:01:03 GMT):
in that case, the number of channel members (MSPs) will determine the number of endrosements you will need I believe
toddinpal (Wed, 10 May 2017 16:01:17 GMT):
@jeffgarratt I understand the endorsement policy, I'm just curious if it is the client's responsibility to seek the required endorsements or does a peer do that on the client's behalf
jeffgarratt (Wed, 10 May 2017 16:01:35 GMT):
ahhh, that is a @jimthematrix question or perhaps @muralisr
jeffgarratt (Wed, 10 May 2017 16:01:35 GMT):
ahhh, that is a @muralisr or perhaps @jimthematrix question
muralisr (Wed, 10 May 2017 16:12:13 GMT):
@toddinpal The client would implement the biz requirements (endorsements, etc) using the peer. Fabric would not try to automatically figure out "what endorsements are needed for the this Proposal" ... hope that helps a bit ?
jimthematrix (Wed, 10 May 2017 17:26:35 GMT):
@toddinpal ideally the client should be able to discover this from the instantiated chaincodes, there is a query available for that (and is supported by node and java SDK) but it currently doesn't return the endorsement policy associated with the instantiated chaincode. so at this point the client needs to know for a specific transaction what is the expected endorsement policy (1-of-3, 2-of-2, etc) and decide how many peers to send the proposal to
jtclark (Wed, 10 May 2017 17:47:07 GMT):
Has joined the channel.
JonathanLevi (Wed, 10 May 2017 18:23:39 GMT):
@tkuhrt @tkuhrt [ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=ZyYLTH53iySCh2v4F)
JonathanLevi (Wed, 10 May 2017 18:23:39 GMT):
@tkuhrt @dhuseby [ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=ZyYLTH53iySCh2v4F)
Senthil1 (Thu, 11 May 2017 15:24:30 GMT):
Can we use more than one orderer for a channel?
Senthil1 (Thu, 11 May 2017 15:24:30 GMT):
Is it possible to use more than one orderer for a channel?
toddinpal (Thu, 11 May 2017 18:00:36 GMT):
@jimthematrix So is it the application's responsibility to seek the endorsements, or does the SDK do this for the application?
jimthematrix (Thu, 11 May 2017 18:02:48 GMT):
when you call Chain.sendTransactionProposal(), the SDK send a request to the list of peers in the chain object to solicit endorsements
jimthematrix (Thu, 11 May 2017 18:03:16 GMT):
the peer's endorsements are included in the ProposalResponse objects returned from that function call
jimthematrix (Thu, 11 May 2017 18:03:55 GMT):
which you then use to send to the orderer for consensus and validation/commit by calling Chain.sendTransaction()
toddinpal (Thu, 11 May 2017 18:04:58 GMT):
OK, thanks
markparz (Fri, 12 May 2017 13:29:55 GMT):
Getting ready to start the scrum call 1-888-426-6840 / 33682113
markparz (Fri, 12 May 2017 13:49:34 GMT):
1) CI Build (Ramesh) Green - couple of inconsistent behave tests working on today. Posted on CI channel of Rocket
2) Defects (use 2 widgets)
- https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10409
3669 - Go unit test failure - WIP, failure inconsistent
3320 - No block received from peer - Won't be resolved anytime soon part of bigger issue of network connectivity like 3310. Have to have cloud deployment between network devices between components. Working with Scott and his environment. Not a show stopper
3310 - gRPC timeout - Want to upgrade gRPC to the next version to see if it works. Will reproduce with current.
No blockers for Composer
3) QA -
Nothing further
4) Unit test
Is it ok to get unit test into Alpha 2 or hold out? We need to continue to work on unit test, but no merging for Alpha 2.
5) Endgame items.
- We will review any outstanding items on the feature board. This should be priority items in review and waiting to be merged
- https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10404
- We will review end game items. E.G. serviability
- https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10410
6) Documenation
- https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10406
Nothing at this time.
Using FAB-3040 for tracking the Alpha 2 status, epics are getting mixed. We need to retitle it.
Please review Barry's email propose on test.
Elli - helping with fabric-ca testing coverage and with Vlad on HSM.
Peer needs more coverage. There is a lot of code in the peer package for the cli, so the code has been exercise, just do not have UT to show the coverage. Murali working on server side with SHIM UT and hit on that as well.
Fab-648 - has been marked as done
Power status - working with Oregon university, all power verification currently disabled.
markparz (Fri, 12 May 2017 13:49:34 GMT):
1) CI Build (Ramesh) Green - couple of inconsistent behave tests working on today. Posted on CI channel of Rocket
2) Defects (use 2 widgets)
- https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10409
3669 - Go unit test failure - WIP, failure inconsistent
3320 - No block received from peer - Won't be resolved anytime soon part of bigger issue of network connectivity like 3310. Have to have cloud deployment between network devices between components. Working with Scott and his environment. Not a show stopper
3310 - gRPC timeout - Want to upgrade gRPC to the next version to see if it works. Will reproduce with current.
No blockers for Composer
3) QA -
Nothing further
4) Unit test
Is it ok to get unit test into Alpha 2 or hold out? We need to continue to work on unit test, but no merging for Alpha 2.
5) Endgame items.
- We will review any outstanding items on the feature board. This should be priority items in review and waiting to be merged
- https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10404
- We will review end game items. E.G. serviability
- https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10410
6) Documenation
- https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10406
Nothing at this time.
Using FAB-3040 for tracking the Alpha 2 status, epics are getting mixed. We need to retitle it.
Please review Barry's email propose on test.
Elli - helping with fabric-ca testing coverage and with Vlad on HSM.
Peer needs more coverage. There is a lot of code in the peer package for the cli, so the code has been exercise, just do not have UT to show the coverage. Murali working on server side with SHIM UT and hit on that as well.
Fab-648 - has been marked as done
Power status - working with Oregon university, all power verification currently disabled.
markparz (Fri, 12 May 2017 13:50:16 GMT):
Notes from scrum ^^
rliu (Fri, 12 May 2017 14:37:48 GMT):
Has joined the channel.
rliu (Fri, 12 May 2017 14:40:52 GMT):
We are testing how to put multiple transactions into a block. Following the instruction from @jimthematrix, here is what I did:
1. Modify configtx.yaml at fabric-sdk-node/test/fixtures/channel to set BatchTimeout to 1200s. Copy this file to fabric/sampleconfig.
2. Use configtxgen tool to generate "channel.tx".
3. Copy "channel.tx" to fabric-sdk-node/test/fixtures/channel.
4. Uncomment the code in fabric-sdk-node/test/integration/e2e/create-channel.js to load channel.tx, i.e. :
// use this when the config comes from the configtx tool
data = fs.readFileSync(path.join(__dirname, '../../fixtures/channel/channel.tx'));
....
I'm able to create a new channel. However, after I created two transactions using this new channel within 1 minute, I got 3 blocks. Each block still contains only one transaction. Here are the parameters I changed at configtx.yaml:
BatchTimeout:1200s
BatchSize:
MaxMessageCount: 100
AbsoluteMaxBytes: 99 MB
PreferredMaxBytes: 10 MB
We'd like to test how to put multiple transactions to a block. Could you advice how to make this happen? Thanks!
tomconte (Fri, 12 May 2017 15:32:30 GMT):
Has joined the channel.
jeffgarratt (Fri, 12 May 2017 16:53:02 GMT):
@rliu search for "Orderer.BatchSize.MaxMessageCount unset, setting to" in orderer log
jeffgarratt (Fri, 12 May 2017 16:53:02 GMT):
@rliu Check the log for the orderer properties and see what batchsize is
jeffgarratt (Fri, 12 May 2017 16:54:33 GMT):
specifically => "Orderer.BatchSize.AbsoluteMaxBytes unset, setting to"
jeffgarratt (Fri, 12 May 2017 16:54:33 GMT):
specifically look for anything related to batchsize, etc.
jeffgarratt (Fri, 12 May 2017 16:59:01 GMT):
@rliu also, the first block of any channel should only have 1 TX, as this is controlled by the orderer who puts config_updates into blocks by themselves
muralisr (Fri, 12 May 2017 17:29:08 GMT):
@here a few days back I had a TODO to check if the default "testchainid" can still be used (for some reason I thought it was not working anymore). It *is* working... here is the MINIMAL set of instructions to run some end-to-end transactions using the `testchainid` channel using the default MSP setting
muralisr (Fri, 12 May 2017 17:29:26 GMT):
```
Instructions to use default "testchainid" channel without having to create or join a channel
--------------------------------------------------------------------------------------------
setup
-----
make peer
make orderer
all commands in "fabric/" folder
rm -rf /var/hyperledger/*
start orderer
-------------
orderer
start peer (note we are NOT using --peer-defaultchain=false... ie, we are using the default chain)
---------
peer node start
execute commands
----------------
peer chaincode install -n mycc -v 0 -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02
peer chaincode instantiate -n mycc -v 0 -c '{"Args":["init","a","100","b","200"]}'
peer chaincode invoke -n mycc -c '{"Args":["invoke","a","b","10"]}'
peer chaincode query -n mycc -c '{"Args":["query","a"]}'
```
muralisr (Fri, 12 May 2017 17:29:26 GMT):
```
Instructions to use default "testchainid" channel without having to create or join a channel
--------------------------------------------------------------------------------------------
setup
-----
make peer
make orderer
all commands in "fabric/" folder
rm -rf /var/hyperledger/*
start orderer
-------------
orderer
start peer (note we are NOT using --peer-defaultchain=false... ie, we are using the default chain)
---------
peer node start -o 127.0.0.1:7050
execute commands
----------------
peer chaincode install -n mycc -v 0 -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02
peer chaincode instantiate -n mycc -v 0 -c '{"Args":["init","a","100","b","200"]}'
peer chaincode invoke -n mycc -c '{"Args":["invoke","a","b","10"]}'
peer chaincode query -n mycc -c '{"Args":["query","a"]}'
```
muralisr (Fri, 12 May 2017 17:29:26 GMT):
```
Instructions to use default "testchainid" channel without having to create or join a channel
--------------------------------------------------------------------------------------------
setup
-----
make peer
make orderer
all commands in "fabric/" folder
rm -rf /var/hyperledger/*
start orderer
-------------
orderer
start peer (note we are NOT using --peer-defaultchain=false... ie, we are using the default channel)
---------
peer node start -o 127.0.0.1:7050
execute commands
----------------
peer chaincode install -n mycc -v 0 -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02
peer chaincode instantiate -n mycc -v 0 -c '{"Args":["init","a","100","b","200"]}'
peer chaincode invoke -n mycc -c '{"Args":["invoke","a","b","10"]}'
peer chaincode query -n mycc -c '{"Args":["query","a"]}'
```
muralisr (Fri, 12 May 2017 17:29:26 GMT):
```
Instructions to use default "testchainid" channel without having to explicitly create/join a channel
-------------------------------------------------------------------------------------------------
setup
-----
make peer
make orderer
all commands in "fabric/" folder
rm -rf /var/hyperledger/*
start orderer
-------------
orderer
start peer (note we are NOT using --peer-defaultchain=false... ie, we are using the default channel)
---------
peer node start -o 127.0.0.1:7050
execute commands
----------------
peer chaincode install -n mycc -v 0 -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02
peer chaincode instantiate -n mycc -v 0 -c '{"Args":["init","a","100","b","200"]}'
peer chaincode invoke -n mycc -c '{"Args":["invoke","a","b","10"]}'
peer chaincode query -n mycc -c '{"Args":["query","a"]}'
```
binhn (Fri, 12 May 2017 17:31:43 GMT):
should we include this info in the chaincode.rst?
muralisr (Fri, 12 May 2017 17:32:12 GMT):
this can be useful for some minimal testing ... not for serious work
muralisr (Fri, 12 May 2017 17:32:22 GMT):
good idea @binhn
muralisr (Fri, 12 May 2017 17:33:08 GMT):
there's also variations of this with dev mode and docker based config we can include
mastersingh24 (Sat, 13 May 2017 17:33:31 GMT):
[I don't think we should promote the use of the testchainid. We really need to rip that out of the peer - https://jira.hyperledger.org/browse/FAB-3358 ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=bvnbmjrAMph8NS6Sa) @muralisr
mastersingh24 (Sat, 13 May 2017 17:33:31 GMT):
[I do not think we should promote the use of the testchainid. We really need to rip that out of the peer - https://jira.hyperledger.org/browse/FAB-3358 ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=bvnbmjrAMph8NS6Sa) @muralisr
NiketYende (Mon, 15 May 2017 04:54:15 GMT):
Has joined the channel.
NiketYende (Mon, 15 May 2017 05:21:34 GMT):
@jeffgarratt @rliu I tried checking the log file for orderer but could not find any reference to "batchsize". Also i did not find orderer properties file. Could you help me in this regard?
NiketYende (Mon, 15 May 2017 05:24:32 GMT):
{"log":"\u001b[36m2017-05-12 13:54:17.414 UTC [orderer/common/blockcutter] Ordered -\u003e DEBU 13f2\u001b[0m Enqueuing message into batch\n","stream":"stderr","time":"2017-05-12T13:54:17.416346589Z"}
{"log":"\u001b[36m2017-05-12 13:54:19.414 UTC [orderer/solo] main -\u003e DEBU 13f3\u001b[0m Batch timer expired, creating block\n","stream":"stderr","time":"2017-05-12T13:54:19.414960793Z"}
{"log":"\u001b[36m2017-05-12 13:54:19.414 UTC [kvledger] retrieveBlockByNumber -\u003e DEBU 13f4\u001b[0m retrieveBlockByNumber() - blockNum = [2]\n","stream":"stderr","time":"2017-05-12T13:54:19.414992943Z"}
NiketYende (Mon, 15 May 2017 05:24:41 GMT):
This is what we get.
muralisr (Mon, 15 May 2017 11:43:33 GMT):
https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=qDdau6Wj9KZ4FJz7J
muralisr (Mon, 15 May 2017 11:44:33 GMT):
@mastersingh24 fine with me... figured if testchainid is broken anyway, no one can be using it and we can rip it out
muralisr (Mon, 15 May 2017 11:48:13 GMT):
but turned out it it was not ... its advantages (lesser steps to get something up and running) are outweighed by the disadvantages IMO (hides basic complexity that users have to deal with anyway at some point, "testchainid" has to be disabled in real deployments, etc)
muralisr (Mon, 15 May 2017 11:48:33 GMT):
+1 for removal of testchainid
markparz (Mon, 15 May 2017 13:46:21 GMT):
SCRUM notes for Monday:
markparz (Mon, 15 May 2017 13:46:23 GMT):
ALPHA 2 - some confusion.
Mark will send out an email with info on - > Here are the images, here are the things in alpha2, and delta(point to wiki)
fab-ca
fabric
node.js SDK
Doc
No Java SDK
Automated test is currently blocked
UT is at 71% overall
4 CRs for fab-ca waiting
Murali has some shim testings that will go in today
Artem working on event UT
markparz (Mon, 15 May 2017 13:46:23 GMT):
ALPHA 2 - some confusion.
Mark will send out an email with info on - > Here are the images, here are the things in alpha2, and delta(point to wiki)
Alpha 2 includesfab-ca
fabric
node.js SDK
Doc
No Java SDK
Automated test is currently blocked
UT is at 71% overall
4 CRs for fab-ca waiting
Murali has some shim testings that will go in today
Artem working on event UT
czar0 (Mon, 15 May 2017 20:08:49 GMT):
Has joined the channel.
vdods (Mon, 15 May 2017 21:29:27 GMT):
Has joined the channel.
vdods (Mon, 15 May 2017 21:43:09 GMT):
Hi all, under what circumstances will a peer clean up the docker image for a chaincode that it has run? Is there a way to force this to happen upon peer shutdown?
rangak (Tue, 16 May 2017 06:10:05 GMT):
Hacked up a little utility to help a bit in identifying significant events in orderer and peer logfiles. It is a simplistic algorithm. Welcome pointer to alternatives out there and/or improvements. https://github.com/Rangak/loglights
zemtsov (Tue, 16 May 2017 08:49:13 GMT):
Has left the channel.
laurentkatz (Tue, 16 May 2017 10:23:31 GMT):
Has joined the channel.
weeds (Tue, 16 May 2017 11:20:27 GMT):
@rangak nice! @jimthematrix @muralisr Check it out on what rangak did.
muralisr (Tue, 16 May 2017 11:32:59 GMT):
cool @rangak ... wonder if can add some simple search capabilities (perhaps just a regex grep over the logs after sorting) ? for example in the screen shot search for "Org1MSP" (or if/when we have them, search by TxID)
rangak (Tue, 16 May 2017 14:15:03 GMT):
@weeds Thanks ! Hope you find it useful and can improve it. It is very simple.
rangak (Tue, 16 May 2017 14:16:36 GMT):
@muralisr That's a good idea. Will add that. Thanks. It is a very coarse algorithm that relies on user relevant events being separated in time and deems clustered lines as belonging to the same "event". It could be much improved with knowledge of how fabric orderers and peers log. Please do feel free to improve it and send pull requests.
rangak (Tue, 16 May 2017 16:10:27 GMT):
@muralisr Updated with regex support. Enjoy! https://github.com/Rangak/loglights
muralisr (Tue, 16 May 2017 16:12:03 GMT):
Thanks @rangak ...will check it out
vdods (Tue, 16 May 2017 16:46:17 GMT):
Has left the channel.
rmohta (Tue, 16 May 2017 17:04:36 GMT):
@here is it possible to have a policy where we can restrict asset creation to one organization. Another organization can only update asset after a certain state, etc. For example, in car-lease demo - a new car asset can be created only by manufacturer.
rmohta (Tue, 16 May 2017 17:05:19 GMT):
^^^ can this be done at function level within a single chaincode?
jeffgarratt (Tue, 16 May 2017 17:05:37 GMT):
@rmohta I would refer to composer which specializes in this concept
jeffgarratt (Tue, 16 May 2017 17:05:37 GMT):
@rmohta I would refer to composer which specializes in this concept https://chat.hyperledger.org/channel/composer
jeffgarratt (Tue, 16 May 2017 17:06:02 GMT):
I think you will find exactly what you are looking for
rmohta (Tue, 16 May 2017 17:08:01 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=ZfGS9YeavPyoeDfqh) @jeffgarratt Thank You. I will ask my question there too. But out of curiosity, is that something possible in fabric?
jeffgarratt (Tue, 16 May 2017 17:08:40 GMT):
composer offers a higher level DSL to provide the semantics of asset transfer you are looking for
jeffgarratt (Tue, 16 May 2017 17:08:45 GMT):
and yes :)
jeffgarratt (Tue, 16 May 2017 17:09:03 GMT):
but the editor and language for composer is both salient and powerful
jeffgarratt (Tue, 16 May 2017 17:09:22 GMT):
I would checkout some of the videos they have posted, they are very compelling
jeffgarratt (Tue, 16 May 2017 17:09:28 GMT):
@rmohta ^^^
jeffgarratt (Tue, 16 May 2017 17:10:11 GMT):
they (the composer team) is working diligently to prepare composer for fabric-1.0-alpha2 asap
jeffgarratt (Tue, 16 May 2017 17:10:29 GMT):
but it is demonstrable today and works with v0.6 as well
rmohta (Tue, 16 May 2017 17:11:45 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=kssbRmRNcNpKvmqW7) @jeffgarratt Cool. Will look. For our usecase we have decided to use 1.0. But will check it out. Thank you!!
jeffgarratt (Tue, 16 May 2017 17:11:49 GMT):
@rmohta https://www.youtube.com/watch?v=fdFUsrsv5iw
jeffgarratt (Tue, 16 May 2017 17:12:17 GMT):
you should be fairly well insulated from fabric changes using their DSL
rahulhegde (Tue, 16 May 2017 23:22:12 GMT):
@muralisr
I had question on chaincode upgrade. I see we have to follow the install + upgrade pattern for upgrading the user-chaincode for the peer.
1. If there are any in-flight transaction endorsed using old-version user-chaincode, would they be committed by the time chaincode is upgraded to a new version?
rahulhegde (Tue, 16 May 2017 23:22:12 GMT):
@muralisr
I had question on chaincode upgrade. I see we have to follow the install + upgrade pattern for upgrading the user-chaincode for the peer.
1. If there are any in-flight transaction endorsed using old-version user-chaincode, would they be committed by the time chaincode is upgraded to a new version?
2. I tried upgrading to a new version user-chaincode using E2E Peer CLI for only 1 peer (peer0) and then tried invoking a new transaction on the 2nd peer (who is not yet upgraded - peer1); this fails saying invalid deployment spec. Can you explain - does this upgrade on peer0 invalidates the deployment spec across that channel/chaincode thus mandating an user-chaincode upgrade?
3. Another case, where Peer0 is installed + running with upgraded chaincode (v2.0) however peer1 is installed with old chaincode (v1.0). Peer CLI is invoked on Peer0 and is set with self-endorsed policy. This will pass the endorsement, shouldn't the peer1 at the committing time, can reject the block?
4. Is there best practice guide like i see `docker ps` and `docker images` shows the old chaincode running, can i stop the docker container and at the same time remove the image?
rahulhegde (Tue, 16 May 2017 23:22:12 GMT):
@muralisr
I had question on chaincode upgrade. I see we have to follow the install + upgrade pattern for upgrading the user-chaincode for the peer.
1. If there are any in-flight transaction endorsed using old-version user-chaincode, would they be accepted by committing peer by the time the chaincode is upgraded to a new version?
2. I tried upgrading to a new version user-chaincode using E2E Peer CLI for only 1 peer (peer0) and then tried invoking a new transaction on the 2nd peer (who is not yet upgraded - peer1); this fails saying invalid deployment spec. Can you explain - does this upgrade on peer0 invalidates the deployment spec across that channel/chaincode thus mandating an user-chaincode upgrade?
3. Another case, where Peer0 is installed + running with upgraded chaincode (v2.0) however peer1 is installed with old chaincode (v1.0). Peer CLI is invoked on Peer0 and is set with self-endorsed policy. This will pass the endorsement, shouldn't the peer1 at the committing time reject the block, this is same as point 1 and so as the answer?
4. Is there best practice guide like i see `docker ps` and `docker images` shows the old chaincode running, can i stop the docker container and at the same time remove the image?
muralisr (Wed, 17 May 2017 00:09:40 GMT):
@rahulhegde
muralisr (Wed, 17 May 2017 00:11:20 GMT):
1. transactions based on previous version of CC and committed on or above the block the upgrade is committed will fail. Transactions committed on blocks previous to the block on which upgrade happens will succeed
muralisr (Wed, 17 May 2017 00:11:20 GMT):
1. transactions based on previous version of CC and committed on or greater than the block the upgrade is committed upon will fail. Transactions committed on blocks previous to the block on which upgrade happens will succeed
muralisr (Wed, 17 May 2017 00:12:05 GMT):
2. after upgrade is committed on a channel, all peers on that channel on whom endorsment is required should install the new version of the chaincode
muralisr (Wed, 17 May 2017 00:13:55 GMT):
3. peers may not have install chaincode..if one peer without the chaincode accepted the TX and another with the CC rejected, it will lead to diverging ledgers (non-determinism)
muralisr (Wed, 17 May 2017 00:13:55 GMT):
3. some peers may not have installed chaincode..if one peer without the chaincode accepted the TX and another with the CC rejected, it will lead to diverging ledgers (non-determinism)
muralisr (Wed, 17 May 2017 00:15:35 GMT):
4. yes ... but please see take a look at https://jira.hyperledger.org/browse/FAB-3326 for direction in this area
muralisr (Wed, 17 May 2017 00:18:18 GMT):
Anything to add to the above @jiangyaoguo ?
reoim10 (Wed, 17 May 2017 01:06:01 GMT):
Has joined the channel.
rahulhegde (Wed, 17 May 2017 02:35:15 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=MBkBvHBPKNzHfQQTz) @muralisr
1. So upgrade block (assuming this will be a block holding a single upgrade transaction) will act as a marker and decided to reject or accept based on the chaincode-version information that should be available in each transaction.
Second thought - wasn't checking only the read-set version sufficient to accept or reject block transaction (as committer-only-peer will not have user chain-code installed-instantiated). which case resulted to have marker?
jiangyaoguo (Wed, 17 May 2017 02:43:50 GMT):
@rahulhegde upgrade block may have mutiple txs. commiter will invalid all the other txs which invoke the upgraded cc(no matter old or new version) to avoid upgrade tx being invalided because of RWset conflict. every tx has a field that state the cc version it invokes, commiter will check the version match the latest version of cc qureied from lscc.
weeds (Wed, 17 May 2017 10:56:39 GMT):
@markparz the questions above from rahulhegde and responses from muralisr would be good to add to documentation, so thought I would highlight. Thanks!
weeds (Wed, 17 May 2017 13:31:27 GMT):
We are starting scrum call-
weeds (Wed, 17 May 2017 13:31:44 GMT):
(1-888-426-6840 / 33682113)
weeds (Wed, 17 May 2017 13:31:51 GMT):
Taking notes:
weeds (Wed, 17 May 2017 13:32:27 GMT):
For CI on fabric-ci status is posted- there is a bug that was posted as CA was crashing- FAB-3974
weeds (Wed, 17 May 2017 13:32:36 GMT):
Keith Smith is working on it
weeds (Wed, 17 May 2017 13:33:01 GMT):
Java SDK is working , because it went back to a previous image (ie alpha 2 images)
weeds (Wed, 17 May 2017 13:33:16 GMT):
Nodejs sdk is failing as it is working with the recent images so why it's failling
weeds (Wed, 17 May 2017 13:33:49 GMT):
Murali to follow up how we checked in something that caused the CI to fail
weeds (Wed, 17 May 2017 13:34:36 GMT):
Yesterday- we worked on 685 to publish java artivacts to maven- Linux foundation said that is not possible. We need @cbf on whether this is ok Rick does not agree with the new approached.
weeds (Wed, 17 May 2017 13:34:36 GMT):
Yesterday- we worked on 684 to publish java artivacts to maven- Linux foundation said that is not possible. We need @cbf on whether this is ok Rick does not agree with the new approached.
weeds (Wed, 17 May 2017 13:34:54 GMT):
Rick adding comments to the JIRA on his opinion on this
weeds (Wed, 17 May 2017 13:35:25 GMT):
Gari asked for a link- what is the exact url on where the binaries posted- crytpogen and configtxgen are posted
weeds (Wed, 17 May 2017 13:35:42 GMT):
@rameshthoomu please provide link here for where binaries posted (and add to the jira)
weeds (Wed, 17 May 2017 13:37:14 GMT):
FAB 3925- this is getting started update for doc- it claims it's still in progress- @nickgaski ? It's Ramesh's change to do the Nexus push- that is what is blocking Nick to do the final getting started. are you looking for +2 on Nexus (gari/Greg gave comments).. i will trigger that job on alpha 2 commits (please add comments to clarrify in 3925)... we can't consider alpha 2 until this is done.
weeds (Wed, 17 May 2017 13:37:43 GMT):
FAB 3669- person is out sick
weeds (Wed, 17 May 2017 13:38:20 GMT):
going back to 3925 which is getting started.. but Ramesh is FAB 2986 which does the publish-- there is a codependency here.
weeds (Wed, 17 May 2017 13:38:37 GMT):
Anything else on bugs?
nickgaski (Wed, 17 May 2017 13:40:27 GMT):
8939 is blocking me on 3925 - updating getting started. This is the CR to publish the binaries on nexus
weeds (Wed, 17 May 2017 13:40:47 GMT):
Another team joined today and shared the following: - Dave started to look at not using keystore and can't get it to work... I need to understand why I can't use other file location. .hsc.keystore. The other thing I see is the node.sdk is generating console logs with errors... I don't think we want this. Dave is going to see if he has api changes- if not- he will reopen the JIRA he has and will open it as highest.
weeds (Wed, 17 May 2017 13:41:33 GMT):
Please open JIRa on the errors seen due to nodejs.sdk-- he will open it shortly
weeds (Wed, 17 May 2017 13:47:51 GMT):
Unit test--> We have a ton of unit tests out in review (you can see quite a list on fabric-pr-review channel) we should have maintainers working on getting this stuff merged in provided it follows the criteria:
weeds (Wed, 17 May 2017 13:48:04 GMT):
https://wiki.hyperledger.org/projects/fabric/release_exit_criteria
weeds (Wed, 17 May 2017 13:48:27 GMT):
go to bottom of this link and you will see the guidance maintainers and those checking in pieces of code, test, documentation should be following for version 1.0
weeds (Wed, 17 May 2017 13:49:04 GMT):
For logging components- we should be advancing logging capabilities.. what is the right way to do this to make sure it's not disruptive? Murali plans to surface this on one of channels for discussion and will do that here on peer-endorser-comitter
weeds (Wed, 17 May 2017 13:51:01 GMT):
@mastersingh24 Note the logging discussion to happen here with @muralisr
weeds (Wed, 17 May 2017 13:52:20 GMT):
Anil asking for hepl on reviews - he was highlighting 9285, 3730, 3638, 3735 (fabs)
weeds (Wed, 17 May 2017 13:53:03 GMT):
We need to ask on maintainers on how the alpha 2 will be announced
weeds (Wed, 17 May 2017 13:53:34 GMT):
Dave has some concerns- we are trying to get some feedback and this is not a release candidate
weeds (Wed, 17 May 2017 13:53:50 GMT):
Announce meaning- sending something to e-mail list
weeds (Wed, 17 May 2017 13:55:12 GMT):
@cbf @JonathanLevi note comments on how to communicate the alpha 2 up above (when is appropriate time, who is going to post on hyperledger email distro that alpha 2 is available for people to try out)
cbf (Wed, 17 May 2017 13:55:49 GMT):
@weeds @JonathanLevi will be making the announce
weeds (Wed, 17 May 2017 13:56:10 GMT):
(Please note we did read through Barry Mosakowski's note on system test that he posted on the e-mail distro list- this deals with how he was proposing how to do system test)
rahulhegde (Wed, 17 May 2017 19:02:02 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=27ThbzyxA2ocsdRvq) @jiangyaoguo @muralisr
Can you acknowledge - do you say upgrade block can have multiple transaction. Do we mean a single block can hold transaction created as part of Invoke call + upgrade config transaction?
If Yes - Do we say these transaction within this block (containing the upgrade transaction config) will be marked Invalid or not accepted?
If still - Yes - Is it mandatory to Invalid the transaction which are part of the upgrade block as RW-Version must get independently verified by committing peer (think who is not even the endorser) irrespective of user-chaincode upgrade?
rahulhegde (Wed, 17 May 2017 19:02:02 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=27ThbzyxA2ocsdRvq) @jiangyaoguo @muralisr
Can you acknowledge - do you say upgrade block can have multiple transaction. Do we mean a single block can hold transaction created as part of Invoke call + upgrade config transaction?
If Yes - Do we say these invoke transaction within this block (containing the upgrade transaction config) will be marked Invalid or not accepted?
If still - Yes - Is it mandatory to Invalid the transaction which are part of the upgrade block as RW-Version must get independently verified by committing peer (think who is not even the endorser) irrespective of user-chaincode upgrade?
muralisr (Wed, 17 May 2017 19:12:45 GMT):
@rahulhegde orderer could receive invoke and upgrade (say from different peers) and put them in the same block and sent for committment. So Yes to the first question. On the committer side, the Upgrade tx will go through (assuming it succeeds other checks such as endorsement policy) but the invoke transactions for same upgraded chaincode on the block with be marked Invalid. Since all committers on the channel will evaluate the block in the same manner, they all will end up with the same end result - valid upgraded transaction and invalidated invoke transactions that happened to end up on the upgraded transaction's block.
rahulhegde (Wed, 17 May 2017 20:42:10 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=WhqjwdoSDqC5hResc) @muralisr
` but the invoke transactions for same upgraded chaincode on the block with be marked Invalid ` v/s ` commiter will invalid all the other txs which invoke the upgraded cc(no matter old or new version)` which one is true?
muralisr (Wed, 17 May 2017 20:44:21 GMT):
@rahulhegde its probably just words, but they are saying (at least tryong to say) the same thing
muralisr (Wed, 17 May 2017 20:48:39 GMT):
Considering a block of transactins for commitment; "invoke txs generated from a CC ending up on the same block as a TX for upgrading the CC.." in that statement, the "invoke txs" will be invalidated and the "upgrade TX" marked valid (provided it passed other tests)
rahulhegde (Wed, 17 May 2017 21:25:57 GMT):
Had a offline chat with Murali
```
Legend
* [] is a blockchain-block separator
* Tn are the ledger transaction
```
```
[T1], [T2, T3], [T4, T5]
where:
T1 - transaction endorsed on user-chaincode v1.0
T2 - transaction endorsed on user-chaincode v1.0
T3 - upgrade chaincode transaction having v1.1
T4 - transaction endorsed on user-chaincode v1.0
T5 - transaction endorsed on user-chaincode v1.1
```
```
Peer Committer processing/order
T1 - accepted
T3 - accepted
T2 - invalid
T4 - invalid
T5 - accepted
```
Thanks @muralisr
muralisr (Wed, 17 May 2017 21:26:53 GMT):
thats nicely done, @rahulhegde !
RistoAlas (Thu, 18 May 2017 09:40:58 GMT):
Has joined the channel.
jongeun.park (Thu, 18 May 2017 10:48:50 GMT):
Has joined the channel.
rmohta (Thu, 18 May 2017 16:16:04 GMT):
@here A silly question, when we install a chaincode in peer1-org1 with policy for org1 and org2 members - do we have to install chaincode for peer2 too? I'm assuming we have to. Can someone confirm?
rmohta (Thu, 18 May 2017 16:16:04 GMT):
@here A silly question, when we install a chaincode in peer1-org1 with policy for org1 and org2 members - do we have to install chaincode for peer for org 2 or peer 2 of same org too? I'm assuming we have to. Can someone confirm?
jimthematrix (Thu, 18 May 2017 16:16:52 GMT):
@rmohta each peer node that will be later asked to endorser a transaction must have the chaincode installed
jimthematrix (Thu, 18 May 2017 16:17:22 GMT):
if you plan to send transaction proposals to peers in org2, or peer2 in org1, then they must have the chaincode installed first
rmohta (Thu, 18 May 2017 16:17:51 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=ezBRGEMf7gPp5opXS) @jimthematrix OKay. So every peer should go and install the chaincode separately. Is there a need/way for us to make sure - org1 and org2 peer are using the same chaincode?
rmohta (Thu, 18 May 2017 16:17:51 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=ezBRGEMf7gPp5opXS) @jimthematrix OKay. So every peer should go and install the chaincode separately. Is there a need/way for us to make sure - org1 and org2 peer are using the same chaincode? Same version and same spec?
jimthematrix (Thu, 18 May 2017 16:20:55 GMT):
they do need to be same version, exactly the same code, in order for the chaincode instantiate call to succeed
rmohta (Thu, 18 May 2017 22:37:17 GMT):
Has anyone encountered this error when trying to instantiate chaincode `Error: Error endorsing chaincode: rpc error: code = 2 desc = Error starting container: API error (500): {"message":"Error parsing reference: \"dev-peer0-assetOperationscc-2\" is not a valid repository/tag"}`
jeffgarratt (Thu, 18 May 2017 23:25:20 GMT):
@rmohta are you sure you have installed the chaincode?
rmohta (Thu, 18 May 2017 23:25:49 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=q7jxRrHPRR5xmb2o6) @jeffgarratt Yes. Got some answers in #fabric-dev-env
rmohta (Thu, 18 May 2017 23:25:49 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=q7jxRrHPRR5xmb2o6) @jeffgarratt Yes. Got some answers in #fabric-dev-env Thank You
jeffgarratt (Thu, 18 May 2017 23:26:22 GMT):
good deal
jimthematrix (Fri, 19 May 2017 00:29:10 GMT):
@muralisr can you take a look at this JIRA I just opened based on our conversation yesterday? want to make sure it's accurate for the state of things and long term plan is to keep the design that way: https://jira.hyperledger.org/browse/FAB-4014
jimthematrix (Fri, 19 May 2017 00:29:10 GMT):
@muralisr can you take a look at this JIRA I just opened based on our conversation yesterday? want to make sure it's accurate for the state of things and long term plan is to keep the design that way: https://jira.hyperledger.org/browse/FAB-4014, thanks!
muralisr (Fri, 19 May 2017 00:35:46 GMT):
@jimthematrix just responded. hope that helps and we are on the same page...
jimthematrix (Fri, 19 May 2017 03:42:45 GMT):
thanks @muralisr
SaranyaM (Fri, 19 May 2017 10:56:59 GMT):
Has joined the channel.
muralisr (Fri, 19 May 2017 12:34:38 GMT):
@here volume mount on `windows` doesn't appear to be working right in a container created using docker compose. The dir itself is there in the container but doesn't have files. Appreciate any hints/tips on that
weeds (Fri, 19 May 2017 13:34:21 GMT):
Scrum started-
weeds (Fri, 19 May 2017 13:34:52 GMT):
(1-888-426-6840 / 33682113)
weeds (Fri, 19 May 2017 13:35:03 GMT):
- See Fabric-release channel for latest update on where we are on alpha 2
weeds (Fri, 19 May 2017 13:35:24 GMT):
while all posted in that channel, understanding is we could announce- Dave tested the getting started
weeds (Fri, 19 May 2017 13:35:40 GMT):
Windows still needs to be updated and may come later (believe arnaud is working it)
weeds (Fri, 19 May 2017 13:36:06 GMT):
There are subsequent work post this cut of the release outlined by Dave Enyeart on fabric-release channel
weeds (Fri, 19 May 2017 13:36:26 GMT):
- open defects
weeds (Fri, 19 May 2017 13:36:39 GMT):
fab 4013- orderer panic
weeds (Fri, 19 May 2017 13:37:04 GMT):
Kafka related panic--> @kostas can you please assign it?
weeds (Fri, 19 May 2017 13:37:41 GMT):
this is highest bug
weeds (Fri, 19 May 2017 13:38:13 GMT):
fab 3925- still seems in progress
weeds (Fri, 19 May 2017 13:38:29 GMT):
Fab 3669 go unit tests are failling interimitently
weeds (Fri, 19 May 2017 13:40:03 GMT):
- Unit test unit test
kostas (Fri, 19 May 2017 13:40:30 GMT):
@weeds: Got in touch with the team, in all of these defects the service doesn't look like it's set up right. Pointed the team to the right config settings, asked for reproduction, tagged all of these items with "reproduction-needed".
kostas (Fri, 19 May 2017 13:41:10 GMT):
This has been captured in JIRA as well.
weeds (Fri, 19 May 2017 13:41:23 GMT):
perfect- thanks much Kostas!
weeds (Fri, 19 May 2017 13:43:06 GMT):
Elli- crypto squad
weeds (Fri, 19 May 2017 13:44:00 GMT):
Crypto is at 85%- we need to make sure that Maintainers are ok with our coverage
weeds (Fri, 19 May 2017 13:45:33 GMT):
all checked in
weeds (Fri, 19 May 2017 13:45:39 GMT):
for unit test that we did
weeds (Fri, 19 May 2017 13:45:49 GMT):
no help required
weeds (Fri, 19 May 2017 13:46:24 GMT):
so Murali plans to go through the list of unit tests in gerrit and will post on the pr review of what needs to be merged
weeds (Fri, 19 May 2017 13:48:34 GMT):
Request from Murali to all the leads in particular areas
weeds (Fri, 19 May 2017 13:49:41 GMT):
What unit tests fabs are opened on your components? What needs to be merged and still waiting for maintainers? Are all those crs/fabs address comments from maintainers and rebased if required... and cleaned up any work on dependencies that they may have as well? Can you list those fabs/CRs int he peer review channel in next few hours so maintainers know what they need to do?
lehors (Fri, 19 May 2017 13:52:51 GMT):
@weeds I made progress on the windows problem, see comment on https://jira.hyperledger.org/browse/FAB-4032
weeds (Fri, 19 May 2017 13:53:11 GMT):
@elli-androulaki @kostas @muralisr @smithbk @dave.enyeart @jimthematrix See immediately above
dave.enyeart (Fri, 19 May 2017 13:59:10 GMT):
@weeds lehors has indeed made great progress. I just chatted with him and we agree to assign FAB-4032 to him to drive the fixes into gerrit. He's still trying to chase down some root cause vs workarounds though.
dave.enyeart (Fri, 19 May 2017 13:59:10 GMT):
@weeds lehors has indeed made great progress. I just chatted with him and we agreed to assign FAB-4032 to him to drive the fixes into gerrit. He's still trying to chase down some root cause vs workarounds though.
weeds (Fri, 19 May 2017 14:44:58 GMT):
Thanks!
muralisr (Fri, 19 May 2017 20:27:56 GMT):
@here please checkout https://jira.hyperledger.org/browse/FAB-4046 for helping out with UT for peer-endorser-committer components. It has some simple instructions and has some easy "Unassigned" sub-tasks to get started with
yacovm (Fri, 19 May 2017 21:33:41 GMT):
Enjoy @muralisr
yacovm (Sat, 20 May 2017 18:45:47 GMT):
https://github.com/hyperledger/fabric/blob/master/peer/chaincode/common.go#L110
This line `logger.Infof("Invoke result: %v", proposalResp)` should not print the payload of the *ProposalResponse* in my opinion. It's just `[]byte` anyway and doesn't give the user any useful information.
On the other hand, if the chaincode invocation creates a large WSet - it just fills up the screen...
yacovm (Sat, 20 May 2017 18:45:51 GMT):
@muralisr ^
hendry19901990 (Sat, 20 May 2017 19:20:14 GMT):
Has joined the channel.
hendry19901990 (Sat, 20 May 2017 19:21:10 GMT):
i am new developer here, i would like to help here, I don't know how to start
smonfort (Sat, 20 May 2017 19:53:42 GMT):
Has joined the channel.
muralisr (Sat, 20 May 2017 21:24:59 GMT):
@yacovm actually there's a CR that outputs correct chaincode response https://gerrit.hyperledger.org/r/#/c/9253/
muralisr (Sat, 20 May 2017 21:26:29 GMT):
@hendry19901990 did you familiarize with some of the fabric (and welcome!)
hendry19901990 (Sat, 20 May 2017 22:30:16 GMT):
umm ok
hendry19901990 (Sat, 20 May 2017 22:31:12 GMT):
how to do that
hendry19901990 (Sat, 20 May 2017 22:33:02 GMT):
is there a document to intro ??
muralisr (Sat, 20 May 2017 23:07:28 GMT):
@hendry19901990 the alpha2 docs about to be released would be a good place to start ( @nickgaski ...could you help with pointing to the right doc while alpha2 is being published please ?)
muralisr (Sat, 20 May 2017 23:09:48 GMT):
while waiting for @nickgaski ...here's the docs link http://hyperledger-fabric.readthedocs.io/en/latest/ ... not sure how "latest" it is but should help get started
nickgaski (Sat, 20 May 2017 23:10:01 GMT):
hey we are updated now
nickgaski (Sat, 20 May 2017 23:10:09 GMT):
so getting started will work on all platforms
nickgaski (Sat, 20 May 2017 23:10:25 GMT):
@hendry19901990 - did you get your network up?
hendry19901990 (Sat, 20 May 2017 23:11:02 GMT):
yes
hendry19901990 (Sat, 20 May 2017 23:11:13 GMT):
thanks my friends
nickgaski (Sat, 20 May 2017 23:12:13 GMT):
awesome. we are planning on publishing some higher level material with a more conceptual introduction into the various components and how they fit together. However, for now we'll be happy with a stable getting started that leaves you with all your images and artifacts :)
bmkor (Sun, 21 May 2017 05:56:39 GMT):
Has joined the channel.
hendry19901990 (Sun, 21 May 2017 15:04:21 GMT):
yes i 've got the network up, thanks my friend @nickgaski
Calvin_Heo (Mon, 22 May 2017 02:52:18 GMT):
Has joined the channel.
rmohta (Mon, 22 May 2017 18:53:28 GMT):
@here Does anyone know how to debug this ```2017-05-22 18:26:38.023 UTC [msp] getMspConfig -> INFO 001 intermediate certs folder not found at [/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp/intermediatecerts]. Skipping.: [stat /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp/intermediatecerts: no such file or directory]
2017-05-22 18:26:38.023 UTC [msp] getMspConfig -> INFO 002 crls folder not found at [/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp/intermediatecerts]. Skipping.: [stat /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp/crls: no such file or directory]
2017-05-22 18:26:38.023 UTC [msp] getMspConfig -> INFO 003 MSP configuration file not found at [/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp/config.yaml]: [stat /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp/config.yaml: no such file or directory]
2017-05-22 18:26:38.052 UTC [msp] GetLocalMSP -> DEBU 004 Returning existing local MSP
2017-05-22 18:26:38.052 UTC [msp] GetDefaultSigningIdentity -> DEBU 005 Obtaining default signing identity
2017-05-22 18:26:38.053 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 006 Using default escc
2017-05-22 18:26:38.054 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 007 Using default vscc
2017-05-22 18:26:38.055 UTC [msp/identity] Sign -> DEBU 008 Sign: plaintext: 0AB0070A6608031A0B08DEDA8CC90510...324D53500A04657363630A0476736363
2017-05-22 18:26:38.055 UTC [msp/identity] Sign -> DEBU 009 Sign: digest: E3434FC0BED2D90868418E53D33B2D09FB7D119C5CC634A78FA46199B03901FF
2017-05-22 18:26:38.062 UTC [msp/identity] Sign -> DEBU 00a Sign: plaintext: 0AB0070A6608031A0B08DEDA8CC90510...16D7AAA511225E74165F36064F2E26E3
2017-05-22 18:26:38.062 UTC [msp/identity] Sign -> DEBU 00b Sign: digest: 181B13C08DBB130246649B345EFA1219F26F2830AF763AE6602ECCFD79737B67
Error: Got unexpected status: NOT_FOUND
Usage:
peer chaincode instantiate [flags]
```
jeffgarratt (Mon, 22 May 2017 18:54:49 GMT):
@rmohta check your orderer logs
jeffgarratt (Mon, 22 May 2017 18:55:09 GMT):
looks like perhaps an issue with the broadcast of the instantiate TX
rmohta (Mon, 22 May 2017 18:55:39 GMT):
When would we get `Error: Got unexpected status: NOT_FOUND`. Installed cc successfully.
rmohta (Mon, 22 May 2017 18:55:52 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=uwF3Nta7H7eedd5JT) @jeffgarratt Checked. No error.
jeffgarratt (Mon, 22 May 2017 18:55:57 GMT):
installed and instantiate are 2 different steps
jeffgarratt (Mon, 22 May 2017 18:56:13 GMT):
installation does NOT require orderer
rmohta (Mon, 22 May 2017 18:56:23 GMT):
right.. for some reason, I can see new docker containers. But I cannot invoke anything on them
jeffgarratt (Mon, 22 May 2017 18:56:24 GMT):
instantiate does
jeffgarratt (Mon, 22 May 2017 18:56:42 GMT):
guessing the install worked... but instantiate failed
jeffgarratt (Mon, 22 May 2017 18:56:54 GMT):
thus not ledger for the peer for that chanincode/channel
rmohta (Mon, 22 May 2017 18:56:59 GMT):
But won't the container start only when we instantiate it?
jeffgarratt (Mon, 22 May 2017 18:57:05 GMT):
install may start it
jeffgarratt (Mon, 22 May 2017 18:57:18 GMT):
would need to check with @muralisr to verify
jeffgarratt (Mon, 22 May 2017 18:57:23 GMT):
but seems reasonable
jeffgarratt (Mon, 22 May 2017 18:57:33 GMT):
as this would prove the install worked
jeffgarratt (Mon, 22 May 2017 18:57:39 GMT):
and the chaincode can launch
jeffgarratt (Mon, 22 May 2017 18:58:10 GMT):
let me see if I can check real quick
rmohta (Mon, 22 May 2017 18:58:18 GMT):
@jeffgarratt anything specific I should look in my docker compose for broadcast and gossip?
rmohta (Mon, 22 May 2017 18:58:25 GMT):
okies. Thank You @jeffgarratt
jeffgarratt (Mon, 22 May 2017 18:59:53 GMT):
k, install does NOT seem to create the chaincode container
jeffgarratt (Mon, 22 May 2017 19:00:08 GMT):
so your instantiate seems to have successfully processed
jeffgarratt (Mon, 22 May 2017 19:00:34 GMT):
or perhaps at least partially succeeded
jeffgarratt (Mon, 22 May 2017 19:00:37 GMT):
would need the logs
jeffgarratt (Mon, 22 May 2017 19:00:49 GMT):
@muralisr may be your best bet at this point
rmohta (Mon, 22 May 2017 19:00:52 GMT):
```[rmohta@LPDMA728: ~/workspace/bc/gcs-blockchain/infrastructure]$ docker logs --tail 20 peer0.org1.example.com
2017-05-22 18:35:27.846 UTC [deliveryClient] RequestBlocks -> DEBU 1c2a7 Starting deliver with block [1]
2017-05-22 18:35:27.847 UTC [blocksProvider] DeliverBlocks -> WARN 1c2a8 Got error &{NOT_FOUND}
2017-05-22 18:35:28.849 UTC [deliveryClient] RequestBlocks -> DEBU 1c2a9 Starting deliver with block [1]
2017-05-22 18:35:28.850 UTC [blocksProvider] DeliverBlocks -> WARN 1c2aa Got error &{NOT_FOUND}
2017-05-22 18:35:29.852 UTC [deliveryClient] RequestBlocks -> DEBU 1c2ab Starting deliver with block [1]
2017-05-22 18:35:29.853 UTC [blocksProvider] DeliverBlocks -> WARN 1c2ac Got error &{NOT_FOUND}
2017-05-22 18:35:30.855 UTC [deliveryClient] RequestBlocks -> DEBU 1c2ad Starting deliver with block [1]
2017-05-22 18:35:30.856 UTC [blocksProvider] DeliverBlocks -> WARN 1c2ae Got error &{NOT_FOUND}
2017-05-22 18:35:31.857 UTC [deliveryClient] RequestBlocks -> DEBU 1c2af Starting deliver with block [1]
2017-05-22 18:35:31.858 UTC [blocksProvider] DeliverBlocks -> WARN 1c2b0 Got error &{NOT_FOUND}
2017-05-22 18:35:32.860 UTC [deliveryClient] RequestBlocks -> DEBU 1c2b1 Starting deliver with block [1]
2017-05-22 18:35:32.861 UTC [blocksProvider] DeliverBlocks -> WARN 1c2b2 Got error &{NOT_FOUND}
2017-05-22 18:35:33.863 UTC [deliveryClient] RequestBlocks -> DEBU 1c2b3 Starting deliver with block [1]
2017-05-22 18:35:33.864 UTC [blocksProvider] DeliverBlocks -> WARN 1c2b4 Got error &{NOT_FOUND}
2017-05-22 18:35:34.866 UTC [deliveryClient] RequestBlocks -> DEBU 1c2b5 Starting deliver with block [1]
2017-05-22 18:35:34.867 UTC [blocksProvider] DeliverBlocks -> WARN 1c2b6 Got error &{NOT_FOUND}
2017-05-22 18:35:35.869 UTC [deliveryClient] RequestBlocks -> DEBU 1c2b7 Starting deliver with block [1]
2017-05-22 18:35:35.870 UTC [blocksProvider] DeliverBlocks -> WARN 1c2b8 Got error &{NOT_FOUND}
2017-05-22 18:35:36.871 UTC [deliveryClient] RequestBlocks -> DEBU 1c2b9 Starting deliver with block [1]
2017-05-22 18:35:36.872 UTC [blocksProvider] DeliverBlocks -> WARN 1c2ba Got error &{NOT_FOUND}
```
rmohta (Mon, 22 May 2017 19:00:52 GMT):
```[rmohta@]$ docker logs --tail 20 peer0.org1.example.com
2017-05-22 18:35:27.846 UTC [deliveryClient] RequestBlocks -> DEBU 1c2a7 Starting deliver with block [1]
2017-05-22 18:35:27.847 UTC [blocksProvider] DeliverBlocks -> WARN 1c2a8 Got error &{NOT_FOUND}
2017-05-22 18:35:28.849 UTC [deliveryClient] RequestBlocks -> DEBU 1c2a9 Starting deliver with block [1]
2017-05-22 18:35:28.850 UTC [blocksProvider] DeliverBlocks -> WARN 1c2aa Got error &{NOT_FOUND}
2017-05-22 18:35:29.852 UTC [deliveryClient] RequestBlocks -> DEBU 1c2ab Starting deliver with block [1]
2017-05-22 18:35:29.853 UTC [blocksProvider] DeliverBlocks -> WARN 1c2ac Got error &{NOT_FOUND}
2017-05-22 18:35:30.855 UTC [deliveryClient] RequestBlocks -> DEBU 1c2ad Starting deliver with block [1]
2017-05-22 18:35:30.856 UTC [blocksProvider] DeliverBlocks -> WARN 1c2ae Got error &{NOT_FOUND}
2017-05-22 18:35:31.857 UTC [deliveryClient] RequestBlocks -> DEBU 1c2af Starting deliver with block [1]
2017-05-22 18:35:31.858 UTC [blocksProvider] DeliverBlocks -> WARN 1c2b0 Got error &{NOT_FOUND}
2017-05-22 18:35:32.860 UTC [deliveryClient] RequestBlocks -> DEBU 1c2b1 Starting deliver with block [1]
2017-05-22 18:35:32.861 UTC [blocksProvider] DeliverBlocks -> WARN 1c2b2 Got error &{NOT_FOUND}
2017-05-22 18:35:33.863 UTC [deliveryClient] RequestBlocks -> DEBU 1c2b3 Starting deliver with block [1]
2017-05-22 18:35:33.864 UTC [blocksProvider] DeliverBlocks -> WARN 1c2b4 Got error &{NOT_FOUND}
2017-05-22 18:35:34.866 UTC [deliveryClient] RequestBlocks -> DEBU 1c2b5 Starting deliver with block [1]
2017-05-22 18:35:34.867 UTC [blocksProvider] DeliverBlocks -> WARN 1c2b6 Got error &{NOT_FOUND}
2017-05-22 18:35:35.869 UTC [deliveryClient] RequestBlocks -> DEBU 1c2b7 Starting deliver with block [1]
2017-05-22 18:35:35.870 UTC [blocksProvider] DeliverBlocks -> WARN 1c2b8 Got error &{NOT_FOUND}
2017-05-22 18:35:36.871 UTC [deliveryClient] RequestBlocks -> DEBU 1c2b9 Starting deliver with block [1]
2017-05-22 18:35:36.872 UTC [blocksProvider] DeliverBlocks -> WARN 1c2ba Got error &{NOT_FOUND}
```
jeffgarratt (Mon, 22 May 2017 19:01:27 GMT):
hmm, not sure what that is
rmohta (Mon, 22 May 2017 19:02:05 GMT):
oh I was trying to say is - I can see these errors in peer container. Now sure why do we have these many times.
rmohta (Mon, 22 May 2017 19:02:25 GMT):
will try to rebuild the network from scratch and see.
jeffgarratt (Mon, 22 May 2017 19:02:53 GMT):
gonna run and see if I see the same thing
rmohta (Mon, 22 May 2017 19:02:56 GMT):
@muralisr if you have any idea on specific area to check, please do let me know
jeffgarratt (Mon, 22 May 2017 19:03:00 GMT):
will do
jeffgarratt (Mon, 22 May 2017 19:03:12 GMT):
how recent is your code?
rmohta (Mon, 22 May 2017 19:03:21 GMT):
alpha-2 image.
jeffgarratt (Mon, 22 May 2017 19:03:23 GMT):
k
muralisr (Mon, 22 May 2017 19:03:58 GMT):
@jeffgarratt `Error: Got unexpected status: NOT_FOUND`. might be orderer complaining some chainid is not there ?
muralisr (Mon, 22 May 2017 19:03:58 GMT):
@jeffgarratt `Error: Got unexpected status: NOT_FOUND`. might be orderer complaining some channel is not there ?
jeffgarratt (Mon, 22 May 2017 19:04:26 GMT):
that appears to be from the deliver service in the peer
jeffgarratt (Mon, 22 May 2017 19:04:46 GMT):
but it may be the deliver attempting to search on the newly created channel
jeffgarratt (Mon, 22 May 2017 19:05:06 GMT):
so perhaps expected, as there may NOT be a block 1
jeffgarratt (Mon, 22 May 2017 19:05:09 GMT):
genesis is 0
jeffgarratt (Mon, 22 May 2017 19:05:20 GMT):
have you issued a subsequent TX?
jeffgarratt (Mon, 22 May 2017 19:05:28 GMT):
on that channel?
jeffgarratt (Mon, 22 May 2017 19:05:36 GMT):
assume the instantiate would be block 1
rmohta (Mon, 22 May 2017 19:05:45 GMT):
nope. nothing as of now. @jeffgarratt
jeffgarratt (Mon, 22 May 2017 19:05:48 GMT):
ahhh
jeffgarratt (Mon, 22 May 2017 19:06:03 GMT):
perhaps this is expected if you join channel and nothing subseqquently sent
rmohta (Mon, 22 May 2017 19:06:05 GMT):
started, join channel, install cc, instantiate (failed)
rmohta (Mon, 22 May 2017 19:06:36 GMT):
what kind of transaction should be done post join? @jeffgarratt
jeffgarratt (Mon, 22 May 2017 19:06:42 GMT):
instantiate
jeffgarratt (Mon, 22 May 2017 19:06:57 GMT):
well, if you are the first to join and the channel is new
rmohta (Mon, 22 May 2017 19:07:55 GMT):
@jeffgarratt two peers (from different orgs) join the channel. install cc on both the peers. And then instantiate on only one peer for the network. It's the last part which fails.
rmohta (Mon, 22 May 2017 19:08:12 GMT):
BTW, rebooting my network. It might be some lingering thing from previos test
jeffgarratt (Mon, 22 May 2017 19:08:17 GMT):
k
yacovm (Mon, 22 May 2017 19:09:55 GMT):
@rmohta this seems to me like the ordering service is missing the channel the peer is trying to seek
yacovm (Mon, 22 May 2017 19:10:02 GMT):
if you git pull and rebuild
yacovm (Mon, 22 May 2017 19:10:12 GMT):
it now logs the channel name you try to pull
jeffgarratt (Mon, 22 May 2017 19:10:39 GMT):
this is definitely a post instantiate attempt issue
jeffgarratt (Mon, 22 May 2017 19:11:01 GMT):
I believe, as I ran the steps up to this point, and blocksProvider is never logging yet
yacovm (Mon, 22 May 2017 19:11:19 GMT):
this goroutine is run after JoinChannel occurrs
rmohta (Mon, 22 May 2017 19:11:47 GMT):
`CORE_PEER_ENDORSER_ENABLED=true` This was commented in our file between alpha-1 and alpha-2 test. Can this be an issue? None of the peers have this env.
yacovm (Mon, 22 May 2017 19:11:48 GMT):
or if the peer starts with a channel already in the ledger
yacovm (Mon, 22 May 2017 19:12:07 GMT):
I don't think so...
yacovm (Mon, 22 May 2017 19:12:07 GMT):
> `CORE_PEER_ENDORSER_ENABLED=true` This was commented in our file between alpha-1 and alpha-2 test. Can this be an issue? None of the peers have this env.
I don't think so...
rmohta (Mon, 22 May 2017 19:12:44 GMT):
okes. Then I will have it commented. And create a new channel and the whole nine yard. Will get to know in few mins @yacovm
yacovm (Mon, 22 May 2017 19:13:49 GMT):
I think that instantiate stats the container, not install.
yacovm (Mon, 22 May 2017 19:13:49 GMT):
I think that instantiate starts the container, not install.
rmohta (Mon, 22 May 2017 19:14:45 GMT):
When I try to create a new channel, I can see this ```2017-05-22 18:49:15.291 UTC [msp] GetLocalMSP -> DEBU 014 Returning existing local MSP
2017-05-22 18:49:15.291 UTC [msp] GetDefaultSigningIdentity -> DEBU 015 Obtaining default signing identity
2017-05-22 18:49:15.291 UTC [msp/identity] Sign -> DEBU 016 Sign: plaintext: 0ADF060A1508021A0608ABE58CC90522...00120D1A0B08FFFFFFFFFFFFFFFFFF01
2017-05-22 18:49:15.291 UTC [msp/identity] Sign -> DEBU 017 Sign: digest: 15EB17A64CE3B4E8612EFABDA3A393CB2B54A5ACB86EEC76D7ADCA6FE6A343B5
Got status &{NOT_FOUND}
2017-05-22 18:49:15.301 UTC [msp] GetLocalMSP -> DEBU 018 Returning existing local MSP
2017-05-22 18:49:15.301 UTC [msp] GetDefaultSigningIdentity -> DEBU 019 Obtaining default signing identity
2017-05-22 18:49:15.503 UTC [msp] GetLocalMSP -> DEBU 01a Returning existing local MSP
```
rmohta (Mon, 22 May 2017 19:14:45 GMT):
When I try to create a new channel, I can see this ```2017-05-22 18:49:15.291 UTC [msp] GetLocalMSP -> DEBU 014 Returning existing local MSP
2017-05-22 18:49:15.291 UTC [msp] GetDefaultSigningIdentity -> DEBU 015 Obtaining default signing identity
2017-05-22 18:49:15.291 UTC [msp/identity] Sign -> DEBU 016 Sign: plaintext: 0ADF060A1508021A0608ABE58CC90522...00120D1A0B08FFFFFFFFFFFFFFFFFF01
2017-05-22 18:49:15.291 UTC [msp/identity] Sign -> DEBU 017 Sign: digest: 15EB17A64CE3B4E8612EFABDA3A393CB2B54A5ACB86EEC76D7ADCA6FE6A343B5
Got status &{NOT_FOUND}
2017-05-22 18:49:15.301 UTC [msp] GetLocalMSP -> DEBU 018 Returning existing local MSP
2017-05-22 18:49:15.301 UTC [msp] GetDefaultSigningIdentity -> DEBU 019 Obtaining default signing identity
2017-05-22 18:49:15.503 UTC [msp] GetLocalMSP -> DEBU 01a Returning existing local MSP
```
yacovm (Mon, 22 May 2017 19:14:53 GMT):
BTW I have tested the master branch as of yesterday and things worked for me... had like 2 peers and an ordering service, everything generated with cryptogen and my own customly made-in-vi configtxgen.yaml file
yacovm (Mon, 22 May 2017 19:14:53 GMT):
BTW I have tested the master branch as of yesterday and things worked for me... had like 2 peers and an ordering service, everything generated with cryptogen and my own customly made-in-vi configtx.yaml file
yacovm (Mon, 22 May 2017 19:15:11 GMT):
well @rmohta what do the ordering service logs tell you?
rmohta (Mon, 22 May 2017 19:16:04 GMT):
```2017-05-22 18:49:15.505 UTC [cauthdsl] func2 -> DEBU 7d9 Principal evaluation succeeds: (&{0}) (used [false])
2017-05-22 18:49:15.505 UTC [cauthdsl] func1 -> DEBU 7da Gate evaluation succeeds: (&{n:1 policies:
rmohta (Mon, 22 May 2017 19:16:57 GMT):
it also tells this in the start ```2017-05-22 18:49:15.350 UTC [msp/identity] Sign -> DEBU 7cb Sign: plaintext: 0AD4060A0A4F7264657265724D535012...C9317A01D7C0A6EAAACF038715C2DDBE
2017-05-22 18:49:15.350 UTC [msp/identity] Sign -> DEBU 7cc Sign: digest: 2E3A3C19FBCC7B5791CC389EDE7AFB0F3B87A28F229E5EF10348B0AF12FF8461
2017-05-22 18:49:15.352 UTC [fsblkstorage] indexBlock -> DEBU 7cd Indexing block [blockNum=1, blockHash=[]byte{0x9a, 0xbb, 0x2c, 0x8a, 0x93, 0x82, 0xee, 0xc1, 0xb6, 0xa5, 0x7c, 0x90, 0x9, 0x80, 0x25, 0xa1, 0x5a, 0xe0, 0x2, 0x74, 0x40, 0x78, 0xef, 0x88, 0x67, 0xee, 0x5d, 0xef, 0x52, 0xd4, 0xe4, 0xb9} txOffsets=
txId= locPointer=offset=70, bytesLength=10571
]
2017-05-22 18:49:15.352 UTC [fsblkstorage] updateCheckpoint -> DEBU 7ce Broadcasting about update checkpointInfo: latestFileChunkSuffixNum=[0], latestFileChunksize=[19115], isChainEmpty=[false], lastBlockNumber=[1]
2017-05-22 18:49:15.352 UTC [orderer/multichain] WriteBlock -> DEBU 7cf [channel: testchainid] Wrote block 1
```
yacovm (Mon, 22 May 2017 19:20:08 GMT):
These logs of the ordering service are after the `Deliver` from the peer is tried
yacovm (Mon, 22 May 2017 19:20:21 GMT):
look at the micro-seconds
rmohta (Mon, 22 May 2017 19:57:17 GMT):
@yacovm @jeffgarratt this time it worked. Not sure if something was left over from our previous state. Thank You for your help
jeffgarratt (Mon, 22 May 2017 19:57:36 GMT):
@rmohta good deal!!
toddinpal (Tue, 23 May 2017 21:40:15 GMT):
When writing blocks, does the peer wait for the I/O to complete before generating the transaction committed event?
yacovm (Tue, 23 May 2017 22:06:17 GMT):
That's a question for #fabric-ledger
simsc (Wed, 24 May 2017 13:13:17 GMT):
Instead of a conf call in number for the 9:30 scrum, the team proposed using the fabric channel as a mechanism for holding the meeting. there will be no call in and the team will type directly into the 'fabric' channel (not this channel).
baohua (Wed, 24 May 2017 14:05:44 GMT):
Has joined the channel.
rmohta (Thu, 25 May 2017 01:53:49 GMT):
@here within a single channel if we plan to create multiple consortium, for sharing same assets but between different groups - how should we control access to that data?
rmohta (Thu, 25 May 2017 01:53:49 GMT):
@here within a single channel if we plan to create multiple consortia, for sharing the same type of assets but between different groups - how should we control access to that data?
prashiyn (Thu, 25 May 2017 09:49:07 GMT):
Has joined the channel.
prashiyn (Thu, 25 May 2017 09:51:04 GMT):
Get the following error on orderer log I get the following error `Principal deserialization failed: (The supplied identity is not valid, Verify() returned x509: certificate signed by unknown authority)` from the orderer while creating the channel. openssl verify
prashiyn (Thu, 25 May 2017 09:51:35 GMT):
I did not use the cryptogen tool but created the certificates using fabric-ca
jsong1230 (Thu, 25 May 2017 12:43:48 GMT):
2017-05-25 21:42:08.904 KST [chaincode] ExecuteChaincode -> ERRO 008 Error executing chaincode: Could not get deployment transaction from LSCC for mycc:1.0 - Get ChaincodeDeploymentSpec for mycc/mychannel from LSCC error: chaincode fingerprint mismatch data mismatch
jsong1230 (Thu, 25 May 2017 12:44:05 GMT):
What is the reason for the above error? Anyone has an idea? Thanks.
yacovm (Thu, 25 May 2017 13:00:24 GMT):
Yeah. The chaincode (binary file produced) you are trying to install has a different hash than the one instantiated in the channel
yacovm (Thu, 25 May 2017 13:00:27 GMT):
@jsong1230
guoger (Thu, 25 May 2017 15:08:00 GMT):
Has joined the channel.
jeffgarratt (Thu, 25 May 2017 18:31:56 GMT):
@rmohta consortia exist outside of the context of a channel. Channels are defined with respect to a particular consortium, and must be some sub-set of that definition.
rahulhegde (Thu, 25 May 2017 21:34:35 GMT):
@muralisr
Multiple endorsement request processing is allowed as part of v1.0 at the same point of time, is there field which I can print in the user-chaincode which will allow me for easy debugging?
rahulhegde (Thu, 25 May 2017 21:34:35 GMT):
@muralisr
Multiple endorsement request processing is allowed as part of v1.0 at the same point of time, is there field which I can print/log in the user-chaincode which will allow me for easy debugging?
muralisr (Thu, 25 May 2017 21:35:52 GMT):
@rahulhegde let me make sure I understand...
muralisr (Thu, 25 May 2017 21:36:51 GMT):
you want to log something in the chaincode that'll help figure out if a request will be endorsed successfully ?
rmohta (Thu, 25 May 2017 21:49:01 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=fNA7qhj8pqMmT7YqN) @jeffgarratt So if I understand the heirarchy. Constorium are made of 1 or many channels?
rmohta (Thu, 25 May 2017 21:50:09 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=8dEH7BEmQeBLaLg4f) @prashiyn Does the orderer msp/ca directory have the root cert for your Org?
rahulhegde (Thu, 25 May 2017 22:20:10 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=qy9okcmdYGenRWZ6G) @muralisr
No exactly, apologies for the short description.
Single peer can receive multiple endorsement request from multiple HFC in the same time instance and hence they will be processed by peer (to user-chaincode) in parallel. I would like to know if there is any identifier that can be logged by user-chaincode thus helping on debugging.
muralisr (Thu, 25 May 2017 22:26:17 GMT):
@rahulhegde shim.GetTxID() can be used to differentiate
jeffgarratt (Thu, 25 May 2017 23:11:52 GMT):
@rmohta slightly inverted to that. Every channel refers to a consortium. The members of the channel must either be the members of the consortium or a subset thereof.
Glen (Fri, 26 May 2017 01:14:18 GMT):
Has joined the channel.
prashiyn (Fri, 26 May 2017 04:24:27 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=r6sd5eQojfLzMBvJA) @rmohta Sorted with help from @smithbk. There was an issue with the chaincerts. Thank you
icodezjb (Fri, 26 May 2017 05:22:12 GMT):
Has joined the channel.
lehors (Fri, 26 May 2017 13:34:42 GMT):
for fabric scrum, go to #fabric
thakkarparth007 (Fri, 26 May 2017 16:36:22 GMT):
Has joined the channel.
thakkarparth007 (Fri, 26 May 2017 16:40:08 GMT):
Hi guys, I'm trying to setup fabric on a multihost setup, and have 4 orgs, with 2 peers each. I want to instantiate a chaincode (using node-sdk) that has already been installed on all of them. My endorsement policy is that 3 out of 4 admins of the 4 orgs should endorse (I don't fully understand this, but I'll come to that later).
Right now, I'm sending instantiate proposals to all the 8 peers (again, not sure if sending to all 8 is required, but that's not important right now). I get all the 8 endorsements, and this by itself starts the chaincode containers on all the 8 peers. I didn't even send the endorsements to the orderer. Why should this happen?
@muralisr @binhn
jeffgarratt (Fri, 26 May 2017 17:00:33 GMT):
@thakkarparth007 I would assume that you can not invoke the chaincode though on the endorsers?
thakkarparth007 (Fri, 26 May 2017 17:00:46 GMT):
Nope, I can't.
jeffgarratt (Fri, 26 May 2017 17:00:50 GMT):
good
jeffgarratt (Fri, 26 May 2017 17:01:04 GMT):
you need to submit the instantiate to orderer to complete the process
thakkarparth007 (Fri, 26 May 2017 17:01:22 GMT):
"failed to obtain cds for generic-chaincode - could not find chaincode with name 'generic-chaincode'
at /root/tools/scripts/IRL/load_generator/node_modules/grpc/src/node/src/client.js:434:17"
jeffgarratt (Fri, 26 May 2017 17:01:31 GMT):
that is expected
thakkarparth007 (Fri, 26 May 2017 17:01:36 GMT):
But if I do, it says the chaincode already exists
jeffgarratt (Fri, 26 May 2017 17:02:02 GMT):
you attempted to submit the instantiate TX to the orderer?
thakkarparth007 (Fri, 26 May 2017 17:03:09 GMT):
Okay, it did so before. Now it's not doing. But the client doesn't hear any event from the peer about the transaction commit.
thakkarparth007 (Fri, 26 May 2017 17:03:38 GMT):
I have the transaction id, can I see if it has been committed?
jeffgarratt (Fri, 26 May 2017 17:03:40 GMT):
until the TX is committed, the peers will not receive it
jeffgarratt (Fri, 26 May 2017 17:04:12 GMT):
@muralisr may be able to advise at this point.
jeffgarratt (Fri, 26 May 2017 17:05:08 GMT):
@muralisr @dave.enyeart do we expose the ability to get a TX by id? or the block it is in?
jeffgarratt (Fri, 26 May 2017 17:05:08 GMT):
@muralisr @dave.enyeart do we expose the ability to get a TX by id? or the block it is in from the peer interface?
dave.enyeart (Fri, 26 May 2017 17:06:43 GMT):
yes, query system chaincode has these functions:
dave.enyeart (Fri, 26 May 2017 17:06:47 GMT):
``` GetChainInfo string = "GetChainInfo"
GetBlockByNumber string = "GetBlockByNumber"
GetBlockByHash string = "GetBlockByHash"
GetTransactionByID string = "GetTransactionByID"
GetBlockByTxID string = "GetBlockByTxID"```
jeffgarratt (Fri, 26 May 2017 17:07:31 GMT):
@thakkarparth007 ^^^^ thanks Dave
dave.enyeart (Fri, 26 May 2017 17:07:32 GMT):
/fabric/core/scc/qscc/query.go
thakkarparth007 (Fri, 26 May 2017 17:08:20 GMT):
Thanks, I'll try finding if anything got committed and get back
jeffgarratt (Fri, 26 May 2017 17:08:26 GMT):
good luck!!
dave.enyeart (Fri, 26 May 2017 17:09:21 GMT):
example invoke:
dave.enyeart (Fri, 26 May 2017 17:09:25 GMT):
`peer chaincode query -C "" -n qscc -c '{"Args":["GetTransactionByID","myc1","19badf25511cad45665c5291b8f1bff5d10a0fe0db6cb4dba7f7f3abbb5b0b89"]}' `
Senthil1 (Fri, 26 May 2017 17:09:40 GMT):
@jeffgarratt what will happen if we just instantiate on one peer and send the proposalResponse to orderer? Will all peer deploy the chaincode on a docker container?
jeffgarratt (Fri, 26 May 2017 17:09:44 GMT):
@thakkarparth007 ^^ see above
jeffgarratt (Fri, 26 May 2017 17:09:50 GMT):
thanks @dave.enyeart
jeffgarratt (Fri, 26 May 2017 17:10:58 GMT):
@Senthil1 I presume they would fail, as they will not be able to perform the function.
thakkarparth007 (Fri, 26 May 2017 17:11:02 GMT):
Thanks @dave.enyeart and @jeffgarratt There was a bug in my event-receiving code.
thakkarparth007 (Fri, 26 May 2017 17:11:11 GMT):
It got installed.
jeffgarratt (Fri, 26 May 2017 17:11:21 GMT):
@thakkarparth007 awesome!!
thakkarparth007 (Fri, 26 May 2017 17:11:23 GMT):
Initally I was trying to instantiate on the anchor nodes
dave.enyeart (Fri, 26 May 2017 17:11:50 GMT):
you need to `install` chaincode on all peers
thakkarparth007 (Fri, 26 May 2017 17:11:52 GMT):
But maybe it's required to instantiate on every peer?
thakkarparth007 (Fri, 26 May 2017 17:11:56 GMT):
How do things work?
thakkarparth007 (Fri, 26 May 2017 17:12:02 GMT):
Yeah, we installed on all peers.
dave.enyeart (Fri, 26 May 2017 17:12:03 GMT):
you only need to `instantiate` once
Senthil1 (Fri, 26 May 2017 17:12:12 GMT):
I see. @thakkarparth007 can you see what happens when we send instantiate to only one peer ?
thakkarparth007 (Fri, 26 May 2017 17:12:18 GMT):
Oh. Let me try that once again, I'm not sure if that was working.
Senthil1 (Fri, 26 May 2017 17:12:26 GMT):
@dave.enyeart that what I thought too..
jeffgarratt (Fri, 26 May 2017 17:12:59 GMT):
@thakkarparth007 you should not be able to as you require 3 of 4 endorsements.
Senthil1 (Fri, 26 May 2017 17:13:30 GMT):
@jeffgarratt we got endorsement for 4 peers and submitted to orderer
Senthil1 (Fri, 26 May 2017 17:13:30 GMT):
@jeffgarratt we got endorsement from 4 peers and submitted to orderer
Senthil1 (Fri, 26 May 2017 17:13:41 GMT):
but the chaincode was started only on those 4 nodes..
thakkarparth007 (Fri, 26 May 2017 17:14:02 GMT):
Yeah
thakkarparth007 (Fri, 26 May 2017 17:14:13 GMT):
The containers, that is.
thakkarparth007 (Fri, 26 May 2017 17:14:31 GMT):
Can you explain how it's supposed to work in my case?
dave.enyeart (Fri, 26 May 2017 17:14:36 GMT):
chaincode containers can come and go as they are needed
dave.enyeart (Fri, 26 May 2017 17:14:36 GMT):
chaincode containers can come and go, as they are needed by endorsement
jeffgarratt (Fri, 26 May 2017 17:15:03 GMT):
you must first install the chaincode on the peers (requires local MSP admin priveldge).
Senthil1 (Fri, 26 May 2017 17:15:15 GMT):
hmm.. make sense.. e2e cli has similar example..
Senthil1 (Fri, 26 May 2017 17:15:27 GMT):
@jeffgarratt yeah, chaincodes are installed on all peers.
thakkarparth007 (Fri, 26 May 2017 17:15:34 GMT):
My case being 4 orgs, each 2 peers. Endorsement policy: 3 out of 4 admins should endorse.
jeffgarratt (Fri, 26 May 2017 17:15:57 GMT):
k, then as long as those peers have joined the channel, the instantiate should flow through as expected
jeffgarratt (Fri, 26 May 2017 17:16:23 GMT):
and policy met for endorsement, things should be good
thakkarparth007 (Fri, 26 May 2017 17:16:52 GMT):
So I should instantiate on any 3 out of the 8 peers, is it?
jeffgarratt (Fri, 26 May 2017 17:17:14 GMT):
as long as that meets the policy, it is up to you
dave.enyeart (Fri, 26 May 2017 17:17:35 GMT):
instantiate is only done once for the channel
dave.enyeart (Fri, 26 May 2017 17:17:52 GMT):
it puts an entry on the channel's chain
dave.enyeart (Fri, 26 May 2017 17:18:08 GMT):
gets replicated to all peers via normal block dissemination
dave.enyeart (Fri, 26 May 2017 17:18:08 GMT):
gets replicated to all peers on the channel via normal block dissemination
Senthil1 (Fri, 26 May 2017 17:18:27 GMT):
@thakkarparth007 Can you check the following? Do instantiate on only 1 peer (say peer0 in our case) and submit the endorsement to orderer. Then, do an invoke on peer1. As dave says, chaincode container might come and go..
thakkarparth007 (Fri, 26 May 2017 17:18:49 GMT):
Yup, doing that right now
thakkarparth007 (Fri, 26 May 2017 17:23:09 GMT):
Okay, so here's what happened: I instantiated on one peer, and after some time the chaincode got launched on 2 other peers, but not on anyone else.
jeffgarratt (Fri, 26 May 2017 17:23:50 GMT):
did you try an endorsment of that new chaincode on peer0?
thakkarparth007 (Fri, 26 May 2017 17:23:50 GMT):
My application that does instantiation waits for 'event' from its peer, and as I told that part is buggy (not sure what's going on there), so it doesn't display any output
thakkarparth007 (Fri, 26 May 2017 17:24:21 GMT):
Now when I saw a container running on one of the peers (peer1 - which initially didn't have it), I stopped my application.
thakkarparth007 (Fri, 26 May 2017 17:24:51 GMT):
But all it was doing was waiting for the event from the peer, so it couldn't have stopped deploying chaincodes on other peers, could it?
thakkarparth007 (Fri, 26 May 2017 17:24:57 GMT):
I did.
thakkarparth007 (Fri, 26 May 2017 17:25:06 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=sXaaic6B54hM6ygPy) @jeffgarratt I did, that is
jeffgarratt (Fri, 26 May 2017 17:25:11 GMT):
response?
thakkarparth007 (Fri, 26 May 2017 17:25:33 GMT):
No errors, but didn't hear of any event from peer0 either.
thakkarparth007 (Fri, 26 May 2017 17:25:48 GMT):
And the containers got deployed on 2 other peers,
thakkarparth007 (Fri, 26 May 2017 17:25:53 GMT):
but not one anyone else.
jeffgarratt (Fri, 26 May 2017 17:25:56 GMT):
k, then the instantiate appears to have occurred then on peer0?
Senthil1 (Fri, 26 May 2017 17:25:58 GMT):
@thakkarparth007 better use our fetch-block tool and inspect the block content.. we can find out more..
thakkarparth007 (Fri, 26 May 2017 17:26:15 GMT):
@Senthil1 I'll do that.
dave.enyeart (Fri, 26 May 2017 17:26:17 GMT):
you wont see a chaincode container until all three conditions are met: 1) chaincode is installed on the peer 2) chaincode is instantiated on the channel 3) chaincode is invoked on the peer
thakkarparth007 (Fri, 26 May 2017 17:26:26 GMT):
@jeffgarratt yes
jeffgarratt (Fri, 26 May 2017 17:26:45 GMT):
k, then working as expected, except for you lack of event from peer0?
thakkarparth007 (Fri, 26 May 2017 17:26:49 GMT):
@dave.enyeart I didn't invoke the chaincoe on any peer
jeffgarratt (Fri, 26 May 2017 17:26:59 GMT):
wait, I just asked that
jeffgarratt (Fri, 26 May 2017 17:27:22 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=QNBgLBMud3phsHmS6) @thakkarparth007 See below
jeffgarratt (Fri, 26 May 2017 17:27:36 GMT):
wen I asked.,.. did you try an endorsment of that new chaincode on peer0?
jeffgarratt (Fri, 26 May 2017 17:27:47 GMT):
that is asking if you invoked the new chaincode
thakkarparth007 (Fri, 26 May 2017 17:27:56 GMT):
No, I didn't invoke it.
jeffgarratt (Fri, 26 May 2017 17:28:02 GMT):
ahhh... give that a go
thakkarparth007 (Fri, 26 May 2017 17:28:04 GMT):
I thought you meant if I instantiated it on peer0
jeffgarratt (Fri, 26 May 2017 17:28:16 GMT):
;)
thakkarparth007 (Fri, 26 May 2017 17:28:39 GMT):
"Error executing chaincode: Error chaincode is being launched: generic-chaincode:1.0"
jeffgarratt (Fri, 26 May 2017 17:29:10 GMT):
hmmm. try once again?
thakkarparth007 (Fri, 26 May 2017 17:29:12 GMT):
But nothing's really happening. The containers got deployed on 2 other peers long back. Others should've caught on by now.
jeffgarratt (Fri, 26 May 2017 17:29:24 GMT):
k, will see if I can replicate
jeffgarratt (Fri, 26 May 2017 17:29:30 GMT):
latest code?
jeffgarratt (Fri, 26 May 2017 17:29:54 GMT):
meaning, are you running from latest master?
jeffgarratt (Fri, 26 May 2017 17:29:56 GMT):
or close?
thakkarparth007 (Fri, 26 May 2017 17:30:03 GMT):
I think so.
thakkarparth007 (Fri, 26 May 2017 17:30:06 GMT):
Close at least.
jeffgarratt (Fri, 26 May 2017 17:30:06 GMT):
;)
jeffgarratt (Fri, 26 May 2017 17:30:11 GMT):
good deal!!
jeffgarratt (Fri, 26 May 2017 17:30:18 GMT):
gonna eat first, then see if I can replicate
Senthil1 (Fri, 26 May 2017 17:30:41 GMT):
@jeffgarratt alpha2 it is
jeffgarratt (Fri, 26 May 2017 17:30:45 GMT):
ahhh
jeffgarratt (Fri, 26 May 2017 17:30:53 GMT):
k
jeffgarratt (Fri, 26 May 2017 17:31:08 GMT):
I assume would not have been fixed if this is an issue
jeffgarratt (Fri, 26 May 2017 17:34:38 GMT):
k, I am seeing same behavior
thakkarparth007 (Fri, 26 May 2017 17:34:47 GMT):
The peer emits an event.
thakkarparth007 (Fri, 26 May 2017 17:34:53 GMT):
I confirmed it.
jeffgarratt (Fri, 26 May 2017 17:34:54 GMT):
wait, I missed one step...
thakkarparth007 (Fri, 26 May 2017 17:35:22 GMT):
@Senthil1, fetch-block detects the block
thakkarparth007 (Fri, 26 May 2017 17:36:01 GMT):
This is when instantiating on peer0, though other peers haven't gotten the containers running yet
Senthil1 (Fri, 26 May 2017 17:36:19 GMT):
where is the block json? is it in perfLog dir?
Senthil1 (Fri, 26 May 2017 17:37:00 GMT):
found it..
jeffgarratt (Fri, 26 May 2017 17:40:41 GMT):
@Senthil1 @thakkarparth007 k.. I performed similar and it works as expected. The endorsement takes a bit of extra time on the peer which did NOT endorse the isntantiate.
jeffgarratt (Fri, 26 May 2017 17:40:57 GMT):
but appears to work as advertised
thakkarparth007 (Fri, 26 May 2017 17:41:13 GMT):
:/ hmm.
Senthil1 (Fri, 26 May 2017 17:41:23 GMT):
I see.
jeffgarratt (Fri, 26 May 2017 17:41:34 GMT):
have time for a zoom meeting to demonstrate?
thakkarparth007 (Fri, 26 May 2017 17:41:35 GMT):
So you're instantiating on a single peer and container gets created on all peers?
jeffgarratt (Fri, 26 May 2017 17:42:15 GMT):
yes
jeffgarratt (Fri, 26 May 2017 17:42:39 GMT):
https://ibm.zoom.us/j/572191856
jeffgarratt (Fri, 26 May 2017 17:42:47 GMT):
can you join a quick conference on zoom?
thakkarparth007 (Fri, 26 May 2017 17:42:58 GMT):
Joining
thakkarparth007 (Fri, 26 May 2017 17:43:58 GMT):
Installing the package. min.
thakkarparth007 (Fri, 26 May 2017 17:44:01 GMT):
2min*
jeffgarratt (Fri, 26 May 2017 17:44:05 GMT):
take time :)
jeffgarratt (Fri, 26 May 2017 17:48:00 GMT):
@Senthil1 you are welcome as well
jeffgarratt (Fri, 26 May 2017 17:49:58 GMT):
you guys still coming?
thakkarparth007 (Fri, 26 May 2017 17:50:25 GMT):
Yeah, I'm coming. Nearly done with the installation
jeffgarratt (Fri, 26 May 2017 17:50:29 GMT):
:)
Senthil1 (Fri, 26 May 2017 18:10:12 GMT):
@jeffgarratt Thanks for your help. It did work finally using cli
Senthil1 (Fri, 26 May 2017 18:10:26 GMT):
I did instantiate on one peer and then did a query on all other peer
jeffgarratt (Fri, 26 May 2017 18:10:28 GMT):
@Senthil1 @thakkarparth007 awesome!!!!
Senthil1 (Fri, 26 May 2017 18:10:33 GMT):
container came up..
Senthil1 (Fri, 26 May 2017 18:10:38 GMT):
thanks a ton..
jeffgarratt (Fri, 26 May 2017 18:10:43 GMT):
you are most welcome!!!
thakkarparth007 (Fri, 26 May 2017 18:10:55 GMT):
Thank you! :D
Senthil1 (Fri, 26 May 2017 18:24:13 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=hYdAeRH2Rh4a7F6S8) @dave.enyeart thanks for your help.. it did work finally. let see how the performance differ between couchdb vs leveldb. Btw, @thakkarparth007 is our intern who is working on performance benchmarking of fabric 1.0
rmohta (Fri, 26 May 2017 18:28:31 GMT):
@here How can we enable `debug` logging for cc container? For now, it seems to be at a default `> WARN` level
rmohta (Fri, 26 May 2017 18:28:31 GMT):
@here How can we enable `debug` logging for cc container? For now, it seems to be at a default `> WARN` level. I am using the `flogging` package within fabric
wlahti (Fri, 26 May 2017 18:29:23 GMT):
Hey, I can help with that @rmohta
wlahti (Fri, 26 May 2017 18:30:48 GMT):
how are you running your environment, first of all?
rmohta (Fri, 26 May 2017 18:31:29 GMT):
@wlahti Didn't get your question? Do you mean how I have started my peer? or how my docker-compose file is?
wlahti (Fri, 26 May 2017 18:32:50 GMT):
are you just running the e2e_cli setup, alpha2 images, or something else? trying to get a sense for whether you need to override with environment variables or if you have access to sampleconfig/core.yaml to change the setting
wlahti (Fri, 26 May 2017 18:34:11 GMT):
if you look at core.yaml: https://github.com/hyperledger/fabric/blob/master/sampleconfig/core.yaml at line 341, you'll see the logging section for the chaincode container and explanation of the currently available options
wlahti (Fri, 26 May 2017 18:35:38 GMT):
depending on your environment, you can change the values there or by passing in the CORE_CHAINCODE_LOGGING_LEVEL and CORE_CHAINCODE_LOGGING_SHIM variables for whichever one you need to modify
wlahti (Fri, 26 May 2017 18:38:52 GMT):
if you've defined your own logger in your chaincode, you'll want to set CORE_CHAINCODE_LOGGING_LEVEL=debug. otherwise, you can set CORE_CHAINCODE_LOGGING_SHIM=debug or just set both to debug to ensure you get all logging levels in your environment
bmalavan (Sat, 27 May 2017 15:47:38 GMT):
Has joined the channel.
akash42145 (Sun, 28 May 2017 13:48:35 GMT):
Has joined the channel.
akash42145 (Sun, 28 May 2017 13:49:57 GMT):
Hello All, could you please help me to know how to create new peers dynamically for any organization.
yacovm (Sun, 28 May 2017 14:04:55 GMT):
you need to generate the content of the MSP folder
yacovm (Sun, 28 May 2017 14:05:10 GMT):
and assign an ip address / hostname for the peer
baohua (Mon, 29 May 2017 02:50:09 GMT):
Base on the checking of the existing code, we believe there's no usage of the peer.workers config in core.yaml
So will plan to remove this config.
Pls let me know if there's any purpose to keep it.
Thanks!
baohua (Mon, 29 May 2017 02:50:09 GMT):
Base on the checking of the existing code, we believe there's no usage of the `peer.workers` config in core.yaml
So will plan to remove this config.
Pls let me know if there's any purpose to keep it.
Thanks!
baohua (Mon, 29 May 2017 02:50:15 GMT):
https://jira.hyperledger.org/browse/FAB-4199
bmkor (Tue, 30 May 2017 12:00:54 GMT):
What's that intended for? @baohua
bmkor (Tue, 30 May 2017 12:00:54 GMT):
What's `peer.workers` intended for? @baohua
yacovm (Tue, 30 May 2017 12:03:22 GMT):
I assume it's an ancient remnant from 0.5
yacovm (Tue, 30 May 2017 12:03:30 GMT):
Don't let it bother you
bmkor (Tue, 30 May 2017 12:05:44 GMT):
Thanks.
xixuejia (Tue, 30 May 2017 14:08:33 GMT):
I wonder whether there's a config parameter to make a peer as endorser or committer? It seems there's no such config in core.yaml, but it's in dockefile https://github.com/hyperledger/fabric/blob/master/examples/e2e_cli/base/peer-base.yaml#L19
xixuejia (Tue, 30 May 2017 14:08:51 GMT):
and it's doesn't take effect
xixuejia (Tue, 30 May 2017 14:08:51 GMT):
and it doesn't take effect
jimthematrix (Tue, 30 May 2017 16:11:04 GMT):
@muralisr what's the intended workflow for testing chaincode in dev mode? i've tried the following:
- build chaincode locally
- start the peer docker with --peer-chaincodedev=true
- run chaincode with the following command:
```
CORE_PEER_TLS_ENABLED=true CORE_PEER_TLS_ROOTCERT_FILE=$PEERDIR/cacerts/org1.example.com-cert.pem CORE_PEER_TLS_SERVERHOSTOVERRIDE=peer0.org1.example.com CORE_CHAINCODE_ID_NAME=end2endnodesdk ./example_cc --peer.address=localhost:7051
```
- the above process successfully registered with the peer:
```
registered handler complete for chaincode end2endnodesdk
```
jimthematrix (Tue, 30 May 2017 16:11:49 GMT):
now i assume we don't need to install, do we still need to instantiate for a channel? or invoke directly?
jimthematrix (Tue, 30 May 2017 16:13:38 GMT):
when I tried to instantiate:
```
Error: cannot get package for the chaincode to be instantiated (end2endnodesdk:v0)-cannot retrieve package for chaincode end2endnodesdk/v0, error open /var/hyperledger/production/chaincodes/end2endnodesdk.v0: no such file or directory
```
muralisr (Tue, 30 May 2017 16:13:47 GMT):
@jimthematrix we do need to install unfortunately
muralisr (Tue, 30 May 2017 16:13:56 GMT):
just to make LSCC happy
muralisr (Tue, 30 May 2017 16:14:05 GMT):
the install itself wont be used
jimthematrix (Tue, 30 May 2017 16:14:06 GMT):
oh, did not expect that
muralisr (Tue, 30 May 2017 16:14:12 GMT):
yeah :-(
jimthematrix (Tue, 30 May 2017 16:14:27 GMT):
but i see why this is needed as temporary workaround
jimthematrix (Tue, 30 May 2017 16:14:31 GMT):
will try that
muralisr (Tue, 30 May 2017 16:14:45 GMT):
don't have a switch in the lscc to say "don't look for package..you are in dev mode"
muralisr (Tue, 30 May 2017 16:15:30 GMT):
one more thing
muralisr (Tue, 30 May 2017 16:16:05 GMT):
I think you need the version also ..like `CORE_CHAINCODE_ID_NAME=end2endnodesdk:
muralisr (Tue, 30 May 2017 16:16:24 GMT):
in your case `CORE_CHAINCODE_ID_NAME=end2endnodesdk:v0`
jimthematrix (Tue, 30 May 2017 16:23:51 GMT):
ah, good catch, was just wondering about that, getting this:
```
[chaincode] Launch -> ERRO 392 sending init failed(handler not found for chaincode end2endnodesdk:v0)
```
jimthematrix (Tue, 30 May 2017 16:24:04 GMT):
will try adding the version to the registered name
jimthematrix (Tue, 30 May 2017 16:25:11 GMT):
works better now!
jimthematrix (Tue, 30 May 2017 16:25:14 GMT):
thanks!
jimthematrix (Tue, 30 May 2017 16:25:14 GMT):
thanks @muralisr !
arek20 (Tue, 30 May 2017 17:31:06 GMT):
Has joined the channel.
thakkarparth007 (Wed, 31 May 2017 16:36:01 GMT):
I have a set up with a few peers, and while experimenting I found out that the number of times their blockfiles were modified was different for each peer. None of my peers had disconnected during the experiment, so it couldn't be due to the gossip data-retrieval. I don't understand why this should happen.
thakkarparth007 (Wed, 31 May 2017 16:36:05 GMT):
Can anyone explain?
thakkarparth007 (Wed, 31 May 2017 16:37:03 GMT):
I used inotify to monitor the blockfiles, in case that's relevant.
thakkarparth007 (Wed, 31 May 2017 16:37:36 GMT):
I'd been under the impression that the blockfile would be modified every time a new block needs to be added
thakkarparth007 (Wed, 31 May 2017 16:38:07 GMT):
Or is this simply due to buffering of the 'write' calls?
jyellick (Wed, 31 May 2017 20:58:10 GMT):
@muralisr @cbf
The peer channel create tests still fail for me on master, even after https://gerrit.hyperledger.org/r/#/c/9997/
```
--- FAIL: TestCreateChainNilCF (0.00s)
assertions.go:225: ^M ^M Error Trace: create_test.go:527
^M Error: "channel create configuration tx file not found open /tmp/createinvaltest-755067002/mockchannel: no such file or directory" does not contain "error: code = Unavailable desc = grpc: the connection is unavailable"
```
jyellick (Wed, 31 May 2017 20:58:10 GMT):
@muralisr @cbf
The peer channel create tests still fail for me locally on master, even after https://gerrit.hyperledger.org/r/#/c/9997/
```
--- FAIL: TestCreateChainNilCF (0.00s)
assertions.go:225: ^M ^M Error Trace: create_test.go:527
^M Error: "channel create configuration tx file not found open /tmp/createinvaltest-755067002/mockchannel: no such file or directory" does not contain "error: code = Unavailable desc = grpc: the connection is unavailable"
```
any ideas?
jyellick (Wed, 31 May 2017 20:58:10 GMT):
@muralisr @cbf
The peer channel create tests still fail for me locally on master, even after https://gerrit.hyperledger.org/r/#/c/9997/
```
--- FAIL: TestCreateChainNilCF (0.00s)
assertions.go:225: ^M ^M Error Trace: create_test.go:527
^M Error: "channel create configuration tx file not found open /tmp/createinvaltest-755067002/mockchannel: no such file or directory" does not contain "error: code = Unavailable desc = grpc: the connection is unavailable"
```
~any ideas?~ Realized the problem. I happened to have an orderer running on 7050, which allowed the connection to occur.
muralisr (Wed, 31 May 2017 21:05:27 GMT):
ah
muralisr (Wed, 31 May 2017 21:05:57 GMT):
I just began looking at it and was pouring over the difference in the strings with 997
muralisr (Wed, 31 May 2017 21:05:57 GMT):
I just began looking at it and was pouring over the difference in the strings with 9997
latitiah (Thu, 01 Jun 2017 15:40:10 GMT):
When trying to join a channel (using the peer cli command), I receive the following error:
```
Error: proposal failed (err: rpc error: code = 2 desc = Failed to reconstruct the genesis block, Failed to reconstruct the genesis block, proto: bad wiretype for field common.BlockHeader.Number: got wiretype 2, want 0```
Can anyone point me in the direction to look to figure out this issue?
latitiah (Thu, 01 Jun 2017 15:40:46 GMT):
From the logs, it looks as though tthe channel has been created successfully
latitiah (Thu, 01 Jun 2017 17:39:03 GMT):
nm... user error: I passed the transaction file and not the block file
toddinpal (Fri, 02 Jun 2017 01:49:23 GMT):
Is there any way to join to separate Fabric networks into a single network?
JasonD (Fri, 02 Jun 2017 05:25:14 GMT):
Has joined the channel.
JasonD (Fri, 02 Jun 2017 05:26:47 GMT):
@muralisr FYI, check this issue, https://jira.hyperledger.org/browse/FAB-4254, it seems like this is fabric-peer's bug
BhavishaDawda (Fri, 02 Jun 2017 16:07:38 GMT):
Has joined the channel.
latitiah (Fri, 02 Jun 2017 17:52:52 GMT):
@muralisr: I think this may be a fabric-peer bug as well: https://jira.hyperledger.org/browse/FAB-4327
muralisr (Fri, 02 Jun 2017 17:54:52 GMT):
thanks @latitiah assigned tit to self
muralisr (Fri, 02 Jun 2017 17:54:52 GMT):
thanks @latitiah assigned it to self
dbshah (Fri, 02 Jun 2017 18:01:54 GMT):
Hey, I am trying aplha2 code: when i do a `peer channel join` getting this
```
2017-06-01 20:18:53.132 UTC [ConnProducer] NewConnection -> ERRO 304 Failed connecting to orderer-0c.net_blockchain.com:3004 , error: grpc: timed out when dialing
2017-06-01 20:18:56.133 UTC [ConnProducer] NewConnection -> ERRO 305 Failed connecting to orderer-0b.net_blockchain.com:2004 , error: grpc: timed out when dialing
2017-06-01 20:18:59.134 UTC [ConnProducer] NewConnection -> ERRO 306 Failed connecting to orderer-0a.net_blockchain.com:1004 , error: grpc: timed out when dialing
2017-06-01 20:18:59.134 UTC [deliveryClient] connect -> ERRO 307 Failed obtaining connection: Could not connect to any of the endpoints: [orderer-0c.net_blockchain.com:3004 orderer-0b.net_blockchain.com:2004 orderer-0a.net_blockchain.com:1004]
2017-06-01 20:19:03.136 UTC [ConnProducer] NewConnection -> ERRO 308 Failed connecting to orderer-0a.net_blockchain.com:1004 , error: grpc: timed out when dialing
2017-06-01 20:19:06.138 UTC [ConnProducer] NewConnection -> ERRO 309 Failed connecting to orderer-0b.net_blockchain.com:2004 , error: grpc: timed out when dialing
2017-06-01 20:19:09.139 UTC [ConnProducer] NewConnection -> ERRO 30a Failed connecting to orderer-0c.net_blockchain.com:3004 , error: grpc: timed out when dialing
2017-06-01 20:19:09.139 UTC [deliveryClient] connect -> ERRO 30b Failed obtaining connection: Could not connect to any of the endpoints: [orderer-0a.net_blockchain.com:1004 orderer-0b.net_blockchain.com:2004 orderer-0c.net_blockchain.com:3004]
2017-06-01 20:19:14.141 UTC [ConnProducer] NewConnection -> ERRO 30c Failed connecting to orderer-0a.net_blockchain.com:1004 , error: grpc: timed out when dialing
2017-06-01 20:19:17.141 UTC [ConnProducer] NewConnection -> ERRO 30d Failed connecting to orderer-0b.net_blockchain.com:2004 , error: grpc: timed out when dialing
2017-06-01 20:19:20.142 UTC [ConnProducer] NewConnection -> ERRO 30e Failed connecting to orderer-0c.net_blockchain.com:3004 , error: grpc: timed out when dialing
2017-06-01 20:19:20.142 UTC [deliveryClient] connect -> ERRO 30f Failed obtaining connection: Could not connect to any of the endpoints: [orderer-0a.net_blockchain.com:1004 orderer-0b.net_blockchain.com:2004 orderer-0c.net_blockchain.com:3004]
```
and on the orderer
```
2017-06-01 20:18:57.140 UTC [grpc] Printf -> DEBU 891 grpc: Server.Serve failed to complete security handshake from "172.21.0.13:50102": EOF
2017-06-01 20:18:58.609 UTC [grpc] Printf -> DEBU 892 grpc: Server.Serve failed to complete security handshake from "172.21.0.13:50104": EOF
2017-06-01 20:19:00.142 UTC [grpc] Printf -> DEBU 893 grpc: Server.Serve failed to complete security handshake from "172.21.0.13:50106": EOF
2017-06-01 20:19:01.142 UTC [grpc] Printf -> DEBU 894 grpc: Server.Serve failed to complete security handshake from "172.21.0.13:50108": EOF
2017-06-01 20:19:02.807 UTC [grpc] Printf -> DEBU 895 grpc: Server.Serve failed to complete security handshake from "172.21.0.13:50110": EOF
2017-06-01 20:19:11.146 UTC [grpc] Printf -> DEBU 896 grpc: Server.Serve failed to complete security handshake from "172.21.0.13:50124": EOF
2017-06-01 20:19:12.149 UTC [grpc] Printf -> DEBU 897 grpc: Server.Serve failed to complete security handshake from "172.21.0.13:50126": EOF
2017-06-01 20:19:13.895 UTC [grpc] Printf -> DEBU 898 grpc: Server.Serve failed to complete security handshake from "172.21.0.13:50132": EOF
2017-06-01 20:19:24.150 UTC [grpc] Printf -> DEBU 899 grpc: Server.Serve failed to complete security handshake from "172.21.0.13:50166": EOF
2017-06-01 20:19:25.150 UTC [grpc] Printf -> DEBU 89a grpc: Server.Serve failed to complete security handshake from "172.21.0.13:50168": EOF
2017-06-01 20:19:26.580 UTC [grpc] Printf -> DEBU 89b grpc: Server.Serve failed to complete security handshake from "172.21.0.13:50170": EOF
2017-06-01 20:19:41.153 UTC [grpc] Printf -> DEBU 89c grpc: Server.Serve failed to complete security handshake from "172.21.0.13:50190": EOF
```
i am not sure why, `peer cli` commands work so i guess peer-tls certs are good, and also for `peer channel create` the orderer does not complain
any ideas?
jimthematrix (Sun, 04 Jun 2017 14:50:05 GMT):
@muralisr I just opened https://jira.hyperledger.org/browse/FAB-4347 as `Highest`, let me know if I understood the situation wrong or if you have any questions
jimthematrix (Sun, 04 Jun 2017 14:50:23 GMT):
@bretharrison @rickr ^^^
muralisr (Sun, 04 Jun 2017 14:52:58 GMT):
@jimthematrix there were recent bug fixes based to what was returned. Let me check
muralisr (Sun, 04 Jun 2017 14:53:38 GMT):
so to recreate, try to install twice and look at the second error ?
jimthematrix (Sun, 04 Jun 2017 14:55:30 GMT):
yes
jimthematrix (Sun, 04 Jun 2017 14:58:00 GMT):
from what I've seen, the ProposalResponse.Response has the right status code (500), but the HTTP response status was 200
muralisr (Sun, 04 Jun 2017 15:19:21 GMT):
Right
muralisr (Sun, 04 Jun 2017 15:19:52 GMT):
long story short... previously we were reporting all chaincode errors as fabric errors
muralisr (Sun, 04 Jun 2017 15:19:59 GMT):
and suppressing chaincode responses
muralisr (Sun, 04 Jun 2017 15:20:28 GMT):
this was fixed in https://gerrit.hyperledger.org/r/#/c/9213/
muralisr (Sun, 04 Jun 2017 15:21:28 GMT):
which basically says "if chaincode returns a response and is > ERROR_THRESHOLD don't endorse it but return the response directly"
muralisr (Sun, 04 Jun 2017 15:23:32 GMT):
the problem was that if we returned error from the fabric users (and SDK) won't be able to tell if there was some non-chaincode related issue as well
muralisr (Sun, 04 Jun 2017 15:24:04 GMT):
would it be better to return a HTTP response 500 with the special message "chaincode error" ?
muralisr (Sun, 04 Jun 2017 15:24:14 GMT):
so you don't have to change code ?
muralisr (Sun, 04 Jun 2017 15:41:31 GMT):
@jimthematrix ^^ updated the JIRA
muralisr (Sun, 04 Jun 2017 15:41:39 GMT):
will provide a CR if this is the way to go
muralisr (Sun, 04 Jun 2017 15:42:11 GMT):
to @wlahti credit, he did raise the question when he fixed the bug....
jimthematrix (Sun, 04 Jun 2017 19:08:37 GMT):
@muralisr thanks for the response, I added my comments, using http status code 500 to indicate errors in chaincode (ProposalResponse.Response.status >= 400) makes sense to me.
jimthematrix (Sun, 04 Jun 2017 19:08:37 GMT):
@muralisr thanks for the response, I added my comments, using http status code to reflect errors in chaincode makes sense to me. I don't think always using 500 when the chaincode returns an error (>=400) is right. 500 is defined as "the server acted in unexpected ways", or "internal server errors", and it's typically not the client's fault. I don't think all chaincode error statuses can be characterized this way. for instance, if the chaincode checks the Creator field and applies access control, and returns 403, I would think an HTTP code of 403 is more appropriate than 500
jimthematrix (Sun, 04 Jun 2017 19:31:05 GMT):
so your https://gerrit.hyperledger.org/r/#/c/10135 (reflecting chaincode's status in http status code) as-is looks right to me
jimthematrix (Sun, 04 Jun 2017 19:31:21 GMT):
+2'ed
muralisr (Sun, 04 Jun 2017 19:57:33 GMT):
we should definitely use the code range to direct error processing on client @jimthematrix
Rachitga (Mon, 05 Jun 2017 08:26:38 GMT):
Has joined the channel.
Rachitga (Mon, 05 Jun 2017 08:39:37 GMT):
Hello all, I was trying to understand how the endorsing peer simulates the transactions in the code, can someone please help and point me to the code flow of how it happens, and point to the code sections involved?
Rachitga (Mon, 05 Jun 2017 08:41:49 GMT):
@muralisr can you please help me with the above query
jun (Mon, 05 Jun 2017 08:59:48 GMT):
Has joined the channel.
LordGoodman (Mon, 05 Jun 2017 09:58:19 GMT):
Has joined the channel.
thakkarparth007 (Mon, 05 Jun 2017 11:35:32 GMT):
I need to understand how the communication between a committer and an orderer works (wrt blocks). Does a committer pull blocks from orderer, or does the orderer push them, or is it a mix?
muralisr (Mon, 05 Jun 2017 11:48:05 GMT):
@Rachitga the involved code sections are in core/endorser/endorser.go - in particular "simulateProposal" and "endorseProposal" where endorseProposal calls the ESCC system chaincode in core/scc/escc/endorser_onevalidsignature.go ... btw, endorser_onevalidsignature.go is a misleading name.. it should really just be escc.go
muralisr (Mon, 05 Jun 2017 11:49:56 GMT):
@thakkarparth007 orderer pushes (or in orderer-speak, "delivers") blocks to the committer
thakkarparth007 (Mon, 05 Jun 2017 11:50:55 GMT):
So is the orderer aware of the positions (#blocks) of different clients?
thakkarparth007 (Mon, 05 Jun 2017 11:52:32 GMT):
Or does it ask the client from which block it must deliver to the client?
jeffgarratt (Mon, 05 Jun 2017 13:38:55 GMT):
@thakkarparth007 it is a mix of messages between the peer and the orderer through a stream. The peer sends a seek request to the orderer and the orderere sends the requested blocks back
thakkarparth007 (Mon, 05 Jun 2017 13:40:48 GMT):
Okay, so can you help me understand this - I'm trying to measure the performance of fabric components, and during one the runs, I found that the Ledger was not acquiring a write-lock in order to commit often. Could this be because the orderer is slow, or because the peer is too busy to pull?
thakkarparth007 (Mon, 05 Jun 2017 13:42:14 GMT):
Disk activity of orderer shows that it doesn't do much in that particular period, and hence I think that the orderer is the one causing trouble, but I'm not fully sure.
jeffgarratt (Mon, 05 Jun 2017 13:43:48 GMT):
@thakkarparth007 I would run the orderer in 'solo' mode to reduce the latency of orderer to minimum
thakkarparth007 (Mon, 05 Jun 2017 13:44:27 GMT):
Hmm. Right, I'll try that out. Thanks!
jeffgarratt (Mon, 05 Jun 2017 13:45:21 GMT):
yw!
thakkarparth007 (Mon, 05 Jun 2017 13:47:08 GMT):
To do so, is it enough to set the `CONFIGTX_ORDERER_ORDERERTYPE` env-variable to 'solo'?
jeffgarratt (Mon, 05 Jun 2017 13:57:14 GMT):
@thakkarparth007 check the log of your orderer, it will log the genesis type
jeffgarratt (Mon, 05 Jun 2017 13:57:19 GMT):
it may already be solo
jeffgarratt (Mon, 05 Jun 2017 13:57:46 GMT):
the default for most example scenarios is solo
thakkarparth007 (Mon, 05 Jun 2017 14:02:08 GMT):
No, it was setup with kafka in our setup, but I hadn't set it up. I can't contact the people who set it up, that's why I asked here :P
thakkarparth007 (Mon, 05 Jun 2017 14:02:50 GMT):
I see a script that starts the orderer and one of the environment variables that is passed to it is `CONFIGTX_ORDERER_ORDERERTYPE=kafka`.
jeffgarratt (Mon, 05 Jun 2017 14:29:48 GMT):
@thakkarparth007 that is for generating the appropriate genesis block for the orderer.
thakkarparth007 (Mon, 05 Jun 2017 14:30:41 GMT):
Oh okay then. I'll just wait for them then. Thank you!
jeffgarratt (Mon, 05 Jun 2017 14:30:48 GMT):
yw
yacovm (Mon, 05 Jun 2017 20:41:32 GMT):
does anyone know how do I setup TLS for chaincode? the chaincode container complains: `Error trying to connect to local peer: x509: certificate signed by unknown authority`
jdockter (Mon, 05 Jun 2017 20:52:38 GMT):
Has left the channel.
Rachitga (Tue, 06 Jun 2017 05:42:29 GMT):
Thanks for the reply @muralisr , so I went through the files you mentioned, so what I understand is that the escc.go just signs the proposal back, it doesn't read the fields of the proposal, all those checks happen in endorser.go. Simulate proposal in endorser.go is where the simulation is called, so how does the simulation go through? Which system chaincodes are involved there, how does it read the ledger on the peer that has been stored uptil now? Can you clear if I have understood correctly, and the aspects that I am missing.
muralisr (Tue, 06 Jun 2017 11:51:52 GMT):
@Rachitga simulate proposal calls the chaincode in the Proposal request. On successful execution, the results are collected and send to escc to create a proposal response and sign it.
bretharrison (Tue, 06 Jun 2017 17:59:26 GMT):
@mastersingh24 I have been looking at the `Wireshark` trace of the grpc `keepalive` and I see only 3 blocks of TCP activity to the peer from the NodeApp exactly on the defined keepalive_time and then no more activity. Have you seen this, is this normal ?
mastersingh24 (Tue, 06 Jun 2017 18:46:44 GMT):
@bretharrison - so you are saying the NodeApp only sends keepalives for 3 intervals?
bretharrison (Tue, 06 Jun 2017 19:58:14 GMT):
Yes
rahulhegde (Tue, 06 Jun 2017 22:55:57 GMT):
Is shim.GetTxID() going to return same value across all endorsers for the same endorsing transaction?
muralisr (Wed, 07 Jun 2017 00:09:44 GMT):
@rahulhegde assuming the SDK is sending the same proposal, yes
bh4rtp (Wed, 07 Jun 2017 03:10:03 GMT):
Has joined the channel.
bh4rtp (Wed, 07 Jun 2017 03:14:24 GMT):
@here hi, i have problem with `GetState` in chaincode. i changed to use kafka ordering. the `batchSize` and `batchTimeout` are set as default, i.e. 5 and 2s. in the cli command script, sleep 5 is done after register 5 entities (5 invocation finished). but `GetState` always return nil, nil even though adding sleep 10 before querying. so my question is why `GetState` fails as the ordering block commit condition meeted (both batch timeout and count)?
bh4rtp (Wed, 07 Jun 2017 03:14:24 GMT):
@here hi, i have problem with `GetState` in chaincode. i changed to use kafka ordering. the `batchSize` and `batchTimeout` are set to be 5 and 2s. in the cli command script, sleep 5 is done after register 5 entities (5 invocation finished). but `GetState` always return nil, nil even though adding sleep 10 before querying. so my question is why `GetState` fails as the ordering block commit condition meeted (both batch timeout and count)?
bh4rtp (Wed, 07 Jun 2017 03:14:24 GMT):
@here hi, i have problem with `GetState` in chaincode. i changed to use kafka ordering. the `batchSize` and `batchTimeout` are set to be 5 and 2s. in the cli command script, sleep 5 is done after register 5 entities (5 invocation finished). but `GetState` always return `nil, nil` even though adding sleep 10 before querying. so my question is why `GetState` fails as the ordering block commit condition meeted (both batch timeout and count)?
bh4rtp (Wed, 07 Jun 2017 07:58:23 GMT):
the problem is solved. the hash code taken as state key is changed. :blush:
s.narayanan (Wed, 07 Jun 2017 13:59:01 GMT):
what is the behavior of a (endorser/commiter) peer node when couch db fails or is brought down? does the peer return any error messages in response to endorsement requests or during validation/commit phase? ideally the peer can be marked unavailable and request routed to healthy peer in this scenario. Are there other approaches to detect such a scenario and route to healthy peer and to restore the routing to the peer when its underlying couchdb database becomes available?
smithbk (Wed, 07 Jun 2017 15:46:32 GMT):
Has left the channel.
jeffgarratt (Wed, 07 Jun 2017 20:41:20 GMT):
@s.narayanan I did a quick test, and it appears you get a timeout from a client.
jeffgarratt (Wed, 07 Jun 2017 20:41:47 GMT):
the logs of the peer indicated the loss of conn to couchdb, and the attempts to reconnect.
s.narayanan (Thu, 08 Jun 2017 13:53:54 GMT):
@jeffgarratt is the timeout observed during endorsement or validation/commit?
jeffgarratt (Thu, 08 Jun 2017 14:03:23 GMT):
@s.narayanan In my test I killed couchdb just prior to endorsement attempt, so I did not get a response for which I could create a TX (so just during endorsement)
s.narayanan (Thu, 08 Jun 2017 14:10:02 GMT):
@jefg
s.narayanan (Thu, 08 Jun 2017 14:13:29 GMT):
@jeffgarratt thanks. If the client receives an error during endorsement (due to couchdb being down), then client can retry (presumably send request to another endorser node ). However, I would like to understand what occurs during validation. I assume the peer cannot commit to the world state. Until the couchdb is brough back up, the peer will remain unavailable (i.e. it cannot sync its ledger state) and then once the couchdb is restored, the peer can begin delivering blocks from orderer to catch up?
jeffgarratt (Thu, 08 Jun 2017 14:15:16 GMT):
@s.narayanan I would presume there are a several ways the client could recover once the ledger store has recovered. @muralisr or @yacovm may be able to answer more definitively wrt to mechanisms emploed.
jeffgarratt (Thu, 08 Jun 2017 14:15:16 GMT):
@s.narayanan I would presume there are a several ways the client could recover once the ledger store has recovered. @muralisr or @yacovm may be able to answer more definitively wrt to mechanisms employed.
yacovm (Thu, 08 Jun 2017 14:16:07 GMT):
Validation has nothing to do with access to DB.
It's only in commit
yacovm (Thu, 08 Jun 2017 14:16:07 GMT):
> However, I would like to understand what occurs during validation
Validation has nothing to do with access to DB.
It's only in commit
jeffgarratt (Thu, 08 Jun 2017 14:16:19 GMT):
in general this should not be dissimilar from a standard start up of a peer that is behind
yacovm (Thu, 08 Jun 2017 14:16:30 GMT):
Validation is only a logical process (checking endorsement policy, validation of certificates of endorsements, etc.)
muralisr (Thu, 08 Jun 2017 14:39:15 GMT):
@s.narayanan `validation failed` is broad. Softer failures are invalid state changes, endorsement that does not meet policy etc. The scenario you have cited (couchdb down) is a hard failure. In that case admin likely has to get involved, restore couch db and get the peer back up again. At that point regular mechanism of "catching up" ( @yacovm may help here ?) will take over
muralisr (Thu, 08 Jun 2017 14:39:15 GMT):
@s.narayanan `validation failed` is broad. Softer failures are invalid state changes, endorsement that does not meet policy etc. The scenario you have cited (couchdb down) is a hard failure where - for example - the commit of a block fails. In that case admin likely has to get involved, restore couch db and get the peer back up again. At that point regular mechanism of "catching up" ( @yacovm may help here ?) will take over
yacovm (Thu, 08 Jun 2017 14:41:10 GMT):
basically if the DB is in a consistent state then the peer should be able to catch up via other peers or directly from the ordering service
muralisr (Thu, 08 Jun 2017 14:41:45 GMT):
^^^ there you go @s.narayanan
toddinpal (Thu, 08 Jun 2017 14:44:18 GMT):
Do chaincode query functions end up in the ledger? My guess is no, but was having a hard time finding this in the docs.
s.narayanan (Thu, 08 Jun 2017 15:21:18 GMT):
@yacovm @muralisr thanks
jeffgarratt (Thu, 08 Jun 2017 15:24:45 GMT):
@toddinpal any endorsed proposal can be submitted as a transaction, and this be placed within the ledger.
jeffgarratt (Thu, 08 Jun 2017 15:24:45 GMT):
@toddinpal any endorsed proposal can be submitted as a transaction, and thus be placed within the ledger.
jeffgarratt (Thu, 08 Jun 2017 15:25:20 GMT):
you are also free to never submit the proposal, as may be the case for readonly invocations
jeffgarratt (Thu, 08 Jun 2017 15:25:20 GMT):
you are also free to never submit the endorsed proposal, as may be the case for readonly invocations
toddinpal (Thu, 08 Jun 2017 15:26:05 GMT):
@jeffgarratt I was under the impression there is a query operation distinct from the invoke operation
toddinpal (Thu, 08 Jun 2017 15:26:39 GMT):
Are they handled differently in the shim?
jeffgarratt (Thu, 08 Jun 2017 15:26:45 GMT):
I don't think that distinction exists with v1, but @muralisr can correct me
toddinpal (Thu, 08 Jun 2017 15:27:07 GMT):
Argh... so much old documentation... making me crazy! :-)
jeffgarratt (Thu, 08 Jun 2017 15:27:27 GMT):
sorry :(
toddinpal (Thu, 08 Jun 2017 15:38:44 GMT):
Another question: Do endorsing peers asynchronously handle endorsements, in other words can an endorsing peer be simultaneously endorsing multiple requests?
jeffgarratt (Thu, 08 Jun 2017 15:47:31 GMT):
@toddinpal they can endorse in parallel, but the actual endorsement request from the client side is synch.
toddinpal (Thu, 08 Jun 2017 15:48:22 GMT):
So endorsement request is synch, but proposal request is asynch?
jeffgarratt (Thu, 08 Jun 2017 15:48:43 GMT):
not sure what a proposal request is
jeffgarratt (Thu, 08 Jun 2017 15:49:46 GMT):
```service Endorser {
rpc ProcessProposal(SignedProposal) returns (ProposalResponse) {}
}
jeffgarratt (Thu, 08 Jun 2017 15:50:38 GMT):
that is the API, the request will block until the peer responds. However, you can always invoke with asynchronous mechanisms.
toddinpal (Thu, 08 Jun 2017 15:50:43 GMT):
And smart contract containers handle requests in parallel or serially? Just trying to understand the level of parallelism
jeffgarratt (Thu, 08 Jun 2017 15:50:49 GMT):
and the peer can handle these requests in parallel
jeffgarratt (Thu, 08 Jun 2017 15:51:10 GMT):
and I also believe they are parallel against the chaincode
jeffgarratt (Thu, 08 Jun 2017 15:51:24 GMT):
@muralisr can verify ^^
toddinpal (Thu, 08 Jun 2017 15:51:33 GMT):
Ok, many thanks!
jeffgarratt (Thu, 08 Jun 2017 15:51:38 GMT):
yw!
jeffgarratt (Thu, 08 Jun 2017 15:52:40 GMT):
let me clarify, they may be serialized for a specific chaincode within a channel.
jeffgarratt (Thu, 08 Jun 2017 15:52:40 GMT):
@toddinpal let me clarify, they may be serialized for a specific chaincode within a channel.
toddinpal (Thu, 08 Jun 2017 15:53:15 GMT):
makes sense
muralisr (Thu, 08 Jun 2017 15:54:10 GMT):
@jeffgarratt you are right... the proposals can be handled concurrently all through (including chaincode)
muralisr (Thu, 08 Jun 2017 15:54:10 GMT):
@jeffgarratt you are right... the proposals will be handled concurrently all through (including chaincode)
toddinpal (Thu, 08 Jun 2017 15:54:56 GMT):
@muralisr What controls the number of threads in each?
muralisr (Thu, 08 Jun 2017 15:56:07 GMT):
no limit at the chaincode level ... we just use go routines and the grcp stack
toddinpal (Thu, 08 Jun 2017 16:04:46 GMT):
OK, many thanks!
varadatibm (Thu, 08 Jun 2017 17:24:30 GMT):
Has joined the channel.
varadatibm (Thu, 08 Jun 2017 17:26:55 GMT):
We currently have an API to join peer to the channel. Is there an API for 'leave channel' for peer? @yacovm @muralisr @binhn
binhn (Thu, 08 Jun 2017 17:29:31 GMT):
no explicit api but via config update -- the channel material remain on the peer
binhn (Thu, 08 Jun 2017 17:30:16 GMT):
but it will no long receive blocks on the channel
binhn (Thu, 08 Jun 2017 17:30:16 GMT):
but it will no longer receive blocks on the channel
varadatibm (Thu, 08 Jun 2017 17:32:27 GMT):
Config Update for the channel itself? So if I joined 3 of my peers to channel and I just want to remove one of it, the other 2 can still receive blocks?
jeffgarratt (Thu, 08 Jun 2017 17:40:09 GMT):
@varadatibm correct... but be careful with your policies for channel admin as if you require all, you will need all 3 to agree that the one is getting removed
varadatibm (Thu, 08 Jun 2017 17:41:00 GMT):
Just want to me clear all my 3 peers are from the same org
varadatibm (Thu, 08 Jun 2017 17:41:11 GMT):
so I am just removing one of my peers from my org
jeffgarratt (Thu, 08 Jun 2017 17:41:24 GMT):
ahhh.... then that is a CRL issue
jeffgarratt (Thu, 08 Jun 2017 17:41:44 GMT):
you can do a config update updating the CRLs for the mspconfig
varadatibm (Thu, 08 Jun 2017 17:42:02 GMT):
CRL?
jeffgarratt (Thu, 08 Jun 2017 17:42:11 GMT):
certificate revocation
jeffgarratt (Thu, 08 Jun 2017 17:42:21 GMT):
CRL -> certificate revocation list
varadatibm (Thu, 08 Jun 2017 17:42:30 GMT):
I see...
varadatibm (Thu, 08 Jun 2017 17:45:05 GMT):
I am just looking at `src/github.com/hyperledger/fabric/core/scc/cscc/configure.go` which is where there is a join channel
varadatibm (Thu, 08 Jun 2017 17:45:23 GMT):
and I was hoping there was a "Leave Channel" :-)
jeffgarratt (Thu, 08 Jun 2017 17:46:42 GMT):
:) ahh if it were only that simple
jeffgarratt (Thu, 08 Jun 2017 17:47:18 GMT):
@now there is an additional option of specifing the actual cert as the principal setting for the channel config
jeffgarratt (Thu, 08 Jun 2017 17:47:18 GMT):
@varadatibm there is an additional option of specifing the actual cert as the principal setting for the channel config
jeffgarratt (Thu, 08 Jun 2017 17:47:54 GMT):
in general people use the ROLE choice, but you can also use the IDENTITY
jeffgarratt (Thu, 08 Jun 2017 17:48:02 GMT):
in this case, the user can remove themselves directly
jeffgarratt (Thu, 08 Jun 2017 17:48:11 GMT):
without approval I believe
jeffgarratt (Thu, 08 Jun 2017 17:48:25 GMT):
would need to verify
binhn (Thu, 08 Jun 2017 17:49:01 GMT):
is it just a simple leave? ie the peer's cert is still valid and can join at later time?
varadatibm (Thu, 08 Jun 2017 17:49:28 GMT):
right
binhn (Thu, 08 Jun 2017 17:50:23 GMT):
just kill the peer
varadatibm (Thu, 08 Jun 2017 17:50:39 GMT):
But the peer may be needed for other channels
varadatibm (Thu, 08 Jun 2017 17:51:12 GMT):
He may have joined channel1 and channel2, but just need to leave from channel1 for example
binhn (Thu, 08 Jun 2017 17:53:57 GMT):
no easy workaround and it could be complex code (the peer could be a leader, an anchor, etc); could you submit a jira for future
varadatibm (Thu, 08 Jun 2017 17:54:19 GMT):
yeap... opened up one already
varadatibm (Thu, 08 Jun 2017 17:54:35 GMT):
https://jira.hyperledger.org/browse/FAB-4481
binhn (Thu, 08 Jun 2017 17:54:42 GMT):
thanks
binhn (Thu, 08 Jun 2017 17:55:20 GMT):
no, this is a new feature request, not a bug
varadatibm (Thu, 08 Jun 2017 17:55:30 GMT):
sorry! left the default!
varadatibm (Thu, 08 Jun 2017 17:55:46 GMT):
updated
thakkarparth007 (Thu, 08 Jun 2017 18:43:09 GMT):
Can someone tell how to debug a vscc? I want to enable the logs, what is the relevant option in core.yaml?
thakkarparth007 (Thu, 08 Jun 2017 18:43:36 GMT):
Or if I create a temp file in the vscc code, would it be created inside the docker container running that chaincode?
thakkarparth007 (Thu, 08 Jun 2017 18:43:36 GMT):
Or if I create a temp file in the vscc code, would it be created inside the docker container running that chaincode? I tried this already, but didn't get any file
thakkarparth007 (Thu, 08 Jun 2017 18:59:22 GMT):
Nevermind, found a way using http://hyperledger-fabric.readthedocs.io/en/latest/Setup/logging-control.html
toddinpal (Thu, 08 Jun 2017 21:10:02 GMT):
@binhn Is there documentation yet on the leader/anchor roles for peers?
binhn (Thu, 08 Jun 2017 21:58:44 GMT):
@toddinpal peer leader is a yaml config, so take a look at core.yaml in the sampleconfig directory; anchor is a config tx info described in the configtx.rst doc
toddinpal (Thu, 08 Jun 2017 22:10:25 GMT):
@binhn I guess I meant in terms of the specifics of their roles. I've been able to glean some of that from various places, but certainly the 1.0 architecture description in the documentation doesn't reflect it as far as I can tell
binhn (Thu, 08 Jun 2017 22:21:03 GMT):
they are not architectural topic but more on implementation -- specific configuration for connectivity
binhn (Thu, 08 Jun 2017 22:21:03 GMT):
they are not architectural topics but more on implementation -- specific configuration for connectivity
toddinpal (Thu, 08 Jun 2017 22:21:49 GMT):
Perhaps, although I generally like to define architecture as behavior that is held constant over time/releases.
toddinpal (Thu, 08 Jun 2017 22:23:07 GMT):
For example the architecture document says the ordering service delivers the blocks to the peers, yet my understanding of the code is that in fact it is the leader peers that pull the blocks. I think push vs pull is an architecture, not design issue.
toddinpal (Fri, 09 Jun 2017 01:49:29 GMT):
What statistics if any are maintained by the peer/endorser/committer/orderer and how they accessed?
butch.g (Fri, 09 Jun 2017 02:06:51 GMT):
Has joined the channel.
yacovm (Fri, 09 Jun 2017 15:43:47 GMT):
Hi all.
When a peer is switched on TLS that means that all of the docker containers of the chaincode need to be re-built, in order to "pick up" the TLS configuration and possibly the certificates, no?
@muralisr @binhn @greg.haskins
yacovm (Fri, 09 Jun 2017 15:44:53 GMT):
If that is true - I wonder if that is documented somewhere?
muralisr (Fri, 09 Jun 2017 15:58:52 GMT):
@yacovm that's correct
muralisr (Fri, 09 Jun 2017 15:58:58 GMT):
and is not doced
muralisr (Fri, 09 Jun 2017 15:59:38 GMT):
in fact currently the simplest way woud be to manually rmi the image
jeffgarratt (Fri, 09 Jun 2017 16:03:46 GMT):
@yacovm @muralisr this also recently manifested with the removal of the config sections for orderer, which required a make clean to clear the config tars
yacovm (Fri, 09 Jun 2017 16:06:07 GMT):
Yeah I know the solution, I'm asking because I guess the average end user doesn't ;)
jeffgarratt (Fri, 09 Jun 2017 16:08:32 GMT):
wait a sec, for TLS this should not be an issue
jeffgarratt (Fri, 09 Jun 2017 16:08:32 GMT):
@yacovm @muralisr wait a sec, for TLS this should not be an issue
jeffgarratt (Fri, 09 Jun 2017 16:08:59 GMT):
the TLS settings are overridden at launch time with ENV vars
jeffgarratt (Fri, 09 Jun 2017 16:09:13 GMT):
so image rebuilds would be unnecessary in this case
jeffgarratt (Fri, 09 Jun 2017 16:09:50 GMT):
the orderer issue was different in that the config was not overridden but rather deprecated
jeffgarratt (Fri, 09 Jun 2017 16:10:17 GMT):
so I think it is not true that you have to rebuild images if TLS turned on
jeffgarratt (Fri, 09 Jun 2017 16:11:06 GMT):
this is predicated of course on referencing the certs through volumes and supplying the proper ENV var value to point to said volume
yacovm (Fri, 09 Jun 2017 16:13:22 GMT):
Thanks for the correction @jeffgarratt , @muralisr is that true? ^
But this also means that the chaincode needs to be relaunched, no?
jeffgarratt (Fri, 09 Jun 2017 16:13:49 GMT):
@yacovm yes, you would need to relaunch the entire system
muralisr (Fri, 09 Jun 2017 16:14:09 GMT):
@jeffgarratt @yacovm the cert is packaged with the image I;m pretty sure
jeffgarratt (Fri, 09 Jun 2017 16:14:50 GMT):
as long as the certs are available, should be good to go
muralisr (Fri, 09 Jun 2017 16:14:55 GMT):
```func GenerateDockerBuild(cds *pb.ChaincodeDeploymentSpec) (io.Reader, error) {
inputFiles := make(InputFiles)
// ----------------------------------------------------------------------------------------------------
// Determine our platform driver from the spec
// ----------------------------------------------------------------------------------------------------
platform, err := Find(cds.ChaincodeSpec.Type)
if err != nil {
return nil, fmt.Errorf("Failed to determine platform type: %s", err)
}
// ----------------------------------------------------------------------------------------------------
// Transfer the peer's TLS certificate to our list of input files, if applicable
// ----------------------------------------------------------------------------------------------------
// NOTE: We bake the peer TLS certificate in at the time we build the chaincode container if a cert is
// found, regardless of whether TLS is enabled or not. The main implication is that if the administrator
// updates the peer cert, the chaincode containers will need to be invalidated and rebuilt.
// We will manage enabling or disabling TLS at container run time via CORE_PEER_TLS_ENABLED
cert, err := getPeerTLSCert()
if err != nil {
return nil, fmt.Errorf("Failed to read the TLS certificate: %s", err)
}
```
jeffgarratt (Fri, 09 Jun 2017 16:15:14 GMT):
good deal!!
muralisr (Fri, 09 Jun 2017 16:15:21 GMT):
only enabling or disabling is "container time"
jeffgarratt (Fri, 09 Jun 2017 16:15:47 GMT):
and by default chaincodes exit on peer exit (which would be required to enable TLS)
jeffgarratt (Fri, 09 Jun 2017 16:16:08 GMT):
and would relaunch when required (with the new TLS settings of the peer)
muralisr (Fri, 09 Jun 2017 16:16:56 GMT):
right. but would require the old image to be deleted so the new one could be regen with the new cert (if the change was new TLS certs)
jeffgarratt (Fri, 09 Jun 2017 16:16:58 GMT):
the benefits of the client based nature of chaincodes wrt to peer
jeffgarratt (Fri, 09 Jun 2017 16:17:30 GMT):
correct, if you change certs, then all bets off
yacovm (Fri, 09 Jun 2017 16:17:53 GMT):
wait, but how are the env vars passed to the container?
yacovm (Fri, 09 Jun 2017 16:17:58 GMT):
at launch?
jeffgarratt (Fri, 09 Jun 2017 16:18:13 GMT):
yes
yacovm (Fri, 09 Jun 2017 16:24:44 GMT):
Where in the code? `StartContainer` has `nil` for the `cfg *docker.HostConfig`
yacovm (Fri, 09 Jun 2017 16:25:01 GMT):
@muralisr or @jeffgarratt can you shed some light?
muralisr (Fri, 09 Jun 2017 16:25:56 GMT):
for the TLS settings @yacovm ?
muralisr (Fri, 09 Jun 2017 16:26:54 GMT):
https://github.com/hyperledger/fabric/blob/master/core/chaincode/chaincode_support.go#L360
muralisr (Fri, 09 Jun 2017 16:27:22 GMT):
note that the cert is not passed there
yacovm (Fri, 09 Jun 2017 16:27:47 GMT):
I'm trying to understand how and where does the ENV vars get passed
grice_32 (Fri, 09 Jun 2017 19:00:58 GMT):
Has joined the channel.
jeffgarratt (Sun, 11 Jun 2017 16:52:32 GMT):
@yacovm was wondering what the expected value for gossip.externalendpoint should be? Can this be the same port as the peer? i.e. 7051?
jeffgarratt (Sun, 11 Jun 2017 16:52:32 GMT):
@yacovm was wondering what the expected value for gossip.externalendpoint should be? Can this be the same port as the peer? i.e. would
yacovm (Sun, 11 Jun 2017 17:25:28 GMT):
yeah
Rachitga (Mon, 12 Jun 2017 10:44:53 GMT):
Hello All, I was trying to read the propose transaction fields in the /core/endorser/endorser.go file, I could read all the fields, but what I found was that I was always ending up with nil in my data structure in the unmarshalled payload structure (unprop), and if I print the unmarshaled proposal(uprop) the ouptput file size increases to 86 MB. What could be the possible reasons for it, and am I making a mistake in reading my data?
Am using SampleSingleMSPSolo profile for orderer defined in /sampleconfig/configtx.yaml
and am using SampleSingleMSPChannel to create the transaction for the channel, and am running the marbles02 example
Here I indicate the piece of code that I am trying to print ( In /core/endorser/endorser.go)
'inline_code'
// ProcessProposal process the Proposal
func (e *Endorser) ProcessProposal(ctx context.Context, signedProp *pb.SignedProposal) (*pb.ProposalResponse, error) {
// at first, we check whether the message is valid
prop, hdr, hdrExt, err := validation.ValidateProposalMessage(signedProp)
....
....
....
// TODO: if the proposal has an extension, it will be of type ChaincodeAction;
// if it's present it means that no simulation is to be performed because
// we're trying to emulate a submitting peer. On the other hand, we need
// to validate the supplied action before endorsing it
//1 -- simulate
//Lines added by me
marshalprop,err := putils.Marshal(prop)
uprop,err := putils.GetProposal(marshalprop)
if err == nil {
fmt.Printf("Unmarshaled proposal is\n\n%#v\n\n",uprop)
}
unprop, err := putils.UnmarshalPayload(prop.Payload)
if err == nil {
fmt.Printf("Payload is: \n%#v\n",unprop)
}
//Addition finished
....
....
....
}
'inline_code'
A huge structure is printed in bytes where unmarshaled proposal is supposed to be there, and where unmarshaled payload is supposed to be, this gets printed:-
Payload is:
&common.Payload{Header:(*common.Header)(0xc4213d9e90), Data:[]uint8(nil)}
Can somebody explain the observations and how to get what I am looking for?
Rachitga (Mon, 12 Jun 2017 10:44:53 GMT):
@muralisr , @mastersingh24 , @bmos299
I was trying to read the propose transaction fields in the /core/endorser/endorser.go file, I could read all the fields, but what I found was that I was always ending up with nil in my data structure in the unmarshalled payload structure (unprop), and if I print the unmarshaled proposal(uprop) the ouptput file size increases to 86 MB. What could be the possible reasons for it, and am I making a mistake in reading my data?
Am using SampleSingleMSPSolo profile for orderer defined in /sampleconfig/configtx.yaml
and am using SampleSingleMSPChannel to create the transaction for the channel, and am running the marbles02 example
Here I indicate the piece of code that I am trying to print ( In /core/endorser/endorser.go)
```
// ProcessProposal process the Proposal
func (e *Endorser) ProcessProposal(ctx context.Context, signedProp *pb.SignedProposal) (*pb.ProposalResponse, error) {
// at first, we check whether the message is valid
prop, hdr, hdrExt, err := validation.ValidateProposalMessage(signedProp)
....
....
....
// TODO: if the proposal has an extension, it will be of type ChaincodeAction;
// if it's present it means that no simulation is to be performed because
// we're trying to emulate a submitting peer. On the other hand, we need
// to validate the supplied action before endorsing it
//1 -- simulate
//Lines added by me
marshalprop,err := putils.Marshal(prop)
uprop,err := putils.GetProposal(marshalprop)
if err == nil {
fmt.Printf("Unmarshaled proposal is\n\n%#v\n\n",uprop)
}
unprop, err := putils.UnmarshalPayload(prop.Payload)
if err == nil {
fmt.Printf("Payload is: \n%#v\n",unprop)
}
//Addition finished
....
....
....
}
```
A huge structure is printed in bytes where unmarshaled proposal is supposed to be there, and where unmarshaled payload is supposed to be, this gets printed:-
Payload is:
&common.Payload{Header:(*common.Header)(0xc4213d9e90), Data:[]uint8(nil)}
Can somebody explain the observations and how to get what I am looking for?
rahulhegde (Mon, 12 Jun 2017 19:43:51 GMT):
@muralisr @bmos299
I am running on hyperledger beta fabric images and my chaincode instantiation fails, this used to pass on Alpha3 (19th May Images). Our chaincode refers to another package and seems there is something changed the way Peer CLI instantiates the chaincode.
```
2017-06-12 19:34:02.077 UTC [msp/identity] Sign -> DEBU 009 Sign: digest: DCCA7DE03A3B63CA3B84A29637CE6339E90B5C1C5E3101F5A35FE66364260EFA
Error: Error endorsing chaincode: rpc error: code = Unknown desc = Error starting container: Failed to generate platform-specific docker build: Error returned from build: 1 "chaincode/input/src/github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02/chaincode_example02.go:28:2: cannot find package "github.com/shopspring/decimal" in any of:
/chaincode/input/src/github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02/vendor/github.com/shopspring/decimal (vendor tree)
/opt/go/src/github.com/shopspring/decimal (from $GOROOT)
/chaincode/input/src/github.com/shopspring/decimal (from $GOPATH)
/opt/gopath/src/github.com/shopspring/decimal
```
Is this again related to ` govendor ` ==> I am running 2 command ` govendor init ` and ` govendor add external+ ` inside the chaincode folder ?
absingh0 (Tue, 13 Jun 2017 05:53:24 GMT):
Has joined the channel.
mastersingh24 (Tue, 13 Jun 2017 08:58:12 GMT):
@rahulhegde - you definitely need to vendor any external dependencies
rahulhegde (Tue, 13 Jun 2017 10:15:36 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=4sy9xjxec6jDarnst) @mastersingh24
I did that using the above 2 commands but this doesn't seem to resolve.
Can you check the finding of
https://chat.hyperledger.org/channel/fabric-ci?msg=RBxGMq6yGmwFJuHLB
rahulhegde (Tue, 13 Jun 2017 10:15:36 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=4sy9xjxec6jDarnst) @mastersingh24
I did that using the above 2 commands but this doesn't seem to resolve.
Can you check finding of
https://chat.hyperledger.org/channel/fabric-ci?msg=RBxGMq6yGmwFJuHLB
https://chat.hyperledger.org/channel/fabric-ci?msg=N8cfYJBvufi6vwTRD
muralisr (Tue, 13 Jun 2017 14:35:59 GMT):
right saw that
muralisr (Tue, 13 Jun 2017 14:36:36 GMT):
will update soon
mastersingh24 (Tue, 13 Jun 2017 14:46:14 GMT):
@muralisr @rahulhegde @greg.haskins :
1) Rahul is correct - basically the packaging does not include the import itself but rather just the dependency - which is a bit odd - but that is what Rahul's fix above does
2) Greg - did you specifically NOT WANT to support vendoring or were you trying to avoid the need to do it by doing it under the covers? (basically the packaging code today does not account for code already vendored)
muralisr (Tue, 13 Jun 2017 14:53:40 GMT):
@mastersingh24 don't want to put words into @greg.haskins mouth ... open to correction ... but I believe the idea was if its already vendored it'll get picked up automatically
muralisr (Tue, 13 Jun 2017 14:53:53 GMT):
checking this out
muralisr (Tue, 13 Jun 2017 14:56:34 GMT):
@mastersingh24 @rahulhegde will update soon
greg.haskins (Tue, 13 Jun 2017 15:10:18 GMT):
@mastersingh24 @muralisr sorry, was traveling yesterday, just getting back online now
greg.haskins (Tue, 13 Jun 2017 15:10:22 GMT):
trying to digest the backlog
mastersingh24 (Tue, 13 Jun 2017 15:11:44 GMT):
I ran some tests and vendored code is not being picked up
greg.haskins (Tue, 13 Jun 2017 15:12:26 GMT):
the intent was as follows
greg.haskins (Tue, 13 Jun 2017 15:13:01 GMT):
given a package A, we would package up A, A/vendor, and any of A's deps (direct or transitive) _excluding_ the shim
greg.haskins (Tue, 13 Jun 2017 15:13:09 GMT):
if that is not what is happening, its a bug
greg.haskins (Tue, 13 Jun 2017 15:13:33 GMT):
(any relevant detail...A's deps end up in A/vendor in the package
greg.haskins (Tue, 13 Jun 2017 15:13:33 GMT):
(another relevant detail...A's deps end up in A/vendor in the package
mastersingh24 (Tue, 13 Jun 2017 15:13:53 GMT):
I think @rahulhegde has the right fix but need to double check
greg.haskins (Tue, 13 Jun 2017 15:14:13 GMT):
i need to review the whole function to understand what he is proposing
mastersingh24 (Tue, 13 Jun 2017 15:14:49 GMT):
The problem is that the code will not include imports which don't have dependencies or aren't a dependency
greg.haskins (Tue, 13 Jun 2017 15:15:18 GMT):
what does it mean to be an import but not a dep?
mastersingh24 (Tue, 13 Jun 2017 15:15:18 GMT):
Or basically top level dependencies (e.g. the imports) are not being considered
greg.haskins (Tue, 13 Jun 2017 15:15:22 GMT):
that is what is confusing me
greg.haskins (Tue, 13 Jun 2017 15:15:41 GMT):
ah, so basically we pick up transitives but not directs
greg.haskins (Tue, 13 Jun 2017 15:15:42 GMT):
?
greg.haskins (Tue, 13 Jun 2017 15:15:56 GMT):
I would buy that...let me review
mastersingh24 (Tue, 13 Jun 2017 15:17:12 GMT):
correct - https://github.com/hyperledger/fabric/blob/master/core/chaincode/platforms/golang/platform.go#L246
mastersingh24 (Tue, 13 Jun 2017 15:17:37 GMT):
I think we need to add the direct import as a dep in the map
greg.haskins (Tue, 13 Jun 2017 15:18:05 GMT):
ah, yeah, plain as day now that i see the whole thing
greg.haskins (Tue, 13 Jun 2017 15:18:12 GMT):
I meant to merge imports -> deps
greg.haskins (Tue, 13 Jun 2017 15:18:28 GMT):
which is effectively what @rahulhegde 's patch does
greg.haskins (Tue, 13 Jun 2017 15:18:47 GMT):
I agree this is a suitable fix
greg.haskins (Tue, 13 Jun 2017 15:19:16 GMT):
only general comment would be: should be commented, and ideally a test which captures my screw up
greg.haskins (Tue, 13 Jun 2017 15:19:32 GMT):
I can do this if @rahulhegde is not willing
mastersingh24 (Tue, 13 Jun 2017 15:20:03 GMT):
If you can do it Greg that would be best
greg.haskins (Tue, 13 Jun 2017 15:20:11 GMT):
ok
greg.haskins (Tue, 13 Jun 2017 15:20:19 GMT):
should be quick, stand by
mastersingh24 (Tue, 13 Jun 2017 15:20:28 GMT):
gracias
mastersingh24 (Tue, 13 Jun 2017 15:20:37 GMT):
nice catch / find @rahulhegde ;)
greg.haskins (Tue, 13 Jun 2017 15:21:02 GMT):
yes, thank you @rahulhegde (and also sorry for the trouble)
greg.haskins (Tue, 13 Jun 2017 15:22:17 GMT):
@mastersingh24 You also mentioned something about problems with vendored libs?
mastersingh24 (Tue, 13 Jun 2017 15:22:27 GMT):
same problem
greg.haskins (Tue, 13 Jun 2017 15:22:30 GMT):
or was that a false start on this problem
greg.haskins (Tue, 13 Jun 2017 15:22:31 GMT):
ok
mastersingh24 (Tue, 13 Jun 2017 15:22:32 GMT):
fixes both
greg.haskins (Tue, 13 Jun 2017 15:22:45 GMT):
ok...what was the problem with vendor?
mastersingh24 (Tue, 13 Jun 2017 15:23:02 GMT):
it was a side affect
greg.haskins (Tue, 13 Jun 2017 15:23:03 GMT):
(I mean, aside from the fact that I was failing to include _imports_ in the vendor folder
mastersingh24 (Tue, 13 Jun 2017 15:23:21 GMT):
^^^ right
greg.haskins (Tue, 13 Jun 2017 15:23:27 GMT):
ok
mastersingh24 (Tue, 13 Jun 2017 15:25:21 GMT):
just tested an external package with / without vendoring (using the fix above) and all is good
muralisr (Tue, 13 Jun 2017 15:30:07 GMT):
@greg.haskins my apologies too... should have been more careful and caught this when I ran the tests
muralisr (Tue, 13 Jun 2017 15:30:18 GMT):
(and apologies to @rahulhegde of course)
Sandeep (Tue, 13 Jun 2017 15:37:54 GMT):
Has joined the channel.
muralisr (Tue, 13 Jun 2017 15:42:30 GMT):
to make matters worse I think I *suggested* that @rahulhegde vendor it... my memory failing me there
muralisr (Tue, 13 Jun 2017 15:42:58 GMT):
@rahulhegde how do you want to handle it.. do you want to put in the fix yourself (we can move the JIRA to you)
muralisr (Tue, 13 Jun 2017 15:43:19 GMT):
or I can do it for you
rahulhegde (Tue, 13 Jun 2017 15:46:08 GMT):
@muralisr no issues.
I think @greg.haskins decided to take this JIRA.
greg.haskins (Tue, 13 Jun 2017 15:52:47 GMT):
@muralisr im putting together the patch now
greg.haskins (Tue, 13 Jun 2017 15:53:00 GMT):
biggest hold up is I want a unit-test
muralisr (Tue, 13 Jun 2017 15:53:25 GMT):
perfect
muralisr (Tue, 13 Jun 2017 15:53:30 GMT):
will get out of the way
muralisr (Tue, 13 Jun 2017 16:02:52 GMT):
@greg.haskins one thing... the CLI `peer chaincode install` will make sure the external dependencies are vendored and packaged correctly but its currently up to the user to get all the dependencies in the env so the chaincode builds fine (`go build`) in the first place. I remember you wanted to do the equivalent of "go get" as part of the `peer chaincode install` in future but its not there currently. Correct ?
greg.haskins (Tue, 13 Jun 2017 16:15:01 GMT):
that is correct
greg.haskins (Tue, 13 Jun 2017 16:15:31 GMT):
the assumption is that your "peer chaincode install" has the same demands on your GOPATH as "go build" would
greg.haskins (Tue, 13 Jun 2017 16:15:57 GMT):
we could automate this, but we decided it was better to let the user manage
muralisr (Tue, 13 Jun 2017 16:23:28 GMT):
thanks @greg.haskins .... we want to capture this i think @nickgaski
greg.haskins (Tue, 13 Jun 2017 18:03:22 GMT):
@muralisr @mastersingh24 @rahulhegde https://gerrit.hyperledger.org/r/#/c/10539/
muralisr (Tue, 13 Jun 2017 18:10:35 GMT):
LGTM, @greg.haskins
muralisr (Tue, 13 Jun 2017 18:10:57 GMT):
will +2 once CI goes thru
tomveugelers (Wed, 14 Jun 2017 09:42:03 GMT):
Has joined the channel.
tomveugelers (Wed, 14 Jun 2017 11:47:06 GMT):
Hi everyone, we're currently trying to setup a network between 3 different servers. We managed to create and join channels and installed some chaincode. However we get a timeout when we try to instantiate the chaincode. Does anyone know what could've caused this error?
Command:
peer chaincode instantiate -o orderer0.serverhostname:7050 --cafile /artifacts/crypto-config/ordererOrganizations/serverhostname/ca/serverhostname-cert.pem --tls -C mychannel -n mycc -v 1.0 -c '{"Args":["init","a","100","b","200"]}' -P "OR('Org1.member','Org2.member')"
Error message in the peer logs:
`2017-06-13 10:09:47.296 UTC [chaincode] Launch -> ERRO 03d launchAndWaitForRegister failed Timeout expired while starting chaincode mycc:1.0(networkid:dev,peerid:peer0.serverhostname,tx:389f1583ccc651ee9d4a88a11fde18d2a8323de11c7067b4167464bac723bebb)`
Error message in the peer container:
`2017-06-13 10:04:47.094 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 001 Using default escc
2017-06-13 10:04:47.094 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 002 Using default vscc
Error: Error endorsing chaincode: rpc error: code = 2 desc = Timeout expired while starting chaincode mycc:1.0(networkid:dev,peerid:peer0.serverhostname,tx:389f1583ccc651ee9d4a88a11fde18d2a8323de11c7067b4167464bac723bebb)`
tomveugelers (Wed, 14 Jun 2017 11:47:06 GMT):
Hi everyone, we're currently trying to setup a network between 3 different servers. We managed to create and join channels and installed some chaincode. However we get a timeout when we try to instantiate the chaincode. Does anyone know what could've caused this error?
Command:
peer chaincode instantiate -o orderer0.serverhostname:7050 --cafile /artifacts/crypto-config/ordererOrganizations/serverhostname/ca/serverhostname-cert.pem --tls -C mychannel -n mycc -v 1.0 -c '{"Args":["init","a","100","b","200"]}' -P "OR('Org1.member','Org2.member')"
Error message in the peer logs:
`2017-06-13 10:09:47.296 UTC [chaincode] Launch -> ERRO 03d launchAndWaitForRegister failed Timeout expired while starting chaincode mycc:1.0(networkid:dev,peerid:peer0.serverhostname,tx:389f1583ccc651ee9d4a88a11fde18d2a8323de11c7067b4167464bac723bebb)`
Error message in the peer container:
`2017-06-13 10:04:47.094 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 001 Using default escc
2017-06-13 10:04:47.094 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 002 Using default vscc
Error: Error endorsing chaincode: rpc error: code = 2 desc = Timeout expired while starting chaincode mycc:1.0(networkid:dev,peerid:peer0.serverhostname,tx:389f1583ccc651ee9d4a88a11fde18d2a8323de11c7067b4167464bac723bebb)`
muralisr (Wed, 14 Jun 2017 11:52:52 GMT):
@tomveugelers my guess would be the chaincode couldnt startup
muralisr (Wed, 14 Jun 2017 11:55:43 GMT):
if you add CORE_VM_DOCKER_ATTACHSTDOUT=true and CORE_CHAINCODE_LOGGING_LEVEL=debug env vars to the peer you might get more information from the chaincode
tomveugelers (Wed, 14 Jun 2017 12:03:50 GMT):
Thanks! We'll try that now
tomveugelers (Wed, 14 Jun 2017 12:34:39 GMT):
We stopped the peer, added the env vars into the compose-defaults. We restarted the peer, succesfully installed the chaincode example 02 and joined the channel. After that we tried to instantiate the installed chaincode and we get the following error message:
2017/06/14 12:25:52 grpc: addrConn.resetTransport failed to create client transport: connection error: desc = "transport: x509: certificate signed by unknown authority (possibly because of \"x509: ECDSA verification failure\" while trying to verify candidate authority certificate \"serverhostname\")"; Reconnecting to {"peer0.serverhostname:7051"
muralisr (Wed, 14 Jun 2017 12:46:40 GMT):
@tomveugelers `After these error messages the peer exits.` ... you mean the chaincode exits right ?
muralisr (Wed, 14 Jun 2017 12:46:55 GMT):
looks like an TLS issue
tomveugelers (Wed, 14 Jun 2017 12:50:57 GMT):
The peer container and the cc container exit both
pd93 (Wed, 14 Jun 2017 14:45:11 GMT):
Has joined the channel.
Halminhu (Thu, 15 Jun 2017 02:46:22 GMT):
Has joined the channel.
jeffgarratt (Thu, 15 Jun 2017 03:12:44 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-consensus?msg=qWyrHfk9S96SutXfP) @ryokawajp this can be accomplished by using the IDENTITY option for MSPPrincipal
jeffgarratt (Thu, 15 Jun 2017 03:12:44 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-consensus?msg=qWyrHfk9S96SutXfP) @ryokawajp this can be accomplished by using the IDENTITY option for MSPPrincipal classification
jeffgarratt (Thu, 15 Jun 2017 03:15:08 GMT):
@ryokawajp you could actually supply the certificate of the signer for the peer as that Identity
jeffgarratt (Thu, 15 Jun 2017 03:15:15 GMT):
then require that single signature
ryokawajp (Thu, 15 Jun 2017 03:16:59 GMT):
@jeffgarratt thank you. Let me learn more on the endorsement policy specification. Do you mean that not only the role of the peers (member/admin) but also identities can be specified in an endorsement policy?
jeffgarratt (Thu, 15 Jun 2017 03:17:08 GMT):
correct
jeffgarratt (Thu, 15 Jun 2017 03:17:28 GMT):
```message MSPPrincipal {
enum Classification {
ROLE = 0; // Represents the one of the dedicated MSP roles, the
// one of a member of MSP network, and the one of an
// administrator of an MSP network
ORGANIZATION_UNIT = 1; // Denotes a finer grained (affiliation-based)
// groupping of entities, per MSP affiliation
// E.g., this can well be represented by an MSP's
// Organization unit
IDENTITY = 2; // Denotes a principal that consists of a single
// identity
}
jeffgarratt (Thu, 15 Jun 2017 03:17:45 GMT):
ROLE is most often used.... but Identity is also an option
ryokawajp (Thu, 15 Jun 2017 03:20:06 GMT):
@jeffgarratt Ah, the certificate of the signer ... Is there any example? I still do not understand how to specify a certificate. By PEM format? or path of the file?
ryokawajp (Thu, 15 Jun 2017 03:20:13 GMT):
Let me check the source code ...
jeffgarratt (Thu, 15 Jun 2017 03:20:34 GMT):
Not sure how well the CLI supports this at the moment... I work with the protobuf structures myself
jeffgarratt (Thu, 15 Jun 2017 03:21:36 GMT):
the protobuf simply has this field which should be the PEM bytes I believe
jeffgarratt (Thu, 15 Jun 2017 03:22:02 GMT):
jp meaning Japan?
ryokawajp (Thu, 15 Jun 2017 03:22:50 GMT):
@jeffgarratt I see. Thank you for the info. The document in readthedoc site says that the support for ORGANIZATION_UNIT is in the future plan.
ryokawajp (Thu, 15 Jun 2017 03:23:02 GMT):
yes!
jeffgarratt (Thu, 15 Jun 2017 03:23:37 GMT):
@ryokawajp correct... but IDENTITY and ROLE are there now. It is late for me :) But @muralisr should be able to help in the AM our time (US Eastern)
jeffgarratt (Thu, 15 Jun 2017 03:24:00 GMT):
and I will be on a bit later than normal tomorrow as my main computer crashed
jeffgarratt (Thu, 15 Jun 2017 03:24:29 GMT):
we will give you an answer then... just feel free to ping back any time
jeffgarratt (Thu, 15 Jun 2017 03:24:54 GMT):
but know technically this is feasible
ryokawajp (Thu, 15 Jun 2017 03:25:46 GMT):
oh, that is too bad... And thank you for the information again. I will also try studying by myself and come here in AM of US Eastern time
jeffgarratt (Thu, 15 Jun 2017 03:26:10 GMT):
sounds good!!! good luck!!
ryokawajp (Thu, 15 Jun 2017 03:26:58 GMT):
thanks
arner (Thu, 15 Jun 2017 09:54:05 GMT):
Has joined the channel.
AnilOner (Thu, 15 Jun 2017 12:12:00 GMT):
Has joined the channel.
ryokawajp (Thu, 15 Jun 2017 14:22:43 GMT):
Up to now, it seems that CLI supports ROLE only in the current version. I suppose this is the code which parses the command line. https://github.com/hyperledger/fabric/blob/master/common/cauthdsl/policyparser.go
ryokawajp (Thu, 15 Jun 2017 14:25:52 GMT):
While, fabric-sdk-node seems to have some classes which corresponds to IDENTITY. But I am still not sure how to use it. I will continue the study. https://github.com/hyperledger/fabric-sdk-node/blob/master/fabric-client/lib/Policy.js
ryokawajp (Thu, 15 Jun 2017 14:27:14 GMT):
anyway, thank you very much for the information! @jeffgarratt
jeffgarratt (Thu, 15 Jun 2017 14:28:23 GMT):
@ryokawajp you are most welcome!! Hopefully in short order the mechanisms will be exposed to you in a clear and useable way
outis (Fri, 16 Jun 2017 08:32:48 GMT):
Has joined the channel.
Ratnakar (Fri, 16 Jun 2017 15:46:29 GMT):
How can we determine if a transaction is Valid or Invalid in a block ?
jeffgarratt (Fri, 16 Jun 2017 15:48:45 GMT):
@Ratnakar the metadata entry in the block contains one entry for Tx validation information.
jeffgarratt (Fri, 16 Jun 2017 15:48:48 GMT):
```// This enum enlists indexes of the block metadata array
enum BlockMetadataIndex {
SIGNATURES = 0; // Block metadata array position for block signatures
LAST_CONFIG = 1; // Block metadata array position to store last configuration block sequence number
TRANSACTIONS_FILTER = 2; // Block metadata array position to store serialized bit array filter of invalid transactions
ORDERER = 3; // Block metadata array position to store operational metadata for orderers
// e.g. For Kafka, this is where we store the last offset written to the local ledger.
}
jeffgarratt (Fri, 16 Jun 2017 15:49:02 GMT):
index 2 contains the Transaction Filter information
jeffgarratt (Fri, 16 Jun 2017 15:49:24 GMT):
bit array to indicate valid or invalid matching the index in the Tx array
Ratnakar (Fri, 16 Jun 2017 17:29:45 GMT):
@jeffgarratt Thankyou :), I will take a look at the structure
jeffgarratt (Fri, 16 Jun 2017 17:29:58 GMT):
@Ratnakar good luck
muralisr (Fri, 16 Jun 2017 20:49:21 GMT):
also take a peek at examples/events/block-listener/block-listener.go @Ratnakar ...although event based, it shows how to check for tx validity
Ratnakar (Fri, 16 Jun 2017 20:58:11 GMT):
Thanks @muralisr , this is good one :)
snowy13 (Sat, 17 Jun 2017 05:28:25 GMT):
Has joined the channel.
sfukazu (Mon, 19 Jun 2017 06:35:44 GMT):
Has joined the channel.
arner (Mon, 19 Jun 2017 11:54:51 GMT):
Hi, we're trying to set up our own Fabric beta network. Everything seems fine until we try to join a channel:
_Error: proposal failed (err: rpc error: code = Unknown desc = chaincode error (status: 500, message: "JoinChain" request failed authorization check for channel [torchplatformchannel]: [Failed verifying that proposal's creator satisfies local MSP principal during channelless check policy with policy [Admins]: [This identity is not an admin]]))_
Even though we set the CORE_MSPCONFIGPATH to the admin users' msp and channel creation succeeds. Has anyone seen this before?
jeffgarratt (Mon, 19 Jun 2017 13:49:23 GMT):
@arner you will need to join using a cert that is located under the admincerts folder of the MSP config folder.
arner (Mon, 19 Jun 2017 13:53:43 GMT):
@jeffgarratt we're using `crypto-config/peerOrganizations/example.com/users/Admin@example.com/msp` as CORE_MSPCONFIGPATH. Are you saying we need to somehow use `crypto-config/peerOrganizations/example.com/msp/admincerts`?
jeffgarratt (Mon, 19 Jun 2017 13:54:47 GMT):
@arner no, you need to join the channel using a privatekey/cert combination in which that cert is in the admincerts folder of the msp config folder
jeffgarratt (Mon, 19 Jun 2017 13:55:12 GMT):
thus that identity has admin rights on the peer
arner (Mon, 19 Jun 2017 13:59:28 GMT):
I'm using the cli to connect to a peer. As far as I know I need to set the identity using `CORE_MSPCONFIGPATH=crypto-config/peerOrganizations/example.com/users/Admin@example.com/msp`. Or should it be `CORE_MSPCONFIGPATH=crypto-config/peerOrganizations/example.com/msp/` and will it find it by itself?
arner (Mon, 19 Jun 2017 13:59:28 GMT):
I'm using the cli to connect to a peer. As far as I know I need to set the identity using `CORE_PEER_MSPCONFIGPATH=crypto-config/peerOrganizations/example.com/users/Admin@example.com/msp`. Or should it be `CORE_PEER_MSPCONFIGPATH=crypto-config/peerOrganizations/example.com/msp/` and will it find it by itself? [edit: env variable name]
jeffgarratt (Mon, 19 Jun 2017 14:14:00 GMT):
@arner if using the CLI, I would assume the peer would have chosen a peerAdmin identity. Is this correct @muralisr
jeffgarratt (Mon, 19 Jun 2017 14:14:00 GMT):
@arner if using the CLI, I would assume the peer would have chosen a peerAdmin identity. Is this correct @muralisr
jeffgarratt (Mon, 19 Jun 2017 14:14:00 GMT):
@arner if using the CLI, I would assume the peer would have chosen a peerAdmin identity. Is this correct @muralisr ?
Nishi (Mon, 19 Jun 2017 14:53:41 GMT):
Has joined the channel.
arner (Mon, 19 Jun 2017 15:08:53 GMT):
@muralisr would appreciate your insight... We've been struggling with this!
muralisr (Mon, 19 Jun 2017 15:16:14 GMT):
hi @arner I have to take care of somethings but will respond as soon as I can... but I think @jeffgarratt is right ... one suggestion the docker-compose files under examples/e2e_cli give all the ENV variables and examples/e2e_cli/scripts/script.sh gives the way to override them for specific command (such as join)
muralisr (Mon, 19 Jun 2017 15:16:54 GMT):
between the two hopefully you'll find the right settings to get this to work
arner (Mon, 19 Jun 2017 15:21:57 GMT):
thanks, we'll dig deeper
arner (Mon, 19 Jun 2017 16:07:59 GMT):
Is it necessary to keep the paths as in the examples?
arner (Mon, 19 Jun 2017 16:07:59 GMT):
Is it necessary to keep the paths of the volumes (for the keys) as in the examples?
jeffgarratt (Mon, 19 Jun 2017 16:10:28 GMT):
@arner make sure you are setting CORE_PEER_MSPCONFIGPATH=....
arner (Mon, 19 Jun 2017 16:34:43 GMT):
@jeffgarratt I mean is the peer or something else relying on the use of `/etc/hyperledger/` or are we free to use any path?
jeffgarratt (Mon, 19 Jun 2017 16:35:56 GMT):
how are you running? If you are using e2e or behave the paths are determined based upon volume configuration for docker
jeffgarratt (Mon, 19 Jun 2017 16:36:21 GMT):
are you setting up your own environment, then you are free to use whatever paths you wish
jeffgarratt (Mon, 19 Jun 2017 16:36:21 GMT):
if you setting up your own environment, then you are free to use whatever paths you wish
Nishi (Mon, 19 Jun 2017 19:56:54 GMT):
not sure if this helps we mounted keystore and signcerts from org2.example.com/users/Admin@org2.example.com/msp/signcerts under Peer0 in Org2 in docker-compose-e2e.yaml to make Peer0 as admin
volumes:
- /var/run/:/host/var/run/
- ../crypto-config/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/msp:/etc/hyperledger/fabric/msp
- ../crypto-config/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp/keystore:/etc/hyperledger/fabric/msp/keystore
- ../crypto-config/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp/signcerts:/etc/hyperledger/fabric/msp/signcerts
- ../crypto-config/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls:/etc/hyperledger/fabric/tls
Nishi (Mon, 19 Jun 2017 19:56:54 GMT):
@arner not sure if this helps we mounted keystore and signcerts from org2.example.com/users/Admin@org2.example.com/msp/signcerts under Peer0 in Org2 in docker-compose-e2e.yaml to make Peer0 as admin
volumes:
- /var/run/:/host/var/run/
- ../crypto-config/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/msp:/etc/hyperledger/fabric/msp
- ../crypto-config/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp/keystore:/etc/hyperledger/fabric/msp/keystore
- ../crypto-config/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp/signcerts:/etc/hyperledger/fabric/msp/signcerts
- ../crypto-config/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls:/etc/hyperledger/fabric/tls
dilipjain (Tue, 20 Jun 2017 07:22:47 GMT):
Has joined the channel.
arner (Tue, 20 Jun 2017 07:23:55 GMT):
Thanks @Nishi, that does the trick!
dilipjain (Tue, 20 Jun 2017 07:24:30 GMT):
Hi,
Are endorsement policies applied organization-wise or peer-wise?
dilipjain (Tue, 20 Jun 2017 07:24:30 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=aooDakiZGYzm24xda) @arner
Thanks,
As per the page, the endorsement policies look like ... 'Org1.member', 'Org2.member', 'Org3.member', etc.
Could it be like 'Org1.Peer1.member', 'Org1.Peer2.member', 'Org2.Peer0.member', etc
arner (Tue, 20 Jun 2017 07:29:25 GMT):
Hi @dilipjain, as far as I know chaincode-wise (see http://hyperledger-fabric.readthedocs.io/en/latest/endorsement-policies.html)
arner (Tue, 20 Jun 2017 07:29:46 GMT):
So when you instantiate a chaincode on a channel.
dilipjain (Tue, 20 Jun 2017 07:41:17 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=aooDakiZGYzm24xda) @arner
Thanks,
As per the page, the endorsement policies look like ... 'Org1.member', 'Org2.member', 'Org3.member', etc.
Could it be like 'Org1.Peer1.member', 'Org1.Peer2.member', 'Org2.Peer0.member', etc
dilipjain (Tue, 20 Jun 2017 07:41:17 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=aooDakiZGYzm24xda) @arner
Thanks,
As per the page ( http://hyperledger-fabric.readthedocs.io/en/latest/endorsement-policies.html ), the endorsement policies is based on ... 'Org1.member', 'Org2.member', 'Org3.member', etc. What are these members?
And, could member names be like 'Org1.Peer1.member', 'Org1.Peer2.member', 'Org2.Peer0.member', etc.
dilipjain (Tue, 20 Jun 2017 07:41:17 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=aooDakiZGYzm24xda) @arner
Thanks,
As per page ( http://hyperledger-fabric.readthedocs.io/en/latest/endorsement-policies.html ), endorsement policy is based on ... 'Org1.member', 'Org2.member' and 'Org3.member', etc.
What are these members? Do they represent 3 different organizations ?
Could member names be chosen like 'Org1.Peer1.member', 'Org1.Peer2.member' and 'Org2.Peer0.member', etc.
dongqi (Tue, 20 Jun 2017 08:36:24 GMT):
Has joined the channel.
bh4rtp (Tue, 20 Jun 2017 09:01:52 GMT):
hi all, must all the fabric docker containers set the environment variable `FABRIC_CFG_PATH`?
arner (Tue, 20 Jun 2017 09:34:08 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=wvF98YtpEHkoufaSh) @bh4rtp You just need to set it when using configtxgen (http://hyperledger-fabric.readthedocs.io/en/latest/getting_started.html)
bh4rtp (Tue, 20 Jun 2017 09:38:02 GMT):
@arner i found the container must be set too, otherwise it will report an error: `Fatal error when initializing core config : Error when reading core config file: Unsupported Config Type ""`
arner (Tue, 20 Jun 2017 09:39:33 GMT):
@bh4rtp which type of container is this?
bh4rtp (Tue, 20 Jun 2017 09:40:45 GMT):
@arner hyperledger/fabric-tools, peer, orderer, and found that it must be set to be `FABRIC_CFG_PATH=/etc/hyperledger/fabric`
bh4rtp (Tue, 20 Jun 2017 09:43:31 GMT):
because i want to deploy fabric network on multiple hosts. when exporting the docker images onto host2, the env variables will all disappear. and the 'FABRIC_CFG_PATH` must be manually set.
arner (Tue, 20 Jun 2017 09:44:21 GMT):
@bh4rtp, ok, interesting, I think in my project we don't set them and also don't run into errors. Is anyone else seeing this?
bh4rtp (Tue, 20 Jun 2017 09:48:49 GMT):
if use the pulled images online, it will be ok. because i use `docker run -d hyperledger/fabric-tools` and `docker export CONTAINER_ID > fabric-tool.tar` on host1. and then copy fabric-tools.tar onto host2, import the image. the environment variables are lost. you can use `docker inspect IMAGE_ID` to see every image has the FABRIC_CFG_PATH set.
bh4rtp (Wed, 21 Jun 2017 09:05:54 GMT):
what is the use of chaincode container, for example `dev-peer0.org2.example.com-chaincode_example02-1.0:latest` created after instantiating chaincode?
bh4rtp (Wed, 21 Jun 2017 09:05:54 GMT):
what is the use of chaincode container, for example `dev-peer0.org2.example.com-chaincode_example02-1.0:latest`, created after instantiating chaincode?
bh4rtp (Wed, 21 Jun 2017 09:07:18 GMT):
i only find `/usr/local/bin/chaincode` and `/etc/hyperledger/fabric` related to chaincode.
mastersingh24 (Wed, 21 Jun 2017 10:14:45 GMT):
@bh4rtp - not quite sure I understand the question - chaincode is deployed in Docker containers
bh4rtp (Wed, 21 Jun 2017 10:20:49 GMT):
@mastersingh24 yes, that is my understanding too. but the instantiated docker containers cannot find any chaincode inside, even without go environment.
mastersingh24 (Wed, 21 Jun 2017 10:27:37 GMT):
`/usr/local/bin/chaincode` is the compiled chaincode executable
bh4rtp (Thu, 22 Jun 2017 01:26:02 GMT):
@mastersingh24 in `/var/hyperledger/production/chaincodes` of the peer node, there is a `chaincode_example02.1.0` file which is created at `peer chaincode install`. but this file is not golang source file. so is it encrypted or compiled?
fbenhamo (Thu, 22 Jun 2017 06:14:58 GMT):
@mastersingh24 It is compiled.
mastersingh24 (Thu, 22 Jun 2017 10:48:26 GMT):
@bh4rtp - it is a serialized protobuf structure
(https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=5tDqbp97dKAofHyYn)
sidney803 (Fri, 23 Jun 2017 02:18:51 GMT):
Has joined the channel.
vdods (Mon, 26 Jun 2017 21:14:24 GMT):
Has joined the channel.
vdods (Mon, 26 Jun 2017 21:22:54 GMT):
Hi all, I'm trying to ascertain the current status and future plans for endorsement policies. As far as I can tell, the endorsement policy is as described here: http://hyperledger-fabric.readthedocs.io/en/latest/endorsement-policies.html -- Apropos "future enhancements", I would like to see the ability for a chaincode instantiator to also specify chaincode (would this be ESCC?) that defines the endorsement policy, as I want total control over that aspect. Is that planned? I haven't found any Jira tickets specifically talking about that.
ynamiki (Tue, 27 Jun 2017 00:09:44 GMT):
Has joined the channel.
neharprodduturi (Tue, 27 Jun 2017 00:19:17 GMT):
Has joined the channel.
dilipjain (Tue, 27 Jun 2017 09:36:11 GMT):
In V0.6, I was able to create a simple client application to make REST calls for invoke/query chaincode APIs.
In v1.0, as REST calls are not supported, instead Node SDK (gRPC) has come into picture, and it seems difficult to write test application to make gRPC calls.
Another point is ... same v1.0 blockchain application, which is easily tested with CLI, cannot be directly tested with Node SDK since the application folders need to be re-structured to support Node SDK.
*It seems, that writing chaincode application is simpler than writing its test application*
Please let me know if someone has a simple step-by-step guideline/checklist that could help while converting v0.6 test application (REST calls) into v1.0 test application (Node SDK gRPC)
Thanks.
dilipjain (Tue, 27 Jun 2017 09:36:11 GMT):
In V0.6, I was able to create a simple client application to make REST calls for invoke/query chaincode APIs.
In v1.0, as REST calls are not supported, instead Node SDK (gRPC) has come into picture, and it seems difficult to write test application to make gRPC calls.
Another point is ... same v1.0 blockchain application, which is easily tested with CLI, cannot be directly tested with Node SDK since the application folders need to be re-structured to support Node SDK.
*It seems, that writing Node SDK based test application is more difficult then writing blockchain application itself*
Please let me know if someone has a simple step-by-step guideline/checklist that could help while converting v0.6 test application (REST calls) into v1.0 test application (Node SDK gRPC)
Thanks.
dilipjain (Tue, 27 Jun 2017 09:36:11 GMT):
In V0.6, I was able to create a simple client application to make REST calls for invoke/query chaincode APIs.
In v1.0, as REST calls are not supported, instead Node SDK (gRPC) has come into picture, and it seems difficult to write test application to make gRPC calls.
Another point is ... same v1.0 blockchain application, which is easily tested with CLI, cannot be directly tested with Node SDK since the application folders need to be re-structured to support Node SDK.
*It seems, that writing Node SDK based test application is more difficult then writing blockchain application itself*
*and, why the CLI and Node SDK need different approaches for blockchain application folder structures*
Please let me know if someone has a simple step-by-step guideline/checklist that could help while converting v0.6 test application (REST calls) into v1.0 test application (Node SDK gRPC)
Thanks.
dilipjain (Tue, 27 Jun 2017 09:36:11 GMT):
In V0.6, I was able to create a simple client application to make REST calls for invoke/query chaincode APIs.
In v1.0, as REST calls are not supported, instead Node SDK (gRPC) has come into picture, and it seems difficult to write test application to make gRPC calls.
Another point is ... same v1.0 blockchain application, which is easily tested with CLI, cannot be directly tested with Node SDK since the application folders need to be re-structured to support Node SDK.
*It seems, that writing Node SDK based test application is more difficult then writing blockchain application itself
and, why the CLI and Node SDK need different approaches for blockchain application folder structures*
Please let me know if someone has a simple step-by-step guideline/checklist that could help while converting v0.6 test application (REST calls) into v1.0 test application (Node SDK gRPC)
Thanks.
dilipjain (Tue, 27 Jun 2017 09:36:11 GMT):
In V0.6, I was able to create a simple client application to make REST calls for invoke/query chaincode APIs.
In v1.0, as REST calls are not supported, instead Node SDK (gRPC) has come into picture, and it seems difficult to write test application to make gRPC calls.
Another point is ... same v1.0 blockchain application, which is easily tested with CLI, cannot be directly tested with Node SDK since the application folders need to be re-structured to support Node SDK.
*It seems, that writing Node SDK based test application is more difficult then writing blockchain application itself*
*and, why the CLI and Node SDK need different approaches for blockchain application folder structures*
Please let me know if someone has a simple step-by-step guideline/checklist that could help while converting v0.6 test application (REST calls) into v1.0 test application (Node SDK gRPC)
Thanks.
toddinpal (Tue, 27 Jun 2017 21:37:37 GMT):
Is it possible in an endorsement policy to indicate I want more than one endorsement from a single organization?
jeffgarratt (Tue, 27 Jun 2017 21:42:55 GMT):
@toddinpal yes
toddinpal (Tue, 27 Jun 2017 21:43:48 GMT):
Thanks, just found it in the docs on policy...
toddinpal (Tue, 27 Jun 2017 21:51:31 GMT):
oh, perhaps not... I was looking at signature policy. The endorsement policy expression mechanism doesn't appear to allow specifying the number of the endorsements from an org
toddinpal (Tue, 27 Jun 2017 21:51:31 GMT):
@jeffgarratt or, perhaps not... I was looking at signature policy. The endorsement policy expression mechanism doesn't appear to allow specifying the number of the endorsements from an org
toddinpal (Tue, 27 Jun 2017 21:51:44 GMT):
or at least from what I read in the current docs
jeffgarratt (Tue, 27 Jun 2017 23:44:12 GMT):
@jyellick can perhaps clarify for us both ^^
jeffgarratt (Tue, 27 Jun 2017 23:45:04 GMT):
@toddinpal based upon doc, wouldn't T(2, 'A') work?
jeffgarratt (Tue, 27 Jun 2017 23:45:39 GMT):
I am pretty sure there is logic to assure the same singature can not be used twice, thus this should require 2 sigs from the org.
jeffgarratt (Tue, 27 Jun 2017 23:45:49 GMT):
or perhaps itis T(2, 'A'. 'A')
jeffgarratt (Tue, 27 Jun 2017 23:45:52 GMT):
something like this
jeffgarratt (Tue, 27 Jun 2017 23:46:19 GMT):
I can try some some tests to verify.
toddinpal (Tue, 27 Jun 2017 23:52:08 GMT):
@jeffgarratt Perhaps, although it would be hard to deduce that from the docs
jeffgarratt (Tue, 27 Jun 2017 23:52:33 GMT):
agreed
jyellick (Wed, 28 Jun 2017 01:37:08 GMT):
@jeffgarratt @toddinpal Correct. You want `2 of ['A', 'A']` in your case.
jyellick (Wed, 28 Jun 2017 01:37:41 GMT):
You may also craft policies to be more specific, requiring particular certificates, or a particular OU for the certificate
jyellick (Wed, 28 Jun 2017 01:38:22 GMT):
In which case you might craft a policy to require `2 of ['A.Marketing', 'A.Sales']`
Rachitga (Wed, 28 Jun 2017 10:29:44 GMT):
Hello all,
I had doubts about the consistency checks in the various endorsements during the validation phase in the committing peers. How do these peers perform the consistency check among all endorsements? Do they check if all simulation results are same in all endorsements(if that was the case then even one malicious endorser could lead to no transaction being committed), do they pick the majority among the simulation result as the one that should be picked (if that was the case then say a policy that said that four out of ten endorsers should sign it, would not get passed if say four of them were correct and six were malicious), so is it then policy dependent but then each policy can be different how does it deal with ties (if there was a policy that four out of the ten endorsers should sign it, and lets say there are five with one simulation result blob, five with the other simulation result blob), how does it pick then?
Can you please point to the piece of code where the committing peer checks this?
Rachitga (Wed, 28 Jun 2017 10:29:44 GMT):
Hello all,
I had doubts about the consistency checks in the various endorsements during the validation phase in the committing peers. How do these peers perform the consistency check among all endorsements? Do they check if all simulation results are same in all endorsements(if that was the case then even one malicious endorser could lead to no transaction being committed), do they pick the majority among the simulation result as the one that should be picked (if that was the case then say a policy that said that four out of ten endorsers should sign it, would not get passed if say four of them were correct and six were malicious), so is it then policy dependent but then each policy can be different how does it deal with ties (if there was a policy that four out of the ten endorsers should sign it, and lets say there are five with one simulation result blob, five with the other simulation result blob), how does it pick then?
Can you please point to the piece of code where the committing peer checks this?
Rachitga (Wed, 28 Jun 2017 10:32:53 GMT):
@muralisr , @mastersingh24 , @Ratnakar can you please help me out with this query ^^
jeffgarratt (Wed, 28 Jun 2017 13:29:23 GMT):
@Rachitga as long as you get the number of endorsements with the same response that meets the endorsement policy it is sufficient. I am not sure if you are really concerned with consistency vs correctness. You get consistency guarantees wrt to the aforementioned process, but this does not of course guarantee correctness. And yes your system could be effectively halted by a required endorsement returning variant responses, depending on your policy. It is for this reason the N of support exist, to allow for progress in the face of inconsistent results. Selection of the endorsements to choose is up to the requestor. I believe there is also a majority option wrt to policy that will account for membership changes.
Rachitga (Wed, 28 Jun 2017 19:08:26 GMT):
@jeffgarratt , thanks for your answer, so as long as the policy is satisfied then we can pick any one from the ties and it will be consistent. But we might not be sure of the correctness, so if a policy say 4 of support exists, and four malicious endorsing peers collude then they can prevent the correct endorsement from being chosen as ties are not dealt with. Am I correct in my understanding?
I found the code that i was looking for in the vscc system chaincode from where i found the file fabric/common/cauthdsl/cauthdsl.go , this is where a policy evaluation function is generated which takes all the endorsements as arguments and checks their consistency as well as the requirements with respect to the policy.
jeffgarratt (Wed, 28 Jun 2017 19:10:36 GMT):
@Rachitga correct. This was the subtle difference I was trying convey. The consistency means it is consistent with the specification of policy, but is not 'correct' based upon desired outcome
jeffgarratt (Wed, 28 Jun 2017 19:10:36 GMT):
@Rachitga correct. This was the subtle difference I was trying convey. The consistency means it is consistent with the specification of policy, but is not 'correct' based upon desired outcome, which can also be subjective :) as the colluders got exactly what they wanted
jeffgarratt (Wed, 28 Jun 2017 19:13:14 GMT):
leading to the inevitable.....
jeffgarratt (Wed, 28 Jun 2017 19:13:19 GMT):
'caveat emptor' :)
mnosseir (Wed, 28 Jun 2017 23:40:24 GMT):
Has joined the channel.
mnosseir (Wed, 28 Jun 2017 23:43:20 GMT):
Hi all,
mnosseir (Wed, 28 Jun 2017 23:47:35 GMT):
The "Architecture Explained" document implies that we can customize the endorsing logic on an endorsing peer. It states that: "By default, endorsing logic at a peer accepts the tran-proposal and simply signs the tran-proposal. However, endorsing logic may interpret arbitrary functionality,....". But I cannot find any references to how this can be accomplished. Does anyone know how can the endorsing logic be customized? I'm referring to section 2.2 of this document "https://hyperledger-fabric.readthedocs.io/en/latest/arch-deep-dive.html".
mnosseir (Wed, 28 Jun 2017 23:47:35 GMT):
The "Architecture Explained" document implies that we can customize the endorsing logic on an endorsing peer. It states that: _"By default, endorsing logic at a peer accepts the tran-proposal and simply signs the tran-proposal. However, endorsing logic may interpret arbitrary functionality,...."_. But I cannot find any references to how this can be accomplished. Does anyone know how can the endorsing logic be customized? I'm referring to section 2.2 of this document "https://hyperledger-fabric.readthedocs.io/en/latest/arch-deep-dive.html".
muralisr (Thu, 29 Jun 2017 01:14:49 GMT):
@mnosseir the endorsement is done by the system chaincode "escc" (search for "escc" in core/scc/importsyscc.go)... you can copy escc chaincode and customize it. escc can be specified at the time of instantiation of a chaincode on a channel
rezamt (Thu, 29 Jun 2017 04:24:07 GMT):
Has joined the channel.
Rachitga (Thu, 29 Jun 2017 05:52:21 GMT):
@jeffgarratt , haha yeah, I get what you mean. Thanks for clearing my doubt, :relaxed: .
Rachitga (Thu, 29 Jun 2017 07:24:44 GMT):
@jeffgarratt , i was again going through the code in fabric/common/cauthdsl/cauthdsl.go, where is the consistency check done here? I could see the code for the N out of support, but where is the check that the verified signatures that are finally considered are on the same data?
mnosseir (Thu, 29 Jun 2017 20:58:10 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=pvdhGgYLByz7uB7ZZ) @muralisr Thanks a for your answer.
anik (Fri, 30 Jun 2017 06:52:04 GMT):
@muralisr does all channel configuration get saved in orderer ? Does it also include chaincode endorser information
jeffgarratt (Fri, 30 Jun 2017 13:26:58 GMT):
@Ratnakar the endorsements of the proposal that are in the TX, each of them includes a signature across the proposal bytes, these will be verified by the peer upon committing (post orderer)
jeffgarratt (Fri, 30 Jun 2017 13:26:58 GMT):
@Rachitga the endorsements of the proposal that are in the TX, each of them includes a signature across the proposal bytes, these will be verified by the peer upon committing (post orderer)
jeffgarratt (Fri, 30 Jun 2017 13:28:32 GMT):
if they are invalid, the peer will invalidate the TX upon commission
jeffgarratt (Fri, 30 Jun 2017 13:28:32 GMT):
if they are invalid, the peer will invalidate the TX when writing the block to its ledger
awa (Sun, 02 Jul 2017 10:53:24 GMT):
Has joined the channel.
Rachitga (Mon, 03 Jul 2017 07:12:59 GMT):
@jeffgarratt , I get what you are saying but I wanted to know if the vscc does an explicit consistency check or not? What I mean is that after verifying the signature across the proposal bytes in an endorsement as correct, does it compare among the proposal bytes of different endorsements(which it is considering as correct).
The transaction response structure is something like this:
SignedTransaction
|\_ Signature (signature on the Transaction message by the creator specified in the header)
\_ Transaction
\_ TransactionAction (1...n)
|\_ Header (1) (the header of the proposal that requested this action)
\_ Payload (1) (the payload for this action)
*/
And also at the committer, the changes in the ledger state will be made according to the read write set. Where in the code is the read write set that will be chosen in the end to be commited present?
Rachitga (Mon, 03 Jul 2017 07:12:59 GMT):
@jeffgarratt , I get what you are saying but I wanted to know if the vscc does an explicit consistency check or not? What I mean is that after verifying the signature across the proposal bytes in an endorsement as correct, does it compare among the proposal bytes of different endorsements(which it is considering as correct).
The transaction response structure is something like this:
SignedTransaction
|\_ Signature (signature on the Transaction message by the creator specified in the header)
\_ Transaction
\_ TransactionAction (1...n)
|\_ Header (1) (the header of the proposal that requested this action)
\_ Payload (1) (the payload for this action)
*/
So does it do a consistency check among the different payloads in the transaction action array?
And also at the committer, the changes in the ledger state will be made according to the read write set. Where in the code is the read write set that will be chosen in the end to be commited present?
Rachitga (Mon, 03 Jul 2017 07:12:59 GMT):
@jeffgarratt , I get what you are saying but I wanted to know if the vscc does an explicit consistency check or not? What I mean is that after verifying the signature across the proposal bytes in an endorsement as correct, does it compare among the proposal bytes of different endorsements(which it is considering as correct).
The transaction response structure is something like this:
SignedTransaction
|\_ Signature (signature on the Transaction message by the creator specified in the header)
\_ Transaction
.....\_ TransactionAction (1...n)
..........|\_ Header (1) (the header of the proposal that requested this action)
..........\_ Payload (1) (the payload for this action)
*/
So does it do a consistency check among the different payloads in the transaction action array?
And also at the committer, the changes in the ledger state will be made according to the read write set. Where in the code is the read write set that will be chosen in the end to be commited present?
alburt (Mon, 03 Jul 2017 10:47:23 GMT):
Has joined the channel.
jeffgarratt (Mon, 03 Jul 2017 18:19:23 GMT):
@Rachitga there should only be one proposal's bytes submitted for which all of the signatures are validated.
thakkarparth007 (Mon, 03 Jul 2017 21:38:33 GMT):
@Rachitga wrt your second query "Where in the code is the read write set" - search for RWSetBuilder in fabric/core/ledger/kvledger/txmgmt/rwsetutil - this is used by the committer while committing blocks. As far as I understand, the commiter takes a block, does signature validation on the whole block, then verifies the txs within the block, and while doing so, it adds all the writesets into a write-batch (can't remember the exact term) and once all txs have been verified, it writes the whole batch at once.
thakkarparth007 (Mon, 03 Jul 2017 21:38:33 GMT):
@Rachitga wrt your second query "Where in the code is the read write set" - search for RWSetBuilder in fabric/core/ledger/kvledger/txmgmt/rwsetutil - this is used by the committer while committing blocks. As far as I understand, the commiter takes a block, does signature validation on the whole block and the transactions, then verifies the txs within the block for any readwrite conflicts, and while doing so, it adds all the writesets into a write-batch (can't remember the exact term) and once all txs have been verified, it writes the whole batch at once.
thakkarparth007 (Mon, 03 Jul 2017 21:38:33 GMT):
@Rachitga wrt your second query "Where in the code is the read write set" - search for `RWSetBuilder` in `fabric/core/ledger/kvledger/txmgmt/rwsetutil.go` - this is used by the committer while committing blocks. As far as I understand, the commiter takes a block, does:
1. signature validation on the whole block and the transactions,
2. then verifies the txs within the block for any readwrite conflicts, and while doing so, it adds all the writesets into an UpdateBatch
3. and then, it writes the whole updatebatch at once.
thakkarparth007 (Mon, 03 Jul 2017 21:38:33 GMT):
@Rachitga wrt your second query "Where in the code is the read write set" - search for `RWSetBuilder` in `fabric/core/ledger/kvledger/txmgmt/rwsetutil.go` - this is used by the committer while committing blocks. As far as I understand, the commiter takes a block, does:
1. signature validation on the whole block and the transactions,
2. then verifies the txs within the block for any readwrite conflicts, and while doing so, it adds all the writesets into an UpdateBatch
3. and then, it writes the whole updatebatch at once.
#1 happens in `Validate(block, doMVCCValidation)` in `fabric/core/committer/txvalidator/validator.go`. This gets called from `fabric/core/committer/committer_impl.go`.
#2 happens in: `ValidateAndPrepareBatch()` in `fabric/core/ledger/kvledger/txmgmt/validator/statebasedval/state_based_validator.go` - you'll find what you're looking for. Here the validation that's being done is MVCC and intra-block read-write conflict validation and not the signature validation.
thakkarparth007 (Mon, 03 Jul 2017 22:49:09 GMT):
I'm a little confused about the "verifies the txs within the block, and _while doing so_, it adds all the writesets into a write-batch". Look at `ValidateAndPrepareBatch()` in `fabric/core/ledger/kvledger/txmgmt/validator/statebasedval/state_based_validator.go` - you'll find what you're looking for.
I'm confused about the "while doing so" part, because the validation is spread out throughout the codebase, and includes block validation, tx signature validation, tx policy validation (happens in vscc), and I can't really figure out what happens in which order.
thakkarparth007 (Mon, 03 Jul 2017 22:49:09 GMT):
@Rachitga I'm a little confused about the "verifies the txs within the block, and _while doing so_, it adds all the writesets into a write-batch". Look at `ValidateAndPrepareBatch()` in `fabric/core/ledger/kvledger/txmgmt/validator/statebasedval/state_based_validator.go` - you'll find what you're looking for.
I'm confused about the "while doing so" part, because the validation is spread out throughout the codebase, and includes block validation, tx signature validation, tx policy validation (happens in vscc), and I can't really figure out what happens in which order.
thakkarparth007 (Mon, 03 Jul 2017 22:49:09 GMT):
@Rachitga Look at `ValidateAndPrepareBatch()` in `fabric/core/ledger/kvledger/txmgmt/validator/statebasedval/state_based_validator.go` - you'll find what you're looking for. Here the validation that's being done is MVCC-type validation and not the signature validation. Signature validation is done at an earlier stage.
thakkarparth007 (Mon, 03 Jul 2017 23:18:44 GMT):
The same name 'validate' for different functionalities confused me for a (long :P) while.
Rachitga (Tue, 04 Jul 2017 04:57:38 GMT):
@jeffgarratt , do you mean that the client submits only one proposal's bytes to the orderer, out of the many that it gets? @thakkarparth007 , thanks, the functions that you mentioned are helpful :relaxed: ! yeah, it is very confusing for me as well.
DannyWong (Tue, 04 Jul 2017 08:37:06 GMT):
Has left the channel.
jeffgarratt (Tue, 04 Jul 2017 14:18:02 GMT):
@Rachitga correct, the client should compare the proposal responses bytes for equivalence across endorsement requests, and then submit the single proposal response bytes along with the endorsements.
nhrishi (Tue, 04 Jul 2017 18:28:42 GMT):
@jeffgarratt @muralisr Hi, Quick question. If we write a endorsement policy such that a transaction will be only endorsed if a user approves it manually. As in this case, a proposal is already generated (RW set) and there can be other transactions that may get processed before this first one is approved by user. The RW set of the first transaction is really outdated and orderer or committer nodes may not process transactions in the same order as they were generated. Does fabric recreates a RWset if its updated in meantime or is there any other way to handle this scenario. Correct me if i'm missing something.
muralisr (Tue, 04 Jul 2017 18:52:31 GMT):
@nhrishi basically what you are saying is that an asset is modified by other transactions while another tx involving it is awaiting endorsement
nhrishi (Tue, 04 Jul 2017 18:56:38 GMT):
@muralisr Yes thats correct
muralisr (Tue, 04 Jul 2017 18:56:54 GMT):
secondary TXs that use the same asset does get endorsed committed the first one will likely invalidated
muralisr (Tue, 04 Jul 2017 18:58:48 GMT):
its hard to propose approaches without knowing details.. but the first question would be why would the secondary TXs get endorsed ?
muralisr (Tue, 04 Jul 2017 18:58:48 GMT):
its hard to propose approaches without knowing details.. but the first question would be why would the secondary TXs get endorsed (while the first is waiting for "manual" endorsement) ?
nhrishi (Tue, 04 Jul 2017 19:00:21 GMT):
yes so lets say all transactions needs "manual" endorsement. and user may not approve or endorse them in the same sequence/order of creation.
nhrishi (Tue, 04 Jul 2017 19:01:15 GMT):
or its waiting for other endorsements and secondary transactions may get endorsed before
nhrishi (Tue, 04 Jul 2017 19:03:37 GMT):
If first one is invalidated (thats my understanding as well), then how do we recreate or re-propose a transaction and then we'll need to begin endorsement process all over again.
muralisr (Tue, 04 Jul 2017 19:05:59 GMT):
sounds like some level control/sequencing from application layer (as in SDK) may be needed (again, loosely speaking without knowledge of details)
nhrishi (Tue, 04 Jul 2017 19:16:48 GMT):
okay, I'm essentially trying to do a multi-party approval (M of N or N of N) process on the transaction. I can see another way is - to write user defined chaincode and manage multi-party approval process. But i thought endorsement policies are designed for the same purpose. In Multi-party approvals scenario, when users are doing "manual" endorsements (in financial market use cases specifically), its very likely that all transactions may not get endorsed completely in the same order as creation. I'm not really sure if we should do it as SDK level because we may have to go through endorsement process all over again. I think if we address this in the fabric itself, somehow reprocess the transaction considering endorsements are already done, that would be ideal (may be incorrect).
muralisr (Tue, 04 Jul 2017 21:05:41 GMT):
@nhrishi can you do it in two steps ? First step send a proposal / transaction to mark the asset as "in prgress" (no manual approval needed) and in the second do the multi-party endorsement... any other proposal coming in attempting to access the asset will be turned down with error
nhrishi (Wed, 05 Jul 2017 02:46:30 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=BT9Y5yggc7MfCwwo6) @muralisr Yup, correct, this logic will be required. Thanks for your help.
seepgoel (Wed, 05 Jul 2017 05:52:31 GMT):
Has joined the channel.
rahulhegde (Wed, 05 Jul 2017 19:00:40 GMT):
@muralisr @dave.enyeart
I am trying the data persistence of couch-db on the fabric-beta-release using documentation - https://hyperledger-fabric.readthedocs.io/en/latest/build_network.html#a-note-on-data-persistence and see the couch container instance exits. Any input?
rahulhegde (Wed, 05 Jul 2017 19:00:40 GMT):
@muralisr @dave.enyeart
I am trying the data persistence of couch-db on the fabric-beta-release using documentation - https://hyperledger-fabric.readthedocs.io/en/latest/build_network.html#a-note-on-data-persistence and see the couch container instance exits. Any input?
```
[rhegde@dusd1devrhap040 e2e_cli_v1_st]$ docker logs -f 21511ab48e2b
****************************************************
WARNING: CouchDB is running in Admin Party mode.
This will allow anyone with access to the
CouchDB port to access your database. In
Docker's default configuration, this is
effectively any other container on the same
system.
Use "-e COUCHDB_USER=admin -e COUCHDB_PASSWORD=password"
to set it in "docker run".
****************************************************
[os_mon] memory supervisor port (memsup): Erlang has closed
[os_mon] cpu supervisor port (cpu_sup): Erlang has closed
{"Kernel pid terminated",application_controller,"{application_start_failure,couch,{{shutdown,{failed_to_start_child,couch_secondary_services,{shutdown,{failed_to_start_child,auth_cache,{{badmatch,{error,eacces}},[{couch_auth_cache,ensure_users_db_exists,2,[{file,\"src/couch_auth_cache.erl\"},{line,456}]},{couch_auth_cache,open_auth_db,0,[{file,\"src/couch_auth_cache.erl\"},{line,428}]},{couch_auth_cache,reinit_cache,1,[{file,\"src/couch_auth_cache.erl\"},{line,290}]},{couch_auth_cache,init,1,[{file,\"src/couch_auth_cache.erl\"},{line,166}]},{gen_server,init_it,6,[{file,\"gen_server.erl\"},{line,328}]},{proc_lib,init_p_do_apply,3,[{file,\"proc_lib.erl\"},{line,240}]}]}}}}},{couch_app,start,[normal,[]]}}}"}
```
rahulhegde (Wed, 05 Jul 2017 19:00:40 GMT):
@muralisr @dave.enyeart
I am trying the data persistence of couch-db on the fabric-beta-release using documentation - https://hyperledger-fabric.readthedocs.io/en/latest/build_network.html#a-note-on-data-persistence and see the couch container instance exits. Any input?
docker-composer.yaml
```
couchdb5:
container_name: couchdb5
image: hyperledger/fabric-couchdb:x86_64-1.0.0-beta
ports:
- "40005:5984"
volumes:
- ./mount/couchdb5:/opt/couchdb/data
```
```
[rhegde@dusd1devrhap040 e2e_cli_v1_st]$ docker logs -f 21511ab48e2b
****************************************************
WARNING: CouchDB is running in Admin Party mode.
This will allow anyone with access to the
CouchDB port to access your database. In
Docker's default configuration, this is
effectively any other container on the same
system.
Use "-e COUCHDB_USER=admin -e COUCHDB_PASSWORD=password"
to set it in "docker run".
****************************************************
[os_mon] memory supervisor port (memsup): Erlang has closed
[os_mon] cpu supervisor port (cpu_sup): Erlang has closed
{"Kernel pid terminated",application_controller,"{application_start_failure,couch,{{shutdown,{failed_to_start_child,couch_secondary_services,{shutdown,{failed_to_start_child,auth_cache,{{badmatch,{error,eacces}},[{couch_auth_cache,ensure_users_db_exists,2,[{file,\"src/couch_auth_cache.erl\"},{line,456}]},{couch_auth_cache,open_auth_db,0,[{file,\"src/couch_auth_cache.erl\"},{line,428}]},{couch_auth_cache,reinit_cache,1,[{file,\"src/couch_auth_cache.erl\"},{line,290}]},{couch_auth_cache,init,1,[{file,\"src/couch_auth_cache.erl\"},{line,166}]},{gen_server,init_it,6,[{file,\"gen_server.erl\"},{line,328}]},{proc_lib,init_p_do_apply,3,[{file,\"proc_lib.erl\"},{line,240}]}]}}}}},{couch_app,start,[normal,[]]}}}"}
```
rahulhegde (Wed, 05 Jul 2017 19:00:40 GMT):
@muralisr @dave.enyeart
I am trying the data persistence of couch-db on the fabric-beta-release using documentation - https://hyperledger-fabric.readthedocs.io/en/latest/build_network.html#a-note-on-data-persistence and see the couch container instance exits. Any input?
docker-composer.yaml
```
couchdb5:
container_name: couchdb5
image: hyperledger/fabric-couchdb:x86_64-1.0.0-beta
ports:
- "40005:5984"
volumes:
- ./mount/couchdb5:/opt/couchdb/data
```
Couch DB container logs
```
[rhegde@dusd1devrhap040 e2e_cli_v1_st]$ docker logs -f 21511ab48e2b
****************************************************
WARNING: CouchDB is running in Admin Party mode.
This will allow anyone with access to the
CouchDB port to access your database. In
Docker's default configuration, this is
effectively any other container on the same
system.
Use "-e COUCHDB_USER=admin -e COUCHDB_PASSWORD=password"
to set it in "docker run".
****************************************************
[os_mon] memory supervisor port (memsup): Erlang has closed
[os_mon] cpu supervisor port (cpu_sup): Erlang has closed
{"Kernel pid terminated",application_controller,"{application_start_failure,couch,{{shutdown,{failed_to_start_child,couch_secondary_services,{shutdown,{failed_to_start_child,auth_cache,{{badmatch,{error,eacces}},[{couch_auth_cache,ensure_users_db_exists,2,[{file,\"src/couch_auth_cache.erl\"},{line,456}]},{couch_auth_cache,open_auth_db,0,[{file,\"src/couch_auth_cache.erl\"},{line,428}]},{couch_auth_cache,reinit_cache,1,[{file,\"src/couch_auth_cache.erl\"},{line,290}]},{couch_auth_cache,init,1,[{file,\"src/couch_auth_cache.erl\"},{line,166}]},{gen_server,init_it,6,[{file,\"gen_server.erl\"},{line,328}]},{proc_lib,init_p_do_apply,3,[{file,\"proc_lib.erl\"},{line,240}]}]}}}}},{couch_app,start,[normal,[]]}}}"}
```
rahulhegde (Wed, 05 Jul 2017 19:00:40 GMT):
@muralisr @dave.enyeart
I am trying the data persistence of couch-db on the fabric-beta-release using documentation - https://hyperledger-fabric.readthedocs.io/en/latest/build_network.html#a-note-on-data-persistence and see the couch container instance exits. Any input?
docker-composer.yaml
```
couchdb5:
container_name: couchdb5
image: hyperledger/fabric-couchdb:x86_64-1.0.0-beta
ports:
- "40005:5984"
volumes:
- ./mount/couchdb5:/opt/couchdb/data
```
Couch DB container log
```
[rhegde@dusd1devrhap040 e2e_cli_v1_st]$ docker logs -f 21511ab48e2b
****************************************************
WARNING: CouchDB is running in Admin Party mode.
This will allow anyone with access to the
CouchDB port to access your database. In
Docker's default configuration, this is
effectively any other container on the same
system.
Use "-e COUCHDB_USER=admin -e COUCHDB_PASSWORD=password"
to set it in "docker run".
****************************************************
[os_mon] memory supervisor port (memsup): Erlang has closed
[os_mon] cpu supervisor port (cpu_sup): Erlang has closed
{"Kernel pid terminated",application_controller,"{application_start_failure,couch,{{shutdown,{failed_to_start_child,couch_secondary_services,{shutdown,{failed_to_start_child,auth_cache,{{badmatch,{error,eacces}},[{couch_auth_cache,ensure_users_db_exists,2,[{file,\"src/couch_auth_cache.erl\"},{line,456}]},{couch_auth_cache,open_auth_db,0,[{file,\"src/couch_auth_cache.erl\"},{line,428}]},{couch_auth_cache,reinit_cache,1,[{file,\"src/couch_auth_cache.erl\"},{line,290}]},{couch_auth_cache,init,1,[{file,\"src/couch_auth_cache.erl\"},{line,166}]},{gen_server,init_it,6,[{file,\"gen_server.erl\"},{line,328}]},{proc_lib,init_p_do_apply,3,[{file,\"proc_lib.erl\"},{line,240}]}]}}}}},{couch_app,start,[normal,[]]}}}"}
```
moulali308 (Thu, 06 Jul 2017 06:20:27 GMT):
Has joined the channel.
HuangLijun (Thu, 06 Jul 2017 06:52:54 GMT):
Has joined the channel.
nhrishi (Thu, 06 Jul 2017 09:41:10 GMT):
Hi, i'm using rc1 release and when i try to instantiate a chaincode, getting error 2017-07-06 08:56:32.791 UTC [endorser] ProcessProposal -> ERRO 678 simulateProposal() resulted in chaincode response status 500 for txid: "
nhrishi (Thu, 06 Jul 2017 09:41:10 GMT):
Hi, i'm using rc1 release and when i try to instantiate a chaincode, getting error 2017-07-06 08:56:32.791 UTC [endorser] ProcessProposal -> ERRO 678 simulateProposal() resulted in chaincode response status 500 for txid: " . This is what i see in the peer log.
muralisr (Thu, 06 Jul 2017 12:45:53 GMT):
@nhrishi likely chaincode returned an error .... if you add CORE_CHAINCODE_LOGGING_LEVEL=debug CORE_VM_DOCKER_STDOUT=true to peer's env vars you will get logs from chaincode streamed to peer's logs which might give more info
wlahti (Thu, 06 Jul 2017 14:14:09 GMT):
@nhrishi @muralisr Actually, to get the logging enabled for the `shim` which may be of assistance here, you need to set CORE_CHAINCODE_LOGGING_SHIM=DEBUG. CORE_CHAINCODE_LOGGING_LEVEL does set the overall default level for the chaincode container but the shim value is set to warning by default in sampleconfig/core.yaml and will override the level.
nhrishi (Fri, 07 Jul 2017 03:36:06 GMT):
@muralisr @wlahti Thanks. Will check it.
erickbr24 (Sun, 09 Jul 2017 00:05:28 GMT):
Has joined the channel.
erickbr24 (Sun, 09 Jul 2017 00:06:02 GMT):
Hi. Maybe you've had this issue. As I was following the tutorial on ( http://hyperledger-fabric.readthedocs.io/en/latest/build_network.html ). After successfully running [ ./byfn.sh -m generate ], I try to run [ ./byfn.sh -m up ] and I get this...
Starting with channel 'mychannel' and CLI timeout of '10000'
Continue (y/n)? y
proceeding ...
Pulling orderer.example.com (hyperledger/fabric-orderer:latest)...
ERROR: manifest for hyperledger/fabric-orderer:latest not found
ERROR !!!! Unable to start network
Error response from daemon: No such container: cli
I would greatly appreciate if anyone can lead me in the right direction. As I have not found this specific issue solved. Thanks!
Ratnakar (Sun, 09 Jul 2017 02:48:06 GMT):
@erickbr24 Looks like you didn't downloaded the docker images.
Follow the instructions from this section http://hyperledger-fabric.readthedocs.io/en/latest/samples.html#binaries
gauthampamu (Tue, 11 Jul 2017 21:17:35 GMT):
Has joined the channel.
divyank (Wed, 12 Jul 2017 13:42:45 GMT):
Question about events: Can a client with an Org1 e-cert register for events from an Org2 peer?
jeffgarratt (Wed, 12 Jul 2017 15:51:02 GMT):
@divyank if the org2 peer has configured their localMSPConfig to allow it, yes
divyank (Wed, 12 Jul 2017 15:57:30 GMT):
@jeffgarratt How is that configured? I tried adding an Org1 root to the `cacerts` directory of the Org2 peer's local MSP config
jeffgarratt (Wed, 12 Jul 2017 15:58:09 GMT):
@divyank and after peer restart no go?
divyank (Wed, 12 Jul 2017 16:04:30 GMT):
@jeffgarratt MSP ID validation appears to fail : `failed deserializing event creator: [Expected MSP ID Org2MSP, received Org1MSP]`
jeffgarratt (Wed, 12 Jul 2017 16:05:09 GMT):
this was from which process?
jeffgarratt (Wed, 12 Jul 2017 16:05:16 GMT):
the peer your trying to get events from?
jeffgarratt (Wed, 12 Jul 2017 16:05:29 GMT):
or the listener?
divyank (Wed, 12 Jul 2017 16:06:01 GMT):
Yes, this was the response from the event server on the Org2 peer that I am connecting to
jeffgarratt (Wed, 12 Jul 2017 16:09:04 GMT):
k, 2 secs..
jeffgarratt (Wed, 12 Jul 2017 16:10:46 GMT):
@divyank checking with murali, but the code seems to require membership in the peer's org
jeffgarratt (Wed, 12 Jul 2017 16:10:49 GMT):
```// Validates event messages by validating the Creator and verifying
// the signature. Returns the unmarshaled Event object
// Validation of the creator identity's validity is done by checking with local MSP to ensure the
// submitter is a member in the same organization as the peer
jeffgarratt (Wed, 12 Jul 2017 16:11:28 GMT):
@divyank so it appears I was wrong with my statement above
jeffgarratt (Wed, 12 Jul 2017 16:12:32 GMT):
in this case though, it does seem more likely that if you wish this to happen, you would issue the other ORG a cert to allow them access, which you could revoke later if you choose to
divyank (Wed, 12 Jul 2017 16:14:25 GMT):
@jeffgarratt Alright. Thanks for checking
jeffgarratt (Wed, 12 Jul 2017 16:14:43 GMT):
@divyank your most welcome!!
jeffgarratt (Wed, 12 Jul 2017 18:46:52 GMT):
[ ](https://chat.hyperledger.org/channel/fabric?msg=8rtCSybSaEWr5LMyi) @bgaillar @muralisr may be able to address here
bgaillar (Wed, 12 Jul 2017 18:46:52 GMT):
Has joined the channel.
muralisr (Wed, 12 Jul 2017 18:50:55 GMT):
@jeffgarratt @bgaillar this is something thats on the pipeline ( @jiangyaoguo was actively looking into it) but had to be dropped for 1.0 as it was getting too crowded.... please do add @jiangyaoguo
jiangyaoguo (Thu, 13 Jul 2017 02:01:49 GMT):
@jeffgarratt @bgaillar @muralisr Yes, I'll start working on "Start and Stop CC" since now we have 1.0. It was arranged to post 1.0.
WHATISOOP (Fri, 14 Jul 2017 01:31:06 GMT):
Has joined the channel.
thakkarparth007 (Mon, 17 Jul 2017 22:34:32 GMT):
Hello
thakkarparth007 (Mon, 17 Jul 2017 22:34:53 GMT):
I've been trying to modify the validation code to enable parallel vscc validation of tx within a block
thakkarparth007 (Mon, 17 Jul 2017 22:35:42 GMT):
But on doing that, I'm facing a strange situation where some rlocks acquired in the ledger are not being released
thakkarparth007 (Mon, 17 Jul 2017 22:36:19 GMT):
It might be that I'm doing something wrong, but I'm wondering if parallel vscc invocation is safe currently
thakkarparth007 (Mon, 17 Jul 2017 22:38:11 GMT):
Does anyone know of this?
thakkarparth007 (Mon, 17 Jul 2017 22:38:11 GMT):
Does anyone something about this?
muralisr (Tue, 18 Jul 2017 00:27:23 GMT):
@thakkarparth007 from a pure chaincode pov, system chaincode can be invoked in parallel. However vscc does use ledger APIs and there maybe restrictions on concurrent invoke there. Suggest checking with fabric-ledger with the details on what locks are being held please
thakkarparth007 (Tue, 18 Jul 2017 09:15:54 GMT):
Thanks @muralisr
highlander (Tue, 18 Jul 2017 20:27:56 GMT):
Has joined the channel.
chenxuan (Wed, 19 Jul 2017 03:33:16 GMT):
Has joined the channel.
shanlusun (Wed, 19 Jul 2017 08:32:07 GMT):
Hi, when I try to deploy fabric (1.0.0-rc1) with k8s, I could 1.create channel 2.install chaincode. But failed to `3.instantiate chaincode`:
shanlusun (Wed, 19 Jul 2017 08:32:27 GMT):
The error log of peer is here:
shanlusun (Wed, 19 Jul 2017 08:32:53 GMT):
Message Attachments
shanlusun (Wed, 19 Jul 2017 08:33:59 GMT):
I can see the peer already created images: dev-peer0-org1-mycc-1.0
shanlusun (Wed, 19 Jul 2017 08:34:48 GMT):
but seems peer failed to call the image, any idea will be helpful ~
chawlanikhil24 (Wed, 19 Jul 2017 09:01:49 GMT):
Has joined the channel.
shanlusun (Wed, 19 Jul 2017 09:25:09 GMT):
Anyone has some experience on this issue ?
Johnny-The-Dean (Wed, 19 Jul 2017 12:13:40 GMT):
Has joined the channel.
davidkel (Wed, 19 Jul 2017 12:35:40 GMT):
I see the configtxgen has the ability to create an anchor peer transaction, which I assume is used to define say that a specific peer in an org is the anchor peer. I've created a simple network where I have 1 org and 1 peer and I haven't had to explicitly create this transaction and invoke this transaction and it works as expected. So under what circumstances would I need to actually generate and use this transaction ? Would it be if there were multiple organisations or more than 1 peer per organisation ?
jeffgarratt (Wed, 19 Jul 2017 13:49:30 GMT):
@davidkel this is specifically a high availability concept at the moment I believe. This would allow you to retrieve blocks from another organization in the case they can not be retrieved from the orderer
jeffgarratt (Wed, 19 Jul 2017 13:52:07 GMT):
I would assume that at some point in the future they may be relevant to the sideDB concept
jimthematrix (Wed, 19 Jul 2017 18:01:52 GMT):
@greg.haskins @muralisr not sure who's the best to ask this to, just want to double check that in the following proto "NODE" is meant for javascript chaincode:
```
message ChaincodeSpec {
enum Type {
UNDEFINED = 0;
GOLANG = 1;
NODE = 2;
CAR = 3;
JAVA = 4;
}
Type type = 1;
ChaincodeID chaincode_id = 2;
ChaincodeInput input = 3;
int32 timeout = 4;
}
jimthematrix (Wed, 19 Jul 2017 18:02:29 GMT):
i'm pretty sure it should be, but just making sure before I start making use of it for FAB-2331
muralisr (Wed, 19 Jul 2017 18:09:27 GMT):
@jimthematrix yes, it was meant for if we supprrt javascript natively (unlike composer which still uses GOLANG substrate)
muralisr (Wed, 19 Jul 2017 18:10:37 GMT):
ah that's what FAB-2331 is ?
muralisr (Wed, 19 Jul 2017 18:24:05 GMT):
so one thing @jimthematrix ... the chaincode uses FSM which is totally unneecessary now that we do not have the serialization requirements in 0.6 in 1.0. have been playing with code that removes the chaincode and shim FSMs (no external changes) hopefully for 1.1 (was just mentioning this to @mastersingh24). It would make your life a lot simpler to use that model for javascript.... would you like me to push a WIP CR so you can take a look ?
jimthematrix (Wed, 19 Jul 2017 18:36:23 GMT):
@muralisr yes please, thanks for doing that! I always go "huh?" when looking at the FSM code ;-)
jimthematrix (Wed, 19 Jul 2017 18:36:56 GMT):
can we also make sure that your new approach is committed to 1.1?
jimthematrix (Wed, 19 Jul 2017 18:36:56 GMT):
can we also make sure that your new approach is committed for 1.1?
jimthematrix (Wed, 19 Jul 2017 18:37:11 GMT):
maybe voting needed or something?
muralisr (Wed, 19 Jul 2017 18:37:34 GMT):
will create a JIRA so we can vote... right
jimthematrix (Wed, 19 Jul 2017 18:37:42 GMT):
cool
muralisr (Wed, 19 Jul 2017 18:39:07 GMT):
`I always go "huh?" when looking at the FSM code 😉` - I know... dipped in post big bang reverberations and restrictions from 0.6 ...the clean up will help, promise :-)
muralisr (Wed, 19 Jul 2017 18:39:07 GMT):
@jimthematrix `I always go "huh?" when looking at the FSM code 😉` - I know... dipped in post big bang reverberations and restrictions from 0.6 ...the clean up will help, promise :-)
niteshsolanki (Thu, 20 Jul 2017 07:05:24 GMT):
Has joined the channel.
niteshsolanki (Thu, 20 Jul 2017 07:05:28 GMT):
Are there any API's in shim layer to create Index for couchDB queries or it has to be done using Curl only?
jimthematrix (Thu, 20 Jul 2017 12:02:02 GMT):
@greg.haskins @muralisr my plan for the shim part of javascript chaincode support is first exploring calling golang from node.js, instead of re-implementing the whole shim in node.js natively. This first and foremost saves us time for putting this out in v1.1, and in general may prove to be a viable approach to extend to other languages
muralisr (Thu, 20 Jul 2017 12:03:10 GMT):
hmmm... just as composer does ?
jimthematrix (Thu, 20 Jul 2017 12:03:41 GMT):
no, it's the opposite: Composer is golang calling nodejs via an interpret
jimthematrix (Thu, 20 Jul 2017 12:03:41 GMT):
no, it's the opposite: Composer is golang calling nodejs via an interpreter
jimthematrix (Thu, 20 Jul 2017 12:04:01 GMT):
this is node.js calling golang via shared library
muralisr (Thu, 20 Jul 2017 12:04:13 GMT):
oh I see
greg.haskins (Thu, 20 Jul 2017 12:04:22 GMT):
@jimthematrix I suppose I should withhold judgement until I see an implementation but this strikes me as less than ideal
muralisr (Thu, 20 Jul 2017 12:04:24 GMT):
native node js but just calling shim
muralisr (Thu, 20 Jul 2017 12:04:24 GMT):
native node js but just calling golang shim
jimthematrix (Thu, 20 Jul 2017 12:06:15 GMT):
yes Greg the resulting impact remains to be seen but I think this is an incremental step in that if this turns out to be a bad idea (maybe performance is bad), minimal amount of code can just be replaced with native shim impl with javascript
jimthematrix (Thu, 20 Jul 2017 12:06:38 GMT):
note that grpc support in node.js is accomplished this way
muralisr (Thu, 20 Jul 2017 12:06:41 GMT):
its an implementation detail that can be chaged sure
muralisr (Thu, 20 Jul 2017 12:06:41 GMT):
its an implementation detail that can be changed sure
jimthematrix (Thu, 20 Jul 2017 12:06:59 GMT):
so I'm quite hopeful
jimthematrix (Thu, 20 Jul 2017 12:07:32 GMT):
my question is where should I do the build step of the shim to make it a shared object?
muralisr (Thu, 20 Jul 2017 12:09:23 GMT):
in the spirit of keep it all internal, would be good to stuff that into the build image step than outside of it (ie, "saved" in the fabric externally)
muralisr (Thu, 20 Jul 2017 12:09:47 GMT):
but should wait for @greg.haskins thoughts...
jimthematrix (Thu, 20 Jul 2017 12:11:22 GMT):
I guess I could start with adding an image based on ccenv and adding a build step to build the shim as shared object?
greg.haskins (Thu, 20 Jul 2017 12:11:44 GMT):
@jimthematrix still not sold on the approach, but if you were going to do it that way and wanted to know where the build could happen, my inclination would be to suggest during the ccenv build
greg.haskins (Thu, 20 Jul 2017 12:12:23 GMT):
i see no reason to introduce a new image...in fact, i would probably rather see javaenv collapse back into ccenv
greg.haskins (Thu, 20 Jul 2017 12:14:46 GMT):
@jimthematrix orthogonal to this particular aspect of the discussion, but, ill throw this out there that you could consider doing this as a chaintool platform (http://fabric-chaintool.readthedocs.io/en/latest/application-development/#platform)
jimthematrix (Thu, 20 Jul 2017 12:14:59 GMT):
if you are ok doing that in ccenv that's perfect
greg.haskins (Thu, 20 Jul 2017 12:15:15 GMT):
I designed the .car format to be a universal chaincode container, with provisions for things like declaring compatibility constraints, etc
jimthematrix (Thu, 20 Jul 2017 12:15:16 GMT):
wasn't sure if ccenv was meant to be reserved for golang only ...
greg.haskins (Thu, 20 Jul 2017 12:15:45 GMT):
if you _dont_ use .car, then each other type (GOLANG, JAVA, and now NODE) are going to have to replicate this eventually once we move past v1.0
greg.haskins (Thu, 20 Jul 2017 12:16:11 GMT):
nope, ccenv not meant to be golang specific
greg.haskins (Thu, 20 Jul 2017 12:16:33 GMT):
i see no reason why basically all platforms cant be represented as a superset at the time we cut that release
greg.haskins (Thu, 20 Jul 2017 12:16:39 GMT):
(in ccenv, I mean)
jimthematrix (Thu, 20 Jul 2017 12:16:45 GMT):
_are going to have to replicate this eventually once we move past v1.0_ - what's "this"?
greg.haskins (Thu, 20 Jul 2017 12:17:09 GMT):
@jimthematrix "this" is the basic notion of ABI management
greg.haskins (Thu, 20 Jul 2017 12:17:34 GMT):
I would describe it as analogous to how the JVM deals with different versions of java
greg.haskins (Thu, 20 Jul 2017 12:17:53 GMT):
e.g. "JRE-1.9" can emulate 1.9, 1.8, 1.7, 1.6, etc
niteshsolanki (Thu, 20 Jul 2017 12:18:10 GMT):
How can joins be implemented in couchDB in the chaincode ?
greg.haskins (Thu, 20 Jul 2017 12:18:14 GMT):
and .java files explicitly version themselves
greg.haskins (Thu, 20 Jul 2017 12:18:46 GMT):
so its this coupling of runtime compatibility + emulation plus payload specification that I lump into "abi management"
jimthematrix (Thu, 20 Jul 2017 12:18:47 GMT):
ah ok, yes I'm in agreement. if that can be consolidated as much as possible it's a good thing
jimthematrix (Thu, 20 Jul 2017 12:19:00 GMT):
via the .car mechanism
greg.haskins (Thu, 20 Jul 2017 12:19:01 GMT):
and I tried to capture that in a general way in chaintool/car
jimthematrix (Thu, 20 Jul 2017 12:19:18 GMT):
let me take another look at that
greg.haskins (Thu, 20 Jul 2017 12:19:36 GMT):
ok...would be more than happy to help lay the groundwork for a new type in chaintool
jimthematrix (Thu, 20 Jul 2017 12:20:43 GMT):
like you said it's orthogonal so my current step is to get the shared object built in ccenv and then get js calling golang shim working. when I get to the packaging step I'll revisit this with you
greg.haskins (Thu, 20 Jul 2017 12:20:53 GMT):
ok
greg.haskins (Thu, 20 Jul 2017 12:22:17 GMT):
i think longer term, we will need to get away from "peer vX.Y.Z + ccenv vX.Y.Z" coupling and instead having the notion of the platform specifier (chaintool/car or otherwise) drive the right ccenv
greg.haskins (Thu, 20 Jul 2017 12:22:24 GMT):
but for now...
n91 (Thu, 20 Jul 2017 22:31:06 GMT):
Has joined the channel.
jimthematrix (Fri, 21 Jul 2017 02:07:52 GMT):
as for the idea of re-using the golang shim binary for node.js chaincode, so far it's not looking promising. node.js has good integration with c/c++ (using .h files) but support for golang binaries seems to be lacking. I tried 2 different approaches: 1) build golang as shared libs and load dynamically - require("ffi"), 2) load go source with require("node-go-require") and require("gonode"). haven't been successful so far. I think the biggest problem with this approach in general is debugging when there are problems. I'm starting to think it's time to bite the bullet and re-implement the shim in node.js properly
jimthematrix (Fri, 21 Jul 2017 02:08:09 GMT):
@greg.haskins @muralisr @mastersingh24 ^^^
greg.haskins (Fri, 21 Jul 2017 02:08:49 GMT):
i would prefer that anyway
greg.haskins (Fri, 21 Jul 2017 02:08:57 GMT):
so, sounds good to me
jimthematrix (Fri, 21 Jul 2017 04:58:47 GMT):
some initial "success" (in the form of a failure ;-))
```
root@91aa68318434:~/core/chaincode/shim/node# CORE_CHAINCODE_ID_NAME="mycc:v0" node test.js --peer.address grpc://192.168.1.64:7051
Doh! Error: Error handling message, ending stream: transition canceled with error: peer will not accepting external chaincode connection name:"mycc:v0" (except in dev mode)
```
2017-07-21 00:57:10.902 EDT [chaincode] processStream -> DEBU 314 []Received message REGISTER from shim
2017-07-21 00:57:10.902 EDT [chaincode] HandleMessage -> DEBU 315 []Fabric side Handling ChaincodeMessage of type: REGISTER in state created
2017-07-21 00:57:10.902 EDT [chaincode] beforeRegisterEvent -> DEBU 316 Received REGISTER in state created
2017-07-21 00:57:10.902 EDT [chaincode] notifyDuringStartup -> DEBU 317 nothing to notify (dev mode ?)
2017-07-21 00:57:10.902 EDT [chaincode] notifyDuringStartup -> WARN 318 trying to manually run chaincode when not in devmode ?
2017-07-21 00:57:10.902 EDT [chaincode] HandleMessage -> ERRO 319 []Failed to trigger FSM event REGISTER: transition canceled with error: peer will not accepting external chaincode connection name:"mycc:v0" (except in dev mode)
2017-07-21 00:57:10.902 EDT [chaincode] processStream -> ERRO 31a []Error handling message, ending stream: transition canceled with error: peer will not accepting external chaincode connection name:"mycc:v0" (except in dev mode)
jimthematrix (Fri, 21 Jul 2017 04:58:47 GMT):
some initial "success" (in the form of a failure ;-) )
```
root@91aa68318434:~/core/chaincode/shim/node# CORE_CHAINCODE_ID_NAME="mycc:v0" node test.js --peer.address grpc://192.168.1.64:7051
Doh! Error: Error handling message, ending stream: transition canceled with error: peer will not accepting external chaincode connection name:"mycc:v0" (except in dev mode)
```
```
2017-07-21 00:57:10.902 EDT [chaincode] processStream -> DEBU 314 []Received message REGISTER from shim
2017-07-21 00:57:10.902 EDT [chaincode] HandleMessage -> DEBU 315 []Fabric side Handling ChaincodeMessage of type: REGISTER in state created
2017-07-21 00:57:10.902 EDT [chaincode] beforeRegisterEvent -> DEBU 316 Received REGISTER in state created
2017-07-21 00:57:10.902 EDT [chaincode] notifyDuringStartup -> DEBU 317 nothing to notify (dev mode ?)
2017-07-21 00:57:10.902 EDT [chaincode] notifyDuringStartup -> WARN 318 trying to manually run chaincode when not in devmode ?
2017-07-21 00:57:10.902 EDT [chaincode] HandleMessage -> ERRO 319 []Failed to trigger FSM event REGISTER: transition canceled with error: peer will not accepting external chaincode connection name:"mycc:v0" (except in dev mode)
2017-07-21 00:57:10.902 EDT [chaincode] processStream -> ERRO 31a []Error handling message, ending stream: transition canceled with error: peer will not accepting external chaincode connection name:"mycc:v0" (except in dev mode)
```
jimthematrix (Fri, 21 Jul 2017 04:58:47 GMT):
some initial "success" (in the form of a failure ;-) )
JS chaincode:
```
const shim = require('./chaincode.js');
shim.Start();
```
```
root@91aa68318434:~/core/chaincode/shim/node# CORE_CHAINCODE_ID_NAME="mycc:v0" node test.js --peer.address grpc://192.168.1.64:7051
Doh! Error: Error handling message, ending stream: transition canceled with error: peer will not accepting external chaincode connection name:"mycc:v0" (except in dev mode)
```
```
2017-07-21 00:57:10.902 EDT [chaincode] processStream -> DEBU 314 []Received message REGISTER from shim
2017-07-21 00:57:10.902 EDT [chaincode] HandleMessage -> DEBU 315 []Fabric side Handling ChaincodeMessage of type: REGISTER in state created
2017-07-21 00:57:10.902 EDT [chaincode] beforeRegisterEvent -> DEBU 316 Received REGISTER in state created
2017-07-21 00:57:10.902 EDT [chaincode] notifyDuringStartup -> DEBU 317 nothing to notify (dev mode ?)
2017-07-21 00:57:10.902 EDT [chaincode] notifyDuringStartup -> WARN 318 trying to manually run chaincode when not in devmode ?
2017-07-21 00:57:10.902 EDT [chaincode] HandleMessage -> ERRO 319 []Failed to trigger FSM event REGISTER: transition canceled with error: peer will not accepting external chaincode connection name:"mycc:v0" (except in dev mode)
2017-07-21 00:57:10.902 EDT [chaincode] processStream -> ERRO 31a []Error handling message, ending stream: transition canceled with error: peer will not accepting external chaincode connection name:"mycc:v0" (except in dev mode)
```
jimthematrix (Fri, 21 Jul 2017 04:58:47 GMT):
some initial "success" (in the form of a failure ;-) )
JS chaincode:
```
const shim = require('./chaincode.js');
shim.Start();
```
jimthematrix (Fri, 21 Jul 2017 05:00:25 GMT):
@muralisr I'm coming up to the point to need to implement the chat with peer, so your changes to remove the FSM would be needed here, will discuss tomorrow
jimthematrix (Fri, 21 Jul 2017 05:00:25 GMT):
running inside docker based on fabric-baseimage:
```
root@91aa68318434:~/core/chaincode/shim/node# CORE_CHAINCODE_ID_NAME="mycc:v0" node test.js --peer.address grpc://192.168.1.64:7051
Doh! Error: Error handling message, ending stream: transition canceled with error: peer will not accepting external chaincode connection name:"mycc:v0" (except in dev mode)
```
jimthematrix (Fri, 21 Jul 2017 05:02:53 GMT):
output from peer:
```
2017-07-21 00:57:10.902 EDT [chaincode] processStream -> DEBU 314 []Received message REGISTER from shim
2017-07-21 00:57:10.902 EDT [chaincode] HandleMessage -> DEBU 315 []Fabric side Handling ChaincodeMessage of type: REGISTER in state created
2017-07-21 00:57:10.902 EDT [chaincode] beforeRegisterEvent -> DEBU 316 Received REGISTER in state created
2017-07-21 00:57:10.902 EDT [chaincode] notifyDuringStartup -> DEBU 317 nothing to notify (dev mode ?)
2017-07-21 00:57:10.902 EDT [chaincode] notifyDuringStartup -> WARN 318 trying to manually run chaincode when not in devmode ?
2017-07-21 00:57:10.902 EDT [chaincode] HandleMessage -> ERRO 319 []Failed to trigger FSM event REGISTER: transition canceled with error: peer will not accepting external chaincode connection name:"mycc:v0" (except in dev mode)
2017-07-21 00:57:10.902 EDT [chaincode] processStream -> ERRO 31a []Error handling message, ending stream: transition canceled with error: peer will not accepting external chaincode connection name:"mycc:v0" (except in dev mode)
```
jimthematrix (Fri, 21 Jul 2017 05:02:57 GMT):
@muralisr I'm coming up to the point to need to implement the chat with peer, so your changes to remove the FSM would be needed here, will discuss tomorrow
chawlanikhil24 (Fri, 21 Jul 2017 09:19:21 GMT):
```
```
==================== Channel "businesschannel" is created successfully =====================
Having all peers join the channel...
CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt
CORE_PEER_TLS_KEY_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/server.key
CORE_PEER_LOCALMSPID=Org1MSP
CORE_PEER_TLS_CERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/server.crt
CORE_PEER_TLS_ENABLED=false
CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
CORE_PEER_ID=fabric-cli
CORE_LOGGING_LEVEL=DEBUG
CORE_PEER_ADDRESS=peer0-org1:7051
2017-07-21 06:10:24.526 UTC [msp] GetLocalMSP -> DEBU 001 Returning existing local MSP
2017-07-21 06:10:24.526 UTC [msp] GetDefaultSigningIdentity -> DEBU 002 Obtaining default signing identity
2017-07-21 06:10:24.528 UTC [channelCmd] InitCmdFactory -> INFO 003 Endorser and orderer connections initialized
2017-07-21 06:10:24.529 UTC [msp/identity] Sign -> DEBU 004 Sign: plaintext: 0A8A070A5C08011A0C08D0B5C6CB0510...868967B4244E1A080A000A000A000A00
2017-07-21 06:10:24.529 UTC [msp/identity] Sign -> DEBU 005 Sign: digest: D1D5B3DAC02A15FC20787149BFBF6E3FA1DD99B299120C061EA563986C4C22F9
Error: proposal failed (err: rpc error: code = Unknown desc = Failed to deserialize creator identity, err The supplied identity is not valid, Verify() returned x509: certificate signed by unknown authority)
```
chawlanikhil24 (Fri, 21 Jul 2017 09:19:31 GMT):
Hi please help me with this error
indirajith (Fri, 21 Jul 2017 10:21:43 GMT):
Has joined the channel.
muralisr (Fri, 21 Jul 2017 12:19:24 GMT):
@jimthematrix sure, lets ping and chat sometime today
muralisr (Fri, 21 Jul 2017 12:24:20 GMT):
@chawlanikhil24 is there any interesting error from the peer itself (peer0 ?)
chawlanikhil24 (Fri, 21 Jul 2017 12:58:59 GMT):
```
2017-07-21 12:57:56.666 UTC [protoutils] validateChannelHeader -> DEBU 1a2 validateChannelHeader info: header type 1
2017-07-21 12:57:56.666 UTC [protoutils] checkSignatureFromCreator -> DEBU 1a3 checkSignatureFromCreator starts
2017-07-21 12:57:56.666 UTC [endorser] ProcessProposal -> DEBU 1a4 Exit
2017-07-21 12:57:58.738 UTC [endorser] ProcessProposal -> DEBU 1a5 Entry
2017-07-21 12:57:58.738 UTC [protoutils] ValidateProposalMessage -> DEBU 1a6 ValidateProposalMessage starts for signed proposal 0xc4217bb6e0
2017-07-21 12:57:58.738 UTC [protoutils] validateChannelHeader -> DEBU 1a7 validateChannelHeader info: header type 1
2017-07-21 12:57:58.738 UTC [protoutils] checkSignatureFromCreator -> DEBU 1a8 checkSignatureFromCreator starts
2017-07-21 12:57:58.739 UTC [endorser] ProcessProposal -> DEBU 1a9 Exit
2017-07-21 12:58:00.822 UTC [endorser] ProcessProposal -> DEBU 1aa Entry
2017-07-21 12:58:00.822 UTC [protoutils] ValidateProposalMessage -> DEBU 1ab ValidateProposalMessage starts for signed proposal 0xc4217f6690
2017-07-21 12:58:00.822 UTC [protoutils] validateChannelHeader -> DEBU 1ac validateChannelHeader info: header type 1
2017-07-21 12:58:00.822 UTC [protoutils] checkSignatureFromCreator -> DEBU 1ad checkSignatureFromCreator starts
2017-07-21 12:58:00.822 UTC [endorser] ProcessProposal -> DEBU 1ae Exit
2017-07-21 12:58:02.936 UTC [endorser] ProcessProposal -> DEBU 1af Entry
2017-07-21 12:58:02.936 UTC [protoutils] ValidateProposalMessage -> DEBU 1b0 ValidateProposalMessage starts for signed proposal 0xc421865bc0
2017-07-21 12:58:02.936 UTC [protoutils] validateChannelHeader -> DEBU 1b1 validateChannelHeader info: header type 1
2017-07-21 12:58:02.936 UTC [protoutils] checkSignatureFromCreator -> DEBU 1b2 checkSignatureFromCreator starts
2017-07-21 12:58:02.937 UTC [endorser] ProcessProposal -> DEBU 1b3 Exit
```
chawlanikhil24 (Fri, 21 Jul 2017 12:59:27 GMT):
Nothing appears to be an error here in the pods Log !
chawlanikhil24 (Fri, 21 Jul 2017 12:59:27 GMT):
Nothing appears to be an error here in the pod peer0 Log !
muralisr (Fri, 21 Jul 2017 13:27:01 GMT):
@chawlanikhil24 can you try the join command with `CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp` ?
chawlanikhil24 (Fri, 21 Jul 2017 13:27:32 GMT):
sure !
blw (Sat, 22 Jul 2017 16:56:07 GMT):
Has joined the channel.
blw (Sat, 22 Jul 2017 17:17:20 GMT):
Has left the channel.
bgaillar (Mon, 24 Jul 2017 14:14:55 GMT):
@jiangyaoguo Any update on the Start and Stop functionality for CC?
jimthematrix (Mon, 24 Jul 2017 18:26:24 GMT):
@muralisr @greg.haskins quick question, how to inspect the content of the installed chaincodes? I tried `tar -tvf /var/hyperledger/production/chaincodes/mycc.v0` and `tar -ztvf` but neither worked
jimthematrix (Mon, 24 Jul 2017 18:35:14 GMT):
is it a serialized protobuf structure?
greg.haskins (Mon, 24 Jul 2017 18:50:27 GMT):
@jimthematrix Murali is your man on that
greg.haskins (Mon, 24 Jul 2017 18:50:59 GMT):
.car is a serialized protobuf, but not sure about the deployment payload
muralisr (Mon, 24 Jul 2017 19:58:28 GMT):
@jimthematrix its a serialized ChaincodeDeploymentSpec... so you can readin the bytes and Unmarshal
divyank (Tue, 25 Jul 2017 15:30:11 GMT):
I noticed that chaincode events are not propagated through chaincode calling chaincode. Was this intentional?
muralisr (Tue, 25 Jul 2017 17:51:26 GMT):
@divyank yes, only responses from called chaincode are returned to the calling chaincode
l1nux (Tue, 25 Jul 2017 19:24:03 GMT):
Has joined the channel.
noyonthe1 (Wed, 26 Jul 2017 18:23:57 GMT):
Has joined the channel.
Asara (Wed, 26 Jul 2017 19:32:05 GMT):
Hey all, can someone take a look at this for a sec?
Asara (Wed, 26 Jul 2017 19:32:11 GMT):
https://pastebin.com/bXwz3XaP
Asara (Wed, 26 Jul 2017 19:33:57 GMT):
I am able to deploy this chain code when running byfn, but when running on multiple servers I cannot
Asara (Wed, 26 Jul 2017 19:34:04 GMT):
I feel like it has to do with my docker environment variables
Asara (Wed, 26 Jul 2017 19:34:05 GMT):
But i'm unsure
Asara (Wed, 26 Jul 2017 19:50:29 GMT):
Could `CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE` have something to do with it?
kostas (Wed, 26 Jul 2017 20:14:35 GMT):
Looking at [the documentation](http://hyperledger-fabric.readthedocs.io/en/latest/chaincode4noah.html), and this bit is unclear to me:
> When -s is specified, the -S option must also be specified if other owners are going to need to sign. Otherwise, the process will create a SignedCDS that includes only the instantiation policy in addition to the CDS. The -S option directs the process to sign the package using the MSP identified by the value of the localMspid property in core.yaml.
kostas (Wed, 26 Jul 2017 20:15:18 GMT):
Why does `-S` (capital S) must be specified if _other_ owners are going to need to sign? If this option directs the process to sign the package, it seems that it's needed regardless?
kostas (Wed, 26 Jul 2017 20:15:18 GMT):
Why does `-S` (capital S) must be specified if _other_ owners are going to need to sign? If this option directs the process to sign the package (as the last sentence indicates), it seems that it's needed regardless?
kostas (Wed, 26 Jul 2017 20:15:18 GMT):
Q1: Why does `-S` (capital S) must be specified if _other_ owners are going to need to sign? If this option directs the process to sign the package (as the last sentence indicates), it seems that it's needed regardless?
kostas (Wed, 26 Jul 2017 20:20:02 GMT):
And one more question, I have that same on the documet:
> If no policy is provided, the default policy is used, which only allows the admin identity of the peer’s MSP to instantiate chaincode.
But just a couple of paragraphs down we write:
> If the instantiation policy is not specified, the default policy is any MSP administrator of the channel.
Is the peer's MSP (and which peer by the way?), or is it the MSP administrator of the channel? These two are not necessarily identical.
kostas (Wed, 26 Jul 2017 20:20:02 GMT):
And one more question, I have that same on the documet:
> If no policy is provided, the default policy is used, which only allows the admin identity of the peer’s MSP to instantiate chaincode.
But just a couple of paragraphs down we write:
> If the instantiation policy is not specified, the default policy is any MSP administrator of the channel.
Q2: Is the peer's MSP (and which peer by the way?), or is it the MSP administrator of the channel? These two are not necessarily identical.
kostas (Wed, 26 Jul 2017 20:20:02 GMT):
And one more question, I have that same on the documet:
> If no policy is provided, the default policy is used, which only allows the admin identity of the peer’s MSP to instantiate chaincode.
But just a couple of paragraphs down we write:
> If the instantiation policy is not specified, the default policy is any MSP administrator of the channel.
Q2: Is the peer's MSP (and which peer by the way?), or is it the MSP administrator of the channel? These two are not necessarily identical. (I would note that the phrasing that follows several paragraphs later -- "For example, recall that the default instantiation policy is any channel MSP administrator, so the creator of a chaincode instantiate transaction must be a member of the channel administrators. " -- is much less ambiguous.)
kostas (Wed, 26 Jul 2017 20:20:02 GMT):
And one more question, I have that same on the documet:
> If no policy is provided, the default policy is used, which only allows the admin identity of the peer’s MSP to instantiate chaincode.
But just a couple of paragraphs down we write:
> If the instantiation policy is not specified, the default policy is any MSP administrator of the channel.
Q2: Is the peer's MSP (and which peer by the way?), or is it the MSP administrator of the channel? These two are not necessarily identical. (The phrasing that follows several paragraphs later -- "For example, recall that the default instantiation policy is any channel MSP administrator, so the creator of a chaincode instantiate transaction must be a member of the channel administrators. " -- is much less ambiguous, and matches my understanding of what's going on as well.)
yacovm (Wed, 26 Jul 2017 20:43:10 GMT):
@kostas I believe it's https://github.com/hyperledger/fabric/blob/release/core/scc/lscc/lscc.go#L497
yacovm (Wed, 26 Jul 2017 20:46:37 GMT):
Also I think there is an unwritten rule of thumb in fabric -
1) Signing is with local MSP
2) verification is with channel MSP (unless very specific cases)
muralisr (Wed, 26 Jul 2017 23:06:24 GMT):
@kostas the `-s` stands for "signed package format" (not used currently by SDKs...and in general not used or advertised much). the `-S` stands for if the package should be signed or not... ie, the format may be "signed package" but one need not sign it. If a policy is not provided (and for the non `-s` format, it is not...) the default policy is `any admin of the channel`.
kostas (Thu, 27 Jul 2017 02:54:36 GMT):
@muralisr: I'm confused :slight_smile: Could you expand a bit more on the `-S` switch?
kostas (Thu, 27 Jul 2017 02:54:36 GMT):
@muralisr: Not sure I follow. Perhaps we could give a few examples with the `-S` switch?
kostas (Thu, 27 Jul 2017 02:54:36 GMT):
@muralisr: Not sure I follow. Perhaps you could give a few examples with the `-S` switch?
SyneBlockChainTeam (Thu, 27 Jul 2017 10:15:51 GMT):
Hi,
We have deployed 6 chain-codes on 6 peer across 2 organizations (i.e. each organization has 3 peers).
We followed both approaches, CLI as well as Node SDK.
In case of CLI, everything works fine on each peer (alll calls worked fine).
In case of Node SDK, we are able to call chain-code APIs from first 3 peers (of Org1) successfully, but when we tried to call any API from Peers of Org2, it gives following error on SDK Terminal :
error: [client-utils.js]: sendPeersProposal - Promise is rejected: Error: Error executing chaincode: Could not get deployment transaction from LSCC for mycc:v0 - Get ChaincodeDeploymentSpec for mycc/mychannel from LSCC error: chaincode fingerprint mismatch data mismatch
at /home/venky/go/src/github.com/hyperledger/mortgage/mortgage/dlt-service/mortgage/node_modules/grpc/src/node/src/client.js:434:17
[2017-07-27 14:42:26.290] [ERROR] invoke-chaincode - transaction proposal was bad
[2017-07-27 14:42:26.290] [ERROR] invoke-chaincode - Failed to send Proposal or receive valid response. Response null or status is not 200. exiting...
[2017-07-27 14:42:26.290] [ERROR] invoke-chaincode - Failed to order the transaction. Error code: undefined
Incase someone has faced similar issue, please let us know its resolution or any clue.
We appreciate any help.
Thanks
yacovm (Thu, 27 Jul 2017 11:06:23 GMT):
@SyneBlockChainTeam did you run the peer CLI from the same host, and did you run the node SDK from the same host too?
yacovm (Thu, 27 Jul 2017 11:06:33 GMT):
I'd assume you ran the node SDK from a different host
SyneBlockChainTeam (Thu, 27 Jul 2017 12:02:22 GMT):
Initially we tried with CLI and tested with (ORG1 - Peer0, Peer1, Peer2 and ORG2 - Peer0, Peer1, Peer2) successfully.
Later-on we tried with Sdk Node as per the configurations suggested in the online documentation. We noticed that everything (Invoke, Query) works find with Peer0, Peer1, Peer2 of ORG1 but when we attempted testing on Peer0, Peer1, Peer2 of ORG2 we started getting above mentioned error.
Thanks.
davidkel (Thu, 27 Jul 2017 12:43:11 GMT):
Is there a way to stop a peer restarting a container if the container dies/crashes ? I have a situation where a chaincode container dies, but because the peer removes that container completely and starts a new one there is no way to attach to the container for indepth diagnostics
jeffgarratt (Thu, 27 Jul 2017 15:58:18 GMT):
@muralisr could you point @davidkel to the launch line where he could locally disable the removal of the container on exit?
muralisr (Thu, 27 Jul 2017 16:04:00 GMT):
@jeffgarratt sure... but let me ask this @davidkel if you just want logs from chaincode, a better approach would be to add `CORE_CHAINCODE_LOGGING_LEVEL=debug CORE_CHAINCODE_LOGGING_SHIM=debug CORE_VM_DOCKER_ATTACHSTDOUT=true` to the peer envs. This will get you all the logs from chaincode to debug
davidkel (Thu, 27 Jul 2017 16:10:31 GMT):
@muralisr unfortunately the logs don't show anything which is why I want to go into the container and see if there are any other places I could look for why the container just died
muralisr (Thu, 27 Jul 2017 16:34:59 GMT):
In that case @davidkel just use this comment in core/chaincode/chaincode_support.go
muralisr (Thu, 27 Jul 2017 16:35:04 GMT):
``` sir := container.StopImageReq{CCID: ccintf.CCID{ChaincodeSpec: cds.ChaincodeSpec, NetworkID: chaincodeSupport.peerNetworkID, PeerID: chaincodeSupport.peerID, Version: cccid.Version}, Timeout: 0}
// The line below is left for debugging. It replaces the line above to keep
// the chaincode container around to give you a chance to get data
//sir := container.StopImageReq{CCID: ccintf.CCID{ChaincodeSpec: cds.ChaincodeSpec, NetworkID: chaincodeSupport.peerNetworkID, PeerID: chaincodeSupport.peerID, ChainID: cccid.ChainID, Version: cccid.Version}, Timeout: 0, Dontremove: true}```
Asara (Thu, 27 Jul 2017 17:22:29 GMT):
What version of couchdb should be running for the peer?
Asara (Thu, 27 Jul 2017 17:25:16 GMT):
When starting the peer, it seems like couchDB is unable to create some necessary tables.
Asara (Thu, 27 Jul 2017 17:26:17 GMT):
```
Jul 27 17:24:52 ip-172-30-2-9 peer[4904]: 2017-07-27 17:24:52.615 UTC [couchdb] CreateSystemDatabasesIfNotExist -> ERRO 004 Error during CouchDB CreateDatabaseIfNotExist() for system dbName: _global_changes error: Couch DB Error:illegal_database_name, Status Code:400, Reason:Name: '_global_changes'. Only lowercase characters (a-z), digits (0-9), and any of the characters _, $, (, ), +, -, and / are allowed. Must begin with a letter.
```
Asara (Thu, 27 Jul 2017 17:34:23 GMT):
Which version of `couchdb` is used with the peers?
jeffgarratt (Thu, 27 Jul 2017 18:28:56 GMT):
@Asara https://github.com/hyperledger/fabric/blob/release/images/couchdb/Dockerfile.in#L47
Asara (Thu, 27 Jul 2017 18:29:45 GMT):
thanks @jeffgarratt
kostas (Thu, 27 Jul 2017 19:42:34 GMT):
Just a reminder that I'm trying to get this, but I'm still not there, so any help would be appreciated:
kostas (Thu, 27 Jul 2017 19:42:35 GMT):
https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=ZA9rWgqkFsdHd5qQ4
Asara (Thu, 27 Jul 2017 21:32:14 GMT):
Hey all, When trying to start chaincode, I get the following error:
```
ERRO 002 Error trying to connect to local peer: x509: cannot validate certificate for 0.0.0.0 because it doesn't contain any IP SANs
```
yacovm (Thu, 27 Jul 2017 21:36:30 GMT):
Hmm
yacovm (Thu, 27 Jul 2017 21:36:44 GMT):
@Asara are you running with docker or on plain linux?
Asara (Thu, 27 Jul 2017 21:36:52 GMT):
Yeap
Asara (Thu, 27 Jul 2017 21:36:55 GMT):
Centos 7
yacovm (Thu, 27 Jul 2017 21:37:01 GMT):
no docker
yacovm (Thu, 27 Jul 2017 21:37:02 GMT):
right?
Asara (Thu, 27 Jul 2017 21:37:09 GMT):
running the binary yeah
yacovm (Thu, 27 Jul 2017 21:37:17 GMT):
ok assume the ip of the peer is `IP`
Asara (Thu, 27 Jul 2017 21:37:36 GMT):
Where would I change that?
yacovm (Thu, 27 Jul 2017 21:37:56 GMT):
wait
yacovm (Thu, 27 Jul 2017 21:37:59 GMT):
I'm telling you
yacovm (Thu, 27 Jul 2017 21:38:02 GMT):
denote the ip of your peer
yacovm (Thu, 27 Jul 2017 21:38:04 GMT):
as IP
yacovm (Thu, 27 Jul 2017 21:38:04 GMT):
as `IP`
yacovm (Thu, 27 Jul 2017 21:38:39 GMT):
https://github.com/hyperledger/fabric/blob/release/sampleconfig/core.yaml#L87
yacovm (Thu, 27 Jul 2017 21:38:42 GMT):
what does this line say?
yacovm (Thu, 27 Jul 2017 21:38:50 GMT):
and this line? https://github.com/hyperledger/fabric/blob/release/sampleconfig/core.yaml#L74
yacovm (Thu, 27 Jul 2017 21:39:03 GMT):
and this line https://github.com/hyperledger/fabric/blob/release/sampleconfig/core.yaml#L318
yacovm (Thu, 27 Jul 2017 21:39:23 GMT):
in *your* core.yaml
Asara (Thu, 27 Jul 2017 21:42:05 GMT):
```listenAddress: 0.0.0.0:7051```
yacovm (Thu, 27 Jul 2017 21:42:20 GMT):
and the rest?
Asara (Thu, 27 Jul 2017 21:42:28 GMT):
``peerAddress:```
Asara (Thu, 27 Jul 2017 21:42:28 GMT):
```peerAddress:```
Asara (Thu, 27 Jul 2017 21:42:29 GMT):
is unset
yacovm (Thu, 27 Jul 2017 21:43:07 GMT):
ok, please go to `sampleconfig/tls/`
yacovm (Thu, 27 Jul 2017 21:43:09 GMT):
and then do:
Asara (Thu, 27 Jul 2017 21:43:32 GMT):
I'm making all these files via ansible, so what should the values be? I can set them to whatever they need to be
yacovm (Thu, 27 Jul 2017 21:43:50 GMT):
wait wait
yacovm (Thu, 27 Jul 2017 21:43:53 GMT):
one step at atime
yacovm (Thu, 27 Jul 2017 21:44:01 GMT):
where is the TLS folder
yacovm (Thu, 27 Jul 2017 21:44:11 GMT):
https://github.com/hyperledger/fabric/blob/release/sampleconfig/core.yaml#L212
yacovm (Thu, 27 Jul 2017 21:44:15 GMT):
what does it say?
yacovm (Thu, 27 Jul 2017 21:44:35 GMT):
do `openssl x509 -in tls/server.crt -text -noout`
Asara (Thu, 27 Jul 2017 21:44:38 GMT):
Same thing as the sample, but I have the msp/tls stuff in the proper directory
yacovm (Thu, 27 Jul 2017 21:44:57 GMT):
ok, please tell me what is the output of the above command
yacovm (Thu, 27 Jul 2017 21:45:07 GMT):
you may tell me only the DNS names
yacovm (Thu, 27 Jul 2017 21:45:09 GMT):
if you want
Asara (Thu, 27 Jul 2017 21:45:11 GMT):
```Subject: C=US, ST=California, L=San Francisco, CN=peer0.org1.example.com```
yacovm (Thu, 27 Jul 2017 21:45:16 GMT):
aha
yacovm (Thu, 27 Jul 2017 21:45:26 GMT):
ping peer0.org1.example.com
yacovm (Thu, 27 Jul 2017 21:45:32 GMT):
do you get a resolution?
Asara (Thu, 27 Jul 2017 21:45:34 GMT):
I have dns set up
Asara (Thu, 27 Jul 2017 21:45:48 GMT):
```
peer0.org1.example.com (172.30.2.219) 56(84) bytes of data.
64 bytes from peer0.org1.example.com (172.30.2.219): icmp_seq=1 ttl=64 time=0.023 ms
```
yacovm (Thu, 27 Jul 2017 21:45:51 GMT):
ok great
yacovm (Thu, 27 Jul 2017 21:46:01 GMT):
so let's try something
yacovm (Thu, 27 Jul 2017 21:46:11 GMT):
listenAddress: `peer0.org1.example.com:7051`
yacovm (Thu, 27 Jul 2017 21:46:11 GMT):
`listenAddress: peer0.org1.example.com:7051`
yacovm (Thu, 27 Jul 2017 21:46:24 GMT):
can you please change to this
yacovm (Thu, 27 Jul 2017 21:46:29 GMT):
and restart the peer?
yacovm (Thu, 27 Jul 2017 21:46:32 GMT):
and then try again?
Asara (Thu, 27 Jul 2017 21:47:26 GMT):
will do
Asara (Thu, 27 Jul 2017 21:47:39 GMT):
for some reason it takes chaincode ~15 minutes to get through packaging
Asara (Thu, 27 Jul 2017 21:47:41 GMT):
so i'll let you know how ti goes :)
yacovm (Thu, 27 Jul 2017 21:48:06 GMT):
ouch
yacovm (Thu, 27 Jul 2017 22:34:24 GMT):
@Asara you still alive?
Asara (Thu, 27 Jul 2017 22:34:52 GMT):
Yeah sorry hitting some silly snags with my scripts (unrelated to fabric)
Asara (Thu, 27 Jul 2017 22:35:00 GMT):
I'll ping ya in a few min :)
Asara (Fri, 28 Jul 2017 00:00:14 GMT):
Alright @yacovm
Asara (Fri, 28 Jul 2017 00:00:25 GMT):
so now a image came up, but not my chaincode
Asara (Fri, 28 Jul 2017 00:00:34 GMT):
```hyperledger/fabric-ccenv:x86_64-1.0.0```
Asara (Fri, 28 Jul 2017 00:01:37 GMT):
Ah it was trying to start
Asara (Fri, 28 Jul 2017 00:01:48 GMT):
```
2017-07-28 00:00:37.803 UTC [bccsp] initBCCSP -> DEBU 001 Initialize BCCSP [SW]
2017-07-28 00:00:37.804 UTC [grpc] Printf -> DEBU 002 grpc: addrConn.resetTransport failed to create client transport: connection error: desc = "transport: Error while dialing dial tcp 0.0.0.0:7051: getsockopt: connection refused"; Reconnecting to {0.0.0.0:7051
muralisr (Fri, 28 Jul 2017 00:37:06 GMT):
@Asara `0.0.0.0:7051`
muralisr (Fri, 28 Jul 2017 00:37:33 GMT):
u are startng the the peer from your host correct (not in docker ) ?
Asara (Fri, 28 Jul 2017 00:37:41 GMT):
yeap
yacovm (Fri, 28 Jul 2017 00:40:20 GMT):
try deleting the CC image
yacovm (Fri, 28 Jul 2017 00:40:30 GMT):
and re-running the CC
muralisr (Fri, 28 Jul 2017 00:41:19 GMT):
well... I'd also try starting the peer with its IP Address ...
muralisr (Fri, 28 Jul 2017 00:41:38 GMT):
but yes, try deleteing the CC image first
Asara (Fri, 28 Jul 2017 00:41:39 GMT):
For which config setting?
muralisr (Fri, 28 Jul 2017 00:41:55 GMT):
lets try what yacov suggested first ...
muralisr (Fri, 28 Jul 2017 00:42:10 GMT):
what's your platform ?
Asara (Fri, 28 Jul 2017 00:42:13 GMT):
centos 7
muralisr (Fri, 28 Jul 2017 00:42:18 GMT):
ok
yacovm (Fri, 28 Jul 2017 00:47:30 GMT):
no, @muralisr - starting the peer with the ip address will give him the original problem :)
yacovm (Fri, 28 Jul 2017 00:47:35 GMT):
he started from that
yacovm (Fri, 28 Jul 2017 00:47:44 GMT):
his problem is that his TLS cert doesn't have an IP SAN
yacovm (Fri, 28 Jul 2017 00:48:15 GMT):
and when the CC shim connects, the validation fails because it tries to connect to the ip
muralisr (Fri, 28 Jul 2017 00:48:21 GMT):
well
muralisr (Fri, 28 Jul 2017 00:48:39 GMT):
let me look first then :-)
yacovm (Fri, 28 Jul 2017 00:48:44 GMT):
ok.
yacovm (Fri, 28 Jul 2017 00:48:49 GMT):
what I am trying to make him do
yacovm (Fri, 28 Jul 2017 00:49:14 GMT):
is to make the shim use the endpoint that of peer's DNS SAN
muralisr (Fri, 28 Jul 2017 00:49:18 GMT):
`Subject: C=US, ST=California, L=San Francisco, CN=peer0.org1.example.com`
yacovm (Fri, 28 Jul 2017 00:49:18 GMT):
and this way it'll match
muralisr (Fri, 28 Jul 2017 00:49:39 GMT):
why cant we just add peer0.org1.example.com to /etc/hosts
muralisr (Fri, 28 Jul 2017 00:49:45 GMT):
and map it to the host IP
yacovm (Fri, 28 Jul 2017 00:50:00 GMT):
it's resolvable though
yacovm (Fri, 28 Jul 2017 00:50:02 GMT):
he pinged it
muralisr (Fri, 28 Jul 2017 00:50:21 GMT):
from the container ?
yacovm (Fri, 28 Jul 2017 00:50:26 GMT):
no from the host
yacovm (Fri, 28 Jul 2017 00:50:34 GMT):
but I assume they share the same DNS
muralisr (Fri, 28 Jul 2017 00:50:47 GMT):
I think its worth a try
yacovm (Fri, 28 Jul 2017 00:50:48 GMT):
anyway I'm going to sleep, back me up ;)
muralisr (Fri, 28 Jul 2017 00:50:58 GMT):
you got it
Asara (Fri, 28 Jul 2017 00:56:32 GMT):
@muralisr the DNS is added to the /etc/hosts of the host
muralisr (Fri, 28 Jul 2017 01:18:40 GMT):
what does ifconfig (ip add) say ?
jrosmith (Fri, 28 Jul 2017 01:21:58 GMT):
Has joined the channel.
Asara (Fri, 28 Jul 2017 01:22:08 GMT):
So I just redeployed the CC and it came up, but we got this following error:
jrosmith (Fri, 28 Jul 2017 01:22:12 GMT):
Error: Calling enrollment endpoint failed with error [Error: write EPROTO 139892388751168:error:1411713E:SSL routines:ssl_check_srvr_ecc_cert_and_alg:ecc cert not for signing:../deps/openssl/openssl/ssl/ssl_lib.c:2512:
139892388751168:error:14082130:SSL routines:ssl3_check_cert_and_algorithm:bad ecc cert:../deps/openssl/openssl/ssl/s3_cln
jrosmith (Fri, 28 Jul 2017 01:22:12 GMT):
```Error: Calling enrollment endpoint failed with error [Error: write EPROTO 139892388751168:error:1411713E:SSL routines:ssl_check_srvr_ecc_cert_and_alg:ecc cert not for signing:../deps/openssl/openssl/ssl/ssl_lib.c:2512:
139892388751168:error:14082130:SSL routines:ssl3_check_cert_and_algorithm:bad ecc cert:../deps/openssl/openssl/ssl/s3_cln```
jrosmith (Fri, 28 Jul 2017 01:22:36 GMT):
^^ that being the error Asara is running into
Asara (Fri, 28 Jul 2017 01:24:07 GMT):
Exactly :)
muralisr (Fri, 28 Jul 2017 01:38:04 GMT):
@Asara I thought you had `ERRO 002 Error trying to connect to local peer: x509: cannot validate certificate for 0.0.0.0 because it doesn't contain any IP SANs`
Asara (Fri, 28 Jul 2017 01:38:37 GMT):
Said above, I redeployed the chaincode and it came up
Asara (Fri, 28 Jul 2017 01:38:44 GMT):
Not sure why, didn't do anything different, but it did
Asara (Fri, 28 Jul 2017 01:39:02 GMT):
Though this seems like an error with the ca and not peer
muralisr (Fri, 28 Jul 2017 01:44:51 GMT):
I see
muralisr (Fri, 28 Jul 2017 01:44:56 GMT):
so the chaincode came up now
Asara (Fri, 28 Jul 2017 01:45:02 GMT):
Yeap
muralisr (Fri, 28 Jul 2017 01:45:17 GMT):
did you mod /etc/hosts ?
Asara (Fri, 28 Jul 2017 01:46:00 GMT):
Nope, it was always set
muralisr (Fri, 28 Jul 2017 01:46:03 GMT):
and then you get the above openssl error in the SDK ?
Asara (Fri, 28 Jul 2017 01:47:04 GMT):
Yeap
muralisr (Fri, 28 Jul 2017 01:47:29 GMT):
ok
Asara (Fri, 28 Jul 2017 01:50:33 GMT):
any idea what could be causing it?
vu3mmg (Fri, 28 Jul 2017 02:03:05 GMT):
Has joined the channel.
passkit (Fri, 28 Jul 2017 02:50:39 GMT):
Is there any waw to re-request confirmation of a block event. The issue I face is when accessing through an SDK client, I need to set a realistic timeout - currently using 30 seconds, although would like to reduce this. Occasionally, the event will come 2 or 3 seconds later. This becomes problematic, since a write has occurred to the chain, but the application sees a timeout. I guess I could try to read the record to confirm, but that requires duplicating the chain code logic in my application to be able to determine the new asset value.
passkit (Fri, 28 Jul 2017 03:08:29 GMT):
Also, any insight as to what could be causing the following error that appears occasionally in the peer logs. They occur after a transaction has been ordered and transaction is always sees fine, but I can't trace where these events with an empty MSP are originating from.
passkit (Fri, 28 Jul 2017 03:08:40 GMT):
```
2017-07-28 02:17:45.206 UTC [eventhub_producer] SendProducerBlockEvent -> DEBU 1d49 Channel [loopyloyalty]: Block event for block number [163] contains transaction id: b7717a3b9ed88749fccf37f818d9e778c4abe7f1a7ad26b104bfd000790754f9
2017-07-28 02:17:45.206 UTC [eventhub_producer] SendProducerBlockEvent -> INFO 1d4a Channel [loopyloyalty]: Sending event for block number [163]
2017-07-28 02:17:45.206 UTC [eventhub_producer] Send -> DEBU 1d4b Entry
2017-07-28 02:17:45.206 UTC [eventhub_producer] Send -> DEBU 1d4c Event processor timeout > 0
2017-07-28 02:17:45.206 UTC [eventhub_producer] Send -> DEBU 1d4d Event sent successfully
2017-07-28 02:17:45.207 UTC [eventhub_producer] Send -> DEBU 1d4e Exit
2017-07-28 02:17:45.207 UTC [eventhub_producer] SendProducerBlockEvent -> DEBU 1d4f Exit
2017-07-28 02:17:45.247 UTC [eventhub_producer] validateEventMessage -> DEBU 1d50 ValidateEventMessage starts for signed event 0xc421632b40
2017-07-28 02:17:45.247 UTC [eventhub_producer] Chat -> ERRO 1d51 Error handling message: event message must be properly signed by an identity from the same organization as the peer: [failed deserializing event creator: [Expected MSP ID PASSKIT, received ]]
2017-07-28 02:17:45.247 UTC [eventhub_producer] deRegisterHandler -> DEBU 1d52 deregistering event type: BLOCK
```
vu3mmg (Fri, 28 Jul 2017 03:56:04 GMT):
Hi,
I am facing a scenario where , peers cannot create grpc connect with orderer0.
When i tried to run nc command I am getting
nc -D orderer0 7050
nc: Permission denied
Have any one faced similar issue. I am running RHEL 7.3
vu3mmg (Fri, 28 Jul 2017 03:56:23 GMT):
i am able to run the system in ubuntu
vu3mmg (Fri, 28 Jul 2017 03:56:36 GMT):
any special permissions have to be given to docker bridge
vu3mmg (Fri, 28 Jul 2017 03:56:37 GMT):
?
SyneBlockChainTeam (Fri, 28 Jul 2017 14:31:23 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=F5NyeQJ7tB4C7o9Aq)
SyneBlockChainTeam (Fri, 28 Jul 2017 14:31:43 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=3n8BH7pPoy49d3qFA)
In SDK Node, has anyone tried with 1 Organization with More then 3 Peers
OR with 2 Organizations each with 3 Peers.
We are looking forward for a reply.
Thanks
chenxuan (Sat, 29 Jul 2017 14:15:15 GMT):
hi every one
chenxuan (Sat, 29 Jul 2017 14:15:24 GMT):
@here
chenxuan (Sat, 29 Jul 2017 14:15:25 GMT):
i see the protos/peer/proposal.proto
it describes the endorsement of the process
but it contains two process
the first one is /*
The flow to get a generic transaction approved goes as follows:
the second one is
/*
The flow to get a CHAINCODE transaction approved goes as follows:
and when i see the first one
it contains two message
message SignedProposal
message Proposal
the proposal_bytes defined in the message SignedProposal
it contains message Proposal
the Proposal contains header,payload,extension
the header is Header defined in the common.proto
?
the payload is
what
and the extension
Eman0 (Mon, 31 Jul 2017 14:44:26 GMT):
Has joined the channel.
Asara (Mon, 31 Jul 2017 15:25:16 GMT):
Quick question, when chaincode is deployed to a peer, does it also install it to the other peers in the channel?
yacovm (Mon, 31 Jul 2017 15:32:36 GMT):
no
Asara (Mon, 31 Jul 2017 15:33:40 GMT):
So chaincode needs to be installed on every peer manually? Regardless of if they belong to the same channel?
Asara (Mon, 31 Jul 2017 16:01:39 GMT):
ah i understand, instantiate vs install
Asara (Mon, 31 Jul 2017 16:01:40 GMT):
:)
yacovm (Mon, 31 Jul 2017 16:12:26 GMT):
exactly
passkit (Mon, 31 Jul 2017 16:49:55 GMT):
My current chaincode version is 30. I just queried but received the following response `Error chaincode is being launched: ll2-cc:28`
passkit (Mon, 31 Jul 2017 16:49:55 GMT):
My current chaincode version is 29. I just queried but received the following response `Error chaincode is being launched: ll2-cc:28`
passkit (Mon, 31 Jul 2017 16:51:12 GMT):
Why would it launch a previous version of the chain code?
passkit (Mon, 31 Jul 2017 16:51:28 GMT):
`CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
75152f3aeb3a passkit-peer-aws-us-east-2a-ll2-cc-28 "chaincode -peer.a..." 3 minutes ago Up 3 minutes passkit-peer-aws-us-east-2a-ll2-cc-28
8aff110c4844 passkit-peer-aws-us-east-2a-ll2-cc-29 "chaincode -peer.a..." About an hour ago Up About an hour `
yacovm (Mon, 31 Jul 2017 16:54:15 GMT):
@passkit
yacovm (Mon, 31 Jul 2017 16:54:24 GMT):
did you have a premature - execution in the error?
yacovm (Mon, 31 Jul 2017 16:54:24 GMT):
did you have a premature execution in the error?
passkit (Mon, 31 Jul 2017 16:57:06 GMT):
@yacovm yes - I think so. The result was not returned, only the error that the code was being launched.
yacovm (Mon, 31 Jul 2017 16:57:28 GMT):
can you check?
passkit (Mon, 31 Jul 2017 16:57:34 GMT):
So - the previous version was due to a channel error - (new code, not installed on that channel)
passkit (Mon, 31 Jul 2017 17:00:35 GMT):
```
2017-07-31 16:46:31.110 UTC [chaincode] notify -> DEBU 253b notifying Txid:7154096ca10d8763a5228a4d4ed704464673947cfb52017dd351484a5f6b54eb
2017-07-31 16:46:31.110 UTC [chaincode] Execute -> DEBU 253c Exit
2017-07-31 16:46:31.110 UTC [chaincode] Launch -> ERRO 253d launchAndWaitForRegister failed Error chaincode is being launched: ll2-cc:28
2017-07-31 16:46:31.110 UTC [chaincode] ExecuteChaincode -> ERRO 253e Error executing chaincode: Error chaincode is being launched: ll2-cc:28
2017-07-31 16:46:31.110 UTC [endorser] callChaincode -> DEBU 253f Exit
2017-07-31 16:46:31.110 UTC [endorser] simulateProposal -> ERRO 2540 failed to invoke chaincode name:"ll2-cc" on transaction 7154096ca10d8763a5228a4d4ed704464673947cfb52017dd351484a5f6b54eb, error: Error executing chaincode: Error chaincode is being launched: ll2-cc:28
```
passkit (Mon, 31 Jul 2017 17:01:54 GMT):
My deployment uses stateless containers with persistent storage - so the chaincode is always available in the filesystem, but there may be cases where the image is not - such as this case. How to ensure that in such cases the peer waits for the cc container to launch?
yacovm (Mon, 31 Jul 2017 17:03:01 GMT):
the peer builds the image itself
yacovm (Mon, 31 Jul 2017 17:03:03 GMT):
on demand
yacovm (Mon, 31 Jul 2017 17:04:22 GMT):
Nick, I can't find the error string in the code... which commit hash are you working on?
passkit (Mon, 31 Jul 2017 17:18:09 GMT):
This should be v1.0.0
yacovm (Mon, 31 Jul 2017 17:22:07 GMT):
yes you're right https://github.com/hyperledger/fabric/blob/d9c320297bd2a4eff2eb253ce84dc431ef860972/core/chaincode/chaincode_support.go#L411
yacovm (Mon, 31 Jul 2017 17:23:00 GMT):
so can you give more details on your env?
what happened to the containers of version 28? of 29? etc.
what you did, what is the flow, etc.
muralisr (Mon, 31 Jul 2017 18:06:14 GMT):
@passkit one possibility is instantiate waiting on a timeout for regtration to kick in ... any other invoke you send meanwhile will get the premature error
muralisr (Mon, 31 Jul 2017 18:07:08 GMT):
if your chaincode never got back (say it crahsed) you are going to waitout the timeout
passkit (Mon, 31 Jul 2017 18:09:08 GMT):
So we currently have issues with the go SDK and event broadcasts not being received. The peers function perfectly and the event is broadcast, but the SDK is not hearing it and timing out.
passkit (Mon, 31 Jul 2017 18:09:39 GMT):
So started debugging on a different channel, but forgot that I had not updated that channel from 28 to 29.
passkit (Mon, 31 Jul 2017 18:09:55 GMT):
So that explains why it launched an older version.
passkit (Mon, 31 Jul 2017 18:11:37 GMT):
Then to Yacov's point, it is possible that it was a second invoke that triggered this error. So I'm ok with this as it is something that could occur if a peer host is restarted and does not contain an image, and therefore I should deal with this scenario in my code.
passkit (Mon, 31 Jul 2017 18:12:25 GMT):
The initial thing that threw me was why an older version was being launched, but I now understand how that happened.
Asara (Mon, 31 Jul 2017 20:19:01 GMT):
Hey all/@greg.haskins, my chaincode packaging takes forever, is there a way to prepackage chaincodes so I can just deploy the 'compiled?' chaincode instead of having to wait 15ish minutes each time
muralisr (Mon, 31 Jul 2017 21:15:53 GMT):
@Asara `peer chaincode package...` command can be used to package it once
muralisr (Mon, 31 Jul 2017 21:16:17 GMT):
and then you install the packaged file simply as `peer chaincode install
greg.haskins (Tue, 01 Aug 2017 02:09:34 GMT):
@Asara in addition to what Murali said, also sounds a bit odd for it to take 15minutes
gauthampamu (Tue, 01 Aug 2017 02:40:59 GMT):
I have question on chaincode upgrade, when you upgrade the chaincode older Docker containers are not terminated. Why ? Thanks in advance
gauthampamu (Tue, 01 Aug 2017 02:42:11 GMT):
@muralisr Is it recommended to use the command line tool to package and install the chaincode or should we use the API to install the chaincode file.
gauthampamu (Tue, 01 Aug 2017 02:43:04 GMT):
@muralisr For production environment should we use the peer chaincode tool or develop Nodejs program to install.
muralisr (Tue, 01 Aug 2017 03:18:02 GMT):
@gauthampamu note that chaincode can run against multiple ledgers. So CC.v1 is running and is instantiated on channel1 and channel2
muralisr (Tue, 01 Aug 2017 03:18:02 GMT):
@gauthampamu note that chaincode can run against multiple ledgers. So CC.v1 is running and is instantiated on channel1 and channel2. CC.v2 installed and instantiated on channel2 ... CC.v1 can still serve requests for channel1
gauthampamu (Tue, 01 Aug 2017 03:25:01 GMT):
@muralisr Thanks for the response. Let say if you just have one channel, how does it work ? Will it create separate docker container or restart the docker container ?
gauthampamu (Tue, 01 Aug 2017 03:33:02 GMT):
How does the fabric authenticate the requests submitted by the application SDK. Does the endorsing peer check the signing identity ? How does it verify the identity of the request ?
passkit (Tue, 01 Aug 2017 03:50:04 GMT):
I'm not sure I ever got an answer to a previous question of whether or not it is possible to query the result of a transaction by txID. In my case, I am using the Fabric Go SDK and there are reliability issues that are preventing my clients from receiving the event broadcast. The peers are functioning perfectly and broadcasting the event as expected, but the SDK intermittently has trouble receiving it. In these cases, I would like to be able to manually pull this broadcast data by txId to determine if the transaction has actually been committed.
yacovm (Tue, 01 Aug 2017 05:36:29 GMT):
@passkit use a qscc query
yacovm (Tue, 01 Aug 2017 05:36:53 GMT):
Perhaps you can access the validated ledger
yacovm (Tue, 01 Aug 2017 05:37:14 GMT):
I need to take a look at the code though, when i get to the office will do that
passkit (Tue, 01 Aug 2017 05:37:54 GMT):
Cool, thanks
yacovm (Tue, 01 Aug 2017 05:55:14 GMT):
`GetTransactionByID` is what you need in QSCC
Asara (Tue, 01 Aug 2017 13:38:46 GMT):
@muralisr @greg.haskins Hey thanks! Is there a way to do that via the SDK?
Asara (Tue, 01 Aug 2017 13:39:21 GMT):
@greg.haskins I agree, and I'm not sure why it is taking so long. But it is always stalled on packaging the chaincode. But again I've only done it via the node-sdk
muralisr (Tue, 01 Aug 2017 13:41:07 GMT):
@Asara if you are stalled on packaging it in node SDK, I'd try installing from CLI first. If that doesn't stall, then it may be an issue with the SDK and worth looking into
Asara (Tue, 01 Aug 2017 13:42:13 GMT):
Alright cool. I'll try packaging/deploying it via the `peer` cli first
Asara (Tue, 01 Aug 2017 15:02:33 GMT):
Are docker instances for the chaincode supposed to start on `peer` servers where the chaincode is installed
gauthampamu (Tue, 01 Aug 2017 15:51:45 GMT):
@Asara It will not start the peer server when you install the chaincode. You will need peers to be up and running to send the request to install the chaincode.
Asara (Tue, 01 Aug 2017 15:53:32 GMT):
@gauthampamu My scenario is as such:
1. peer1 installs and then instantiates chaincode
1.5 peer1's docker instance containing the chaincode comes up
2. peer2 goes to install chaincode
3. peer2 returns a 200, but the docker instance doesn't come up
gauthampamu (Tue, 01 Aug 2017 15:56:28 GMT):
@Asara Have you tried to install the chaincode on both peers and then instantiate the chaincode on the channel
gauthampamu (Tue, 01 Aug 2017 15:56:40 GMT):
Also did both peers join the channel
Asara (Tue, 01 Aug 2017 15:56:49 GMT):
Nope but I can. I am following: http://hyperledger-fabric.readthedocs.io/en/latest/install_instantiate.html
Asara (Tue, 01 Aug 2017 15:56:55 GMT):
for the most part (doing it via the SDK)
Asara (Tue, 01 Aug 2017 15:57:00 GMT):
Yes both peers joined the channel
silliman (Tue, 01 Aug 2017 15:59:09 GMT):
@Asara your scenario is working as designed. Installing chaincode simply places the chaincode binary on the peer's file system. It is a peer-level operation in that it only needs to be done once per peer. When you instantiated the chaincode on peer1, that spins up a docker chaincode container on peer1. Assuming this has all gone well, you will not get a docker chaincode container on peer2 until you target a transactionproposal to peer2.
Asara (Tue, 01 Aug 2017 15:59:52 GMT):
@silliman Alright cool. I'll send a txn to peer2 and see what happens
gauthampamu (Tue, 01 Aug 2017 16:04:32 GMT):
@Asara Where is the docker compose for this tutorials.
gauthampamu (Tue, 01 Aug 2017 16:04:33 GMT):
docker-2peer.yml
Asara (Tue, 01 Aug 2017 16:05:07 GMT):
I'm using binaries, not docker
Eman0 (Tue, 01 Aug 2017 22:55:43 GMT):
Hi, I am trying to decode the callers' certificates in my chaincode. All the callers’ certificates were decoded successfully except for one. I printed the certificate out and decode it using OpenSSL and got a proper certificate content. Any idea why would the chaincode fail to decode this one only?
C0rWin (Tue, 01 Aug 2017 23:31:44 GMT):
@Eman0 can you provide the code? what error do you see, e.g. how do you indicate the problem with this special certificate? how did you created those certificates?
Eman0 (Tue, 01 Aug 2017 23:54:28 GMT):
Message Attachments
Eman0 (Tue, 01 Aug 2017 23:54:48 GMT):
@C0rWin
C0rWin (Tue, 01 Aug 2017 23:55:26 GMT):
can you view logs of the chaincode to see the error?
C0rWin (Tue, 01 Aug 2017 23:57:04 GMT):
btw, have you tested this code outside the chaincode scope? e.g. unit test or just dropping a few lines in some main package?
Eman0 (Tue, 01 Aug 2017 23:58:15 GMT):
I will take few minutes to run the network up again. No, I have not.
C0rWin (Wed, 02 Aug 2017 00:01:22 GMT):
@Eman0 IMO it's worth doing UT to see whenever it's something inherent in fabric or something not related to chaincode
Eman0 (Wed, 02 Aug 2017 00:07:16 GMT):
@C0rWin I just viewed the logs. No errors. I will but it is a bit strange because it works fine for all the other certificates
Glen (Wed, 02 Aug 2017 07:27:04 GMT):
Hi, who can explain what endorse does on earth and where is the relative code? thanks!
dave.enyeart (Wed, 02 Aug 2017 15:22:10 GMT):
@Glen When you instantiate a chaincode you specify an endorsement policy, that is, how many and which organizations must endorse a transaction. Endorsement essentially means authorize/execute/sign a proposal request. It sounds like you would benefit from the the Transaction Flow documentation: https://hyperledger-fabric.readthedocs.io/en/latest/txflow.html
dave.enyeart (Wed, 02 Aug 2017 15:22:54 GMT):
In terms of the code - https://github.com/hyperledger/fabric/blob/release/core/endorser/endorser.go
Asara (Wed, 02 Aug 2017 18:21:20 GMT):
@silliman Hey sorry for not responding earlier. Sending a txn to peer2 brought up the instance. Thanks for the input :)
rmohta (Wed, 02 Aug 2017 21:05:16 GMT):
Upgrading from alpha-2 to 1.0 release, unable to install my cc. Can someone please help?
rmohta (Wed, 02 Aug 2017 21:06:18 GMT):
```root@d2fc341504a5:/opt/gopath/src/github.com/hyperledger/fabric/peer/scripts# ./03-install-cc.sh
Will try to install netpayment1cc-1.0
CORE_PEER_GOSSIP_ORGLEADER=false
CORE_PEER_LOCALMSPID=Org1MSP
CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
CORE_PEER_TLS_ENABLED=false
CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.phx.xyz.com/users/Admin@org1.phx.xyz.com/msp
CORE_PEER_ID=cli
CORE_LOGGING_LEVEL=DEBUG
CORE_PEER_ADDRESS=10.16.125.73:7051
CORE_NEXT=true
2017-08-02 20:53:30.211 UTC [msp] GetLocalMSP -> DEBU 001 Returning existing local MSP
2017-08-02 20:53:30.212 UTC [msp] GetDefaultSigningIdentity -> DEBU 002 Obtaining default signing identity
2017-08-02 20:53:30.212 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 003 Using default escc
2017-08-02 20:53:30.213 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 004 Using default vscc
2017-08-02 20:53:30.281 UTC [golang-platform] getCodeFromFS -> DEBU 005 getCodeFromFS stash.xyz.com/netpayment3
2017-08-02 20:53:30.463 UTC [golang-platform] func1 -> DEBU 006 Discarding GOROOT package bytes
2017-08-02 20:53:30.463 UTC [golang-platform] func1 -> DEBU 007 Discarding GOROOT package encoding/json
2017-08-02 20:53:30.464 UTC [golang-platform] func1 -> DEBU 008 Discarding GOROOT package errors
2017-08-02 20:53:30.464 UTC [golang-platform] func1 -> DEBU 009 Discarding GOROOT package fmt
2017-08-02 20:53:30.464 UTC [golang-platform] func1 -> DEBU 00a Accepting import: github.com/hyperledger/fabric/common/flogging
2017-08-02 20:53:30.464 UTC [golang-platform] func1 -> DEBU 00b Discarding provided package github.com/hyperledger/fabric/core/chaincode/shim
2017-08-02 20:53:30.465 UTC [golang-platform] func1 -> DEBU 00c Discarding provided package github.com/hyperledger/fabric/protos/peer
2017-08-02 20:53:30.465 UTC [golang-platform] func1 -> DEBU 00d Discarding GOROOT package strings
2017-08-02 20:53:30.465 UTC [golang-platform] func1 -> DEBU 00e Discarding GOROOT package time
Error: Error getting chaincode code chaincode: Error getting chaincode package bytes: Error obtaining dependencies for github.com/hyperledger/fabric/common/flogging:
rmohta (Wed, 02 Aug 2017 21:07:35 GMT):
Under GOROOT, I can see the package at `/opt/go/hyperledger/fabric/common/flogging` and not `/opt/go/src/github.com/hyperledger/fabric/common/flogging` as seen in the above error.
scottz (Wed, 02 Aug 2017 21:43:19 GMT):
Scenario: instantiation on channel1 of chaincode named "mycc" takes 9 minutes to create the container. However, we observe that invokes on channel1 fail. We think this is because it takes longer than core.yaml chaincode:startuptimeout value of 300s, and longer than the application waits. BUT notice: if we wait 10 minutes and then instantiate same exact chaincode "mycc" on channel2, it reuses the mycc chaincode container as expected and all invokes are successful immediately on channel2. This proves the "mycc" container was correctly created as a result of the first request, and the request was not cancelled after the alloted 5 minutes when the peer timed out. So... *what is the benefit of the design for using startuptimeout*? All it does is allow the fabric peer to abandon hope. If the peer had waited statelessly and asynchronously for the chaincode container to be established, then channel1 instantiation completion would have been recoreded and invokes would work too. (Alternatively, when it gave up, should it have cancelled the attempt to create the container?)
scottz (Wed, 02 Aug 2017 21:44:06 GMT):
@muralisr @suryalanka ^^^
muralisr (Wed, 02 Aug 2017 22:16:40 GMT):
@scottz @suryalanka on the failure scenario do you see `Timeout expired while starting chaincode` error ? And if in debug mode, `stopping due to error while launching` ?
muralisr (Wed, 02 Aug 2017 22:19:02 GMT):
I'd expect you see those....in which case, I'd also expect the chaincode to be cleaned up and removed after the timeout. The second successful one likely got created by the second request (as opposed to latching on to a lazy chaincode startup from the first)
muralisr (Wed, 02 Aug 2017 22:27:34 GMT):
@rmohta you may want to vendor all dependencies (including shim) within the chaincode .... https://www.youtube.com/watch?v=-mlUaJbFHcM may help....
nate94305 (Thu, 03 Aug 2017 01:01:44 GMT):
Has joined the channel.
nate94305 (Thu, 03 Aug 2017 01:03:48 GMT):
Hi, I have a question regarding endorsing and committing. From which one are the chaincode docker's logs, endorser's chaincode simulation or peer's commit with chaincode?
muralisr (Thu, 03 Aug 2017 01:22:30 GMT):
@nate94305 , endorser's chaincode simulation
nate94305 (Thu, 03 Aug 2017 01:23:15 GMT):
@muralisr thanks.
nate94305 (Thu, 03 Aug 2017 01:26:42 GMT):
With high volume trading, lots of transactions simulated okay during endorsement may fail due to the readset difference between endorsement time and commitment time, such as global sequence counter
nate94305 (Thu, 03 Aug 2017 01:26:42 GMT):
With high volume trading, lots of transactions simulated okay during endorsement may fail due to the readset difference between endorsement time and commitment time, such as global sequence counter. Any solution for this?
nate94305 (Thu, 03 Aug 2017 01:26:42 GMT):
With high volume trading, lots of transactions simulated okay during endorsement may fail during commitment due to the readset difference between endorsement time and commitment time, such as global sequence counter. Any solution for this?
suryalanka (Thu, 03 Aug 2017 02:14:56 GMT):
@muralisr No, haven't seen timeouts in the peer logs
suryalanka (Thu, 03 Aug 2017 02:16:13 GMT):
the chaincode container is up and running without any errors
muralisr (Thu, 03 Aug 2017 02:23:07 GMT):
@suryalanka I meant timeout after the first failed instantiate... not the second successful one
muralisr (Thu, 03 Aug 2017 02:23:24 GMT):
let's check tomorrow
kmohanar (Thu, 03 Aug 2017 10:40:57 GMT):
Has joined the channel.
Eric.Bui (Thu, 03 Aug 2017 16:23:21 GMT):
Has joined the channel.
silliman (Thu, 03 Aug 2017 21:10:24 GMT):
If a client sends a transaction proposal to more than one endorsing peer, after it receives all the responses, does the client send all of the R/W sets in the endorsed transaction it sends to the orderer? Or just a single R/W set.
muralisr (Thu, 03 Aug 2017 22:10:10 GMT):
just from one of the endorsing peers @silliman
pd93 (Fri, 04 Aug 2017 09:13:15 GMT):
Getting this: `identity 0 does not satisfy principal: The identity is a member of a different MSP (expected ordererOrg0, got peerOrg0)` from my orderer logs, anyone know what does this indicates?
pd93 (Fri, 04 Aug 2017 09:13:15 GMT):
Getting this: `identity 0 does not satisfy principal: The identity is a member of a different MSP (expected ordererOrg0, got peerOrg0)` from my orderer logs, does anyone know what this indicates?
mastersingh24 (Fri, 04 Aug 2017 10:02:43 GMT):
@song
(https://chat.hyperledger.org/channel/general?msg=jTBPNKE9zoDBCcffJ)
song (Fri, 04 Aug 2017 10:02:43 GMT):
Has joined the channel.
mastersingh24 (Fri, 04 Aug 2017 10:03:38 GMT):
@pd93 - What transactions are you submitting to the orderer?
pd93 (Fri, 04 Aug 2017 10:05:34 GMT):
@mastersingh24 I haven't submitted anything manually. I'm just brining up a network with behave and I noticed those in the logs. I get a similar error from the eventhub when I try and connect via the node sdk: `{ Error: event message must be properly signed by an identity from the same organization as the peer: [failed deserializing event creator: [Expected MSP ID peerOrg0, received ordererOrg0]]`
mastersingh24 (Fri, 04 Aug 2017 10:19:26 GMT):
@pd93 - It looks like somehow the crypto material being used has been reversed
mastersingh24 (Fri, 04 Aug 2017 10:19:58 GMT):
i.e. Your node sdk app is using creds from the orderer org
pd93 (Fri, 04 Aug 2017 10:25:12 GMT):
Hmm.. okay. I'll double check everything. I'm really not sure how I've done this :')
jimthematrix (Fri, 04 Aug 2017 18:08:44 GMT):
@greg.haskins getting the following error from running 1.0.1 locally:
```error: [client-utils.js]: sendPeersProposal - Promise is rejected: Error: Error starting container: Failed to generate platform-specific docker build: Failed to pull hyperledger/fabric-ccenv:x86_64-1.0.1-snapshot-0a9951b9: API error (404): {"message":"manifest for hyperledger/fabric-ccenv:x86_64-1.0.1-snapshot-0a9951b9 not found"}```
jimthematrix (Fri, 04 Aug 2017 18:09:20 GMT):
what's strange is that the docker's label gives a different snapshot value:
```"Labels": {
"com.docker.compose.config-hash": "e54b6f953cca7f9b35763265ff7b3ecbbcfb71c5c8778ad22e38f2edf88ff53b",
"com.docker.compose.container-number": "1",
"com.docker.compose.oneoff": "False",
"com.docker.compose.project": "fixtures",
"com.docker.compose.service": "peer0.org1.example.com",
"com.docker.compose.version": "1.15.0",
"org.hyperledger.fabric.base.version": "0.3.1",
"org.hyperledger.fabric.version": "1.0.1-snapshot-62fd2682"
}```
jimthematrix (Fri, 04 Aug 2017 18:10:58 GMT):
and the label is consistent with the ccenv image tag: `x86_64-1.0.1-snapshot-62fd2682`
jimthematrix (Fri, 04 Aug 2017 18:11:25 GMT):
I'm a little puzzled where did the chaincode support code get the `x86_64-1.0.1-snapshot-0a9951b9` tag value
jimthematrix (Fri, 04 Aug 2017 18:18:03 GMT):
i'm going to try first do a make clean
jimthematrix (Fri, 04 Aug 2017 18:40:46 GMT):
looks like the files build/docker/bin/peer(orderer) are not being refreshed during `make docker` (even with `make -B docker`), after `make clean` first that deletes them, and rebuild, they are now back in sync: build number inside the binaries are consistent with the docker tag
eacoeytaux (Fri, 04 Aug 2017 19:54:33 GMT):
Has joined the channel.
greg.haskins (Sun, 06 Aug 2017 02:05:17 GMT):
@jimthematrix that problem is consistent with having your builds out of sync
greg.haskins (Sun, 06 Aug 2017 02:05:38 GMT):
as you discovered, simply rebuilding them all should fix it
greg.haskins (Sun, 06 Aug 2017 02:06:23 GMT):
for background, the last number is generated from the commit-sha that was HEAD at the time you did the build
greg.haskins (Sun, 06 Aug 2017 02:06:55 GMT):
so, if you, for example, pull, build the world, commit something, build just one component...the shas would differ
greg.haskins (Sun, 06 Aug 2017 02:08:05 GMT):
@jimthematrix btw: with all the rampant at-here (ab)use, I am missing lots of pings, so just DM me if you have a problem to get my attention
jimthematrix (Sun, 06 Aug 2017 02:20:23 GMT):
thanks @greg.haskins for confirming that. will keep DM in mind ;-)
greg.haskins (Sun, 06 Aug 2017 02:29:01 GMT):
anytime...
greg.haskins (Sun, 06 Aug 2017 02:29:30 GMT):
btw: the last part of the puzzle I should mention: the "0a9951b9" reference was coming from the peer. not the ccenv
greg.haskins (Sun, 06 Aug 2017 02:29:53 GMT):
basically, by default, the peer will attempt to use a ccenv with an identical tag
greg.haskins (Sun, 06 Aug 2017 02:30:22 GMT):
so fabric-peer:x86_64-1.0.1-snapshot-0a9951b9 will expect fabric-ccenv:x86_64-1.0.1-snapshot-0a9951b9
greg.haskins (Sun, 06 Aug 2017 02:31:58 GMT):
this is controlled here: https://github.com/hyperledger/fabric/blob/3abe144d50a6edb367ef978f75387f515b95dc1f/sampleconfig/core.yaml#L329
greg.haskins (Sun, 06 Aug 2017 02:32:36 GMT):
basically, the peer offers a templating engine...it will translate $(PROJECT_VERSION) to be the same as the peers
greg.haskins (Sun, 06 Aug 2017 02:32:59 GMT):
you can, of course, override it to be something else, but by default it will try to match it
greg.haskins (Sun, 06 Aug 2017 02:33:05 GMT):
matching it is typically what you want
greg.haskins (Sun, 06 Aug 2017 02:34:09 GMT):
I see the problem you describe all the time when I rebuild only the peer but not the ccenv _AND_ I happened to have moved to a new gitsha in the interim
greg.haskins (Sun, 06 Aug 2017 02:34:32 GMT):
lesson to be learned here is be really careful, because its the case where you _havent_ moved the gitsha that is the most dangerous
greg.haskins (Sun, 06 Aug 2017 02:34:47 GMT):
(you may be using mismatched peer/ccenv and not even realize it)
jimthematrix (Sun, 06 Aug 2017 19:30:03 GMT):
thanks for the full explanation @greg.haskins , that's exactly what happened. now thinking it a bit more, I had thought that "make docker" would have rebuilt the peer binary in /build/docker/bin so that'll resync the binary running inside docker with the tag on the docker images, but that's apparently not happening. isn't that supposed to be that way: /build/docker/bin gets rebuilt along with docker images themselves?
frbrkoala (Tue, 08 Aug 2017 00:18:40 GMT):
Hi guys. Just a quick question. Is my understanding correct, that we can't use more then one Kafka-based ordering clusters per channel? In such case in the large scaled Fabric-based blockchain network with one large channel an "ordering service" (a combination of ordering peers with Kafka brokers /zookeepers) is becoming a central part of the architecture. Is this correct?
Eman0 (Tue, 08 Aug 2017 00:35:33 GMT):
What happens if a peer is the only endorser for a chaincode and it creates a fake transaction proposal, endorses it and broadcasts it. From what I understand, committing peers only verify that the endorsement is valid and that means other peers will commit the transaction. Is that correct?
frbrkoala (Tue, 08 Aug 2017 00:40:55 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=oxYtzQNpitodmDsoW) @Eman0 To me it looks like you are right. That's why the Endorsement policies are important. If we don't trust one single peer in the network, we should better create a policy that will enforce validation with a number of peers to make sure peers will double check each other.
Eman0 (Tue, 08 Aug 2017 00:53:23 GMT):
@frbrkoala Thank you. That's what I thought too.
Eman0 (Tue, 08 Aug 2017 01:08:36 GMT):
Sorry, another question. How does the client know the set of endorsers for any chaincode ?
dave.enyeart (Tue, 08 Aug 2017 10:04:46 GMT):
The client application is authored together with the chaincode. The client application must have knowledge of the endorsement policies and gather enough endorsements.
dave.enyeart (Tue, 08 Aug 2017 10:04:46 GMT):
@Eman0 The client application is authored together with the chaincode. The client application must have knowledge of the endorsement policies and gather enough endorsements.
dave.enyeart (Tue, 08 Aug 2017 10:04:46 GMT):
@Eman0 The client application is authored together with the chaincode. The client application must have knowledge of the endorsement policies ahead of time, and have logic to gather enough endorsements.
Eman0 (Tue, 08 Aug 2017 16:59:53 GMT):
@dave.enyeart Thank you, that makes sense. Incase of multiple endorsers, is it possible to test that through CLI? or is it only able to interact with one endorser at a time?
dave.enyeart (Tue, 08 Aug 2017 17:01:18 GMT):
CLI only interacts with a single endorser, it is meant for initial trial/demo only. You will need to use the client SDK to send to multiple endorsers.
Selvam_Annamalai (Wed, 09 Aug 2017 09:21:11 GMT):
Has joined the channel.
greg.haskins (Wed, 09 Aug 2017 13:48:39 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=v5AwZzejvfjqrwWPz) @dave.enyeart I am of the opinion that needs to change in a future release though
greg.haskins (Wed, 09 Aug 2017 13:48:51 GMT):
not sure everyone agrees, but this seems logical to me
greg.haskins (Wed, 09 Aug 2017 13:49:38 GMT):
e.g. a client should only really need knowledge of a) a small set of seed peers it trusts (presumably its own) and b) a set of 1 or more chaincodes it wants to interact with
greg.haskins (Wed, 09 Aug 2017 13:50:01 GMT):
everything else (endorsement policies, endorsement members, orderer(s), etc, should be in-band discoverable
greg.haskins (Wed, 09 Aug 2017 13:52:03 GMT):
to address threat vectors against the discoverable data, it should have strong provenance mechanisms back to the channel/chaincode instantiate activity
greg.haskins (Wed, 09 Aug 2017 13:52:45 GMT):
e.g. the signature of the instantiate transaction which includes the endorsement policy/group should be conveyed
greg.haskins (Wed, 09 Aug 2017 13:53:43 GMT):
The v1.0 configuration mechanisms are way to fragile to be considered practical for the long term
greg.haskins (Wed, 09 Aug 2017 13:53:43 GMT):
The v1.0 configuration mechanisms are way too fragile to be considered practical for the long term
Selvam_Annamalai (Thu, 10 Aug 2017 10:04:11 GMT):
I have modified the first network
• Generated certificates and channel artifacts in the first machine with configtx and crypto-config yaml files (which contains both the org details,the 4 nodes & one Orderer) by running the command ./byfn.sh –m generate
• Updated docker-compose-cli, docker-compose-couch, docker-compose-e2e-template and docker-compose-base yaml files to contain first org, 2 peer nodes and 1 Orderer.
• Started the network (First Org with 2 nodes and Orderer) in the first machine by running the command ./byfn.sh –m up
• Copied the generated certificates and the channel artifacts in to the second machine
• Updated docker-compose-cli, docker-compose-couch, docker-compose-e2e-template and docker-compose-base yaml files to contain second org, 2 peer nodes and without Orderer.
• Did not call CreateChannel function in script.sh file. Commented out.
• Started the network (Second Org with 2 nodes without Orderer) in the second machine by running the command ./byfn.sh –m up
• Got the exception “Error: genesis block file not found open mychannel.block: no such file or directory” during Channel Join Operation.
Can you please tell me how to resolve this issue?
qsmen (Fri, 11 Aug 2017 06:59:49 GMT):
Has joined the channel.
SotirisAlfonsos (Fri, 11 Aug 2017 09:52:50 GMT):
Hello. I was wondering, where can i find the code where the peer sends the response to the client after endorsement, and the code where the peer receives the new transaction proposal from the client?
Eman0 (Sat, 12 Aug 2017 17:57:22 GMT):
@SotirisAlfonsos https://github.com/hyperledger/fabric/blob/release/core/endorser/endorser.go
ydk210999 (Sun, 13 Aug 2017 07:23:22 GMT):
Has joined the channel.
Glen (Mon, 14 Aug 2017 01:44:35 GMT):
Hello, How does endorsement validate a transaction, can it prevent a malicious client from doing harm to the BC network?
yacovm (Mon, 14 Aug 2017 06:56:38 GMT):
yes
yacovm (Mon, 14 Aug 2017 06:56:50 GMT):
at endorsement time - the access control policies are checked
ajp (Mon, 14 Aug 2017 15:24:59 GMT):
Has joined the channel.
Glen (Mon, 14 Aug 2017 15:27:24 GMT):
ok
Eman0 (Mon, 14 Aug 2017 17:19:33 GMT):
Does the broadcasted endorsement contain the client signature?
yacovm (Mon, 14 Aug 2017 17:26:53 GMT):
It contains the signed proosal
yacovm (Mon, 14 Aug 2017 17:26:56 GMT):
So yes
Eman0 (Mon, 14 Aug 2017 17:31:45 GMT):
ermm do committing peers revalidate the client signature? or they just verify the endorsers' signatures?
yacovm (Mon, 14 Aug 2017 17:48:23 GMT):
the latter - but in the future they would probably do also the former ( @adc please correct me if that's wrong)
tallharish (Tue, 15 Aug 2017 11:53:49 GMT):
Has joined the channel.
tallharish (Tue, 15 Aug 2017 12:25:56 GMT):
I am developing a chaincode and testing it by modifying script.sh in e2e_cli example with the default network setup (Org1,Org2, 2 members each). If I instantiate chaincode using peer0.Org1, I am able to invoke transactions on it. But when I invoke transactions on peer0.Org2 after instantiating CC on peer0.Org1, I get the following error on peer0.org2. The same behavior other way round as well.
```
2017-08-14 *12:06:27.826 UTC* [chaincode] processStream -> DEBU 645 [8bb78db8]sending state message TRANSACTION
2017-08-14 *12:06:27.922 UTC* [chaincode] processStream -> ERRO 646 Error handling chaincode support stream: rpc error: code = Canceled desc = context canceled
2017-08-14 12:06:27.925 UTC [chaincode] deregisterHandler -> DEBU 647 Deregister handler: mycc:1.0
2017-08-14 12:06:27.925 UTC [chaincode] deregisterHandler -> DEBU 648 Deregistered handler with key: mycc:1.0
(after a while...)
2017-08-14 *12:06:57.829 UTC* [chaincode] Execute -> DEBU 649 Exit
2017-08-14 12:06:57.829 UTC [chaincode] ExecuteChaincode -> ERRO 64a Error executing chaincode: Failed to execute transaction (Timeout expired while executing transaction)
```
On the orderer, I see the following message corresponding to same timestamp
[orderer/common/broadcast] Handle -> WARN a14 Error reading from stream: rpc error: code = Canceled desc = context canceled
My e2e_cli works fine with the default chaincode examples. What could be going wrong with my chaincode? how do I debug? Thanks
tallharish (Tue, 15 Aug 2017 12:25:56 GMT):
I am developing a chaincode and testing it by modifying script.sh in e2e_cli example with the default network setup (Org1,Org2, 2 members each). If I instantiate chaincode using peer0.Org1, I am able to invoke transactions on it. But when I invoke transactions on peer0.Org2 after instantiating CC on peer0.Org1, I get the following error on peer0.org2. The same behavior other way round as well.
```
2017-08-14 *12:06:27.826 UTC* [chaincode] processStream -> DEBU 645 [8bb78db8]sending state message TRANSACTION
2017-08-14 *12:06:27.922 UTC* [chaincode] processStream -> ERRO 646 Error handling chaincode support stream: rpc error: code = Canceled desc = context canceled
2017-08-14 12:06:27.925 UTC [chaincode] deregisterHandler -> DEBU 647 Deregister handler: mycc:1.0
2017-08-14 12:06:27.925 UTC [chaincode] deregisterHandler -> DEBU 648 Deregistered handler with key: mycc:1.0
(after a while...)
2017-08-14 *12:06:57.829 UTC* [chaincode] Execute -> DEBU 649 Exit
2017-08-14 12:06:57.829 UTC [chaincode] ExecuteChaincode -> ERRO 64a Error executing chaincode: Failed to execute transaction (Timeout expired while executing transaction)
```
On the orderer, I see the following message corresponding to same timestamp
```
[orderer/common/broadcast] Handle -> WARN a14 Error reading from stream: rpc error: code = Canceled desc = context canceled
```
My e2e_cli works fine with the default chaincode examples. What could be going wrong with my chaincode? how do I debug? Thanks
muralisr (Tue, 15 Aug 2017 12:28:28 GMT):
@tallharish you can ignore the orderer error (for now at least) its just that peer or cli has disconnected
muralisr (Tue, 15 Aug 2017 12:28:49 GMT):
the timeout could be due to chaincode dying
muralisr (Tue, 15 Aug 2017 12:28:59 GMT):
or reporting an error
muralisr (Tue, 15 Aug 2017 12:30:19 GMT):
if you add env vars`CORE_CHAINCODE_LOGGING_LEVEL=debug and CORE_VM_DOCKER_ATTACHSTDOUT=true` to peer container's the chaincode logs will be redirected to peer side
muralisr (Tue, 15 Aug 2017 12:30:40 GMT):
and you can look at the peer logs to debug
tallharish (Tue, 15 Aug 2017 12:44:03 GMT):
Thanks @muralisr. This was helpful.
```
2017-08-15 12:40:06.932 UTC [dev-peer0.org1.example.com-mycc-1.0] func2 -> INFO 50f Transaction creator ID: Org1MSP
2017-08-15 12:40:06.932 UTC [dev-peer0.org1.example.com-mycc-1.0] func2 -> INFO 510 ACTION
2017-08-15 12:40:06.932 UTC [dev-peer0.org1.example.com-mycc-1.0] func2 -> INFO 511 commission
2017-08-15 12:40:06.941 UTC [dev-peer0.org1.example.com-mycc-1.0] func2 -> INFO 512 panic: runtime error: invalid memory address or nil pointer dereference
2017-08-15 12:40:06.941 UTC [dev-peer0.org1.example.com-mycc-1.0] func2 -> INFO 513 [signal SIGSEGV: segmentation violation code=0x1 addr=0x40 pc=0x4018c8]
2017-08-15 12:40:06.941 UTC [dev-peer0.org1.example.com-mycc-1.0] func2 -> INFO 514
2017-08-15 12:40:06.943 UTC [dev-peer0.org1.example.com-mycc-1.0] func2 -> INFO 515 goroutine 10 [running]:
2017-08-15 12:40:06.944 UTC [dev-peer0.org1.example.com-mycc-1.0] func2 -> INFO 516 panic(0xa65ca0, 0xc420016040)
2017-08-15 12:40:06.945 UTC [dev-peer0.org1.example.com-mycc-1.0] func2 -> INFO 517 /opt/go/src/runtime/panic.go:500 +0x1a1
2017-08-15 12:40:06.945 UTC [dev-peer0.org1.example.com-mycc-1.0] func2 -> INFO 518 main.(*SupplyChainCC).Invoke(0xc4201d8410, 0x1051aa0, 0xc420078c80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
2017-08-15 12:40:06.946 UTC [dev-peer0.org1.example.com-mycc-1.0] func2 -> INFO 519 /chaincode/input/src/example.com/ICI/msp_overlay/chaincode/go/supply_chain/supply_chain.go:74 +0x588
2017-08-15 12:40:06.946 UTC [dev-peer0.org1.example.com-mycc-1.0] func2 -> INFO 51a example.com/ICI/msp_overlay/vendor/github.com/hyperledger/fabric/core/chaincode/shim.(*Handler).handleTransaction.func1(0xc4202b2150, 0xc4201eb0e0)
2017-08-15 12:40:06.947 UTC [dev-peer0.org1.example.com-mycc-1.0] func2 -> INFO 51b /chaincode/input/src/example.com/ICI/msp_overlay/vendor/github.com/hyperledger/fabric/core/chaincode/shim/handler.go:317 +0x483
2017-08-15 12:40:06.947 UTC [dev-peer0.org1.example.com-mycc-1.0] func2 -> INFO 51c created by example.com/ICI/msp_overlay/vendor/github.com/hyperledger/fabric/core/chaincode/shim.(*Handler).handleTransaction
2017-08-15 12:40:06.947 UTC [dev-peer0.org1.example.com-mycc-1.0] func2 -> INFO 51d /chaincode/input/src/example.com/ICI/msp_overlay/vendor/github.com/hyperledger/fabric/core/chaincode/shim/handler.go:328 +0x49
2017-08-15 12:40:07.030 UTC [chaincode] processStream -> ERRO 51e Error handling chaincode support stream: rpc error: code = Canceled desc = context canceled
```
muralisr (Tue, 15 Aug 2017 13:52:41 GMT):
@tallharish sure, once you figure out the panic from `supply_chain.go:74` you should be set
sampath06 (Tue, 15 Aug 2017 16:29:10 GMT):
Has joined the channel.
sampath06 (Tue, 15 Aug 2017 16:49:30 GMT):
What are some sample scenarios where a peer may refuse to endorse a transaction? Is it just to prevent unauthorised nodes from validating transactions?
rahulhegde (Tue, 15 Aug 2017 18:19:11 GMT):
Can you help me understand -
- on starting the peer - how does peer get the orderer host information? I assume the connection is initiated by Peer to Orderer.
- in kafka-consensus orderer service setup - how do we know or control which peer-OSN communicates and I assume there would be switching to the available OSN to support fault tolerance
Thanks.
tallharish (Tue, 15 Aug 2017 18:23:23 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=bzCncs7QnZoTZkikj) Thanks @muralisr. Nailed it immediately :)
vdods (Thu, 17 Aug 2017 00:12:53 GMT):
Hi there, I'm working on enabling TLS on my ca/peer/orderer, and now my chaincode docker container is having problems. It looks like a cert issue; here is the log from the chaincode docker container:
```2017-08-17 00:08:16.348 UTC [shim] SetupChaincodeLogging -> INFO 001 Chaincode (build level: 1.0.0) starting up ...
2017-08-17 00:08:16.348 UTC [bccsp] initBCCSP -> DEBU 002 Initialize BCCSP [SW]
2017-08-17 00:08:16.348 UTC [shim] userChaincodeStreamGetter -> DEBU 003 Peer address: peer0.org0.example.com:7051
2017-08-17 00:08:16.413 UTC [shim] userChaincodeStreamGetter -> ERRO 004 Error trying to connect to local peer: x509: certificate signed by unknown authority (possibly because of "x509: ECDSA verification failure" while trying to verify candidate authority certificate "fabric-ca-server")
Error starting Simple chaincode: Error trying to connect to local peer: x509: certificate signed by unknown authority (possibly because of "x509: ECDSA verification failure" while trying to verify candidate authority certificate "fabric-ca-server")
```
vdods (Thu, 17 Aug 2017 00:13:46 GMT):
I attempted to specify CORE_VM_DOCKER_TLS_ENABLED and the related options for cert,key,ca files, but to no avail.
vdods (Thu, 17 Aug 2017 00:19:49 GMT):
The relevant portion of the log from the peer is
```peer0.org1.example.com | 2017-08-17 00:18:39.147 UTC [chaincode] Launch -> DEBU 336 launchAndWaitForRegister fetched 114631 bytes from file system
peer0.org1.example.com | 2017-08-17 00:18:39.147 UTC [chaincode] getArgsAndEnv -> DEBU 337 Executable is chaincode
peer0.org1.example.com | 2017-08-17 00:18:39.147 UTC [chaincode] getArgsAndEnv -> DEBU 338 Args [chaincode -peer.address=peer0.org1.example.com:7051]
peer0.org1.example.com | 2017-08-17 00:18:39.147 UTC [chaincode] launchAndWaitForRegister -> DEBU 339 start container: mycc:v0(networkid:dev,peerid:peer0.org1.example.com)
peer0.org1.example.com | 2017-08-17 00:18:39.147 UTC [chaincode] launchAndWaitForRegister -> DEBU 33a start container with args: chaincode -peer.address=peer0.org1.example.com:7051
peer0.org1.example.com | 2017-08-17 00:18:39.147 UTC [chaincode] launchAndWaitForRegister -> DEBU 33b start container with env:
peer0.org1.example.com | CORE_CHAINCODE_ID_NAME=mycc:v0
peer0.org1.example.com | CORE_PEER_TLS_ENABLED=true
peer0.org1.example.com | CORE_CHAINCODE_LOGGING_LEVEL=debug
peer0.org1.example.com | CORE_CHAINCODE_LOGGING_SHIM=debug
peer0.org1.example.com | CORE_CHAINCODE_LOGGING_FORMAT=%{color}%{time:2006-01-02 15:04:05.000 MST} [%{module}] %{shortfunc} -> %{level:.4s} %{id:03x}%{color:reset} %{message}
peer0.org1.example.com | 2017-08-17 00:18:39.147 UTC [container] lockContainer -> DEBU 33c waiting for container(dev-peer0.org1.example.com-mycc-v0) lock
peer0.org1.example.com | 2017-08-17 00:18:39.147 UTC [container] lockContainer -> DEBU 33d got container (dev-peer0.org1.example.com-mycc-v0) lock
peer0.org1.example.com | 2017-08-17 00:18:39.148 UTC [dockercontroller] Start -> DEBU 33e Cleanup container dev-peer0.org1.example.com-mycc-v0
peer0.org1.example.com | 2017-08-17 00:18:39.149 UTC [dockercontroller] stopInternal -> DEBU 33f Stop container dev-peer0.org1.example.com-mycc-v0(Container not running: dev-peer0.org1.example.com-mycc-v0)
peer0.org1.example.com | 2017-08-17 00:18:39.158 UTC [dockercontroller] stopInternal -> DEBU 340 Kill container dev-peer0.org1.example.com-mycc-v0 (API error (500): {"message":"Cannot kill container dev-peer0.org1.example.com-mycc-v0: Container 319978f8a4bff75f050a5a26b77d023622391653ec59cf7de9c79cc391ced735 is not running"}
```
muralisr (Thu, 17 Aug 2017 17:31:37 GMT):
@vdods I assume you removed the old chaincode image with `docker rmi ...` ?
niteshsolanki (Thu, 17 Aug 2017 19:25:33 GMT):
can a user Chaincode call qscc ?
vdods (Thu, 17 Aug 2017 23:07:16 GMT):
@muralisr Yes
vdods (Fri, 18 Aug 2017 00:00:20 GMT):
@muralisr I'm pretty sure it's the authentication issue though. What is involved in the chaincode container authenticating itself with the peer?
kelvinzhong (Fri, 18 Aug 2017 01:41:53 GMT):
Has joined the channel.
yacovm (Fri, 18 Aug 2017 07:50:58 GMT):
@vdods if the peer uses TLS - you also use TLS as the shim
greg.haskins (Fri, 18 Aug 2017 13:55:21 GMT):
@vdods you may find it helpful to enable this: https://github.com/hyperledger/fabric/blob/ae4e37dbafe74997534ab317dec5c3f4f53b6a84/sampleconfig/core.yaml#L286
greg.haskins (Fri, 18 Aug 2017 13:55:57 GMT):
that will very likely dump some useful output about why the container is exiting
greg.haskins (Fri, 18 Aug 2017 13:57:52 GMT):
however, I suspect you are getting bit by this: https://jira.hyperledger.org/browse/FAB-3996
greg.haskins (Fri, 18 Aug 2017 13:58:16 GMT):
note that a workaround is provided at the bottom of the thread
vdods (Fri, 18 Aug 2017 15:56:14 GMT):
Thanks, I had tried deleting the images before, to no avail, but for some reason it worked this time. *shrug*
vdods (Fri, 18 Aug 2017 17:39:39 GMT):
@greg.haskins Hmm.. nevermind, it's still failing, though it succeeded once. Seems to fail nondeterministically
vdods (Fri, 18 Aug 2017 17:39:39 GMT):
@greg.haskins Hmm.. nevermind, it's still failing, though it succeeded twice. Seems to fail nondeterministically
vdods (Fri, 18 Aug 2017 17:55:05 GMT):
It alternates success and failure. The following log entries are present in the succeeding one and not present in the failing one:
`[ccprovider] GetChaincodeData -> DEBU 479^[[0m Getting chaincode data for
vdods (Fri, 18 Aug 2017 17:56:39 GMT):
The strange thing is that I'm deleting all state (docker volumes that contain peer/orderer/ca state, docker containers, docker images for chaincode), so the behavior should be identical each time I run it. Maybe there's some anonymous docker volume being created and used somewhere that I'm not seeing
vdods (Fri, 18 Aug 2017 21:09:59 GMT):
It appears to be directly related to which peer is the leader -- the leader peer works, the non-leader doesn't
yacovm (Fri, 18 Aug 2017 21:30:57 GMT):
what's the issue, @vdods ?
vdods (Fri, 18 Aug 2017 21:32:27 GMT):
Upon transaction invocation, my non-leader peer returns with error `[lscc] Invoke -> ERRO 3e0 error getting chaincode mycc on channel: mychannel(err:could not find chaincode with name 'mycc')`, whereas the leader peer functions correctly.
yacovm (Fri, 18 Aug 2017 21:33:08 GMT):
ah well what's the setup?
yacovm (Fri, 18 Aug 2017 21:33:13 GMT):
is the non leader chatting with the leader?
vdods (Fri, 18 Aug 2017 21:49:37 GMT):
I've got 2 orgs, 2 peers each. I've set the CORE_PEER_GOSSIP_ORGLEADER explicitly on each peer so that there is one leader per org
vdods (Fri, 18 Aug 2017 21:49:37 GMT):
@yacovm I've got 2 orgs, 2 peers each. I've set the CORE_PEER_GOSSIP_ORGLEADER explicitly on each peer so that there is one leader per org
vdods (Fri, 18 Aug 2017 21:50:01 GMT):
I am seeing a few chat messages in the peer logs
vdods (Fri, 18 Aug 2017 21:50:54 GMT):
Really only seeing messages like `[shim] StartInProc -> DEBU 15e starting chat with peer using name=qscc:1.0.1` and `[shim] chatWithPeer -> DEBU 15f Registering.. sending REGISTER`
vdods (Fri, 18 Aug 2017 21:51:48 GMT):
But -- I'm sending the transaction proposal to both peers (leader and non-leader), and getting success from leader and failure from non-leader. The failure is `could not find chaincode with name 'mycc' - make sure the chaincode mycc has been successfully instantiated and try again`
vdods (Fri, 18 Aug 2017 22:10:03 GMT):
@yacovm When I switch back to using leader election, I get success every other time I spin up and run my blockchain network+app -- this is starting from scratch after deleting all state.
vdods (Fri, 18 Aug 2017 22:10:03 GMT):
@yacovm When I switch back to using leader election, I get success every other time I spin up and run my blockchain network+app -- this is starting from scratch after deleting all state.
vdods (Fri, 18 Aug 2017 22:10:03 GMT):
@yacovm When I switch back to using leader election, I get success every other time I spin up and run my blockchain network+app -- this is starting from scratch after deleting all state.
vdods (Fri, 18 Aug 2017 22:10:25 GMT):
Well, apparently not in exact alternation.. But it is nondeterministic
vdods (Fri, 18 Aug 2017 22:11:40 GMT):
Presumably the leader election is pseudorandom
yacovm (Sat, 19 Aug 2017 07:35:31 GMT):
@vdods can you please move this convo to #fabric-gossip channel and also provide me with logs with gossip in debug in them?
DarshanBc (Tue, 22 Aug 2017 08:21:42 GMT):
Has joined the channel.
DarshanBc (Tue, 22 Aug 2017 08:23:16 GMT):
Is there any way that I get notified one a block is created?
DarshanBc (Tue, 22 Aug 2017 08:23:16 GMT):
Is there any way that I get notified once a block is created?
Vadim (Tue, 22 Aug 2017 08:24:02 GMT):
@DarshanBc https://fabric-sdk-node.github.io/EventHub.html#registerBlockEvent__anchor
cwng (Tue, 22 Aug 2017 09:43:12 GMT):
Has joined the channel.
rsherwood (Tue, 22 Aug 2017 11:03:08 GMT):
Has joined the channel.
Hai-XuCheng (Wed, 23 Aug 2017 08:43:06 GMT):
Has joined the channel.
Vrai1127 (Wed, 23 Aug 2017 13:53:15 GMT):
Has joined the channel.
Vrai1127 (Wed, 23 Aug 2017 21:39:39 GMT):
All, I have a design question: 1) In most of the use cases, the participants of the network will have data which they would really like to keep confidential (for e.g. how much amount one invested) among select few peers.I understand channel is an option for peers to transact privately. But does that mean for all practical purposes, we will end up with multiple channels irrespective of how big or small a usecase is and then on the application side( front end) we will have to orchestrate to get data from all the channels and present to the user based on access level? 2) is there a mechanism to control access level for a peer on a channel so as it could access only specific data? Please help
vdods (Wed, 23 Aug 2017 23:09:47 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=dofNZi8aBhhqGxqmR) @yacovm Yep, I can do that. Sorry for the delay -- I was on a camping trip to view the total eclipse in central Oregon :)
vdods (Thu, 24 Aug 2017 01:07:51 GMT):
@yacovm In reproducing the bug again, I don't think it's necessarily gossip. I'm getting different failures, with no deterministic reproducibility -- sometimes the node SDK times out on channel creation before the peers do anything at all. Sometimes it fails during a transaction proposal, and sometimes it totally succeeds. This is starting with the peers' chaincode docker images already existing.
vdods (Thu, 24 Aug 2017 01:29:23 GMT):
This nondeterministic failure happens even when I clear all state and start from scratch
vdods (Thu, 24 Aug 2017 01:30:26 GMT):
It looks like it might be a problem with fabric-sdk-node.. when the SDK call to create channel is made, in the successful case the orderer responds, whereas in the failure case the orderer doesn't make a peep (no indication it received any request)
Stas Sorokin (Thu, 24 Aug 2017 10:49:29 GMT):
Has joined the channel.
Stas Sorokin (Thu, 24 Aug 2017 10:51:04 GMT):
Hello. Can someone explain what the difference between Org.member and Org.admin in endorsment policy? as i understood for example endorsment policy specifies way of approving transaction by validating peers. in case of Org.member it is clear - it's just endorosing peer. What does Org.admin mean in case of peer?
Vadim (Thu, 24 Aug 2017 11:08:23 GMT):
@Stas Sorokin I think I know now: the admin is the identity which is in the msp/admincerts, so if you put certificate of peer 1 into peer 2 msp/admincerts folder, then the endorsements of peer1 will satisfy the policy Org1.admin on peer2
Stas Sorokin (Thu, 24 Aug 2017 13:05:16 GMT):
hm...ok, thank you - it is need to try
Stas Sorokin (Thu, 24 Aug 2017 13:05:16 GMT):
hm...ok, thank you - it needs to try
vdods (Thu, 24 Aug 2017 18:09:53 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=dofNZi8aBhhqGxqmR) @yacovm Nevermind about this issue -- I fixed the bug by upgrading docker. The problem is that the grpc calls were experiencing dns resolution failure, and tracking the bug down was a very misleading process.
jeffgarratt (Thu, 24 Aug 2017 18:23:25 GMT):
@Stas Sorokin the difference is that Org.member means any signature from someone with a cert signed by the org (or in trust chain). This in general will be a peer that has been configured by the organization where the localMspConfig/signcerts will contain a cert signed by the org. Whereas an Org.admin refers to someone who has the admin role for the MSP, which requires the cert actually have been configured within the MSPConfig of the channel (which is seeded from the consortium on genesis of the channel). This is NOT the same as placing the cert into the localMSPCOnfig/admins folder of a peer, which will make that user an Admin for the Peer, but not for the Org's MSP.
jeffgarratt (Thu, 24 Aug 2017 18:23:49 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=oZjY6vaj6ByRpEXoD) @Stas Sorokin the difference is that Org.member means any signature from someone with a cert signed by the org (or in trust chain). This in general will be a peer that has been configured by the organization where the localMspConfig/signcerts will contain a cert signed by the org. Whereas an Org.admin refers to someone who has the admin role for the MSP, which requires the cert actually have been configured within the MSPConfig of the channel (which is seeded from the consortium on genesis of the channel). This is NOT the same as placing the cert into the localMSPCOnfig/admins folder of a peer, which will make that user an Admin for the Peer, but not for the Org's MSP.
Vadim (Fri, 25 Aug 2017 05:33:22 GMT):
@jeffgarratt how do one gets an endorsement from such admin? Should there be a peer configured with such MSP or something else? [ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=CS3fKguejYAw34TJZ)
Stas Sorokin (Fri, 25 Aug 2017 15:29:00 GMT):
Hi again, let consider two orgs with three endorsing peers in each organisation. if i instantiate a chaincode with endorsment policy AND('Org1.member', 'Org2.member') then call invoke it is no matter how many peers will endorse transaction, isn't it? One peer from Org1 and One peer from Org2 are enough?
jeffgarratt (Fri, 25 Aug 2017 16:58:29 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=PgurG4uBXbjxbEmyy) @Stas Sorokin correct
jeffgarratt (Fri, 25 Aug 2017 16:59:12 GMT):
@Vadim yes... You would have required a peer to be configured such that the signerscert is one of the certs in the MSPConfig's admins field
jeffgarratt (Fri, 25 Aug 2017 16:59:12 GMT):
@Vadim yes... You would have required a peer to be configured such that the signerscert is one of the certs in the MSPConfig's admins field (i.e. the field encoded in the channel config)
jeffgarratt (Fri, 25 Aug 2017 17:00:30 GMT):
@Stas Sorokin in reality, the multiple possible endorsers peer org would be HA purposes
jeffgarratt (Fri, 25 Aug 2017 17:00:30 GMT):
@Stas Sorokin in reality, the multiple possible endorsers perorg would be HA purposes
jeffgarratt (Fri, 25 Aug 2017 17:00:30 GMT):
@Stas Sorokin in reality, the multiple possible endorsers per org would be HA purposes
jeffgarratt (Fri, 25 Aug 2017 17:00:30 GMT):
@Stas Sorokin in reality, the multiple possible endorsers per org would be for HA purposes
jeffgarratt (Fri, 25 Aug 2017 17:01:36 GMT):
you would not get multiple endorsements from the same or in general
jeffgarratt (Fri, 25 Aug 2017 17:01:36 GMT):
you would not get multiple endorsements from the same org in general
jeffgarratt (Fri, 25 Aug 2017 17:02:05 GMT):
though it would of course not harm anything, just inefficient
nnao (Fri, 25 Aug 2017 17:57:56 GMT):
Has left the channel.
Stas Sorokin (Fri, 25 Aug 2017 18:15:16 GMT):
is it possible to manage of minimum count of endorsing peer in some organisation? i know it is nonsense, but my boss want to know - can we manage count of required endorsments within someone organisation? :nerd:
greg.haskins (Fri, 25 Aug 2017 20:16:03 GMT):
@Stas Sorokin yes, the policy is configurable and could be written as "requires 2 endorsments from Org A and one endorsement from Org B"
greg.haskins (Fri, 25 Aug 2017 20:16:12 GMT):
or whatever you desire
Vadim (Sat, 26 Aug 2017 05:47:23 GMT):
@greg.haskins how will this policy look like? AND('OrgA.member', 'OrgA.member', 'OrgB.member') or something else?
DarshanBc (Sat, 26 Aug 2017 08:02:30 GMT):
I have 2 types of requests one has to be endorsed by org1 and other by org2 how would I do tat
aberfou (Sat, 26 Aug 2017 16:14:48 GMT):
Hi, can someone explain me what kind of validation will be executed by the committer before updating the ledger?
yacovm (Sat, 26 Aug 2017 16:14:56 GMT):
yes
yacovm (Sat, 26 Aug 2017 16:15:00 GMT):
it checks:
yacovm (Sat, 26 Aug 2017 16:16:01 GMT):
1) The transactions are signed by the peers according to the endorsement policy
2) The versions of the Read sets are not "old" in comparison to the existing ones (Multi version concurrency control)
aberfou (Sat, 26 Aug 2017 16:17:56 GMT):
@yacovm thx, that means only the version of the rw sets will be checked?
yacovm (Sat, 26 Aug 2017 16:18:15 GMT):
only, in comparison to.... ?
yacovm (Sat, 26 Aug 2017 16:18:21 GMT):
to values?
aberfou (Sat, 26 Aug 2017 16:19:52 GMT):
i mean you have to trust the endorsment peers, if i have only one endorsment peer then it is possible that the endorsment peer can cheat...am i right?
yacovm (Sat, 26 Aug 2017 16:20:23 GMT):
if the endorsement policy is like "only 1 signature from any org" then yeah
yacovm (Sat, 26 Aug 2017 16:20:26 GMT):
but it's up to you
yacovm (Sat, 26 Aug 2017 16:20:37 GMT):
also - that's true for the default validation system chaincode
yacovm (Sat, 26 Aug 2017 16:20:46 GMT):
if you implement your own system chaincode
yacovm (Sat, 26 Aug 2017 16:21:00 GMT):
that does chaincode simulation and checks that things "make sense"
yacovm (Sat, 26 Aug 2017 16:21:20 GMT):
then you won't be cheated I guess
aberfou (Sat, 26 Aug 2017 16:21:21 GMT):
what is the difference between a nomal chaincode and a system chaincode
yacovm (Sat, 26 Aug 2017 16:21:33 GMT):
a normal chaincode is what you know
yacovm (Sat, 26 Aug 2017 16:21:56 GMT):
a system chaincode is just code in the peer that does all kinds of infrastructure specific tasks
yacovm (Sat, 26 Aug 2017 16:22:02 GMT):
and it has the signature of a chaincode shim
yacovm (Sat, 26 Aug 2017 16:22:30 GMT):
so it's called a system chaincode
yacovm (Sat, 26 Aug 2017 16:22:35 GMT):
i.e when you install a chaincode on a peer
aberfou (Sat, 26 Aug 2017 16:22:38 GMT):
infrastructure specific tasks... e.g.?
yacovm (Sat, 26 Aug 2017 16:22:45 GMT):
you actually call a life-cycle system chaincode
yacovm (Sat, 26 Aug 2017 16:23:05 GMT):
> infrastructure specific tasks... e.g.?
Making a peer join a channel, instantiate chaincode, install chaincode, etc. etc.
aberfou (Sat, 26 Aug 2017 16:24:27 GMT):
@yacovm thx :)
yacovm (Sun, 27 Aug 2017 08:07:37 GMT):
@muralisr https://stackoverflow.com/questions/45884426/fail-to-install-signed-package-with-peer-chaincode-install-command
muralisr (Sun, 27 Aug 2017 15:03:37 GMT):
thanks @yacovm ...answered
aberfou (Mon, 28 Aug 2017 05:54:43 GMT):
what will happen if in case of 2/2 endorsment peers have different results.. is the client checking that? Or does the client only check the endorsment policy?
aberfou (Mon, 28 Aug 2017 06:36:13 GMT):
one more question regarding the anchor peer. the glossary says "A peer node on a channel that all other peers can discover and communicate with. Each Member on a channel has an anchor peer (or multiple anchor peers to prevent single point of failure), allowing for peers belonging to different Members to discover all existing peers on a channel."
aberfou (Mon, 28 Aug 2017 06:37:11 GMT):
why do the peers of the different organizations need to communicate with each other? what kind of information will be exchanged?
DarshanBc (Mon, 28 Aug 2017 08:03:23 GMT):
In balance transfer example what is that we get by "GET query Transaction by TransactionID" lots of data which I amnot able to understand
DarshanBc (Mon, 28 Aug 2017 08:03:23 GMT):
In balance transfer example what is that we get by "GET query Transaction by TransactionID" lots of data which I am not able to understand
mastersingh24 (Mon, 28 Aug 2017 08:59:31 GMT):
@aberfou - the client can check to make sure that it received enough endorsements back and can check to make sure that the endorsement responses match as well, but this is not required (although it's a nice thing to do if possible). Even if the client does not check and submits the endorsement responses to the ordering service, each peer which receives the transaction will actually check to make sure that enough correct endorsements were obtained
(https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=AyWRCsNHgmemahsjg)
aberfou (Mon, 28 Aug 2017 09:12:04 GMT):
ok that means still only the endorsment policies will be checked by other peers but not the result of the endorsment...?
aberfou (Mon, 28 Aug 2017 09:16:12 GMT):
lets say i have two endorsment peers and i need a signature from both endorsment peers. my transaction looks like this: send 100 assets from a to b. lets assume endorsment peer0 executes it properly, but endorsment peer1 transfers 10000 for whatever reason. bot peers sign the proposal.
aberfou (Mon, 28 Aug 2017 09:16:12 GMT):
lets say i have two endorsment peers and i need a signature from both endorsment peers. my transaction looks like this: send 100 assets from a to b. lets assume endorsment peer0 executes it properly, but endorsment peer1 transfers 10000 for whatever reason. both peers sign the proposal, so the endorsment policy has been satisfied
aberfou (Mon, 28 Aug 2017 09:17:18 GMT):
what will happen?
Vadim (Mon, 28 Aug 2017 09:18:34 GMT):
@aberfou as far as I know, the app packs into a transaction one result and n signatures over that result. So in this case you have 2 different results, which means an app must choose. But either way, the endorsement policy will not be satisfied, as only 1 signature can be provided
aberfou (Mon, 28 Aug 2017 09:19:30 GMT):
@Vadim I see
aberfou (Mon, 28 Aug 2017 09:20:41 GMT):
but what do you mean the app must chose?
aberfou (Mon, 28 Aug 2017 09:21:11 GMT):
how does the app distinguish the different results?
Vadim (Mon, 28 Aug 2017 09:24:56 GMT):
@aberfou the app receives all proposal responses, so it can iterate over them and make sure that they are all the same
aberfou (Mon, 28 Aug 2017 09:25:53 GMT):
@Vadim ok that means the app cheks all results
Vadim (Mon, 28 Aug 2017 09:26:57 GMT):
it checks it before ordering, the app might not check it, but then the transaction will be in a block and when committed by peers, marked as invalid because of policy violation
aberfou (Mon, 28 Aug 2017 09:28:42 GMT):
ok that means the peers check it, if there are different results the transaction will be marked as invalid?
Vadim (Mon, 28 Aug 2017 09:30:01 GMT):
I think you can't send different results, it's only one result and many signatures
aberfou (Mon, 28 Aug 2017 09:31:19 GMT):
then i dont understand how and where invalid results will be detected
Vadim (Mon, 28 Aug 2017 09:34:01 GMT):
@aberfou [ ](https://chat.hyperledger.org/channel/fabric-consensus?msg=R2XK8djFiK8Yn5JYc)
Vadim (Mon, 28 Aug 2017 09:35:45 GMT):
@aberfou e.g. in node-sdk here is how it's set: https://github.com/hyperledger/fabric-sdk-node/blob/release/fabric-client/lib/Channel.js#L1450
aberfou (Mon, 28 Aug 2017 09:35:49 GMT):
ok now i understand
Vadim (Mon, 28 Aug 2017 09:35:55 GMT):
one ProposalResponse and many endorsements
aberfou (Mon, 28 Aug 2017 09:36:25 GMT):
yes and if the signature of one endorser is different then the policy is not valid any more
aberfou (Mon, 28 Aug 2017 09:36:46 GMT):
thx a lot!
Vadim (Mon, 28 Aug 2017 09:37:03 GMT):
no problem
aberfou (Mon, 28 Aug 2017 09:54:02 GMT):
one more question regarding the anchor peer. the glossary says "A peer node on a channel that all other peers can discover and communicate with. Each Member on a channel has an anchor peer (or multiple anchor peers to prevent single point of failure), allowing for peers belonging to different Members to discover all existing peers on a channel."
why do the peers of the different organizations need to communicate with each other? what kind of information will be exchanged?
Vadim (Mon, 28 Aug 2017 10:03:38 GMT):
@aberfou I think they can fetch blocks from them if the orderer is not available for some reason
aberfou (Mon, 28 Aug 2017 11:13:10 GMT):
thx
Ratnakar (Mon, 28 Aug 2017 16:03:34 GMT):
This is regarding https://gerrit.hyperledger.org/r/#/c/12799/
As per @greg.haskins suggestion
```
Passing the TLS objects as parameters is not a good idea. They should be passed into the container itself.
```
As part of the JIRA `FAB-5406 - Peer<-->Chaincode Mutual TLS`. @yacovm
Ratnakar (Mon, 28 Aug 2017 16:21:11 GMT):
This is regarding https://gerrit.hyperledger.org/r/#/c/12799/
As per @greg.haskin suggestion
```
Passing the TLS objects as parameters is not a good idea. They should be passed into the container itself.
```
As part of the JIRA `FAB-5406 - Peer<-->Chaincode Mutual TLS`. completed by yacov.
A change to the design has to be made for the above to take care.
^^^ @jimthematrix , @yacovm @mastersingh24
yacovm (Mon, 28 Aug 2017 16:22:53 GMT):
Right. @greg.haskins do you have an alternative? as long as it can be secured with the peer<-->docker TLS connection (if applicable) I'm open to new suggestions, what did you have in mind?
DarshanBc (Mon, 28 Aug 2017 17:33:29 GMT):
@Vadim how to list all the transaction ID of transactions done by particular user
rahulhegde (Mon, 28 Aug 2017 21:04:07 GMT):
@muralisr @kostas @jyellick
[1] Use of config.yaml (4th point - http://hyperledger-fabric.readthedocs.io/en/latest/msp.html#msp-setup-on-the-peer-orderer-side) in the msp folder indicates, let's say for peer fabric, for every signed request received from either client could be orderer or HFC or (anything else, can you please update - is it for Gossip?) must have a entry in the yaml (https://github.com/hyperledger/fabric/blob/release/msp/mspimpl.go#L1118).
Is that correct?
[2] Since the config.yaml is cached in the peer implementation, we would require to reboot the peer process in case there needs to change config.yaml. Is my understanding correct and this should apply to orderer since it is sharing the mspimpl.go code?
[3] I am feeling, by adding config.yaml entry is like mandating every signed request to carry OU field. How do we justify from the security perspective if we loosen this condition - https://github.com/hyperledger/fabric/blob/release/msp/mspimpl.go#L1119 and set to true?
jyellick (Mon, 28 Aug 2017 22:12:39 GMT):
@rahulhegde The MSP information in the `orderer.yaml` and `core.yaml` is local to the process. In the orderer case, this is used only for signing. In the peer, this is used for signing and for local admin actions like installing chaincode. All other signature validation for channel specific things like `Broadcast` and `Deliver` use the channel MSPs as defined by `configtx.yaml`.
jyellick (Mon, 28 Aug 2017 22:12:39 GMT):
@rahulhegde The MSP information in the `orderer.yaml` and `core.yaml` is local to the process. In the orderer case, this is used only for signing. In the peer, this is used for signing and for local admin actions like installing chaincode. All other signature validation for channel specific things like `Broadcast` and `Deliver` use the channel MSPs as initially defined by `configtx.yaml` and stored and propagated in the blockchain
jimthematrix (Tue, 29 Aug 2017 13:37:33 GMT):
@muralisr @yacovm do you guy have an idea what might cause this error?
```Chat stream with peer - on error: "Error: unknown service protos.ChaincodeSupport
jimthematrix (Tue, 29 Aug 2017 13:37:53 GMT):
happening when trying to connect from the chaincode process
yacovm (Tue, 29 Aug 2017 13:37:56 GMT):
yeah
yacovm (Tue, 29 Aug 2017 13:38:00 GMT):
it's the wrong port I guess?
jimthematrix (Tue, 29 Aug 2017 13:38:02 GMT):
oh ;-)
jimthematrix (Tue, 29 Aug 2017 13:38:25 GMT):
pretty sure that shouldn't be the case
yacovm (Tue, 29 Aug 2017 13:38:31 GMT):
what port is that?
yacovm (Tue, 29 Aug 2017 13:38:39 GMT):
7051 no longer works
jimthematrix (Tue, 29 Aug 2017 13:38:42 GMT):
```CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
db6ca221ed65 hyperledger/fabric-peer:latest "peer node start -..." 2 hours ago Up 2 hours 0.0.0.0:7051->7051/tcp, 0.0.0.0:7053->7053/tcp peer0.org1.example.com
yacovm (Tue, 29 Aug 2017 13:38:56 GMT):
it should be 7052
jimthematrix (Tue, 29 Aug 2017 13:39:08 GMT):
this is how it's launched:
```CORE_CHAINCODE_ID_NAME="mycc:v0" node test/integration/test.js --peer.address grpc://localhost:7051
jimthematrix (Tue, 29 Aug 2017 13:39:16 GMT):
7052?
yacovm (Tue, 29 Aug 2017 13:39:16 GMT):
right
yacovm (Tue, 29 Aug 2017 13:39:18 GMT):
it's the wrong port
yacovm (Tue, 29 Aug 2017 13:39:21 GMT):
7052
jimthematrix (Tue, 29 Aug 2017 13:39:37 GMT):
is that related to the auth handler feature?
yacovm (Tue, 29 Aug 2017 13:39:42 GMT):
no...
muralisr (Tue, 29 Aug 2017 13:39:47 GMT):
are you using an old chaincode image ?
yacovm (Tue, 29 Aug 2017 13:39:48 GMT):
it's related to the TLS CC
jimthematrix (Tue, 29 Aug 2017 13:40:33 GMT):
so the new port is always 7052 regardless if tls is enabled or not?
jimthematrix (Tue, 29 Aug 2017 13:40:40 GMT):
in my case I don't have tls enabled
jimthematrix (Tue, 29 Aug 2017 13:43:14 GMT):
@muralisr this is from the node.js chaincode test code ;-)
jimthematrix (Tue, 29 Aug 2017 13:53:19 GMT):
@yacovm node.js chaincode e2e test working fine now after mapping the additional 7052 port, thanks!
yacovm (Tue, 29 Aug 2017 13:54:33 GMT):
the port is now different because the listener is different, because the TLS configuration is different and separate.
rahulhegde (Tue, 29 Aug 2017 15:21:03 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=4yK3ZiAiZxMmXSHGd) @jyellick
Now in that case - to confirm ` config.yaml (4th point - http://hyperledger-fabric.readthedocs.io/en/latest/msp.html#msp-setup-on-the-peer-orderer-side) ` will also become part of the channel-configuration block. Hence for example during Identity Validation process of the received Endorsement Proposal Request, the peer process will pick the endorsement request sender's MSP from the configuration-block (ledger) and one of the step will be to perform the OU validation on that signing cert.
jyellick (Tue, 29 Aug 2017 15:40:33 GMT):
@rahulhegde You keep referring to `config.yaml`, do you mean `conifgtx.yaml`?
jyellick (Tue, 29 Aug 2017 15:40:33 GMT):
@rahulhegde ~You keep referring to `config.yaml`, do you mean `conifgtx.yaml`?~ I see this in the doc now
jyellick (Tue, 29 Aug 2017 15:43:02 GMT):
I have not personally used the OU functions, but yes, looking at the code, if you include this file in your MSP directory, before running the `configtxgen` tool, then this will get included into the configuration block for the channel.
Ratnakar (Tue, 29 Aug 2017 20:51:06 GMT):
@greg.haskins Can we use this patch https://gerrit.hyperledger.org/r/#/c/12799/ for enabling mutual TLS for node chaincode . later we can take up the task of building the client tls certs in the chaincode image ?
anishman (Wed, 30 Aug 2017 14:32:27 GMT):
Has joined the channel.
troyronda (Wed, 30 Aug 2017 20:28:24 GMT):
@greg.haskins @muralisr @cbf hi guys - could you please help me understand the practical purpose of FAB-2122 / CS6059?
troyronda (Wed, 30 Aug 2017 20:31:34 GMT):
It seems to me that a consortium should be able to deploy chaincode applications that meet the interface. Of course, a consortium might want to approve the chaincodes that are deployed consortium-wide (e.g., possibly the result of 3rd party code review). As an example, distributed as a whitelist of hashes. However FAB-2122 and stripping binaries doesn't achieve this.
troyronda (Wed, 30 Aug 2017 20:31:34 GMT):
It seems to me that a consortium should be able to deploy chaincode applications that meet the interface. Of course, a consortium might want to approve the chaincodes that are deployed consortium-wide (e.g., possibly the result of 3rd party code review). As an example, distributed as a whitelist of hashes. However FAB-2122 and stripping content doesn't achieve this.
troyronda (Wed, 30 Aug 2017 20:34:20 GMT):
More strongly, I think we should be able to deploy artificats that are output from our build system rather than submitting source code that peers then compile.
troyronda (Wed, 30 Aug 2017 20:34:20 GMT):
More strongly, I think we should be able to deploy artificats that are output from our "normal" build system rather than submitting source code that peers then compile.
greg.haskins (Wed, 30 Aug 2017 20:34:48 GMT):
@troyronda understand that you are interested in that, but note that FAB-2122 is specific to the type=GOLANG type
greg.haskins (Wed, 30 Aug 2017 20:35:25 GMT):
and type=GOLANG is specific to golang-source payloads
greg.haskins (Wed, 30 Aug 2017 20:35:36 GMT):
i think you are referring to that other thread where you want a new deployment type
troyronda (Wed, 30 Aug 2017 20:36:27 GMT):
There is another thread on that topic but I was trying to review the prior history to understand the current status.
greg.haskins (Wed, 30 Aug 2017 20:36:42 GMT):
OTP, but ill try to respond in a bit
troyronda (Wed, 30 Aug 2017 20:37:10 GMT):
sure, thanks
aleksandar.likic (Wed, 30 Aug 2017 20:52:41 GMT):
Has joined the channel.
jimthematrix (Wed, 30 Aug 2017 21:32:10 GMT):
@greg.haskins if you may allow me to pile on ;-) https://gerrit.hyperledger.org/r/#/c/12799/ is also pending your decision whether to let this one go in as-is (so node.js and golang chaincode are processed exactly the same, by passing the client key and cert on the command line), and use a separate CR to address your concerns and fix it for all chaincode types
jimthematrix (Wed, 30 Aug 2017 21:32:12 GMT):
thanks
greg.haskins (Wed, 30 Aug 2017 21:33:26 GMT):
@jimthematrix im still confused by your statement on that
greg.haskins (Wed, 30 Aug 2017 21:33:38 GMT):
afaict, the other platforms inject the tls using docker-api
greg.haskins (Wed, 30 Aug 2017 21:34:24 GMT):
oh i see what you mean
greg.haskins (Wed, 30 Aug 2017 21:34:29 GMT):
hmm, someone mustve changed that
troyronda (Wed, 30 Aug 2017 22:39:31 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=SAcmewwQLJMLqvvw7) @Vrai1127 I'd suggest you look into the ongoing work on Private Data (FAB-1151)
greg.haskins (Wed, 30 Aug 2017 22:45:56 GMT):
@jimthematrix ah, i see...that snuck in recently
greg.haskins (Wed, 30 Aug 2017 22:45:58 GMT):
https://github.com/hyperledger/fabric/commit/7a26f1fe1f3e09c950a9be0cf1c1adca2dc4dcee
greg.haskins (Wed, 30 Aug 2017 22:46:16 GMT):
thats not the right way to go, though, so lets not perpetuate it
jimthematrix (Wed, 30 Aug 2017 23:08:14 GMT):
@greg.haskins can you recommend an alternative? not sure what you meant by using docker-api
greg.haskins (Wed, 30 Aug 2017 23:16:07 GMT):
@jimthematrix on mobile so can't get links. I think it's called the "upload api" in the docker engine spec. I use it in the container build logic if you search in there
greg.haskins (Wed, 30 Aug 2017 23:16:50 GMT):
Basically CREATE+UPLOAD(TLS)+START is what we want here
greg.haskins (Wed, 30 Aug 2017 23:17:28 GMT):
I'll send link later if you can't find it
greg.haskins (Thu, 31 Aug 2017 00:30:11 GMT):
@jimthematrix https://github.com/hyperledger/fabric/blob/c4c977db678fc9153e1ee37423d5eae828ec87f7/core/chaincode/platforms/util/utils.go#L191
greg.haskins (Thu, 31 Aug 2017 00:33:35 GMT):
@troyronda so, the overall problems with the BINARY proposal, aside from the fact that I am still not convinced that obscure code makes sense, is that it was way too fragile and non deterministic to do it that way
greg.haskins (Thu, 31 Aug 2017 00:34:10 GMT):
my suggestion is to not try to use a native binary, but rather ride on something like JVM/LLVM
greg.haskins (Thu, 31 Aug 2017 00:34:17 GMT):
that would take care of at least part of it
troyronda (Thu, 31 Aug 2017 00:34:19 GMT):
JVM/LLVM is not viable
troyronda (Thu, 31 Aug 2017 00:34:27 GMT):
The source code is Go
troyronda (Thu, 31 Aug 2017 00:34:58 GMT):
let me understand the fragile / non-deterministic comment better
troyronda (Thu, 31 Aug 2017 00:35:09 GMT):
this is the install command, so non-deterministic isn't applicable
greg.haskins (Thu, 31 Aug 2017 00:35:35 GMT):
im just saying what approach I would advise for an obfuscation approach that still allows you to be $arch platform neutral
troyronda (Thu, 31 Aug 2017 00:36:00 GMT):
Go outputs binaries for all the platforms so the easiest way to handle is to include all the binaries
troyronda (Thu, 31 Aug 2017 00:36:00 GMT):
Go outputs binaries for all the platforms so the easiest way to handle is to include all the binaries resulting from x-compile
troyronda (Thu, 31 Aug 2017 00:36:07 GMT):
(the latest patch does this)
greg.haskins (Thu, 31 Aug 2017 00:36:57 GMT):
let me put it this way: is there a variant of running "go build" that you can think of that would produce a sufficiently neutral payload that is independent of $arch/$distro?
greg.haskins (Thu, 31 Aug 2017 00:37:10 GMT):
is that conveyed to the framework?
troyronda (Thu, 31 Aug 2017 00:37:14 GMT):
yes - x-compile
troyronda (Thu, 31 Aug 2017 00:37:16 GMT):
:)
greg.haskins (Thu, 31 Aug 2017 00:37:22 GMT):
can someone else reproduce your binary?
greg.haskins (Thu, 31 Aug 2017 00:37:44 GMT):
your contract isnt very useful unless multiple parties can verify its terms
troyronda (Thu, 31 Aug 2017 00:37:47 GMT):
The build system and code reviewers
troyronda (Thu, 31 Aug 2017 00:38:07 GMT):
Code review should be decoupled from deployment
greg.haskins (Thu, 31 Aug 2017 00:38:09 GMT):
as a code reviewer, how do I know binary X relates to code base Y?
greg.haskins (Thu, 31 Aug 2017 00:38:49 GMT):
what if code reviewer A has a different version of glibc, or nswitch, etc, etc on their system?
troyronda (Thu, 31 Aug 2017 00:39:10 GMT):
build the code in the same docker container
greg.haskins (Thu, 31 Aug 2017 00:39:18 GMT):
bottom line, fabric is a FOSS framework...you can always fork if if you want to run your network that way
greg.haskins (Thu, 31 Aug 2017 00:39:41 GMT):
but the proposal is way too fragile for upstream merging (IMO)
troyronda (Thu, 31 Aug 2017 00:39:45 GMT):
Fabric is a platform that a consortium agrees to run and the consortium defines appropriate processes
greg.haskins (Thu, 31 Aug 2017 00:40:08 GMT):
sure, so your consortium can run a variant that accepts BINARY=4 payloads
greg.haskins (Thu, 31 Aug 2017 00:40:27 GMT):
but it would need to be much more robust to go upstream (again, IMO)
troyronda (Thu, 31 Aug 2017 00:40:42 GMT):
I don't understand your objection - seems philiosophical
greg.haskins (Thu, 31 Aug 2017 00:40:59 GMT):
not philosophical at all...
troyronda (Thu, 31 Aug 2017 00:41:04 GMT):
the proposal isn't fragile - it handles multi-arch
troyronda (Thu, 31 Aug 2017 00:41:27 GMT):
you are placing a requirement on consortiums that doesn't exist - that chaincode must be sent as source code
greg.haskins (Thu, 31 Aug 2017 00:41:28 GMT):
you basically are proposing a weak contract on a interface that needs a strong one
greg.haskins (Thu, 31 Aug 2017 00:41:46 GMT):
I am not placing any requirements on consortiums...
greg.haskins (Thu, 31 Aug 2017 00:42:04 GMT):
I am saying, as one of the maintainers of the code base, I dont think that patch is a good idea for upstream merging
troyronda (Thu, 31 Aug 2017 00:42:08 GMT):
why
troyronda (Thu, 31 Aug 2017 00:42:28 GMT):
multi-arch is supported
greg.haskins (Thu, 31 Aug 2017 00:42:48 GMT):
because, saying "type=BINARY" is a pretty weak description for the payload juxtaposed against all the variants of the peer in which it may encounter
troyronda (Thu, 31 Aug 2017 00:43:15 GMT):
any suggestion for a better type description?
greg.haskins (Thu, 31 Aug 2017 00:46:35 GMT):
I would probably start with the way any ABI is negotiated: either versioned or feature tagged
troyronda (Thu, 31 Aug 2017 00:47:06 GMT):
As an example, what about including as source-code a loader of the binary
troyronda (Thu, 31 Aug 2017 00:47:16 GMT):
this source-code is compiled against the shim
troyronda (Thu, 31 Aug 2017 00:47:28 GMT):
and meets the interface
troyronda (Thu, 31 Aug 2017 00:47:40 GMT):
the binary isn't executable in that case
greg.haskins (Thu, 31 Aug 2017 00:47:47 GMT):
but I would also strongly suggest a more platform neutral approach...there isnt a way today to negotiate the potentially infinite heterogeneous composition of your network apriori
greg.haskins (Thu, 31 Aug 2017 00:48:11 GMT):
what if we add ARM7 in v1.1
greg.haskins (Thu, 31 Aug 2017 00:48:26 GMT):
or update the glibc, but only half the nodes update
greg.haskins (Thu, 31 Aug 2017 00:48:32 GMT):
etc etc
greg.haskins (Thu, 31 Aug 2017 00:48:36 GMT):
its fragile
troyronda (Thu, 31 Aug 2017 00:48:39 GMT):
these are closed consortiums
troyronda (Thu, 31 Aug 2017 00:49:02 GMT):
if arm7 becomes a platform in a consortium, then support is added
greg.haskins (Thu, 31 Aug 2017 00:49:34 GMT):
well, again, that consortium can choose to patch the support...i see no problem in that...then the heterogeneity problem doesnt need to be addressed
greg.haskins (Thu, 31 Aug 2017 00:50:02 GMT):
another alternative is to implement it as system chaincode and embed it in the peer that the consortium runs
troyronda (Thu, 31 Aug 2017 00:50:23 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=3EqmZWiYDQ7CPfQqD)
troyronda (Thu, 31 Aug 2017 00:51:02 GMT):
the objection was the interface contract - i think this can be addressed with the source code loader
troyronda (Thu, 31 Aug 2017 00:51:12 GMT):
I don't buy the argument the fragile argument
troyronda (Thu, 31 Aug 2017 00:51:12 GMT):
I don't buy the fragile argument
greg.haskins (Thu, 31 Aug 2017 00:51:23 GMT):
ok, you dont have to
troyronda (Thu, 31 Aug 2017 00:51:38 GMT):
even CC doesn't necessarily compiled to every platform
troyronda (Thu, 31 Aug 2017 00:51:38 GMT):
even CC doesn't necessarily compile to every platform
greg.haskins (Thu, 31 Aug 2017 00:51:54 GMT):
agreed, and I raised that ABI issue already
greg.haskins (Thu, 31 Aug 2017 00:52:00 GMT):
and plan on fixing it
troyronda (Thu, 31 Aug 2017 00:52:04 GMT):
are you saying that only langauages that compile to every target should be included as environments
troyronda (Thu, 31 Aug 2017 00:52:04 GMT):
are you saying that only languages that compile to every target should be included as platforms
troyronda (Thu, 31 Aug 2017 00:52:38 GMT):
compilation of CC can already fail - you can't guarantee this
greg.haskins (Thu, 31 Aug 2017 00:53:07 GMT):
i am suggesting that golang binaries are a poor/fragile vehicle for heterogeneous execution
troyronda (Thu, 31 Aug 2017 00:53:32 GMT):
Not if multiple archs are included in the package
troyronda (Thu, 31 Aug 2017 00:53:50 GMT):
It's an implementation detail on who produced it
greg.haskins (Thu, 31 Aug 2017 00:53:59 GMT):
I am also suggesting that non-deterministic generation is illogical for chaincode
troyronda (Thu, 31 Aug 2017 00:54:00 GMT):
Same compiler
troyronda (Thu, 31 Aug 2017 00:54:08 GMT):
non-deterministic?
troyronda (Thu, 31 Aug 2017 00:54:42 GMT):
Install has no deterministic requirements - it is run individually on each peer
troyronda (Thu, 31 Aug 2017 00:54:57 GMT):
there is no endorsement
greg.haskins (Thu, 31 Aug 2017 00:55:05 GMT):
im saying that if multiple parties need a smart contract, those parties need to be able to evaluate both what the contract guarantees, and that they are actually interacting with it
troyronda (Thu, 31 Aug 2017 00:55:22 GMT):
Up to the consortium to decide how to handle
greg.haskins (Thu, 31 Aug 2017 00:55:42 GMT):
sure..so, run the consortium however you like
troyronda (Thu, 31 Aug 2017 00:55:45 GMT):
And submitting source code doesn't do anything
greg.haskins (Thu, 31 Aug 2017 00:55:49 GMT):
patch the code to accept binaries...totally fine
troyronda (Thu, 31 Aug 2017 00:55:58 GMT):
Without real reviews of the source code nothing happens
greg.haskins (Thu, 31 Aug 2017 00:56:05 GMT):
its not about review
troyronda (Thu, 31 Aug 2017 00:56:10 GMT):
of course it is
greg.haskins (Thu, 31 Aug 2017 00:56:14 GMT):
(well, it is, but not in this context
greg.haskins (Thu, 31 Aug 2017 00:56:24 GMT):
no, its about attestation
troyronda (Thu, 31 Aug 2017 00:56:37 GMT):
yes - an expert review needs to examine the code
troyronda (Thu, 31 Aug 2017 00:56:43 GMT):
this has nothing to do with compilation on the peer
greg.haskins (Thu, 31 Aug 2017 00:56:50 GMT):
you cant have attestation without a deterministic relationship between source and payload
troyronda (Thu, 31 Aug 2017 00:57:06 GMT):
compile the code in the same environment with the same compiler - reviewer does the same
troyronda (Thu, 31 Aug 2017 00:57:11 GMT):
doesn't need to be done on a peer
greg.haskins (Thu, 31 Aug 2017 00:57:36 GMT):
thats an extra constraint that can't be enforced simply by saying "I accept type=BINARY"
troyronda (Thu, 31 Aug 2017 00:58:00 GMT):
there should be a whitelist feature but this is a general feature not just for binary
greg.haskins (Thu, 31 Aug 2017 00:58:04 GMT):
saying "I accept type=BINARY" means you are relying on an external process to enforce robustness
troyronda (Thu, 31 Aug 2017 00:58:12 GMT):
same with source code
greg.haskins (Thu, 31 Aug 2017 00:58:14 GMT):
and that is fragile
greg.haskins (Thu, 31 Aug 2017 00:58:36 GMT):
no, its not the same
troyronda (Thu, 31 Aug 2017 00:58:47 GMT):
if no one reviews before instantiation on each peer it is
troyronda (Thu, 31 Aug 2017 00:58:52 GMT):
*on each peer*
greg.haskins (Thu, 31 Aug 2017 00:58:55 GMT):
because each peer can take an identical source payload, hash it, and the compile it
troyronda (Thu, 31 Aug 2017 00:59:08 GMT):
install is sent individually to each peer
troyronda (Thu, 31 Aug 2017 00:59:23 GMT):
what's the protection if different source code is sent to one of them
greg.haskins (Thu, 31 Aug 2017 00:59:25 GMT):
that doesnt matter though
greg.haskins (Thu, 31 Aug 2017 00:59:33 GMT):
different source is different hash
troyronda (Thu, 31 Aug 2017 00:59:42 GMT):
different binary is different hash
greg.haskins (Thu, 31 Aug 2017 00:59:54 GMT):
yes, you are making my point
troyronda (Thu, 31 Aug 2017 01:00:12 GMT):
we both agree that if someone does the review then things are good and if they don't then they aren't
troyronda (Thu, 31 Aug 2017 01:00:17 GMT):
:)
greg.haskins (Thu, 31 Aug 2017 01:00:23 GMT):
no, we are talking about different things
troyronda (Thu, 31 Aug 2017 01:00:30 GMT):
if no one reviews the source code on the peer it's the same result
greg.haskins (Thu, 31 Aug 2017 01:00:48 GMT):
review is one part, attestation is a different part, and determinism links them together
troyronda (Thu, 31 Aug 2017 01:01:07 GMT):
but you can deterministically build the binary
greg.haskins (Thu, 31 Aug 2017 01:01:17 GMT):
only with an external process
greg.haskins (Thu, 31 Aug 2017 01:01:23 GMT):
if you are careful, sure, maybe
troyronda (Thu, 31 Aug 2017 01:01:25 GMT):
reviewing code is an external process
greg.haskins (Thu, 31 Aug 2017 01:01:37 GMT):
forget about the review
troyronda (Thu, 31 Aug 2017 01:01:38 GMT):
distribute the same docker image - i don't see the issue
greg.haskins (Thu, 31 Aug 2017 01:01:46 GMT):
the issue is relating the review to what the peer is executing
troyronda (Thu, 31 Aug 2017 01:02:00 GMT):
yes - whether sent as binary or source code, that must be reviewed
greg.haskins (Thu, 31 Aug 2017 01:02:19 GMT):
sure, AND you need to be able to relate the review to what is executing
troyronda (Thu, 31 Aug 2017 01:02:25 GMT):
sure - via the hash
greg.haskins (Thu, 31 Aug 2017 01:02:40 GMT):
yes...and therein lies the relationship to determinism
troyronda (Thu, 31 Aug 2017 01:02:47 GMT):
but source code sent to the peer doesn't change the picture
greg.haskins (Thu, 31 Aug 2017 01:02:59 GMT):
yes, it does
troyronda (Thu, 31 Aug 2017 01:03:23 GMT):
if i have a reviewer reviews the code, deterministically produces the same binary then no issue
troyronda (Thu, 31 Aug 2017 01:03:23 GMT):
if i have a reviewer review the code, deterministically produces the same binary then no issue
greg.haskins (Thu, 31 Aug 2017 01:03:51 GMT):
IFF, then thats _one_ issue
greg.haskins (Thu, 31 Aug 2017 01:03:59 GMT):
but you still have others
troyronda (Thu, 31 Aug 2017 01:04:13 GMT):
I don't have an arch issue
greg.haskins (Thu, 31 Aug 2017 01:04:27 GMT):
no, you dont _think_ you have an arch issue ;)
troyronda (Thu, 31 Aug 2017 01:04:32 GMT):
I know I don't :)
troyronda (Thu, 31 Aug 2017 01:04:51 GMT):
The source is Go and I can cross-compile to all the archs
greg.haskins (Thu, 31 Aug 2017 01:04:59 GMT):
that alone isnt enough
greg.haskins (Thu, 31 Aug 2017 01:05:08 GMT):
its not just $arch
greg.haskins (Thu, 31 Aug 2017 01:05:31 GMT):
$distro matters...$version matters, lots of things you havent thought of, matter
greg.haskins (Thu, 31 Aug 2017 01:05:42 GMT):
its just a bad idea: ive seen this movie
troyronda (Thu, 31 Aug 2017 01:06:07 GMT):
On the interface issue, I can supply the source code that loads the object code - that source code is compiled against the interface
troyronda (Thu, 31 Aug 2017 01:06:15 GMT):
distro doesn't matter - its run in docker
troyronda (Thu, 31 Aug 2017 01:06:35 GMT):
one of the benefits of wrapping the result in docker is that I don't have to worry about this
greg.haskins (Thu, 31 Aug 2017 01:06:36 GMT):
so tell me, what does "runs in docker" mean to you?
troyronda (Thu, 31 Aug 2017 01:06:56 GMT):
I know what environment to expect and what files are available
troyronda (Thu, 31 Aug 2017 01:07:10 GMT):
aka distro
troyronda (Thu, 31 Aug 2017 01:07:44 GMT):
I know that it runs in the host OS and that it uses the host kernel
greg.haskins (Thu, 31 Aug 2017 01:07:51 GMT):
for all $arch? for all $kernel, for all $dockerd?
greg.haskins (Thu, 31 Aug 2017 01:08:27 GMT):
i'm not saying "it cant work"...im just saying "its fragile" and thus I dont think this is a good general solution
greg.haskins (Thu, 31 Aug 2017 01:08:39 GMT):
why is it critical to go upstream?
troyronda (Thu, 31 Aug 2017 01:09:06 GMT):
I think issues that come up can be resolved by an object loader, as needed
greg.haskins (Thu, 31 Aug 2017 01:09:19 GMT):
if you want a good model to follow here, I would look at how JVM negotiation takes place
greg.haskins (Thu, 31 Aug 2017 01:09:37 GMT):
e.g. --target/--source 1.6/1.7/1.8 etc
greg.haskins (Thu, 31 Aug 2017 01:09:52 GMT):
if you had that kind of facility, maybe
troyronda (Thu, 31 Aug 2017 01:09:54 GMT):
sorry don't follow
troyronda (Thu, 31 Aug 2017 01:10:18 GMT):
like a constraint matcher on which binary to load?
greg.haskins (Thu, 31 Aug 2017 01:10:19 GMT):
you are familiar with jvm environment in general, i assume
greg.haskins (Thu, 31 Aug 2017 01:10:43 GMT):
yes, like I mentioned before, version/feature negotiation
greg.haskins (Thu, 31 Aug 2017 01:11:02 GMT):
I can build a .jar for, say, 1.7 and then run it on jvm 1.9
greg.haskins (Thu, 31 Aug 2017 01:11:12 GMT):
it negotiates down to emulate 1.7 based on the payload
troyronda (Thu, 31 Aug 2017 01:11:19 GMT):
Sure
troyronda (Thu, 31 Aug 2017 01:11:59 GMT):
I had been thinking of a simpler constraint matcher (like go dep), but you are talking at the feature level
troyronda (Thu, 31 Aug 2017 01:12:18 GMT):
i.e., take the highest version that meets the constraints
greg.haskins (Thu, 31 Aug 2017 01:12:22 GMT):
if you had a robust feature/version negotiation AND a way to deterministically map from source to payload, I would be more open to the idea
greg.haskins (Thu, 31 Aug 2017 01:12:43 GMT):
without that, I dont think it makes sense to consider in a general framework
troyronda (Thu, 31 Aug 2017 01:12:47 GMT):
am i missing something on the deterministic map?
greg.haskins (Thu, 31 Aug 2017 01:12:54 GMT):
it seems, yes
greg.haskins (Thu, 31 Aug 2017 01:13:29 GMT):
let me play your argument back to you
greg.haskins (Thu, 31 Aug 2017 01:14:24 GMT):
you are saying "i have a well controlled group (consortium) and we agree to play nice such that everyone knows that type=BINARY was generated with process XYZ"
greg.haskins (Thu, 31 Aug 2017 01:14:47 GMT):
and therefore my determinism is derived from everyone doing process XYZ
troyronda (Thu, 31 Aug 2017 01:15:00 GMT):
and was process XYZ was appropriately review and the source code in that process was also appropriately reviewed
troyronda (Thu, 31 Aug 2017 01:15:00 GMT):
and was process XYZ was appropriately reviewed and the source code in that process was also appropriately reviewed
troyronda (Thu, 31 Aug 2017 01:15:00 GMT):
and process XYZ was appropriately reviewed and the source code in that process was also appropriately reviewed
greg.haskins (Thu, 31 Aug 2017 01:15:14 GMT):
sure, that goes without saying
greg.haskins (Thu, 31 Aug 2017 01:15:23 GMT):
but heres the problem
greg.haskins (Thu, 31 Aug 2017 01:16:38 GMT):
as a general purpose platform, we dont have that luxury of assuming everyone will know that is on them to sort out
greg.haskins (Thu, 31 Aug 2017 01:16:48 GMT):
and if they dont know its on them to sort out, its fragile
greg.haskins (Thu, 31 Aug 2017 01:17:31 GMT):
id rather it be an intrinsic property of the platform E.g. "I am a jar for jvm 1.7"
troyronda (Thu, 31 Aug 2017 01:17:32 GMT):
And I then I make the argument that this is still true with source-code based approaches
greg.haskins (Thu, 31 Aug 2017 01:17:45 GMT):
and the platform knows what it is, knows what to do with it, or can reject it if it doesnt
troyronda (Thu, 31 Aug 2017 01:17:47 GMT):
(if each participant doesn't review)
troyronda (Thu, 31 Aug 2017 01:18:02 GMT):
it's so easy not to review right now
greg.haskins (Thu, 31 Aug 2017 01:18:06 GMT):
ok, I will try to explain this one more time
troyronda (Thu, 31 Aug 2017 01:18:10 GMT):
install and insantiate
greg.haskins (Thu, 31 Aug 2017 01:18:21 GMT):
its not about review, its about attestation between what was reviewed, and what is executing
greg.haskins (Thu, 31 Aug 2017 01:18:32 GMT):
do this experiment
greg.haskins (Thu, 31 Aug 2017 01:18:43 GMT):
write "hello world" in golang
greg.haskins (Thu, 31 Aug 2017 01:19:34 GMT):
now run "go build" and hash it with say, shasum
greg.haskins (Thu, 31 Aug 2017 01:20:23 GMT):
repeat that process on every system ...even keeping things like "$arch" constant, do you think you will get the exact shasum on every system
greg.haskins (Thu, 31 Aug 2017 01:21:01 GMT):
say, OSX 10.12 verses ubuntu 16.04, verses alpine, vs OSX 10.11, or OSX 10.12 with todays patch, or .....
greg.haskins (Thu, 31 Aug 2017 01:21:04 GMT):
get the picture?
greg.haskins (Thu, 31 Aug 2017 01:21:21 GMT):
that binary is almost assuredly not going to generate the same shasum
greg.haskins (Thu, 31 Aug 2017 01:21:31 GMT):
but its the same code
greg.haskins (Thu, 31 Aug 2017 01:22:12 GMT):
even tiny things like libc.so are going to completely hose you
greg.haskins (Thu, 31 Aug 2017 01:22:44 GMT):
i.e. native binaries are poor vehicles for distributed systems that rely on determinism
greg.haskins (Thu, 31 Aug 2017 01:23:48 GMT):
so, if I review "hello world" and you review "hello world", but you give me a binary that shas differently than the one I produce, how do I know you didnt really send me "bonjour" instead?
greg.haskins (Thu, 31 Aug 2017 01:25:45 GMT):
i've been doing this a long time: im pretty skeptical that would offer even a modicum of determinism
greg.haskins (Thu, 31 Aug 2017 01:26:33 GMT):
and if its not deterministic, its of little value as a contract vehicle
troyronda (Thu, 31 Aug 2017 01:47:30 GMT):
@greg.haskins fyi - result of experiment .. only two machines though
troyronda (Thu, 31 Aug 2017 01:47:42 GMT):
machine 1 - mac osx; machine 2 - ubuntu
troyronda (Thu, 31 Aug 2017 01:47:47 GMT):
installed exact same docker image
troyronda (Thu, 31 Aug 2017 01:47:52 GMT):
on one:
troyronda (Thu, 31 Aug 2017 01:47:54 GMT):
root@61f715bba28b:/go/src# uname -a
Linux 61f715bba28b 4.9.41-moby #1 SMP Fri Aug 18 01:58:38 UTC 2017 x86_64 GNU/Linux
root@61f715bba28b:/go/src# sha256sum < src
37ead42bf5add387ab254727f805f15209ebf23f95cf0867a8b0e88d2564b4de -
troyronda (Thu, 31 Aug 2017 01:48:10 GMT):
on second: root@19853b642eaa:/go/src# uname -a
Linux 19853b642eaa 4.4.0-78-generic #99-Ubuntu SMP Thu Apr 27 15:29:09 UTC 2017 x86_64 GNU/Linux
root@19853b642eaa:/go/src# sha256sum < src
37ead42bf5add387ab254727f805f15209ebf23f95cf0867a8b0e88d2564b4de -
troyronda (Thu, 31 Aug 2017 01:48:27 GMT):
root@19853b642eaa:/go/src# ./src
hello world
troyronda (Thu, 31 Aug 2017 01:48:45 GMT):
(src is just the name of the executable because I was lazy and just dumped hello.go in the folder)
greg.haskins (Thu, 31 Aug 2017 01:48:49 GMT):
and how are you enforcing all users use "exact same docker image"
greg.haskins (Thu, 31 Aug 2017 01:49:13 GMT):
via process XYZ, right?
troyronda (Thu, 31 Aug 2017 01:49:16 GMT):
This isn't an issue - only those who need to review follow the instructions
troyronda (Thu, 31 Aug 2017 01:49:16 GMT):
This isn't an issue - only those who need to review and accept follow the instructions
troyronda (Thu, 31 Aug 2017 01:49:30 GMT):
Code reviewer(s) say they produce a certain hash
troyronda (Thu, 31 Aug 2017 01:49:35 GMT):
follow the instructions to validate
troyronda (Thu, 31 Aug 2017 01:49:35 GMT):
participants follow the instructions to validate
troyronda (Thu, 31 Aug 2017 01:49:39 GMT):
this is deterministic
troyronda (Thu, 31 Aug 2017 01:50:09 GMT):
instructions are simple
troyronda (Thu, 31 Aug 2017 01:50:30 GMT):
same as hashing a folder of source
troyronda (Thu, 31 Aug 2017 01:50:30 GMT):
same as hashing a folder of source, but in this case hashing a binary
troyronda (Thu, 31 Aug 2017 01:50:53 GMT):
if you trust the reviewer(s), or enough reviewers then this is all good
troyronda (Thu, 31 Aug 2017 01:52:17 GMT):
for those who are curious, this was the go 1.9. root@61f715bba28b:/go/src# go version
go version go1.9 linux/amd64
troyronda (Thu, 31 Aug 2017 01:52:25 GMT):
root@19853b642eaa:/go/src# go version
go version go1.9 linux/amd64
troyronda (Thu, 31 Aug 2017 01:54:36 GMT):
docker was started using docker run -it golang:1.9 bash
greg.haskins (Thu, 31 Aug 2017 01:55:21 GMT):
so, to be clear, i was talking about native platform go-execution, not in a docker container
greg.haskins (Thu, 31 Aug 2017 01:55:25 GMT):
but lets talk about that
greg.haskins (Thu, 31 Aug 2017 01:55:30 GMT):
what does your dockerfile look like?
troyronda (Thu, 31 Aug 2017 02:08:16 GMT):
For simplicity, I just used the first one I saw that already installed Go 1.9 (https://hub.docker.com/_/golang/ ; https://github.com/docker-library/golang/blob/94e49ca93c5bbf172e462cea8872c77f9bc08c10/1.9/stretch/Dockerfile)
troyronda (Thu, 31 Aug 2017 02:08:48 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=XJ6SeFSitSAWnxFtQ) ok - I always assumed I would create the same environment
greg.haskins (Thu, 31 Aug 2017 02:09:30 GMT):
any thoughts about this line w.r.t. determinism?: https://github.com/docker-library/golang/blob/94e49ca93c5bbf172e462cea8872c77f9bc08c10/1.9/stretch/Dockerfile#L4
troyronda (Thu, 31 Aug 2017 02:09:32 GMT):
(not that I would use this one in particular)
greg.haskins (Thu, 31 Aug 2017 02:09:42 GMT):
how about running "ldd ./src"
troyronda (Thu, 31 Aug 2017 02:10:03 GMT):
the dockerfile that one would actually use would need to lock the apt repo sources for example
greg.haskins (Thu, 31 Aug 2017 02:10:30 GMT):
ok, so maybe "use docker is process X, and use fixed containers is process Y
greg.haskins (Thu, 31 Aug 2017 02:10:37 GMT):
what else is in the mix?
greg.haskins (Thu, 31 Aug 2017 02:10:45 GMT):
what is that binary linked against?
troyronda (Thu, 31 Aug 2017 02:10:45 GMT):
but my point was just to see if the same docker image across two OSes with Golang resulted in the same
troyronda (Thu, 31 Aug 2017 02:10:45 GMT):
but my goal was just to see if the same docker image across two OSes with Golang resulted in the same
greg.haskins (Thu, 31 Aug 2017 02:11:15 GMT):
what do you get when you look at the linker tables
greg.haskins (Thu, 31 Aug 2017 02:11:21 GMT):
?
troyronda (Thu, 31 Aug 2017 02:11:24 GMT):
root@61f715bba28b:/go/src# ldd ./src
not a dynamic executable
root@61f715bba28b:/go/src# ./src
hello world
root@61f715bba28b:/go/src#
greg.haskins (Thu, 31 Aug 2017 02:11:53 GMT):
is this system on glibc?
greg.haskins (Thu, 31 Aug 2017 02:12:57 GMT):
musl perhaps?
troyronda (Thu, 31 Aug 2017 02:13:10 GMT):
root@61f715bba28b:/go/src# ldd --version
ldd (Debian GLIBC 2.24-11+deb9u1) 2.24
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
root@61f715bba28b:/go/src#
greg.haskins (Thu, 31 Aug 2017 02:13:31 GMT):
do you see any instances of dlopen in the symbol table?
troyronda (Thu, 31 Aug 2017 02:15:32 GMT):
no
troyronda (Thu, 31 Aug 2017 02:15:56 GMT):
(if this is sufficient: readelf --symbols src | grep -i dlopen)
greg.haskins (Thu, 31 Aug 2017 02:16:27 GMT):
not sure...the real test will be to try to have the image try to gethostbyname()
greg.haskins (Thu, 31 Aug 2017 02:17:08 GMT):
usually when you link to glibc, even statically, it will embed a call to dlopen the libnss.so stuff
greg.haskins (Thu, 31 Aug 2017 02:17:18 GMT):
depending on how it was compiled
greg.haskins (Thu, 31 Aug 2017 02:20:05 GMT):
if the container you used happens to be close enough to the libnss.so available in the baseos container, it may get past that hurdle too
greg.haskins (Thu, 31 Aug 2017 02:20:41 GMT):
assuming we dont go to FROM scratch/busybox again, which we did in the past
troyronda (Thu, 31 Aug 2017 02:25:58 GMT):
root@373aaaf4a98c:/go/src/hello2# go build
root@373aaaf4a98c:/go/src/hello2# ./hello2
address: [23.185.0.4 2620:12a:8000::4 2620:12a:8001::4]
root@373aaaf4a98c:/go/src/hello2# sha256sum < hello2
82ff9bf158bf35d8a9b9dba65ce24b4dde60c18c9d54e2b1e0dfe0422bbb1ff1 -
root@373aaaf4a98c:/go/src/hello2# ldd hello2
linux-vdso.so.1 (0x00007fff0cd2e000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fd3cf94b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd3cf5ac000)
/lib64/ld-linux-x86-64.so.2 (0x000055a8c41a5000)
root@373aaaf4a98c:/go/src/hello2#
greg.haskins (Thu, 31 Aug 2017 02:26:44 GMT):
so thats dynamically linked...thats even worse
troyronda (Thu, 31 Aug 2017 02:26:49 GMT):
root@61f715bba28b:/go/src/hello2# go build
root@61f715bba28b:/go/src/hello2# ./hello2
address: [23.185.0.4 ffff:ffff:8000::4 ffff:ffff:8001::4]
root@61f715bba28b:/go/src/hello2# sha256sum < hello2
82ff9bf158bf35d8a9b9dba65ce24b4dde60c18c9d54e2b1e0dfe0422bbb1ff1 -
root@61f715bba28b:/go/src/hello2# ldd hello2
linux-vdso.so.1 (0x00007fffc9703000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f81c870e000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f81c836f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f81c892b000)
root@61f715bba28b:/go/src/hello2#
greg.haskins (Thu, 31 Aug 2017 02:26:54 GMT):
what was the difference in how you compiled the first "src"
troyronda (Thu, 31 Aug 2017 02:27:10 GMT):
Different source code, same build command
troyronda (Thu, 31 Aug 2017 02:27:12 GMT):
(go build)
troyronda (Thu, 31 Aug 2017 02:27:37 GMT):
root@61f715bba28b:/go/src/hello2# cat hello2.go
package main
import (
"fmt"
"net"
)
func main() {
addrs, err := net.LookupHost("hyperledger.org")
if err == nil {
fmt.Printf("address: %v\n", addrs)
} else {
fmt.Printf("error: %v\n", err)
}
}
root@61f715bba28b:/go/src/hello2#
greg.haskins (Thu, 31 Aug 2017 02:28:29 GMT):
ok, now take "hello2" and put it in a "FROM scratch" container
greg.haskins (Thu, 31 Aug 2017 02:28:56 GMT):
(actually put both the static link and dyn linked ones in, just for fun)
greg.haskins (Thu, 31 Aug 2017 02:32:16 GMT):
something like this ```FROM scratch
WORKDIR /usr/local/app
COPY hello2 .
CMD ./hello2```
troyronda (Thu, 31 Aug 2017 02:35:54 GMT):
ok
troyronda (Thu, 31 Aug 2017 02:36:30 GMT):
i hadn't bothered with cmd, but did this:
troyronda (Thu, 31 Aug 2017 02:36:31 GMT):
➜ d docker run -it 172603008db3 /hello
hello world
➜ d docker run -it 172603008db3 /hello2
standard_init_linux.go:187: exec user process caused "no such file or directory"
greg.haskins (Thu, 31 Aug 2017 02:36:52 GMT):
sure, thats fine
greg.haskins (Thu, 31 Aug 2017 02:37:35 GMT):
its hard to tell from the output, but I think that bottom one is an example of my point
greg.haskins (Thu, 31 Aug 2017 02:38:17 GMT):
its likely dying because it cant find things like /lib/x86_64-linux-gnu/libc.so.6
greg.haskins (Thu, 31 Aug 2017 02:38:45 GMT):
so, you can partially mitigate that by forcing the link as static
greg.haskins (Thu, 31 Aug 2017 02:39:00 GMT):
but, I suspect your net.LookupHost will still fail
troyronda (Thu, 31 Aug 2017 02:39:23 GMT):
Those .so would be in the peer-created docker image
greg.haskins (Thu, 31 Aug 2017 02:39:46 GMT):
anyway, main point is that even with docker normalizing the tool chain, you still have decoupled environments
greg.haskins (Thu, 31 Aug 2017 02:39:57 GMT):
and theres no negotiation of this as far as I can tell
troyronda (Thu, 31 Aug 2017 02:40:13 GMT):
If I submit the source code for the peer to compile, the same thing happen
greg.haskins (Thu, 31 Aug 2017 02:40:18 GMT):
those would really be the two main things I would want to see addressed
greg.haskins (Thu, 31 Aug 2017 02:40:34 GMT):
well, no, because the peer compiles it to its environment
greg.haskins (Thu, 31 Aug 2017 02:41:28 GMT):
for instance, if one peer has /lib/libc.musl-x86_64.so.1 and another has /lib/libc.glibc-x86_64.so.1, each is linked locally
greg.haskins (Thu, 31 Aug 2017 02:41:28 GMT):
for instance, if one peer has /lib/libc.musl-x86_64.so.1 and another has /lib/libc.glibc-ppcle64.so.1, each is linked locally
troyronda (Thu, 31 Aug 2017 02:41:58 GMT):
Is that expected?
greg.haskins (Thu, 31 Aug 2017 02:42:02 GMT):
yes
troyronda (Thu, 31 Aug 2017 02:42:05 GMT):
in the docker image
troyronda (Thu, 31 Aug 2017 02:42:17 GMT):
not on the peer because that's not relevant
troyronda (Thu, 31 Aug 2017 02:42:27 GMT):
in the docker image environment that the CC is injected into
greg.haskins (Thu, 31 Aug 2017 02:42:31 GMT):
yes, its expected
greg.haskins (Thu, 31 Aug 2017 02:42:54 GMT):
even in just the simple example of heterogeneous $arch
greg.haskins (Thu, 31 Aug 2017 02:43:23 GMT):
the ppcle team could very well have built their container with a different lineage
greg.haskins (Thu, 31 Aug 2017 02:44:10 GMT):
in fact, they do today, though they all have debian roots so its "sorta" normalized
greg.haskins (Thu, 31 Aug 2017 02:44:15 GMT):
but you cant bank on that
troyronda (Thu, 31 Aug 2017 02:44:42 GMT):
does bring up a question about even with source submitted if everything always works then
greg.haskins (Thu, 31 Aug 2017 02:44:51 GMT):
also consider things like we base on debian/ubuntu today, but I know the redhat folks are busy porting it over to RH ecosystem
greg.haskins (Thu, 31 Aug 2017 02:45:14 GMT):
so you could easily have a network were some peers are ubuntu and others are rhel based, for example
greg.haskins (Thu, 31 Aug 2017 02:45:26 GMT):
or, the next drop could be alpine based, whatever
troyronda (Thu, 31 Aug 2017 02:45:34 GMT):
(not scripts like node, but source that is compiled)
troyronda (Thu, 31 Aug 2017 02:45:43 GMT):
(like the existing golang platform)
greg.haskins (Thu, 31 Aug 2017 02:45:54 GMT):
yes, so even the source needs better ABI management than we have today
greg.haskins (Thu, 31 Aug 2017 02:45:59 GMT):
i have been arguing for this
greg.haskins (Thu, 31 Aug 2017 02:46:20 GMT):
but the problem is greatly exacerbated by the proposition of binary payloads
greg.haskins (Thu, 31 Aug 2017 02:46:23 GMT):
thus my objections
troyronda (Thu, 31 Aug 2017 02:47:50 GMT):
unless the binary is static linked...
greg.haskins (Thu, 31 Aug 2017 02:48:07 GMT):
not to shamelessly plug my own project, but I was trying to tackle this problem in chaintool with the notion of "platform specifier"
greg.haskins (Thu, 31 Aug 2017 02:48:12 GMT):
http://fabric-chaintool.readthedocs.io/en/latest/platforms/golang/#platform-specifier
greg.haskins (Thu, 31 Aug 2017 02:48:32 GMT):
something like that is similar to the "jar v1.7 on jvm v1.9"
greg.haskins (Thu, 31 Aug 2017 02:48:37 GMT):
notion
troyronda (Thu, 31 Aug 2017 02:48:52 GMT):
To be honest, when I first heard about that tool - before reading the description, i had thought it would create packaged binaries from me
troyronda (Thu, 31 Aug 2017 02:48:52 GMT):
To be honest, when I first heard about that tool - before reading the description, i had thought it would create packaged binaries from mefor
troyronda (Thu, 31 Aug 2017 02:48:52 GMT):
To be honest, when I first heard about that tool - before reading the description, i had thought it would create packaged binaries for me
troyronda (Thu, 31 Aug 2017 02:48:53 GMT):
;)
greg.haskins (Thu, 31 Aug 2017 02:49:06 GMT):
even static linked isnt a panecea...static linking is really weak in golang/glibc
greg.haskins (Thu, 31 Aug 2017 02:49:31 GMT):
theres that nasty problem with gethostbyname to contend with
troyronda (Thu, 31 Aug 2017 02:49:32 GMT):
that I would have something to plug into my build system :)
greg.haskins (Thu, 31 Aug 2017 02:49:46 GMT):
and theres still the problem that you cant predict the $arch that might be in the network
troyronda (Thu, 31 Aug 2017 02:50:13 GMT):
<= fabric supported archs :)
troyronda (Thu, 31 Aug 2017 02:50:41 GMT):
these problems are less so for binaries derived from go
greg.haskins (Thu, 31 Aug 2017 02:50:43 GMT):
yes...but to my point...each one of those constraints are one more point of fragility
greg.haskins (Thu, 31 Aug 2017 02:51:03 GMT):
and trust me, if its there, users will try to shove @##$ into it, and then we get the hard to decipher bug reports
greg.haskins (Thu, 31 Aug 2017 02:53:07 GMT):
so, I would really rather see a strong story about deterministic payloads, ideally universal $arch/$distro neutrality, and feature/compat negotiation
troyronda (Thu, 31 Aug 2017 02:54:58 GMT):
I'm still wondering about a mechanism to bring in a binary library that is loaded by submitted source (that the peer compiles).
greg.haskins (Thu, 31 Aug 2017 02:55:40 GMT):
that seems more like an alternate way to do the same concept, with the same concerns
greg.haskins (Thu, 31 Aug 2017 02:56:11 GMT):
i still think you are barking up the wrong tree with native object code
greg.haskins (Thu, 31 Aug 2017 02:57:01 GMT):
if you want to deploy obfuscated uberjars on top of a JVM, written in clojure, im all over that
greg.haskins (Thu, 31 Aug 2017 02:57:05 GMT):
;)
troyronda (Thu, 31 Aug 2017 02:57:23 GMT):
yeh ha.
greg.haskins (Thu, 31 Aug 2017 02:57:54 GMT):
if my team and I can ever get some spare cycles, we'll be tackling that
troyronda (Thu, 31 Aug 2017 02:58:22 GMT):
The obfuscated part?
greg.haskins (Thu, 31 Aug 2017 02:59:00 GMT):
well, my interest in is clojure chaincode in general...but I can see how that could be extended to .jar deployment model fairly trivially and without the issues I am raising now
troyronda (Thu, 31 Aug 2017 02:59:24 GMT):
Ah - I was curious if you had an obfuscation use case :)
greg.haskins (Thu, 31 Aug 2017 02:59:39 GMT):
it would at least solve 2 of the 3 concerns cleanly, and the third could be managed I think
greg.haskins (Thu, 31 Aug 2017 03:00:01 GMT):
its not high on my radar now, but I can understand why it interest you
greg.haskins (Thu, 31 Aug 2017 03:01:13 GMT):
anyway, that is why I initially suggested the JVM/LLVM route
troyronda (Thu, 31 Aug 2017 03:01:15 GMT):
From the above, it does seem that object code produced specifically from Go has potential though (still pushing)
greg.haskins (Thu, 31 Aug 2017 03:01:33 GMT):
yeah, the problem is that it "feels" like that when you first get into it
greg.haskins (Thu, 31 Aug 2017 03:01:49 GMT):
but it leads to disappointment/despair ;)
troyronda (Thu, 31 Aug 2017 03:02:01 GMT):
I felt good so far ;)
greg.haskins (Thu, 31 Aug 2017 03:02:32 GMT):
look in JIRA for my foray into busybox optimization
greg.haskins (Thu, 31 Aug 2017 03:02:53 GMT):
so promising based on golang+static
greg.haskins (Thu, 31 Aug 2017 03:03:00 GMT):
25MB containers
greg.haskins (Thu, 31 Aug 2017 03:03:06 GMT):
only to get whacked by NSS
troyronda (Thu, 31 Aug 2017 03:03:18 GMT):
doh!
greg.haskins (Thu, 31 Aug 2017 03:03:48 GMT):
thats why I brought up the dlopen thing...thats the part that screwed me
greg.haskins (Thu, 31 Aug 2017 03:04:49 GMT):
the other route might be to go in the other direction
greg.haskins (Thu, 31 Aug 2017 03:04:58 GMT):
docker containers exported
troyronda (Thu, 31 Aug 2017 03:05:26 GMT):
See this is where I think object code that is loaded from a submitted source has an advantage (that object code could be very simple and not have dependencies)
greg.haskins (Thu, 31 Aug 2017 03:05:31 GMT):
but even that I suspect is fragile in this ecosystem
troyronda (Thu, 31 Aug 2017 03:06:05 GMT):
(simple meaning not needing to link to things)
greg.haskins (Thu, 31 Aug 2017 03:06:29 GMT):
yes, and that is why I was steering you to xVM code, because it has those properties AND not the other issues
greg.haskins (Thu, 31 Aug 2017 03:06:46 GMT):
e.g. uberjar on jvm, or whatever
troyronda (Thu, 31 Aug 2017 03:06:52 GMT):
Codebase is in Go... I didn't see a good path ...
troyronda (Thu, 31 Aug 2017 03:06:52 GMT):
Codebase is in Go... I didn't see a good path on llvm...
greg.haskins (Thu, 31 Aug 2017 03:06:59 GMT):
LLVM is actually really cool, though I dont know how golang support is on it
greg.haskins (Thu, 31 Aug 2017 03:07:16 GMT):
I know historically its been strongest in the C++ space
greg.haskins (Thu, 31 Aug 2017 03:07:23 GMT):
but the model is awesome for this stuff
troyronda (Thu, 31 Aug 2017 03:07:25 GMT):
there is a project but it doesn't look too active
troyronda (Thu, 31 Aug 2017 03:07:37 GMT):
i only know it from swift
greg.haskins (Thu, 31 Aug 2017 03:08:12 GMT):
yeah...its been awhile but there is the notion of a discrete front-end and back-end
troyronda (Thu, 31 Aug 2017 03:08:34 GMT):
(and I was wondering how well obfuscation actually ends up working if you use something like llvm)
greg.haskins (Thu, 31 Aug 2017 03:08:45 GMT):
so you can have something like clang compile C++ to .llvm and then JIT it on the target platform in the llvm runtime
greg.haskins (Thu, 31 Aug 2017 03:09:15 GMT):
ive never looked but in theory its no different than x86_64 object code
greg.haskins (Thu, 31 Aug 2017 03:09:32 GMT):
its just like a different $arch, and one that can be JIT'ed to a host $arch with high performance
greg.haskins (Thu, 31 Aug 2017 03:10:08 GMT):
im sure you can strip debug symbols, etc, to get a similar surface as standard machine code
greg.haskins (Thu, 31 Aug 2017 03:10:23 GMT):
anyway, I digress
greg.haskins (Thu, 31 Aug 2017 03:10:55 GMT):
anyway, im toast for the day
greg.haskins (Thu, 31 Aug 2017 03:10:59 GMT):
thanks for the chat
troyronda (Thu, 31 Aug 2017 03:11:02 GMT):
ok good night!
troyronda (Thu, 31 Aug 2017 03:11:08 GMT):
thanks for taking the time
troyronda (Thu, 31 Aug 2017 03:14:59 GMT):
I did one last experiment - static linking hello2
troyronda (Thu, 31 Aug 2017 03:15:01 GMT):
root@61f715bba28b:/go/src/hello2# CGO_ENABLED=0 GOOS=linux go build -a -ldflags '-extldflags "-static"' .
root@61f715bba28b:/go/src/hello2# ./hello2
address: [23.185.0.4 ffff:ffff:8000::4 ffff:ffff:8001::4]
root@61f715bba28b:/go/src/hello2# ldd hello2
not a dynamic executable
root@61f715bba28b:/go/src/hello2# sha256sum < hello2
4a832b59e0203541ef3bf10796efeed09be644f0b61469b367d4b57390316c97 -
root@61f715bba28b:/go/src/hello2#
troyronda (Thu, 31 Aug 2017 03:15:11 GMT):
root@373aaaf4a98c:/go/src/hello2# CGO_ENABLED=0 GOOS=linux go build -a -ldflags '-extldflags "-static"' .
root@373aaaf4a98c:/go/src/hello2# ./hello2
address: [23.185.0.4 2620:12a:8000::4 2620:12a:8001::4]
root@373aaaf4a98c:/go/src/hello2# ldd hello2
not a dynamic executable
root@373aaaf4a98c:/go/src/hello2# sha256sum < hello2
4a832b59e0203541ef3bf10796efeed09be644f0b61469b367d4b57390316c97 -
root@373aaaf4a98c:/go/src/hello2#
troyronda (Thu, 31 Aug 2017 03:16:38 GMT):
➜ d docker run -it 663221ffe5db /hello2
address: [23.185.0.4 ffff:ffff:8000::4 ffff:ffff:8001::4]
➜ d
troyronda (Thu, 31 Aug 2017 03:16:50 GMT):
(this is the scratch container)
troyronda (Thu, 31 Aug 2017 03:16:50 GMT):
(this is the from scratch container with the static linked hello2)
greg.haskins (Thu, 31 Aug 2017 12:05:23 GMT):
@troyronda ah, CGO_ENABLED=0 is cheating
greg.haskins (Thu, 31 Aug 2017 12:05:32 GMT):
the shim is not compatible
troyronda (Thu, 31 Aug 2017 12:05:57 GMT):
Shim is not compatible?
greg.haskins (Thu, 31 Aug 2017 12:05:58 GMT):
and if you dont have CGO_ENABLED=0, you are screwed because it becomes coupled to libc version you compiled on
greg.haskins (Thu, 31 Aug 2017 12:06:04 GMT):
no, unfortunately
greg.haskins (Thu, 31 Aug 2017 12:06:11 GMT):
its all coming back to me now
greg.haskins (Thu, 31 Aug 2017 12:06:32 GMT):
CGO is required, CGO requires xlibc, xlibc binds you to unportable binary
troyronda (Thu, 31 Aug 2017 12:06:56 GMT):
confused... shouldn't all the shim need to do is enable protobufs back to the peer?
greg.haskins (Thu, 31 Aug 2017 12:07:33 GMT):
one of the direct/transitive crypto libraries that the shim uses/provides requires CGO, IIRC
troyronda (Thu, 31 Aug 2017 12:07:59 GMT):
My solution with a binary loader is unaffected :)
greg.haskins (Thu, 31 Aug 2017 12:08:22 GMT):
i dont think so
troyronda (Thu, 31 Aug 2017 12:08:48 GMT):
shim would be compiled to the source code that was submitted ... the rest of the code would be object code
greg.haskins (Thu, 31 Aug 2017 12:08:53 GMT):
anyway, point being, you are dancing with fragility
greg.haskins (Thu, 31 Aug 2017 12:08:57 GMT):
there are many ways to lose
troyronda (Thu, 31 Aug 2017 12:09:14 GMT):
(remember in that solution, object code is submitted not a binary)
troyronda (Thu, 31 Aug 2017 12:09:32 GMT):
the binary is created similar to now, but linked to an additional library (or loads a submitted .so)
troyronda (Thu, 31 Aug 2017 12:09:49 GMT):
this seems to be the most elegant mechanism to me
greg.haskins (Thu, 31 Aug 2017 12:09:49 GMT):
have you tried using .so's with golang?
troyronda (Thu, 31 Aug 2017 12:10:28 GMT):
I want to see how golang plugins look in 1.9
greg.haskins (Thu, 31 Aug 2017 12:10:46 GMT):
yes, that is the most promising for what you are proposing
greg.haskins (Thu, 31 Aug 2017 12:10:55 GMT):
i can tell you its basically a non-starter pre v1.9
greg.haskins (Thu, 31 Aug 2017 12:11:16 GMT):
BUT, I also think we need to get away from decoupling the shim from the code
greg.haskins (Thu, 31 Aug 2017 12:11:28 GMT):
so you are reintroducing a problem I am trying to get rid of
troyronda (Thu, 31 Aug 2017 12:12:00 GMT):
Just an example of how something could work against what exists
troyronda (Thu, 31 Aug 2017 12:12:36 GMT):
If there was a decoupling for the source code version, then a decoupling would exist for this solution too
troyronda (Thu, 31 Aug 2017 12:13:05 GMT):
(since I am basically saying you could use the golang source code version but allow object code linking)
greg.haskins (Thu, 31 Aug 2017 12:13:05 GMT):
no no, what i am saying is: decoupling for source is how we do it today, and its a broken model
greg.haskins (Thu, 31 Aug 2017 12:13:15 GMT):
I am advocating we _stop_ doing that
greg.haskins (Thu, 31 Aug 2017 12:13:16 GMT):
https://jira.hyperledger.org/browse/FAB-5177
greg.haskins (Thu, 31 Aug 2017 12:13:38 GMT):
the ABI management should be at the GRPC level, not chaincode->shim level
troyronda (Thu, 31 Aug 2017 12:14:00 GMT):
yes I get that - and that would be my gut as well
troyronda (Thu, 31 Aug 2017 12:14:21 GMT):
but i feel that it reinforces the point that CC applications are simply seperate services from the peer
troyronda (Thu, 31 Aug 2017 12:14:34 GMT):
and then you could ask why is there an install command at all
greg.haskins (Thu, 31 Aug 2017 12:14:58 GMT):
not following your last comment
greg.haskins (Thu, 31 Aug 2017 12:15:10 GMT):
isnt "install" simply a way to distribute your payload?
troyronda (Thu, 31 Aug 2017 12:15:21 GMT):
yes - there are many ways to do that today
greg.haskins (Thu, 31 Aug 2017 12:15:22 GMT):
what does that have to do with its runtime environment or topology?
troyronda (Thu, 31 Aug 2017 12:16:43 GMT):
(sorry it's a digression)
greg.haskins (Thu, 31 Aug 2017 12:17:48 GMT):
so, i agree that the BINARY proposal similarly solves FAB-5177, but the problem is the other issues I pointed out
yacovm (Thu, 31 Aug 2017 12:17:49 GMT):
> the ABI management should be at the GRPC level, not chaincode->shim level
What do you mean? (Hi :) )
greg.haskins (Thu, 31 Aug 2017 12:18:19 GMT):
greetings @yacovm
greg.haskins (Thu, 31 Aug 2017 12:19:12 GMT):
@yacovm its coverd ad nauseam in FAB-5177, so I wont repeat it here
yacovm (Thu, 31 Aug 2017 12:19:37 GMT):
btw I was thinking about a similar topic - if we had a more easy to use API between the peer and the shim, we could have simply declared an API that the peer would've used to serve a shim, via protobuf, and then just declared, that you can simply install a *container* into the peer and that *container* would be simply spawned.
What do you think?
greg.haskins (Thu, 31 Aug 2017 12:19:43 GMT):
in particular, read my last comment
troyronda (Thu, 31 Aug 2017 12:20:00 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=RSKr5ExydSW9i7XMq) or any other package management system
troyronda (Thu, 31 Aug 2017 12:20:00 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=RSKr5ExydSW9i7XMq) or any other package management system... or things like ansible
troyronda (Thu, 31 Aug 2017 12:20:00 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=RSKr5ExydSW9i7XMq) or any other package management system... or things like ansible... that was where I was leading into with my digression above...
yacovm (Thu, 31 Aug 2017 12:20:11 GMT):
of course - this is only in theory and in retrospect, no something we have the manpower / time for IMO
greg.haskins (Thu, 31 Aug 2017 12:21:21 GMT):
@yacovm as far as that API is concerned, we more or less have that today
yacovm (Thu, 31 Aug 2017 12:21:30 GMT):
no, the API sucks.
greg.haskins (Thu, 31 Aug 2017 12:21:33 GMT):
theres a GRPC contract between the chaincode and peer
greg.haskins (Thu, 31 Aug 2017 12:21:39 GMT):
ok, well, thats a different problem
yacovm (Thu, 31 Aug 2017 12:21:39 GMT):
yeah I think it's not good
greg.haskins (Thu, 31 Aug 2017 12:21:55 GMT):
thats fair...but ignore that for a second
greg.haskins (Thu, 31 Aug 2017 12:21:59 GMT):
lets say it didnt suck
yacovm (Thu, 31 Aug 2017 12:22:01 GMT):
but that's what you get when you just add more and more features
yacovm (Thu, 31 Aug 2017 12:22:01 GMT):
but that's what you get when you just add more and more features. if we knew the features ahead...
greg.haskins (Thu, 31 Aug 2017 12:22:38 GMT):
all I was saying is that its easier to do ABI management between two GRPC endpoints than it is to do ABI management between a golang application and a golang library
yacovm (Thu, 31 Aug 2017 12:22:50 GMT):
I totally agree
greg.haskins (Thu, 31 Aug 2017 12:22:51 GMT):
thats it, really
greg.haskins (Thu, 31 Aug 2017 12:23:13 GMT):
if the GRPC contract sucks, lets fix that
yacovm (Thu, 31 Aug 2017 12:23:37 GMT):
I don't think it's that easy. compatibility, etc.
I'd like to see a "ng" (next-gen) chaincode or something
yacovm (Thu, 31 Aug 2017 12:23:39 GMT):
that would do just that
yacovm (Thu, 31 Aug 2017 12:23:44 GMT):
and we can provide with a toolbox
yacovm (Thu, 31 Aug 2017 12:23:47 GMT):
to make it easy
yacovm (Thu, 31 Aug 2017 12:23:50 GMT):
and examples, etc.
yacovm (Thu, 31 Aug 2017 12:24:32 GMT):
but I'm now acting as an armchair economist, etc.
I don't think it'll actually happen soon
troyronda (Thu, 31 Aug 2017 12:25:43 GMT):
The issue I was having above is how to deal with & distribute Golang CC that isn't being compiled by the peer (without getting into a fork)
troyronda (Thu, 31 Aug 2017 12:25:54 GMT):
I agree with the grpc point
yacovm (Thu, 31 Aug 2017 12:26:02 GMT):
if we have a chaincode type: container
yacovm (Thu, 31 Aug 2017 12:26:04 GMT):
that'd be easy ;)
greg.haskins (Thu, 31 Aug 2017 12:26:57 GMT):
@yacovm you are essentially making the same argument as @troyronda
troyronda (Thu, 31 Aug 2017 12:26:59 GMT):
would this type imply that the container was installed out-of-band of the install command
greg.haskins (Thu, 31 Aug 2017 12:27:05 GMT):
except his "container" is a static golang binary
troyronda (Thu, 31 Aug 2017 12:27:17 GMT):
which is injected into a container by the peer ;)
greg.haskins (Thu, 31 Aug 2017 12:27:21 GMT):
(well, a multi-arch golang binary
greg.haskins (Thu, 31 Aug 2017 12:27:44 GMT):
but there are a few problems to sort out
troyronda (Thu, 31 Aug 2017 12:28:12 GMT):
yes longer version: multi-arch golang binary, that can have the minimum source code to link against the chaincode shim library, and is then injected into a container
troyronda (Thu, 31 Aug 2017 12:28:24 GMT):
the minimum source code bit is how we got on this GRPC topic :)
greg.haskins (Thu, 31 Aug 2017 12:28:40 GMT):
yeah..and I would drop that part of it honestly
greg.haskins (Thu, 31 Aug 2017 12:28:46 GMT):
i think its taking it in the wrong direction
troyronda (Thu, 31 Aug 2017 12:29:02 GMT):
I'm only saying that due to the current situation - not because i like it :)
greg.haskins (Thu, 31 Aug 2017 12:29:11 GMT):
I like the notion of "something that just needs a GRPC endpoint" which is closer to your original BINARY propsal
greg.haskins (Thu, 31 Aug 2017 12:29:16 GMT):
got it
greg.haskins (Thu, 31 Aug 2017 12:29:49 GMT):
but as I said, I am trying to eradicate that problem, not cement it as a requirement to solve a different problem ;)
greg.haskins (Thu, 31 Aug 2017 12:31:34 GMT):
but do you at least see my concern w.r.t. an "auto-vendored" source payload being the most robust way to solve the various problems I highlighted?
troyronda (Thu, 31 Aug 2017 12:32:16 GMT):
of course - ideally it would simply be a grpc contract and more like micro-services
troyronda (Thu, 31 Aug 2017 12:32:16 GMT):
of course - ideally it would simply be a grpc contract
greg.haskins (Thu, 31 Aug 2017 12:32:39 GMT):
right...its just that golang isnt a great way to do this
greg.haskins (Thu, 31 Aug 2017 12:33:18 GMT):
(IMO)
troyronda (Thu, 31 Aug 2017 12:33:27 GMT):
which part?
greg.haskins (Thu, 31 Aug 2017 12:33:53 GMT):
well, just in general, as a universal binary
greg.haskins (Thu, 31 Aug 2017 12:34:29 GMT):
the golang folks somewhat tried with the --static thing, but its a bit half-arsed
greg.haskins (Thu, 31 Aug 2017 12:35:06 GMT):
they did a great job with the ubiquitous x-compile out of the can
troyronda (Thu, 31 Aug 2017 12:35:09 GMT):
Golang has much easier x-compile than many other solutions - its not byte code but its nice
greg.haskins (Thu, 31 Aug 2017 12:35:14 GMT):
thats probably the best x-compile ive ever seen
troyronda (Thu, 31 Aug 2017 12:35:24 GMT):
agree
greg.haskins (Thu, 31 Aug 2017 12:35:24 GMT):
agreed, I agree its the best
greg.haskins (Thu, 31 Aug 2017 12:35:28 GMT):
but its not perfect
greg.haskins (Thu, 31 Aug 2017 12:36:27 GMT):
one of the mistakes I think that was made was they took the integration to 85% and then let things like g++/clang bleed through
greg.haskins (Thu, 31 Aug 2017 12:36:32 GMT):
that causes some of the problems ive seen
greg.haskins (Thu, 31 Aug 2017 12:36:48 GMT):
and things like CGO, etc, being another
troyronda (Thu, 31 Aug 2017 12:39:43 GMT):
yeh...
troyronda (Thu, 31 Aug 2017 12:44:13 GMT):
btw - the reason I'm pushing so much on this topic is that I believe that you should be able to use an off-the-shelf fabric peer and then simply add-on the specific behaviors for a consortium - those specific behaviors having appropriate reviews. I don't think having to have forks of the base system is a good-long steady-state strategy (so I end up believing in a strong base that is extensible). I also think it's important to enable an ecosystem of independent developers of CC/consortium applications...
troyronda (Thu, 31 Aug 2017 12:44:13 GMT):
btw - the reason I'm pushing so much on this topic is that I believe that you should be able to use an off-the-shelf fabric peer and then simply add-on the specific behaviors for a consortium - those specific behaviors having appropriate reviews. I don't think having to have forks of the base system is a good steady-state strategy (so I end up believing in a strong base that is extensible). I also think it's important to enable an ecosystem of independent developers of CC/consortium applications...
troyronda (Thu, 31 Aug 2017 12:44:13 GMT):
btw - one of the reasons I'm pushing so much on this topic is that I believe that you should be able to use an off-the-shelf fabric peer and then simply add-on the specific behaviors for a consortium - those specific behaviors having appropriate reviews. I don't think having to have forks of the base system is a good steady-state strategy (so I end up believing in a strong base that is extensible). I also think it's important to enable an ecosystem of independent developers of CC/consortium applications...
troyronda (Thu, 31 Aug 2017 12:47:45 GMT):
(i.e., i hate maintaining cherry picked code in the base system & I much prefer the decoupled reviewability)
greg.haskins (Thu, 31 Aug 2017 12:48:15 GMT):
thats understandable...but I still dont think the review argument applies here
greg.haskins (Thu, 31 Aug 2017 12:48:43 GMT):
perhaps part of the problem is we changed the instance addressing a while back which weakened the relationship a bit
greg.haskins (Thu, 31 Aug 2017 12:48:49 GMT):
but I am working on putting that back
troyronda (Thu, 31 Aug 2017 12:49:03 GMT):
(review of fabric vs the various consortium extensions)
troyronda (Thu, 31 Aug 2017 12:49:03 GMT):
(review of fabric vs the various consortium extensions such as CC)
greg.haskins (Thu, 31 Aug 2017 12:49:58 GMT):
but anyway, I understand why its desirable to be upstream: all I am saying is it cant (IMO) go upstream if its not robust enough or general enough
greg.haskins (Thu, 31 Aug 2017 12:50:12 GMT):
and we havent got it over that bar yet
greg.haskins (Thu, 31 Aug 2017 12:51:00 GMT):
like I said, I could see how some kind of uberjar-on-jvm scenario could meet all those criteria...i think golang is a little weak in this regard
greg.haskins (Thu, 31 Aug 2017 12:51:16 GMT):
so its not the concepts per se, just the impl
troyronda (Thu, 31 Aug 2017 12:51:43 GMT):
the thing is golang ended up as the first/default CC platform
troyronda (Thu, 31 Aug 2017 12:52:07 GMT):
(btw - i really only personally care about binaries from golang anyways)
troyronda (Thu, 31 Aug 2017 12:52:07 GMT):
(btw - i really only personally care about binaries from golang anyways in the topic above)
greg.haskins (Thu, 31 Aug 2017 12:52:13 GMT):
sure, BUT, that doesnt matter too much anyway since we are talking about augmenting the execution layer
greg.haskins (Thu, 31 Aug 2017 12:52:58 GMT):
the biggest benefit to utilizing golang is simply the maturity of the tooling (like the shim)
greg.haskins (Thu, 31 Aug 2017 12:52:58 GMT):
the biggest benefit to utilizing golang is simply the maturity of the ecosystem (like the shim)
greg.haskins (Thu, 31 Aug 2017 12:53:15 GMT):
but whatever we do, its a net-new platform, effectively
jimthematrix (Thu, 31 Aug 2017 17:05:46 GMT):
@greg.haskins @yacovm can we get clarity on what's needed to address Greg's concern over passing the client key/cert to the chaincode container please. I believe Greg is advocating for that to be done during the docker image build, but Yacov said this should be done at the time of launching the container instance (so each launch will result in a different key/cert pair)
jimthematrix (Thu, 31 Aug 2017 17:06:04 GMT):
just want to bring us together to sort this out so we can move this along
greg.haskins (Thu, 31 Aug 2017 17:06:23 GMT):
to be clear: I also agree it should be done at launch, I am just saying it should be done via upload-api and not parameters
jimthematrix (Thu, 31 Aug 2017 17:06:33 GMT):
ok
greg.haskins (Thu, 31 Aug 2017 17:06:41 GMT):
I had originally done this during cotnainer build when I didnt know about the upload-api
greg.haskins (Thu, 31 Aug 2017 17:06:59 GMT):
which was suboptimal, but I didnt know how else to handle at the time
greg.haskins (Thu, 31 Aug 2017 17:07:31 GMT):
@yacovm snuck the parameter one into GOLANG ;)
greg.haskins (Thu, 31 Aug 2017 17:07:35 GMT):
but I think we should fix both
yacovm (Thu, 31 Aug 2017 17:07:39 GMT):
Oh yes
jimthematrix (Thu, 31 Aug 2017 17:07:52 GMT):
right that should be done regardless of the chaincode type
greg.haskins (Thu, 31 Aug 2017 17:08:01 GMT):
agreed
jimthematrix (Thu, 31 Aug 2017 17:08:24 GMT):
so i think we now have clarity, let me dive into that (Yacov is pre-occupied with other work at the moment)
greg.haskins (Thu, 31 Aug 2017 17:08:34 GMT):
sounds good, thanks @jimthematrix
greg.haskins (Thu, 31 Aug 2017 17:08:41 GMT):
you got my notes about how I used it elsewhere?
jimthematrix (Thu, 31 Aug 2017 17:08:42 GMT):
may have other questions for you guys, thanks
jimthematrix (Thu, 31 Aug 2017 17:08:49 GMT):
yep
greg.haskins (Thu, 31 Aug 2017 17:08:52 GMT):
cool
greg.haskins (Thu, 31 Aug 2017 17:10:27 GMT):
@jimthematrix relevant JIRA: https://jira.hyperledger.org/browse/FAB-4447
jimthematrix (Thu, 31 Aug 2017 17:12:20 GMT):
:ok_hand: thanks
jimthematrix (Thu, 31 Aug 2017 17:13:38 GMT):
hmm, so it's marked as low, are we sure we want this to be addressed at this point in time for v1.1?
jimthematrix (Thu, 31 Aug 2017 17:14:26 GMT):
can we live with what Yacov has for v1.1, and address FAB-4447 for both the server and client TLS materials at a later time?
jimthematrix (Thu, 31 Aug 2017 17:15:19 GMT):
@greg.haskins ^^^
greg.haskins (Thu, 31 Aug 2017 17:15:51 GMT):
I would say fix it
greg.haskins (Thu, 31 Aug 2017 17:16:13 GMT):
its not like we are in an -rc10 freeze to ship
jimthematrix (Thu, 31 Aug 2017 17:18:08 GMT):
would you be ok with a partial fix in v1.1, to only use the upload-api approach for the client key/cert, and address FAB-4447 (the server ca cert) later?
jimthematrix (Thu, 31 Aug 2017 17:19:16 GMT):
so leave what we have for the server cert alone, but make sure the new capabilities w.r.t mutual TLS follows best practices?
greg.haskins (Thu, 31 Aug 2017 18:33:43 GMT):
sorry, was OTP
greg.haskins (Thu, 31 Aug 2017 18:35:46 GMT):
I havent had a chance to review, but im guessing the point of the mutual TLS changes was to recognize that both the client (chaincode) and server (peer) need a common trust root. The path of least resistance is probably to have the peer inject a key-pair/cert for the client into the client, along with the peer cert
greg.haskins (Thu, 31 Aug 2017 18:35:55 GMT):
i assume that is more or less what @yacovm already did
greg.haskins (Thu, 31 Aug 2017 18:36:07 GMT):
now its just a question of vehicle to transfer those assets
greg.haskins (Thu, 31 Aug 2017 18:36:46 GMT):
I had previously added the server-side injection at container build time, but that is way too early
yacovm (Thu, 31 Aug 2017 18:36:47 GMT):
The idea is to have a strict mapping between the chaincode *name* and its cert
yacovm (Thu, 31 Aug 2017 18:37:03 GMT):
Each shim container gets its own cert
greg.haskins (Thu, 31 Aug 2017 18:37:29 GMT):
so what I would suggest is any TLS material (server or client) be injected right before launch, via upload API
yacovm (Thu, 31 Aug 2017 18:37:47 GMT):
Sounds good. Into the file system?
greg.haskins (Thu, 31 Aug 2017 18:37:57 GMT):
@yacovm yeah
greg.haskins (Thu, 31 Aug 2017 18:38:22 GMT):
some well known location, like /etc/hyperledger/fabric/chaincode/tls or something
yacovm (Thu, 31 Aug 2017 18:38:59 GMT):
Ok sounds good to me
yacovm (Thu, 31 Aug 2017 18:39:32 GMT):
Also shoukd remove some code that i wrote that does base64 encoding, always good to remove code
greg.haskins (Thu, 31 Aug 2017 18:42:27 GMT):
yes, pls
greg.haskins (Thu, 31 Aug 2017 18:44:13 GMT):
@yacovm not sure you saw this, but I posted an example of what I mean: https://github.com/hyperledger/fabric/blob/c4c977db678fc9153e1ee37423d5eae828ec87f7/core/chaincode/platforms/util/utils.go#L191
greg.haskins (Thu, 31 Aug 2017 18:45:06 GMT):
I use that technique to move src/binary payloads into/out of the container during build...similar approach could be used to inject something like [peer.crt, chaincode.key, chaincode.crt]
yacovm (Thu, 31 Aug 2017 18:46:08 GMT):
I did. Thanks though
ngeorge (Tue, 05 Sep 2017 11:08:03 GMT):
Has joined the channel.
ngeorge (Tue, 05 Sep 2017 11:33:46 GMT):
Hi, while running the End2EndIT.java integration test, whatever endorsement policy is given, the instantiation is getting successful ..eg. with a wrong value for identity mspid, the endorsement is supposed to fail, but in my case, instantiation succeeds.. Is endorsement policy not required/validated during instantiation?
muralisr (Tue, 05 Sep 2017 11:49:32 GMT):
@ngeorge the endorsement policy is used for invokes to the chaincode
muralisr (Tue, 05 Sep 2017 11:49:32 GMT):
@ngeorge the endorsement policy is used to enforce invokes to the chaincode
ngeorge (Tue, 05 Sep 2017 12:08:50 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=Zr52yicCZFtFo2ffA) @muralisr So, does that mean, endorsement policy need not be set while instantiating a chaincode?
muralisr (Tue, 05 Sep 2017 12:33:08 GMT):
@ngeorge it needs to be set while instantiating a chancode to suit the policy for invokes
Eman0 (Tue, 05 Sep 2017 12:50:57 GMT):
Hi, is it possible to call another chaincode on another channel from a chaincode ?
muralisr (Tue, 05 Sep 2017 13:28:21 GMT):
@Eman0 yes you can call a chaincode on another channel but that will be "read only" ... any "PutState" you do on the called CC won't be written.. doc in https://github.com/hyperledger/fabric/blob/release/core/chaincode/shim/interfaces.go#L80
Ashish (Tue, 05 Sep 2017 14:56:54 GMT):
Has joined the channel.
Eman0 (Tue, 05 Sep 2017 15:39:51 GMT):
@muralisr Thank you
aleksandar.likic (Tue, 05 Sep 2017 15:46:53 GMT):
@greg.haskins Regarding the lack of determinism in golang CC build across environment variations (go/compiler/lib verions); don't we have the same problem with the .so fabric plugin mechanism (based on go plugins) that is being proposed? What is the approach to attestation that "what is executing is what was reviewed" in that case?
greg.haskins (Tue, 05 Sep 2017 15:48:14 GMT):
not really, no
greg.haskins (Tue, 05 Sep 2017 15:49:21 GMT):
non determinism is just another form of byzantine error...besides, work is already underway to provide deterministic chaincode environments
greg.haskins (Tue, 05 Sep 2017 15:50:10 GMT):
"determinism" in this case is about relating to "what was written/reviewed" to "what is running"
aleksandar.likic (Tue, 05 Sep 2017 15:50:33 GMT):
"work is already underway to provide deterministic chaincode environments" - is there a JIRA ticker?
greg.haskins (Tue, 05 Sep 2017 15:50:44 GMT):
if what is written/reviewed generates non-deterministic outputs, that is a different problem
greg.haskins (Tue, 05 Sep 2017 15:51:05 GMT):
not sure, its just an R&D project right now
aleksandar.likic (Tue, 05 Sep 2017 15:52:18 GMT):
Sorry, I still don't understand why .so plugins don't have the same issue.
greg.haskins (Tue, 05 Sep 2017 15:52:37 GMT):
im not sure what you mean
greg.haskins (Tue, 05 Sep 2017 15:52:59 GMT):
we dont have a fabric .so mechanism as far as I know
aleksandar.likic (Tue, 05 Sep 2017 15:53:44 GMT):
https://jira.hyperledger.org/browse/FAB-5378 assumes that at some point SCCs will be deployable as .so files.
aleksandar.likic (Tue, 05 Sep 2017 15:54:01 GMT):
... go plugins
greg.haskins (Tue, 05 Sep 2017 15:54:50 GMT):
i havent had a chance to review that proposal, but overall I would say "no" because thats more of a fabric-admin decision (same to bake SCCs into the peer binary)
greg.haskins (Tue, 05 Sep 2017 15:55:45 GMT):
e.g. not sure what the linkage has to do with determinism in that case
aleksandar.likic (Tue, 05 Sep 2017 15:56:41 GMT):
so your objection to per-compiled user CCs is due to the fact they are deployable by someone who is not fabric-admin, right? You don't have a problem with fabric admins deploying binaries.
aleksandar.likic (Tue, 05 Sep 2017 15:56:41 GMT):
so your objection to pre-compiled user CCs is due to the fact they are deployable by someone who is not fabric-admin, right? You don't have a problem with fabric admins deploying binaries.
greg.haskins (Tue, 05 Sep 2017 15:56:59 GMT):
i havent had a chance to review the proposal
greg.haskins (Tue, 05 Sep 2017 15:57:34 GMT):
what I can say is the user deployable scenario you presented before was not adequately robust in a heterogeneous environment
greg.haskins (Tue, 05 Sep 2017 15:58:13 GMT):
overall, I think FAB-5378 might be missing the point of SCCs, so it needs careful review
aleksandar.likic (Tue, 05 Sep 2017 15:59:03 GMT):
Yes, I understand, I am just trying to find where that line is - that we must not cross with the binaries.
greg.haskins (Tue, 05 Sep 2017 15:59:34 GMT):
but again, ignoring that...if someone wants to fork fabric, add/remove SCCs, and recompile it, that is an administrative action for a given consortia
aleksandar.likic (Tue, 05 Sep 2017 15:59:54 GMT):
What I hear is that fabric admins should be OK with deploying fabric binary extensions. Is that what you think?
greg.haskins (Tue, 05 Sep 2017 16:00:20 GMT):
I dont know...i havent had a chance to review the proposal
greg.haskins (Tue, 05 Sep 2017 16:00:40 GMT):
like I said, I think it might be missing the point of SCCs to begin with so thats the part I need to study
aleksandar.likic (Tue, 05 Sep 2017 16:00:56 GMT):
I am not referring now to any proposal, I am asking in general.
greg.haskins (Tue, 05 Sep 2017 16:01:21 GMT):
I don yet have an opinion
greg.haskins (Tue, 05 Sep 2017 16:01:21 GMT):
I don't yet have an opinion
aleksandar.likic (Tue, 05 Sep 2017 16:03:56 GMT):
OK, thanks for getting back so quickly.
sudeshrshetty (Tue, 05 Sep 2017 16:19:41 GMT):
Has joined the channel.
DarshanBc (Wed, 06 Sep 2017 14:27:05 GMT):
I have endorsement policy AND('Org1.member', 'Org2.member') my question is when I invoke a transaction on a chaincode on what basis a transaction gets signature from org1.member and org2.member
jeffgarratt (Wed, 06 Sep 2017 16:11:46 GMT):
@DarshanBc you will need to get endorsements from peers from both organizations
DarshanBc (Wed, 06 Sep 2017 16:48:10 GMT):
@jeffgarratt If I send a transaction proposal to peers of org1 and I invoke a chaincode installed only on org2 from chaincode of org1 will the endorsement policy be satisfied
Glen (Thu, 07 Sep 2017 01:03:29 GMT):
sorry wrong place sent.
Glen (Thu, 07 Sep 2017 01:03:29 GMT):
Who can help explain what the directories under /var/hyperledger/production/ledgersData on peer are used for? i know they are are leveldb files used for block storage. i want to know more about the database organisation on peer. why are there directories historyLeveldb ledgerProvider stateLeveldb besides chains?
DarshanBc (Thu, 07 Sep 2017 01:06:39 GMT):
Can someone explain me example purpose for AND(org1.member,org2.member) endorsement since same chaincode is installed on peers of both orgs obviously always the transaction proposal gets endorsed by 2peers and committed but when does it fail except when org2 peers collapse
DarshanBc (Thu, 07 Sep 2017 04:33:44 GMT):
when does this endorsement policy AND('org1.member',org2.member2) is not satisified apart from not sending transactino proposal to peers org1 and org2
DarshanBc (Thu, 07 Sep 2017 04:33:44 GMT):
when does this endorsement policy AND('org1.member',org2.member2) is not satisified apart from not sending transactino proposal to peers org1 and org2 I want to know based on what endorsement policy fails documentation says APIs check whether responses are same if same then they are sent for ordering I have same chaincode installed on org1.memeber and org2.member obviously we need to get same response from both of them so whats the use of having endorsement policy
DarshanBc (Thu, 07 Sep 2017 04:33:44 GMT):
when does this endorsement policy AND('org1.member',org2.member2) is not satisified apart from not sending transactino proposal to peers org1 and org2. I want to know based on what endorsement policy fails. Documentation says APIs check whether responses are same, if same then they are sent for ordering. when I have same chaincode installed on org1.memeber and org2.member obviously we need to get same response from both of the peers so whats the use of having endorsement policy.
boliang (Thu, 07 Sep 2017 07:29:21 GMT):
Has joined the channel.
boliang (Thu, 07 Sep 2017 07:51:00 GMT):
@DarshanBc 1) There could be more peers than just Org1 and Org2 in the same channel, for example, Org3. In this case, the policy And(Org1.member, Org2.member) means you just need to get endorsement from these two orgs (excludes Org3). 2) The client SDK checks the endorsement results from multiple endorsers. But if it's malicious client, he can still send responses for ordering even they are not the same. That's why committers have to check the endorsement policy to make sure the signatures from endorsers are correct and the signatures satisfy the rules.
DarshanBc (Thu, 07 Sep 2017 08:09:49 GMT):
@boliang so you mean to say endorsement policy is only to avoid malicious attack and in no case of genuine transaction endorsement policy fails except if the all peers of org1 are down
boliang (Thu, 07 Sep 2017 08:15:01 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=Yi57PJKyiFHD5skNY) @DarshanBc Yes. In my opinion, consensus consists of endorsement and ordering. That's why you should carefully design the endorsement policy.
DarshanBc (Thu, 07 Sep 2017 08:45:25 GMT):
@boliang ok can you clarify my view on endorsement. I have a car selling market, to buy a car literally I need an endorsement of payment class and an endorsement of manufacturer of car saying payment is done and car is manufactured so can I achieve this by endorsement policy of Hyperledger-fabric
boliang (Thu, 07 Sep 2017 08:49:52 GMT):
@DarshanBc What do you mean by "endorsement of payment class"?
DarshanBc (Thu, 07 Sep 2017 08:55:54 GMT):
@boliang I meant in a literal way in other words confirmation from payment class saying payment is done by buyer
boliang (Thu, 07 Sep 2017 09:00:34 GMT):
@DarshanBc could you specify the roles of endorsers in your case? For example, manufacturer.
boliang (Thu, 07 Sep 2017 09:01:03 GMT):
I don't know what else in your case
DarshanBc (Thu, 07 Sep 2017 09:16:53 GMT):
for successfull sellCar transaction my endorsement policy should be AND('payment.member','seller.member','buyer.member') which means transfer of ownership is being done and signature of buyer.member and seller.member is obtained in parallel if payment is done then only payment.member signs the transaction hence all the endorsers have endorsed and this txn can be sent for ordering thus for commit in DB
boliang (Thu, 07 Sep 2017 09:35:54 GMT):
In reality, the scenarios donot work in the way you mentioned. Then endorsement result is automatically generated by peer based on the simulation result of chaincode. It means in current implementation, the result only relies on ledger and chaincode. @DarshanBc
DarshanBc (Thu, 07 Sep 2017 10:38:21 GMT):
@boliang http://hyperledger-fabric.readthedocs.io/en/latest/txflow.html says for transaction of radish both buyer and seller has to endorse doesn't that mean in the way I mentioned
boliang (Thu, 07 Sep 2017 11:26:00 GMT):
@DarshanBc No, it's not what you describe.
bstasyszyn (Thu, 07 Sep 2017 13:58:54 GMT):
Has joined the channel.
kostas (Thu, 07 Sep 2017 18:41:35 GMT):
Why is it that if a chaincode with the same name exists, an instantiation will return an error?
kostas (Thu, 07 Sep 2017 18:41:36 GMT):
https://github.com/hyperledger/fabric/blob/release/core/scc/lscc/lscc.go#L573
kostas (Thu, 07 Sep 2017 18:41:46 GMT):
Am I parsing this bit wrong? (I most likely am.)
yacovm (Thu, 07 Sep 2017 19:50:41 GMT):
because that LSCC invocation (deploy) is in the context of a channel so it it already exists in LSCC it is already instantiated
yacovm (Thu, 07 Sep 2017 19:50:41 GMT):
because that LSCC invocation (deploy) is in the context of a channel so it it already instantiated (exists under the LSCC namespace) it shouldn't work
kostas (Thu, 07 Sep 2017 20:17:25 GMT):
Isn't this where the version should come into play though?
kostas (Thu, 07 Sep 2017 20:17:25 GMT):
@yacovm: Thanks. Isn't this where the version should come into play though?
kostas (Thu, 07 Sep 2017 20:17:59 GMT):
(The doc says that "multiple versions of a chaincode may be active simultaneously".)
C0rWin (Thu, 07 Sep 2017 20:32:32 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=wqv3dYgTGQKCo5DaY) @kostas different versions will be result of the upgrade rather than instantiate
yacovm (Thu, 07 Sep 2017 20:34:46 GMT):
the version isn't the "key" of the LSCC
yacovm (Thu, 07 Sep 2017 20:34:49 GMT):
the key is the chaincode "name"
yacovm (Thu, 07 Sep 2017 20:35:00 GMT):
the version is like the value in our story, @kostas
kostas (Thu, 07 Sep 2017 20:36:09 GMT):
Roger, thanks guys. I see: https://github.com/hyperledger/fabric/blob/release/core/scc/lscc/lscc.go#L269
kostas (Thu, 07 Sep 2017 20:37:03 GMT):
The role of that version field was a bit fuzzy in my mind, but it's less so now.
sushantdm (Fri, 08 Sep 2017 08:02:56 GMT):
Has joined the channel.
muralisr (Fri, 08 Sep 2017 12:24:32 GMT):
https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=fQ5of4hhQgc8QxdQt
muralisr (Fri, 08 Sep 2017 12:24:47 GMT):
What story is that @yacovm ?
yacovm (Fri, 08 Sep 2017 12:35:12 GMT):
Thething be asked
Ashish (Sun, 10 Sep 2017 18:36:01 GMT):
Hi, endorsements are being done by the designated Peers' rite?
Ashish (Sun, 10 Sep 2017 18:36:55 GMT):
then why is that the endorsement policy setup configuration has roles like "member" and "admin" ?
Ashish (Sun, 10 Sep 2017 18:38:20 GMT):
arent these the user level roles?
We do not start a peer with a role when we start it, rite? Nor we join a channel by specifying a role.
divyank (Mon, 11 Sep 2017 16:44:19 GMT):
Hello, can anybody here explain the reasoning behind compiling the peer binary statically?
https://github.com/hyperledger/fabric/blob/release/docker-env.mk#L65
yacovm (Mon, 11 Sep 2017 17:47:17 GMT):
@greg.haskins ^
Ashish (Tue, 12 Sep 2017 10:28:53 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=fQ5of4hhQgc8QxdQt) @yacovm
I was getting this error while trying to instantiate a chaincode example_cc to 2 Organizations which are members of a channel say "dualchannel" [ Each Org had 2 peers ]
I was doing it in an iterative manner ( first Org1, then Org2 ). And I was using JAVA SDK
I had sent out a Instantiation proposal to 2 peers of Org1 first. At that time i didnt know that I need to instantiate only once. But it was successful.( i.e, even though I had two peers in the proposal, it was still successfull)
Then my code picked up Org2 and tried to tried to send an Instantiating proposal to the two peers which are left. This time, i got the above mentioned error that " chaincode exists example_cc"
I agree to the above error [ But I was confused a bit as it looked similar to the error during the duplicate installation. ]
My question is, why didn't the same error come when I tried to instantiate to both the peers of Org1 ? Is it because I had both the peers clubbed in the same Instantiation proposal ?
Now what I am planning to do is, to iterate further down, at peer level, and instantiate only till the first successful response.
jon_s (Tue, 12 Sep 2017 12:05:57 GMT):
Has joined the channel.
jrosmith (Tue, 12 Sep 2017 17:26:53 GMT):
@Ashish installing is an action specific to the peers, instantiating is specific to the channel. it doesn't matter that there are two peers in the instantiate proposal, when org1 goes to instantiate it is still the first proposal to instantiate the chaincode on that channel. when org2 tried to send a proposal it found that the chaincode was already bound to the channel
greg.haskins (Wed, 13 Sep 2017 11:32:09 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=g4c5Y6zbcKcNFtfcp) @divyank The rationale is that we use effectively a multi-stage docker build (e.g. builder container is different from run-time container)...since the runtime container is stripped down, it is not safe to assume that ldd linkages that are available at build-time are also available at run-time. Thus, we use --static builds to eliminate dynamic linking and create a more self-contained payload that is easier to migrate
greg.haskins (Wed, 13 Sep 2017 11:32:46 GMT):
in the earlier versions of the code, this was actually true as we were using ubuntu for build-time and busybox for runtime
greg.haskins (Wed, 13 Sep 2017 11:33:11 GMT):
however, we had to back away from that because of a snafu with glibc, so now the runtime is also based on a stripped down ubuntu
greg.haskins (Wed, 13 Sep 2017 11:33:44 GMT):
thus, the requirements are more lax than they used to be, at least currently
greg.haskins (Wed, 13 Sep 2017 11:34:22 GMT):
(would like to revisit this again in the future...as a stripped ubuntu build is like 160MB and a busybox build is about 25MB)
divyank (Wed, 13 Sep 2017 12:39:13 GMT):
@greg.haskins I see.
I'm working on extending FAB-4207 to use Go plugins and found that plugins are not compatible with static builds. Would you be open to changing the way we manage the ldd linkages?
greg.haskins (Wed, 13 Sep 2017 12:40:40 GMT):
@divyank it would technically work, since we currently do ubuntu-to-ubuntu, but I would be concerned that it would preclude us from ever revisiting the optimization
greg.haskins (Wed, 13 Sep 2017 12:40:57 GMT):
i guess we should discuss the merits of plugins vs size optimization
divyank (Wed, 13 Sep 2017 13:35:34 GMT):
As a user I'm pretty happy with the current 150 MB image size. It's almost like loading the CNN homepage :)
divyank (Wed, 13 Sep 2017 13:36:25 GMT):
If we did move to something like ubuntu to alpine in the future, wouldn't it be sufficient to ensure the same version of the dependency is available at build and runtime?
greg.haskins (Wed, 13 Sep 2017 14:59:16 GMT):
@divyank generally yes, though the details of managing that can sometimes be unattractive
greg.haskins (Wed, 13 Sep 2017 14:59:25 GMT):
but essentially, that is more or less what we are doing today
greg.haskins (Wed, 13 Sep 2017 14:59:54 GMT):
e.g. the builder and runtime environments share a lineage and thus abi compatibility is a natural benefit of that
greg.haskins (Wed, 13 Sep 2017 15:00:09 GMT):
we could continue to manage it that way
divyank (Wed, 13 Sep 2017 15:00:28 GMT):
Would something like docker multi-stage builds help manage this? https://docs.docker.com/engine/userguide/eng-image/multistage-build/
greg.haskins (Wed, 13 Sep 2017 15:01:31 GMT):
no, but only because a) we are effectively doing the same thing already, and b) while the built-in docker-multistage support is more attractive that rolling our own multi-stage in many ways, there are a few issues with converting
greg.haskins (Wed, 13 Sep 2017 15:02:05 GMT):
for one, it requires docker-engine v17.06+ and I am not ready the demand that as a fabric requirement on our users
greg.haskins (Wed, 13 Sep 2017 15:02:05 GMT):
for one, it requires docker-engine v17.06+ and I am not ready to demand that as a fabric requirement on our users
greg.haskins (Wed, 13 Sep 2017 15:03:01 GMT):
the second is that the docker multi-stage support is somewhat limiting because stage 1 runs as a docker-build and not a docker-run and it precludes some capabilities that we take advantage of
greg.haskins (Wed, 13 Sep 2017 15:03:15 GMT):
such as volume-mounting intermediate artifacts
greg.haskins (Wed, 13 Sep 2017 15:03:40 GMT):
i digress...not really relevant here because it doesnt get us any closer to --static vs plugins
divyank (Wed, 13 Sep 2017 15:05:11 GMT):
Yes, so it would be okay to install ldd linkages in both baseos and base image?
greg.haskins (Wed, 13 Sep 2017 16:42:15 GMT):
well, they are already there naturally
greg.haskins (Wed, 13 Sep 2017 16:42:54 GMT):
baseimage derives from baseos, so it shares the necessary lineage in a way that non --static has a shot at working
greg.haskins (Wed, 13 Sep 2017 16:43:06 GMT):
actually, i just remembered the other problem though
greg.haskins (Wed, 13 Sep 2017 16:43:13 GMT):
still solvable, but not as clearcut
greg.haskins (Wed, 13 Sep 2017 16:44:03 GMT):
the reason I stuck with --static even after re-establishing a baseos lineage is you cant really predict in a generic way what libs the app will need
greg.haskins (Wed, 13 Sep 2017 16:44:49 GMT):
for instance, if peer pulled in libfoo.so that was installed in baseimage, it would require the installation of the same in baseos in order to work
greg.haskins (Wed, 13 Sep 2017 16:44:56 GMT):
--static solved that nicely
greg.haskins (Wed, 13 Sep 2017 16:45:13 GMT):
like I said, you could still solve it, but it gets a little messier
divyank (Wed, 13 Sep 2017 17:25:56 GMT):
I ran into that issue as well. I'm currently trying to see if it's possible to statically link certain libraries while still producing a dynamically linked binary. This way there would be no need for adding the required .so files to the baseos image.
ngeorge (Thu, 14 Sep 2017 10:49:33 GMT):
Has anyone tried passing an endorsement policy as byte array? I couldnt find any samples of the same..
acloudfan (Thu, 14 Sep 2017 16:22:11 GMT):
Has joined the channel.
jimthematrix (Thu, 14 Sep 2017 17:08:01 GMT):
@muralisr do we still need stub.GetBinding()? what is that used for? I suppose a chaincode can use it to get a unique hash for the transaction proposal, and use it for some purpose. but seeing how it's computed, hash(nonce, creator, epoch), it's almost identical to txId
jimthematrix (Thu, 14 Sep 2017 17:08:45 GMT):
trying to decide whether I should make this available in node.js chaincode stub API. i'm leaning toward no. what's your opinion?
fred0071 (Fri, 15 Sep 2017 06:42:30 GMT):
Has joined the channel.
muralisr (Fri, 15 Sep 2017 11:54:20 GMT):
@jimthematrix I was trying to reason out exactly the same way you described. This appears to have come from https://jira.hyperledger.org/browse/FAB-1752. I'm also not sure when this would be used... let;s check with @elli-androulaki @adc ?
elli-androulaki (Fri, 15 Sep 2017 12:27:32 GMT):
Hi @jimthematrix , @muralisr , binding is to be used for invocation access control at the chaincode layer when the chaincode authentication is based on alternate authentication mechanisms (other than creator)
elli-androulaki (Fri, 15 Sep 2017 12:29:36 GMT):
it fulfils the same purpose for chaincodes/application and fabric platform as tls-unique when used by applications running on tls
elli-androulaki (Fri, 15 Sep 2017 12:29:36 GMT):
it fulfils the same purpose for chaincodes/application on top of fabric as tls-unique when used by applications running on tls
jimthematrix (Fri, 15 Sep 2017 14:26:03 GMT):
@elli-androulaki thanks for the detailed explanation (on the whiteboard), as we discussed this is a useful and advanced API and is likely the least understood feature of the chaincode API, we should provide more documentation and also have the SDKs add a "generateBinding()" as part of constructing a proposal.
jimthematrix (Fri, 15 Sep 2017 14:26:23 GMT):
@muralisr as a result of a f2f discussion with Elli, I now understood the function it provides and how it's supposed to be used. so I'll add it to node.js chaincode
elli-androulaki (Fri, 15 Sep 2017 14:33:52 GMT):
sure!
vdods (Sun, 17 Sep 2017 18:59:51 GMT):
Has left the channel.
SyneBlockChainTeam (Mon, 18 Sep 2017 08:24:34 GMT):
We need to deploy each peer on different physical machines. Might be, this could be achieved by creating peer on different machines with help docker. Could you please suggest the configuration steps for this?
Thanks
joifsi (Mon, 18 Sep 2017 08:31:40 GMT):
Has joined the channel.
joifsi (Mon, 18 Sep 2017 08:34:10 GMT):
I keep getting the following debug logs in the peer console saying that security handshake failed. Can someone help with what this means and why is the handshake failing
```2017-09-18 07:44:46.243 UTC [grpc] Printf -> DEBU 19e grpc: addrConn.resetTransport failed to create client transport: connection error: desc = "transport: x509: cannot validate certificate for 127.0.0.1 because it doesn't cont ain any IP SANs"; Reconnecting to {"127.0.0.1:7051"
mastersingh24 (Mon, 18 Sep 2017 10:19:16 GMT):
@joifsi - Basically hostname verification is failing at the TLS layer. Assuming you are using certs generated by cryptogen, they only contain hostnames in the SAN (Subject Alternative Name) field.
How are you running your peers? Docker, binary, etc?
joifsi (Mon, 18 Sep 2017 11:19:55 GMT):
@mastersingh24 Thanks for the quick response. I am using docker but not using the hostnames of the docker containers, rather I am using the ip address of the host machine and the exposed ports
mastersingh24 (Mon, 18 Sep 2017 11:23:01 GMT):
@joifsi - maybe this will help: https://stackoverflow.com/a/46115806/6160507 ?
joifsi (Mon, 18 Sep 2017 11:24:40 GMT):
I have tried this out but and I am using the dns names instead of ip addresses, but still the same issue comes up.
bryanhuang (Mon, 18 Sep 2017 13:02:04 GMT):
Hi all, while I upgrade a chaincode, endorser report an error "UpgradeChaincode Endorser returned error: Transaction processor (localhost:7051) returned error 'rpc error: code = Unknown desc = Failed to transaction message(proto: Marshal called with nil)'"
bryanhuang (Mon, 18 Sep 2017 13:03:13 GMT):
Could you please help on this problem, thanks a lot.
troyronda (Mon, 18 Sep 2017 14:07:58 GMT):
@mastersingh24 - was just looking at FAB-6161 - do you guys have a solution for PKCS11?
troyronda (Mon, 18 Sep 2017 14:07:58 GMT):
@mastersingh24 - was just looking at FAB-6161 - do you guys have a solution for PKCS11 that can leverage "official" builds?
troyronda (Mon, 18 Sep 2017 14:08:47 GMT):
(that does not involve custom builds/images)
yyyyyyy9 (Tue, 19 Sep 2017 00:37:42 GMT):
Has joined the channel.
CarlXK (Tue, 19 Sep 2017 02:35:18 GMT):
@here my peer node receive a SIGTERM and the peer quit, why it will got a SIGTERM? i can't got ant clue from the log
```
2017-09-18 11:23:50.703 CST [shim] func1 -> DEBU 3f3ae Sending KEEPALIVE response
2017-09-18 11:23:50.703 CST [chaincode] processStream -> DEBU 3f3af []Received message KEEPALIVE from shim
2017-09-18 11:23:50.703 CST [chaincode] processStream -> DEBU 3f3b0 Received KEEPALIVE Response
2017-09-18 11:23:53.805 CST [shim] func1 -> DEBU 3f3b1 []Received message KEEPALIVE from shim
2017-09-18 11:23:53.805 CST [shim] func1 -> DEBU 3f3b2 Sending KEEPALIVE response
2017-09-18 11:23:53.806 CST [chaincode] processStream -> DEBU 3f3b3 []Received message KEEPALIVE from shim
2017-09-18 11:23:53.806 CST [chaincode] processStream -> DEBU 3f3b4 Received KEEPALIVE Response
2017-09-18 11:23:55.753 CST [chaincode] processStream -> DEBU 3f3b5 []Received message KEEPALIVE from shim
2017-09-18 11:23:55.754 CST [chaincode] processStream -> DEBU 3f3b6 Received KEEPALIVE Response
2017-09-18 11:23:58.466 CST [nodeCmd] func3 -> DEBU 3f3b7 sig: terminated
2017-09-18 11:23:58.466 CST [fsblkstorage] Shutdown -> DEBU 3f3b8 closing fs blockStore:xnchannel
2017-09-18 11:23:58.466 CST [main] main -> INFO 3f3b9 Exiting.....
```
jeffgarratt (Wed, 20 Sep 2017 16:01:15 GMT):
@CarlXK it appears something is sending the SIGTERM to the process. This could occur depending on how you execute the process (e.g. CTRL-C directly, or running a process through a remote session and NOT using NOHUP)
CarlXK (Thu, 21 Sep 2017 01:48:20 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=nDnGzY6zfxn5kSeEa) @jeffgarratt yep, i run the peer use docker swarm (docker stack deploy) command , but on other machine's peer not receive the signal
SachinAmingad (Thu, 21 Sep 2017 12:48:34 GMT):
Has joined the channel.
SachinAmingad (Thu, 21 Sep 2017 12:49:00 GMT):
Hi there my orderer and peer fails due to grpc connection unavaliable what could be the actual reason . I am using Yacov fabric deployment !!
muralisr (Thu, 21 Sep 2017 13:02:26 GMT):
@yacovm ^^^
yacovm (Thu, 21 Sep 2017 13:08:25 GMT):
Lol
yacovm (Thu, 21 Sep 2017 13:08:30 GMT):
Is that a thing?
yacovm (Thu, 21 Sep 2017 13:08:43 GMT):
Come to private chat
t_stephens67 (Fri, 22 Sep 2017 19:46:22 GMT):
Has joined the channel.
divyank (Fri, 22 Sep 2017 19:49:40 GMT):
Hi all, we would like some feedback on the pkcs11/static build incompatibility discussion at: https://jira.hyperledger.org/browse/FAB-6161?focusedCommentId=31106&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-31106
divyank (Fri, 22 Sep 2017 19:50:26 GMT):
^ @mastersingh24 @greg.haskins @aleksandar.likic @troyronda
aleksandar.likic (Fri, 22 Sep 2017 23:05:04 GMT):
Chaincode Type Agnostic Peer - Proposal
Hi all, we need a way to distribute pre-compiled golang chaincode. We had a proposal how to achieve this, and after receiving great feedback (a couple of reviews from the community, namely @greg.haskins :wink: ) We considered @greg.haskins ’ recommendation from https://jira.hyperledger.org/browse/FAB-6014?focusedCommentId=30526&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-30526 to fully commit to docker as a solution. We took the idea a bit further, as we realized that committing fully to docker provides and opportunity to move chaincode type specific processing out of the peer source code, which we believe has many great positives. We came up with a draft proposal: https://jira.hyperledger.org/browse/FAB-6014?focusedCommentId=30526&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-30526. It’s still a bit rough, so we would appreciate feedback and contribution from the community. Particularly, @greg.haskins ‘ help would be greatly appreciated. Thanks!
aleksandar.likic (Fri, 22 Sep 2017 23:05:04 GMT):
Chaincode Type Agnostic Peer - Proposal
Hi all, we need a way to distribute pre-compiled golang chaincode. We had a proposal on how to achieve this, and after receiving great feedback (a couple of reviews from the community, namely @greg.haskins :wink: ), we considered @greg.haskins ’ recommendation from https://jira.hyperledger.org/browse/FAB-6014?focusedCommentId=30526&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-30526 to fully commit to docker as a solution. We took the idea a bit further, as we realized that committing fully to docker provides and opportunity to move chaincode type specific processing out of the peer source code, which we believe has many great positives. We came up with a draft proposal: https://jira.hyperledger.org/browse/FAB-6014?focusedCommentId=30526&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-30526. It’s still a bit rough, so we would appreciate feedback and contribution from the community. Particularly, @greg.haskins ‘ help would be greatly appreciated. Thanks!
greg.haskins (Fri, 22 Sep 2017 23:05:48 GMT):
@aleksandar.likic I will try to review it this weekend
aleksandar.likic (Fri, 22 Sep 2017 23:09:54 GMT):
@greg.haskins Thanks Greg! I hope we'll get feedback from others too!
yacovm (Sat, 23 Sep 2017 08:40:39 GMT):
@aleksandar.likic don't forget this needs to play nicely with the peer<-->chaincode mutual TLS auth which the peergenerates tne cert for,else the peer won't accept the gRPC stream
ToddKitchens3 (Sat, 23 Sep 2017 17:42:27 GMT):
Has joined the channel.
aleksandar.likic (Sat, 23 Sep 2017 18:28:55 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=LfShpy9W95AopjB5q) @yacovm Of course. Implementation would use the existing peer<-->chaincode gRPC schema, no need to invent anything new in this regard. The changes would be mostly around install and instantiate.
aleksandar.likic (Sat, 23 Sep 2017 18:28:55 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=LfShpy9W95AopjB5q) @yacovm Of course. Implementation would use the existing peer<-->chaincode gRPC schema, no need to invent anything new in this regard. The changes would be mostly around chaincode install and instantiate.
yacovm (Sat, 23 Sep 2017 18:29:26 GMT):
I'm talking about the "sort-of-recent" mutual TLS thing
yacovm (Sat, 23 Sep 2017 18:29:50 GMT):
when the peer spawns a chaincode container, it injects it with a TLS certificate and a TLS private key
aleksandar.likic (Sat, 23 Sep 2017 18:30:04 GMT):
Understood, thanks.
yacovm (Sat, 23 Sep 2017 18:30:08 GMT):
you *have* to use it to connect to the peer, or else it'll block youu
yacovm (Sat, 23 Sep 2017 18:30:08 GMT):
you *have* to use it to connect to the peer, or else it'll block you
aleksandar.likic (Sat, 23 Sep 2017 18:34:43 GMT):
@greg.haskins has already suggested having a standard peer-chaincode contract for instantiation, so i think TLS is one of the things that should be covered.
aleksandar.likic (Sat, 23 Sep 2017 18:34:43 GMT):
@greg.haskins has already suggested having a standard peer-chaincode contract for instantiation, so i think TLS is one of the things that should be covered. Current proposal doesn't go into details on this, that's one area where it should improve I guess.
toriaezunama (Mon, 25 Sep 2017 12:17:54 GMT):
Has joined the channel.
GiorgiBlockchain (Tue, 26 Sep 2017 02:30:31 GMT):
Has joined the channel.
albrandt (Tue, 26 Sep 2017 15:08:32 GMT):
Has left the channel.
gauthampamu (Tue, 26 Sep 2017 17:26:09 GMT):
https://chat.hyperledger.org/channel/fabric-sdk-node?msg=vhFHthbBHTdmcrL6S
DarshanBc (Wed, 27 Sep 2017 02:17:33 GMT):
I need to join another organization to my network of channel xyz dynamically where already 2orgs exist org3 have their own set of functionalities p,q,r written in chaincode how to make these new functionalities available for the members of org1 and org2
C0rWin (Wed, 27 Sep 2017 05:33:09 GMT):
@DarshanBc you need to install new chaincode on peers of org1 and org2.
aleksandar.likic (Wed, 27 Sep 2017 13:57:42 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=S6WmmnovmH2XTdiTg) @greg.haskins Hi Greg, have you had a chance to review it?
greg.haskins (Wed, 27 Sep 2017 16:03:25 GMT):
@aleksandar.likic not yet, sorry
t_stephens67 (Wed, 27 Sep 2017 17:35:41 GMT):
I have created 3 fabric peers and generated new keys and certs for those and then mapped each peer to its own couchdb. I have created a channel on peer0 and added peer1 and peer2 to the channel I then deploy my .bna network onto all 3 peers. When I run my composer-rest-server how does it interact with all 3 peers? Is consensus built in or do I need to configure consensus.
dhuseby (Thu, 28 Sep 2017 01:52:30 GMT):
is the membership service provider a centralized server that all peers talk to?
dhuseby (Thu, 28 Sep 2017 01:52:39 GMT):
or is there a local instance of the MSP on each peer?
dhuseby (Thu, 28 Sep 2017 01:52:48 GMT):
if so, then how are the MSP instances kept synchronized/
dhuseby (Thu, 28 Sep 2017 01:52:50 GMT):
?
yacovm (Thu, 28 Sep 2017 05:47:45 GMT):
In v1.0 we have an MSP instance per channel, and a local MSP that is cross channel. The channel MSPs are updated with cobfiguration blocks
yacovm (Thu, 28 Sep 2017 05:48:14 GMT):
But its not a server, just a module in the code
shubhammangla (Thu, 28 Sep 2017 12:30:59 GMT):
Has joined the channel.
jworthington (Thu, 28 Sep 2017 14:25:36 GMT):
Has joined the channel.
qizhang (Fri, 29 Sep 2017 18:10:38 GMT):
Has joined the channel.
asaningmaxchain (Sun, 01 Oct 2017 07:55:37 GMT):
Has joined the channel.
asaningmaxchain (Sun, 01 Oct 2017 07:57:27 GMT):
@yacovm each peer/orderer contains a msp?
yacovm (Sun, 01 Oct 2017 08:02:58 GMT):
yes
asaningmaxchain (Sun, 01 Oct 2017 08:32:37 GMT):
i know the in the orderer system channel, it loads the all msp in the genesis config
asaningmaxchain (Sun, 01 Oct 2017 08:32:37 GMT):
i know the in the orderer system channel, it loads the all msp in the genesis config,why the orderer contains the local msp
yacovm (Sun, 01 Oct 2017 08:48:15 GMT):
well the local msp contains its signing key ;)
yacovm (Sun, 01 Oct 2017 08:48:22 GMT):
the orderer signs blocks
asaningmaxchain (Sun, 01 Oct 2017 09:01:04 GMT):
the peer will deliver the block from the orerer,how the peer verify the signature
yacovm (Sun, 01 Oct 2017 09:27:11 GMT):
what do you mean how
epm2wi (Sun, 01 Oct 2017 10:16:25 GMT):
Has joined the channel.
asaningmaxchain (Tue, 03 Oct 2017 11:44:10 GMT):
i think the msp is a ca
asaningmaxchain (Tue, 03 Oct 2017 11:44:10 GMT):
i think the msp is a ca,it's right? @yacovm
asaningmaxchain (Tue, 03 Oct 2017 11:44:13 GMT):
@yacovm
asaningmaxchain (Tue, 03 Oct 2017 11:45:54 GMT):
when i in the 'examples/e2e_cli` to execute the generateArtifacts.sh to produce the artifacts
yacovm (Tue, 03 Oct 2017 11:51:01 GMT):
I don't understand
asaningmaxchain (Tue, 03 Oct 2017 11:56:53 GMT):
can you explain the msp
asaningmaxchain (Tue, 03 Oct 2017 11:56:53 GMT):
can you explain the msp? and how the fabric use the msp
yacovm (Tue, 03 Oct 2017 12:00:03 GMT):
this is a question to #fabric-crypto
thakkarparth007 (Tue, 03 Oct 2017 12:29:33 GMT):
@asaningmaxchain msp only plays a role once you have an identity. It verifies if an identity belongs to an org or has permissions to perform an action. CA on the other hand is for enrolling/unregistering identities to organizations.
You don't always need a CA for fabric to work - you _can_ work without it if you use the cryptogen tool that will generate identities for you. But that's not a very straightforward way for big networks.
asaningmaxchain (Tue, 03 Oct 2017 12:33:22 GMT):
https://pastebin.com/ytSvakkp @thakkarparth007 can you explain each folder
thakkarparth007 (Tue, 03 Oct 2017 12:59:07 GMT):
I'm not very well worsed with that folder structure. Fabric crypto would be a better place to get the details. I can only give a high level overview
thakkarparth007 (Tue, 03 Oct 2017 12:59:07 GMT):
I'm not very well verrsed with that folder structure. Fabric crypto would be a better place to get the details. I can only give a high level overview
thakkarparth007 (Tue, 03 Oct 2017 12:59:07 GMT):
I'm not very well versed with that folder structure. Fabric crypto would be a better place to get the details. I can only give a high level overview
yacovm (Tue, 03 Oct 2017 13:08:52 GMT):
So the `ca` folder is to initialize a CA. contains a private key and a CA's cert.
the `msp` folder is actually the data that is persisted in the config block about the organization, used to build the "verifier" MSP per channel.
the `peers` folder contains 2 folders:
- `msp` folder to store the signing MSP of a peer
- `tls` folder to store the TLS stuff (cert, root CA cert, and signing key)
- `tlsca` folder is used to store in the config block, the TLS verification data - it's basically root CA certs.
@asaningmaxchain
asaningmaxchain (Tue, 03 Oct 2017 13:14:35 GMT):
so the `ca` is the root
asaningmaxchain (Tue, 03 Oct 2017 13:17:36 GMT):
what's the `users` folder
asaningmaxchain (Tue, 03 Oct 2017 13:17:36 GMT):
what's the `users` folder @yacovm
yacovm (Tue, 03 Oct 2017 13:27:16 GMT):
the user's signing key and CA cert
yacovm (Tue, 03 Oct 2017 13:28:41 GMT):
also the user's admin cert (not sure why a user would need the admin cert of the admin user... @jimthematrix @mastersingh24 ideas?)
Vadim (Tue, 03 Oct 2017 13:30:09 GMT):
@yacovm @asaningmaxchain this is the peer admin user cert
Vadim (Tue, 03 Oct 2017 13:30:31 GMT):
it can be used to e.g. install/instantiate chaincodes
yacovm (Tue, 03 Oct 2017 13:32:03 GMT):
nope, that is only correct in case the user is an admin itself
yacovm (Tue, 03 Oct 2017 13:32:34 GMT):
but I was referring to:
```
└── User1@org2.example.com
├── msp
│ ├── admincerts
│ │ └── User1@org2.example.com-cert.pem
Vadim (Tue, 03 Oct 2017 13:33:37 GMT):
that user's cert is located in the peer/msp/admincerts, at least for cryptogen 1.0.2
Vadim (Tue, 03 Oct 2017 13:33:37 GMT):
that admin user's cert is located in the peer/msp/admincerts, at least for cryptogen 1.0.2
Vadim (Tue, 03 Oct 2017 13:34:06 GMT):
what is incorrect about that?
Vadim (Tue, 03 Oct 2017 13:35:50 GMT):
ok, I meant Admin@peer user [ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=5d2BEEYW6hexYRTF3)
yacovm (Tue, 03 Oct 2017 13:41:57 GMT):
yep in that case you're correct
jimthematrix (Tue, 03 Oct 2017 13:53:06 GMT):
@yacovm @Vadim hmm, this is confusing: so the following two files are identical (just tried generating from the latest cryptogen built from master):
```cat crypto-config/peerOrganizations/org1.example.com/users/User1\@org1.example.com/msp/admincerts/User1\@org1.example.com-cert.pem
crypto-config/peerOrganizations/org1.example.com/users/User1\@org1.example.com/msp/signcerts/User1\@org1.example.com-cert.pem
jimthematrix (Tue, 03 Oct 2017 13:53:06 GMT):
@yacovm @Vadim hmm, this is confusing: so the following two files are identical (just tried generating from the latest cryptogen built from master):
```org1.example.com/users/User1\@org1.example.com/msp/admincerts/User1\@org1.example.com-cert.pem
org1.example.com/users/User1\@org1.example.com/msp/signcerts/User1\@org1.example.com-cert.pem
yacovm (Tue, 03 Oct 2017 13:53:39 GMT):
looks like the user is an admin? ;)
jimthematrix (Tue, 03 Oct 2017 13:53:54 GMT):
it can't
yacovm (Tue, 03 Oct 2017 13:53:55 GMT):
or at least thinks he is?
jimthematrix (Tue, 03 Oct 2017 13:54:17 GMT):
because the peers msp config dir is set to `org1.example.com/`
jimthematrix (Tue, 03 Oct 2017 13:54:17 GMT):
because the peers msp config dir is set to `org1.example.com/msp`
jimthematrix (Tue, 03 Oct 2017 13:54:44 GMT):
which has a different admin cert
yacovm (Tue, 03 Oct 2017 13:54:53 GMT):
I don't think admincerts should even be in that folder since a client SDK doesn't listen for connections and only invokes operations on network nodes, not the other way around so there is no admin operation on an SDK that can be verified
jimthematrix (Tue, 03 Oct 2017 13:56:30 GMT):
right, that's likely what the "admincerts" under the User1 folder is meant for, that it's validating a response signed by the admin
jimthematrix (Tue, 03 Oct 2017 13:56:30 GMT):
right, that's likely what the "admincerts" under the User1 folder is meant for, that it's validating a response signed by the admin (presumably you could have a peer be configured with the admin identity, and an endorsement policy containing `org1.ADMIN`)
jimthematrix (Tue, 03 Oct 2017 13:56:44 GMT):
but the problem is the cert has the wrong content
yacovm (Tue, 03 Oct 2017 13:58:37 GMT):
but what response by an admin can an SDK even validate??
yacovm (Tue, 03 Oct 2017 13:59:18 GMT):
> and an endorsement policy containing
This doesn't make sense, a peer cannot be an admin...
yacovm (Tue, 03 Oct 2017 13:59:44 GMT):
BTW Jim - the SDK doesn't verify the signature of the endorsements returned from the peer, does it?
jimthematrix (Tue, 03 Oct 2017 13:59:47 GMT):
a peer SHOULDN'T be an admin, but it definitely CAN be made one
jimthematrix (Tue, 03 Oct 2017 14:00:53 GMT):
the node SDK doesn't validate the certs accompanying proposal response, but Java SDK does in fact
jimthematrix (Tue, 03 Oct 2017 14:01:13 GMT):
(both SDKs do verify the signature, to be clear)
yacovm (Tue, 03 Oct 2017 14:01:15 GMT):
so I'm not talking about cert validation, but about signature validation of the endorsements
yacovm (Tue, 03 Oct 2017 14:01:25 GMT):
> (both SDKs do verify the signature, to be clear)
oh? really?
yacovm (Tue, 03 Oct 2017 14:01:37 GMT):
what if a signature is signed improperly then ?
yacovm (Tue, 03 Oct 2017 14:01:53 GMT):
lets say you got an endorsements from peer0, peer1, peer2 and the signature from peer2 is wrong
yacovm (Tue, 03 Oct 2017 14:02:00 GMT):
will the endorsement fail?
yacovm (Tue, 03 Oct 2017 14:02:14 GMT):
will the client SDK return an error?
yacovm (Tue, 03 Oct 2017 14:02:24 GMT):
so that the submission of the transaction to the orderer will not happen?
yacovm (Tue, 03 Oct 2017 14:05:49 GMT):
@jimthematrix ^
jimthematrix (Tue, 03 Oct 2017 14:09:41 GMT):
both SDK's expose a utility API to check if all responses have valid signatures, and returns `false` if any failed to verify
jimthematrix (Tue, 03 Oct 2017 14:09:56 GMT):
then it's up to the app (that uses the SDK) to decide whether to proceed or not
yacovm (Tue, 03 Oct 2017 14:18:55 GMT):
Could you perhaps give me a link to the code (node.SDK preferred) @jimthematrix ?
Thanks in advance!
yacovm (Tue, 03 Oct 2017 14:37:01 GMT):
https://github.com/hyperledger/fabric-sdk-node/blob/6f7310ccda8648473d0f794e28c5b390ac030480/fabric-client/lib/Channel.js#L1620-L1665
Is this here?
jimthematrix (Tue, 03 Oct 2017 17:14:29 GMT):
@yacovm that's correct
yacovm (Tue, 03 Oct 2017 17:20:15 GMT):
@troyronda @aleksandar.likic do you guys know if it's checked in go-SDK ?
yacovm (Tue, 03 Oct 2017 17:21:22 GMT):
Message Attachments
aleksandar.likic (Tue, 03 Oct 2017 18:03:11 GMT):
Go SDK is currently not checking endorsement signatures. How does other SDKs achieve this without discovery service (that the client could use to obtain endorsers' certs)? By sticking the certs in the client configuration?
yacovm (Tue, 03 Oct 2017 19:10:40 GMT):
@aleksandar.likic - simple. When you get the endorsement, the endorser's certs are already in the signed proposal !
yacovm (Tue, 03 Oct 2017 19:11:18 GMT):
The SDK is primed with the root CA certs of all orgs and with this, it can validate the endorser's cert, and then afterwards - verify the signature.
yacovm (Tue, 03 Oct 2017 19:12:09 GMT):
Can you configure the root CA certs of other orgs in the Go-SDK? (I don't remember... used it too long ago)
yacovm (Tue, 03 Oct 2017 19:15:17 GMT):
@troyronda ^
falix (Wed, 04 Oct 2017 02:01:06 GMT):
Has joined the channel.
rock_martin (Wed, 04 Oct 2017 06:01:44 GMT):
HI ,Can we access transaction id of the parent invocation of the transaction in chaincode?
Vadim (Wed, 04 Oct 2017 07:16:06 GMT):
@rock_martin stub.GetTxID()?
yacovm (Wed, 04 Oct 2017 07:58:44 GMT):
I think by parent invocation he means a chaincode2chaincode call no?
Vadim (Wed, 04 Oct 2017 07:59:23 GMT):
@yacovm I don't know what he means, trying to get more info from him ;)
Colonel_HLE (Wed, 04 Oct 2017 09:23:33 GMT):
Has joined the channel.
Colonel_HLE (Wed, 04 Oct 2017 09:23:41 GMT):
Hey, what is the main difference between *endorsers* in fabric and a *notary node* in corda? They look quite similar to me, but i think i am missing something.
surabhi (Wed, 04 Oct 2017 09:42:05 GMT):
Has joined the channel.
rock_martin (Wed, 04 Oct 2017 10:30:00 GMT):
sorry @Vadim @yacovm its not parent.its current
rock_martin (Wed, 04 Oct 2017 10:30:09 GMT):
sorry for typographical mistake
Vadim (Wed, 04 Oct 2017 10:35:21 GMT):
@rock_martin so then `stub.GetTxID()` should work for you
rock_martin (Wed, 04 Oct 2017 10:35:32 GMT):
@vadim Thanks
rock_martin (Wed, 04 Oct 2017 10:36:17 GMT):
Could you please let me know for implementation of fabric as for production level i.e as running on multiple hosts
asaningmaxchain (Wed, 04 Oct 2017 11:13:36 GMT):
@jimthematrix can you explain the msp detailly?
chrispoole (Wed, 04 Oct 2017 15:18:01 GMT):
Has joined the channel.
Menniti (Wed, 04 Oct 2017 20:22:41 GMT):
Has joined the channel.
elli-androulaki (Thu, 05 Oct 2017 07:35:03 GMT):
@asaningmaxchain here is the doc on MSP http://hyperledger-fabric.readthedocs.io/en/latest/msp.html and for MSP identities http://hyperledger-fabric.readthedocs.io/en/latest/msp-identity-validity-rules.html.
return_01 (Thu, 05 Oct 2017 13:42:35 GMT):
Has joined the channel.
AbhishekSeth (Fri, 06 Oct 2017 07:19:30 GMT):
Has joined the channel.
AbhishekSeth (Fri, 06 Oct 2017 07:21:37 GMT):
hey all...
Where and how to define which peer acts as admin for an org?
rock_martin (Fri, 06 Oct 2017 10:14:08 GMT):
if I install chaincode on 3 peers of a channel that has total number of 5 so when I instantiate chaincode does the endorsement policy exclude those 2 peers by itself even if they are involved in the organisation that endorsed the chaincode
rock_martin (Fri, 06 Oct 2017 11:18:18 GMT):
I had a query, because the node SDK keeps all the certificates and keys in artifacts. So I think we need to have one node app for each and every organization(or pehaps every peer), that only have certificates for their organization's peer??
How would we transport the client and channel objects between these applications??
DarshanBc (Fri, 06 Oct 2017 13:11:39 GMT):
Hi today with endorsement policy I observed a peculiar behavior of txn execution in balance transfer instead of A and B I'm extracting enroll ID from getcreator() and making that as key and value is manipulated in two ways 1.simply adding value to balance 2. Like normal txn i.e., increase receiver balance and decrease sendor's balance. I have Jim from org1 and Barry from org2 I've put AND(org1.member,org2.member) endorsement policy for my chaincode. I observed that txn is successful if I add amount to Jim's balance just like that without any transfer and *execute this txn on peers of org1* block also got added. Txn fails because of endorsement failure only when I do nornal txn any idea why?
jrosmith (Fri, 06 Oct 2017 13:15:06 GMT):
@rock_martin you're right that each organization, assuming you wanted them on separate servers, to have their own node application. you wouldn't need to transport client/channel objects between them...you can just build them for each application. only the channel network config needs to be shared between orgs
jrosmith (Fri, 06 Oct 2017 13:15:36 GMT):
in the future questions like that are better for #fabric-sdk-node
Menniti (Fri, 06 Oct 2017 19:48:29 GMT):
Guys, conceptual questions...
I`m able to create peers instantiate in different networks (IE - My house, Amazon, Digital Ocean) to then talk to each other and be in the same Hyperledger network ?
Until now I have done this only everything in My Local Machine
t_stephens67 (Fri, 06 Oct 2017 19:49:56 GMT):
^
Asara (Fri, 06 Oct 2017 19:52:07 GMT):
@Menniti As long as they are configured to talk to each other and can communicate on the same channel, then yes they are on the same network.
Menniti (Fri, 06 Oct 2017 19:53:57 GMT):
Sorry Asara, i don`t get it
I will be able to connect My house, Amazon and Digital Ocean in the same network by instanciate the same peer on those 3 machines
Menniti (Fri, 06 Oct 2017 19:54:00 GMT):
?
Menniti (Fri, 06 Oct 2017 19:56:35 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=qGczp9wgPB2KwX3Sr) @Asara Got it!!! thank you very much!!!
Menniti (Fri, 06 Oct 2017 19:57:07 GMT):
Other question, make sense use smartphones to instantiate this peers ?
Menniti (Fri, 06 Oct 2017 19:57:28 GMT):
in therm of internet, computing capacity, storage etc..
jrosmith (Fri, 06 Oct 2017 20:59:37 GMT):
@Menniti you don't need the same peer on 3 machines. each machine has its own peer(s), but PeerHouse, PeerAmazon, and PeerDigital need to be connected to the same channel.
Menniti (Sat, 07 Oct 2017 02:11:10 GMT):
@jrosmith, totally make sens! tank you very much
Menniti (Sat, 07 Oct 2017 02:11:23 GMT):
@Asara Thank you too
DarshanBc (Mon, 09 Oct 2017 08:57:02 GMT):
There are 3 orgs org1,org2,org3 there are 2 chaincodes with different endorsement policies such as A->AND(org1.member,org2.member), B->AND(org2.member,org3.member). If chaincode A invokes B only on peers of org2 doesn't the endorsement policy fail?
C0rWin (Mon, 09 Oct 2017 10:27:31 GMT):
@DarshanBc chaincode A could only invoke chaincode B for reads, therefore it cannot fail endorsement policy
DarshanBc (Mon, 09 Oct 2017 10:28:07 GMT):
how about for writes?
DarshanBc (Mon, 09 Oct 2017 10:28:07 GMT):
@C0rWin how about for writes?
C0rWin (Mon, 09 Oct 2017 10:32:41 GMT):
currently, chaincode to chaincode is only for reads
yacovm (Mon, 09 Oct 2017 10:34:24 GMT):
AFAIK you can do a CC2CC write for the same channel
yacovm (Mon, 09 Oct 2017 10:34:34 GMT):
the endorsement policy is checked for all the RWSets
muralisr (Mon, 09 Oct 2017 14:11:00 GMT):
@yacovm +1 ^^^ :-)
nhrishi (Mon, 09 Oct 2017 17:41:49 GMT):
Hi, I've been running an app server that invokes a chaincode. I'm running fabric and App server on 2 different VMs. Its been running perfectly fine for last 4-5 days. I was doing a batch processing. Somehow it worked for around 10 invoke transactions and all of sudden started failing for next invoke transaction. Its giving me below errror and looks to me that peer is no longer accessible to App server. Is there anyway to find out. I see docker container is still running fine. Can anyone please advise asap. This is little urgent. ```error: [Peer.js]: sendProposal - timed out after:60000
error: [client-utils.js]: sendPeersProposal - Promise is rejected: Error: REQUEST_TIMEOUT
at Timeout._onTimeout (./node_modules/fabric-client/lib/Peer.js:121:19)
at ontimeout (timers.js:386:14)
at tryOnTimeout (timers.js:250:5)
at Timer.listOnTimeout (timers.js:214:5)
[2017-10-09 07:50:42.582] [ERROR] invoke-chaincode - transaction proposal was bad
[2017-10-09 07:50:42.582] [ERROR] invoke-chaincode - Failed to send Proposal or receive valid response. Response null or status is not 200. exiting...
[2017-10-09 07:50:42.582] [ERROR] invoke-chaincode - Failed to order the transaction. Error code: undefined
```
yacovm (Mon, 09 Oct 2017 17:44:15 GMT):
@nhrishi any logs of the peer?
yacovm (Mon, 09 Oct 2017 17:44:20 GMT):
also what is the memory consumption of the peer?
yacovm (Mon, 09 Oct 2017 17:44:27 GMT):
CPU consumption?
nhrishi (Mon, 09 Oct 2017 17:59:34 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=QmRieZRgdM9D52Bjo) @yacovm Somehow docker logs is not giving me any output. Its taking forever. Memory usage - 114.4 MiB / 62.75 GiB 0.18% and CPU usage is varying between 15% - 50%
yacovm (Mon, 09 Oct 2017 18:01:40 GMT):
you can do `docker inspect` and see where the logs are outputted to
yacovm (Mon, 09 Oct 2017 18:01:43 GMT):
is the file system full perhaps?
nhrishi (Mon, 09 Oct 2017 18:18:16 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=sSWBup3eogeCnD6bE) @yacovm Thanks. Interestingly, I processed 10 invoke transactions through this peer successfully but dont see anything in the log. I also dont see any transaction received when i invoke from app. Yes I upgraded the diskspace today, its not full.
yacovm (Mon, 09 Oct 2017 18:19:07 GMT):
so you invoke from the node SDK
yacovm (Mon, 09 Oct 2017 18:19:09 GMT):
wait for the event
yacovm (Mon, 09 Oct 2017 18:19:16 GMT):
and you don't get it
yacovm (Mon, 09 Oct 2017 18:19:17 GMT):
right?
nhrishi (Mon, 09 Oct 2017 18:19:24 GMT):
yes
nhrishi (Mon, 09 Oct 2017 18:19:49 GMT):
its failing at sendProposal
yacovm (Mon, 09 Oct 2017 18:19:50 GMT):
aha, ok - and if you query for the chaincode - do you see that the state changed?
yacovm (Mon, 09 Oct 2017 18:19:56 GMT):
ah I see
yacovm (Mon, 09 Oct 2017 18:20:14 GMT):
and you say you can't look at the peer logs?
nhrishi (Mon, 09 Oct 2017 18:20:45 GMT):
I cant see using docker logs but I could see it using path in docker inspect.
yacovm (Mon, 09 Oct 2017 18:21:20 GMT):
and what does it say?
yacovm (Mon, 09 Oct 2017 18:21:26 GMT):
anythinh interesting?
nhrishi (Mon, 09 Oct 2017 18:22:52 GMT):
Interestingly, I don't see any log updates for today.Rest all looks usual and no errors
nhrishi (Mon, 09 Oct 2017 18:23:35 GMT):
I'm looking at " "LogPath": "/var/lib/docker/containers/2930214f3f1e95016e3b41264372ed26290c74ae121069479d90c1b2168bc303/2930214f3f1e95016e3b41264372ed26290c74ae121069479d90c1b2168bc303-json.log",
"
nhrishi (Mon, 09 Oct 2017 18:23:50 GMT):
do you think its not the one
yacovm (Mon, 09 Oct 2017 18:24:54 GMT):
no idea
nhrishi (Mon, 09 Oct 2017 18:25:51 GMT):
its weird
yacovm (Mon, 09 Oct 2017 20:45:46 GMT):
@nhrishi is the peer still alive?
nhrishi (Tue, 10 Oct 2017 04:04:20 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=EY6NvQJvh5ifA8QeS) @yacovm Yes its still alive.
nhrishi (Tue, 10 Oct 2017 08:45:15 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=KuawKpBZBamzabWFk) @nhrishi @yacovm Today, I've started getting this issue for other peers as well and yesterday, I managed to invoke and query on these peers successfully. This looks like related to Docker containers.
nhrishi (Tue, 10 Oct 2017 08:45:15 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=KuawKpBZBamzabWFk) @nhrishi @yacovm Today, I've started getting this issue for other peers as well and yesterday, I managed to invoke and query on these peers successfully. This looks like related to Docker containers. Btw I've been running the network for 5 days now.
DarshanBc (Tue, 10 Oct 2017 10:53:17 GMT):
Can an endorsement policy be on different peers of same orgs
yacovm (Tue, 10 Oct 2017 10:58:50 GMT):
yes
nhrishi (Tue, 10 Oct 2017 11:33:10 GMT):
@yacovm I did check ther peer log but i dont see the request is hitting the peer at all. Also when i do a docker stats Net I/O is as below. Do you think this is something can cause the issue - ``` 965 MB / 1.21 GB
1.23 GB / 1.13 GB
3.16 GB / 3.95 GB
4.24 GB / 4.19 GB
1.13 GB / 1.21 GB
3.19 GB / 3.98 GB
1.21 GB / 917 MB
3.06 GB / 4.03 GB
1.15 GB / 1.22 GB```
nhrishi (Tue, 10 Oct 2017 11:33:10 GMT):
@yacovm I did check ther peer log but i dont see the request is hitting the peer at all. Also when I do a docker stats on peers Net I/O is as below. Do you think this is something can cause the issue - ``` 965 MB / 1.21 GB
1.23 GB / 1.13 GB
3.16 GB / 3.95 GB
4.24 GB / 4.19 GB
1.13 GB / 1.21 GB
3.19 GB / 3.98 GB
1.21 GB / 917 MB
3.06 GB / 4.03 GB
1.15 GB / 1.22 GB```
yacovm (Tue, 10 Oct 2017 11:33:29 GMT):
what is this GB?
nhrishi (Tue, 10 Oct 2017 11:33:47 GMT):
Net I/O
yacovm (Tue, 10 Oct 2017 11:33:49 GMT):
if you don't see the request hitting the peer - can you perhaps use `tcpdump` and see if there is any traffic reaching it?
DarshanBc (Tue, 10 Oct 2017 11:33:55 GMT):
@yacovm can I have affiliations for peers and have endorsements based on that?
yacovm (Tue, 10 Oct 2017 11:33:58 GMT):
on port 7051
yacovm (Tue, 10 Oct 2017 11:34:10 GMT):
> @yacovm can I have affiliations for peers and have endorsements based on that?
affiliation? What's that?
nhrishi (Tue, 10 Oct 2017 11:34:20 GMT):
Ok let me try
nhrishi (Tue, 10 Oct 2017 17:17:26 GMT):
@yacovm, Can I add new additional anchor peer in the existing network and kill/remove existing one later.
nhrishi (Tue, 10 Oct 2017 17:21:04 GMT):
Hi, I'm running a network with multiple organization and peers since last 5 days. Apparently, node app is not connecting to nodes and looks like they are in the deadlock situation and not responding. Is there anyway to resolve this issue without restarting the network or adding additional new nodes and kill existing ones later. Can someone pls advise asap. This is really urgent.
yacovm (Tue, 10 Oct 2017 17:26:23 GMT):
Yes you can
yacovm (Tue, 10 Oct 2017 17:26:56 GMT):
@nhrishi did you do tcpdump like i suggested?
nhrishi (Tue, 10 Oct 2017 17:28:51 GMT):
@yacovm yes I did and see traffic on the network. In fact, I'm able to invoke/query one of the peer. The issue is only for some set of peers.
nhrishi (Tue, 10 Oct 2017 17:29:44 GMT):
I'm trying to do docker stop and start but peer is not stopping
yacovm (Tue, 10 Oct 2017 17:30:57 GMT):
ah it's not stopping?
yacovm (Tue, 10 Oct 2017 17:31:26 GMT):
can you please then do `ps exec
nhrishi (Tue, 10 Oct 2017 17:31:28 GMT):
yes so i have 2 peers for this organization. Peer0 and Peer1. Peer0 is anchor node.
nhrishi (Tue, 10 Oct 2017 17:31:46 GMT):
I managed to stop peer1 but not peer0
yacovm (Tue, 10 Oct 2017 17:31:47 GMT):
kill with SIGABRT will make a peer crash and dump its stack trace to stdout/stderr
yacovm (Tue, 10 Oct 2017 17:31:55 GMT):
then you can send me the stack trace
nhrishi (Tue, 10 Oct 2017 17:32:43 GMT):
Okay, Just want to confirm, but I can replace another peer with this one. I don't want to restart the network and lose data.
nhrishi (Tue, 10 Oct 2017 17:32:43 GMT):
Okay, Just want to confirm, but can I replace another peer with this one? I don't want to restart the network and lose data.
yacovm (Tue, 10 Oct 2017 17:33:09 GMT):
well I just want to fix a problem in case there is a bug
yacovm (Tue, 10 Oct 2017 17:33:16 GMT):
well the peer writes to a volume
yacovm (Tue, 10 Oct 2017 17:33:19 GMT):
right?
yacovm (Tue, 10 Oct 2017 17:33:29 GMT):
if the volume is persisted with docker restart
yacovm (Tue, 10 Oct 2017 17:33:32 GMT):
then you're good
yacovm (Tue, 10 Oct 2017 17:33:42 GMT):
is the volume shared between the host and the peer?
yacovm (Tue, 10 Oct 2017 17:33:42 GMT):
is the volume shared between the host and the peer? (docker)
nhrishi (Tue, 10 Oct 2017 17:33:55 GMT):
yes Its shared. Its just i never did it
yacovm (Tue, 10 Oct 2017 17:34:31 GMT):
lets do an experiment: start a peer the way you start it but instead of a peer make there a sleep command
yacovm (Tue, 10 Oct 2017 17:34:40 GMT):
and then, log into the docker container
yacovm (Tue, 10 Oct 2017 17:34:42 GMT):
of the sleep command
yacovm (Tue, 10 Oct 2017 17:34:55 GMT):
and do `echo "bla bla" > /var/hyperledger/production`
yacovm (Tue, 10 Oct 2017 17:35:06 GMT):
and then restart the docker instance and see if it is still there
yacovm (Tue, 10 Oct 2017 17:35:13 GMT):
this way you'll test the docker setup
yacovm (Tue, 10 Oct 2017 17:35:16 GMT):
if it is persisted, or not
nhrishi (Tue, 10 Oct 2017 17:37:45 GMT):
Sorry I didnt understand about the sleep command in the docker. You mean shell command?
yacovm (Tue, 10 Oct 2017 17:38:58 GMT):
yes
nhrishi (Tue, 10 Oct 2017 17:47:33 GMT):
sure let me try that. Btw If I crash the peer, will I be able to bring it back using docker start.
nhrishi (Tue, 10 Oct 2017 17:54:32 GMT):
I tried `kill -SIGABRT 1` in my dev environment and did docker start. I'm able to see existing data and invoke/query.
yacovm (Tue, 10 Oct 2017 17:59:38 GMT):
noooooooo
yacovm (Tue, 10 Oct 2017 17:59:42 GMT):
why did you do docker start?
yacovm (Tue, 10 Oct 2017 17:59:46 GMT):
I wanted the logs!
nhrishi (Tue, 10 Oct 2017 18:00:18 GMT):
yes, I did it in my dev environment. This is not the actual environement i'm having a problem
nhrishi (Tue, 10 Oct 2017 18:00:28 GMT):
I'm having this issue in my UAT environment
yacovm (Tue, 10 Oct 2017 18:00:29 GMT):
ah
nhrishi (Tue, 10 Oct 2017 18:00:35 GMT):
so I'm trying things in dev first before UAT
yacovm (Tue, 10 Oct 2017 18:00:41 GMT):
I see
nhrishi (Tue, 10 Oct 2017 18:19:48 GMT):
Sorry I missed one point. I tried to stop one of the peer in my UAT environment (in order to start again). But it didnt stop gracefully and now we can't do exec -it into it.
nhrishi (Tue, 10 Oct 2017 18:20:13 GMT):
This was an hour back
nhrishi (Wed, 11 Oct 2017 10:25:16 GMT):
@yacovm I tried `kill -SIGABRT 1` on the peer exec bash. It doesn't work. the container is still active in docker ps and running. I tried SIGKILL and SIGTERM as well. Same issue.
yacovm (Wed, 11 Oct 2017 10:25:42 GMT):
it won't die?
nhrishi (Wed, 11 Oct 2017 10:25:49 GMT):
yes
nhrishi (Wed, 11 Oct 2017 10:25:55 GMT):
its still running
nhrishi (Wed, 11 Oct 2017 10:26:04 GMT):
```USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 29.0 0.1 667260 100328 ? Ssl Oct04 2864:22 peer node start
root 21 0.0 0.0 18256 2052 ? Ss+ Oct09 0:00 /bin/bash
root 209 0.1 0.0 18264 1888 ? Ss 10:23 0:00 /bin/bash
root 219 0.0 0.0 34416 1456 ? R+ 10:24 0:00 ps -auxwww
```
nhrishi (Wed, 11 Oct 2017 10:47:27 GMT):
@yacovm Do you see any other options. I need restart this peer.
nhrishi (Wed, 11 Oct 2017 10:47:46 GMT):
and we can also capture stack trace so we can also investigate
yacovm (Wed, 11 Oct 2017 10:48:04 GMT):
hmm not sure what you can do, also i'm in a meeting... sorry
nhrishi (Wed, 11 Oct 2017 10:48:53 GMT):
oh ok
nhrishi (Wed, 11 Oct 2017 10:48:56 GMT):
no worries
nhrishi (Thu, 12 Oct 2017 07:40:17 GMT):
@yacovm @Vadim Just want to update on the issue, we discussed for last 2 days. We've managed bring nodes back up. We had to remove the node, then restart docker daemon and start all docker containers in the network. All unresponsive nodes are brought up and synced with the network without losing data. Really appreciate your help. Thanks a lot. :thumbsup: A couple of points/ observations - We couldn't pinpoint the real issue behind peer going into the unresponsive mode. For adding new peer with different name on the live network, we need to really look at cryptogen utility to produce certs based on the root CA. Also we mainly need to look at how we can increase transaction throughput. I've some ideas, will let update you after my investigation. We should have the best practices guide on it.
yacovm (Thu, 12 Oct 2017 07:41:06 GMT):
what's wrong with Tx throughput?
yacovm (Thu, 12 Oct 2017 07:41:16 GMT):
are you running v1.0.x or master branch?
nhrishi (Thu, 12 Oct 2017 07:41:33 GMT):
yes I'm running on the 1.0.2
yacovm (Thu, 12 Oct 2017 07:43:38 GMT):
and what's the problem with throughput?
nhrishi (Thu, 12 Oct 2017 07:44:31 GMT):
Just want to clarify, the above issue started when I was processing around 100 transactions and the invoke started failing with REQUEST_TIMEOUT issue after 20-25 transactions. Since then it went into the unresponsive mode. I'm sure something went wrong during this.
nhrishi (Thu, 12 Oct 2017 07:45:24 GMT):
I'm planning to do more regressive testing in our dev environment to see if I can replicate the issue.
nhrishi (Thu, 12 Oct 2017 07:45:24 GMT):
I'm planning to do more regression testing in our dev environment to see if I can replicate the issue.
niteshsolanki (Thu, 12 Oct 2017 13:46:34 GMT):
Hi. I had a question regarding events in hyperledger. What happens if the rate of consumption of events is slower than the production? what happens if the events.buffer is full and events.timeout has reached ? are the events from the buffer dropped ?
rsherwood (Fri, 13 Oct 2017 10:20:15 GMT):
Does anyone know if when proposing or endorsing a transaction if the current version of the channel configuration block is recorded in the transaction, and if would be checked in the orderer or VSCC ? The question behind the question is, if we start changing the CRL list in the MSP of the channel configuration block will that affect in-flight transactions (assuming that we do not add any of the endorsers or proposers cert numbers to the CRL list so the transaction is still valid with both the old and amended configuration block).
yacovm (Fri, 13 Oct 2017 10:28:57 GMT):
@rsherwood a configuration transaction (one that has CRLs, or any policy or MSP change) comes in its own block
yacovm (Fri, 13 Oct 2017 10:29:33 GMT):
so when a block with transactions is processed, it doesn't have in-flight transactions affected by the config update because the config update has been already either committed, or in flight itself.
yacovm (Fri, 13 Oct 2017 10:29:33 GMT):
so when a block with transactions is processed, it doesn't have in-flight transactions affected by the config update because the config update has been already either committed, or in flight itself (inside the orderer, or queued for delivery to the peer)
rsherwood (Fri, 13 Oct 2017 10:30:58 GMT):
So at the time of endorsement the state of the configuration block is not recorded in the normal transaction ?
yacovm (Fri, 13 Oct 2017 11:43:33 GMT):
no, we don't need it because the transactions comes in a block
yacovm (Fri, 13 Oct 2017 11:43:40 GMT):
and blocks are processed in a sequenced order @rsherwood
tongli (Fri, 13 Oct 2017 15:12:21 GMT):
Has joined the channel.
tongli (Fri, 13 Oct 2017 15:14:58 GMT):
good morning, reading the doc, looking at the chaincode package command, a bit confused by options -s -S and -i, Do not feel that the question was answered, here it is again. using -s without -S, means it will be a signed CDS, but who actually signs the package?
tongli (Fri, 13 Oct 2017 15:16:27 GMT):
reading the doc about chaincode package, confused about -s -S and -i option. When using -s without -S option, means it will be a signed CDS, but who actually signs the package? how does it get signed?
tongli (Fri, 13 Oct 2017 15:18:37 GMT):
can anyone shed a bit light on this?
tongli (Fri, 13 Oct 2017 17:40:58 GMT):
@here, can anyone help out with the question above? Thanks.
JonathanLevi (Fri, 13 Oct 2017 17:42:11 GMT):
Tong, did we not ask you something?
yacovm (Fri, 13 Oct 2017 17:42:11 GMT):
Please don't use here here either
tongli (Fri, 13 Oct 2017 17:42:52 GMT):
@JonathanLevi need to get an answer for my question.
JonathanLevi (Fri, 13 Oct 2017 17:43:31 GMT):
And therefore... you ignore our requests to behave in a certain way here?
yacovm (Fri, 13 Oct 2017 17:43:35 GMT):
wait, didn't you ask that in another channel?
tongli (Fri, 13 Oct 2017 17:43:40 GMT):
seems to be a relatively easy one.
tongli (Fri, 13 Oct 2017 17:43:47 GMT):
yes I did, was directed here.
JonathanLevi (Fri, 13 Oct 2017 17:43:59 GMT):
I *do not care* how easy is your question...
tongli (Fri, 13 Oct 2017 17:44:04 GMT):
did not get answer.
JonathanLevi (Fri, 13 Oct 2017 17:44:06 GMT):
Just to be *very clear*
tongli (Fri, 13 Oct 2017 17:44:24 GMT):
@JonathanLevi if you can answer the question, please do.
JonathanLevi (Fri, 13 Oct 2017 17:46:07 GMT):
@tongli Can you please confirm that you just wrote to me directly
*if you are so good, please answer that question.*
JonathanLevi (Fri, 13 Oct 2017 17:47:08 GMT):
Just trying to make sure that I read it correctly.
tongli (Fri, 13 Oct 2017 17:47:15 GMT):
@JonathanLevi what do you try to get to. I have a question, and trying to get an answer.
JonathanLevi (Fri, 13 Oct 2017 17:47:55 GMT):
We are trying to tell you over and over, not to use @ here, even you believe that your question is simple/easy or challenging enough.
tongli (Fri, 13 Oct 2017 17:48:40 GMT):
well, I am not getting an answer. if you know, please tell me.
Asara (Fri, 13 Oct 2017 17:53:10 GMT):
@tongli http://hyperledger-fabric.readthedocs.io/en/latest/chaincode4noah.html#creating-the-package
Asara (Fri, 13 Oct 2017 17:53:16 GMT):
Have ya read this?
tongli (Fri, 13 Oct 2017 17:53:40 GMT):
Yes. that part does not really tell me what I like to know.
tongli (Fri, 13 Oct 2017 17:53:48 GMT):
the question is this.
tongli (Fri, 13 Oct 2017 17:54:23 GMT):
if use -s without -S, the package is still called SignedCDS, but who actually signed it?
tongli (Fri, 13 Oct 2017 17:55:37 GMT):
I also said that the doc might have to be improved a bit to make it clear that signing package is out of band as Jeff pointed out. the information is not available from the doc.
tongli (Fri, 13 Oct 2017 17:56:13 GMT):
at least I could not find the answer to my question from that doc.
Asara (Fri, 13 Oct 2017 17:56:55 GMT):
`When -s is specified, the -S option must also be specified if other owners are going to need to sign. Otherwise, the process will create a SignedCDS that includes only the instantiation policy in addition to the CDS.`
Asara (Fri, 13 Oct 2017 17:57:32 GMT):
Someone who knows better, correct me if I'm wrong,but that seems to imply that the peer from which you ran the command?
tongli (Fri, 13 Oct 2017 17:58:02 GMT):
right, read that part multiple times, otherwise, the process will create a SignedCDS, but whose signature is in the package?
tongli (Fri, 13 Oct 2017 17:58:17 GMT):
well it says includes only the instantiation policy in addition to the CDS,
tongli (Fri, 13 Oct 2017 17:58:30 GMT):
did not say anything about signature.
tongli (Fri, 13 Oct 2017 17:59:31 GMT):
assume CDS is said above raw CDS which has nothing about signatures.
wlahti (Fri, 13 Oct 2017 18:08:13 GMT):
looking at the code, without -S, the CDS is signed by the default signing identity of the local MSP of the peer you are running the command against.
wlahti (Fri, 13 Oct 2017 18:08:13 GMT):
@tongli looking at the code, without -S, the CDS is signed by the default signing identity of the local MSP of the peer you are running the command against.
wlahti (Fri, 13 Oct 2017 18:10:16 GMT):
I'd need to look further to determine exactly how the default signing identity is set.
wlahti (Fri, 13 Oct 2017 18:10:16 GMT):
I'd need to look further to determine exactly how the default signing identity is set if that's needed.
tongli (Fri, 13 Oct 2017 18:10:17 GMT):
@wlahti cool, cool. thanks for providing the answer. without -S, the peer's signature will be the only signature inside that package since that package can not be further signed.
wlahti (Fri, 13 Oct 2017 18:11:34 GMT):
yes, that's how I understand it
tongli (Fri, 13 Oct 2017 18:12:12 GMT):
@wlahti the peer has a core_peer_id set when it gets started, is it possibly that is how the peer id to be specified?
tongli (Fri, 13 Oct 2017 18:13:32 GMT):
what throws me off is the statement that says "includes only the instantiation policy in addition to the CDS", but it is still called Signed, I think that was the something confused me, it may be clear to others.
tongli (Fri, 13 Oct 2017 18:15:13 GMT):
@wlahti anyway, thanks a lot for helping out. now I understand. so with -S, the package can be passed around to be signed by more parties. Who would be allowed to sign though?
wlahti (Fri, 13 Oct 2017 18:15:17 GMT):
which doc are you looking at? I can follow-up with Murali, the expert in this area, to make sure things are documented correctly and in an accurate, easy to understand way. (Murali's traveling this week, I believe)
tongli (Fri, 13 Oct 2017 18:15:42 GMT):
http://hyperledger-fabric.readthedocs.io/en/latest/chaincode4noah.html
tongli (Fri, 13 Oct 2017 18:16:04 GMT):
the section is creating the package.
tongli (Fri, 13 Oct 2017 18:16:33 GMT):
below the example, there are explanations for options -s -S and -i.
tongli (Fri, 13 Oct 2017 18:18:38 GMT):
now with -S option, I understand multiple parties can sign the package, but who is allowed to sign?
tongli (Fri, 13 Oct 2017 18:19:11 GMT):
can anyone sign that package?
wlahti (Fri, 13 Oct 2017 18:20:15 GMT):
I'm not sure on that part. I could imagine it would let anyone sign but if the signatures don't match the (instantiation? endorsement?) policy the action won't succeed
wlahti (Fri, 13 Oct 2017 18:21:16 GMT):
but that's a guess :)
tongli (Fri, 13 Oct 2017 18:21:18 GMT):
so you mean that the instantiation policy may play a roll on whose signatures are needed?
tongli (Fri, 13 Oct 2017 18:21:41 GMT):
@wlahti understood. thanks again for helping out.
wlahti (Fri, 13 Oct 2017 18:22:33 GMT):
yes, that's what I'd guess. the instantiation policy may say "Org1 and Org2 must sign this package before it can be instantiated" seems like a likely scenario to me
wlahti (Fri, 13 Oct 2017 18:22:33 GMT):
yes, that's what I'd guess. the instantiation policy may say "Org1 and Org2 must have an Admin sign this package before it can be instantiated" seems like a likely scenario to me
tongli (Fri, 13 Oct 2017 18:24:33 GMT):
@wlahti I thought that signing party and instantiation party may be different, but that is just me thinking out loud. but if signing parties are all peers, your guess could be very well true. thanks again.
wlahti (Fri, 13 Oct 2017 18:26:51 GMT):
glad to add my thoughts. :) I've touched the code in this area a few times but haven't spent much time looking into these kinds of details.
wlahti (Fri, 13 Oct 2017 18:27:34 GMT):
when I figure out more, I'll reach out to you in addition to making sure the documentation is updated.
tongli (Fri, 13 Oct 2017 18:29:02 GMT):
@wlahti very cool, really appreciate your help.
minollo (Fri, 13 Oct 2017 21:50:30 GMT):
Has joined the channel.
minollo (Fri, 13 Oct 2017 21:52:54 GMT):
Hopefully not a too obvious question: from the experiments I've run, it is possible to execute parallel endorsement for X transactions against the same chaincode as long as I direct those endorsement requests to X different peers. But it seems to me that endorsement requests (at least for the same chaincode, same channel) sent to a single peer get serialized. Is that true? If yes, is there any obvious technical reason for serializing endorsement requests issues to a single peer for the same chaincode/channel? Thanks!
yacovm (Fri, 13 Oct 2017 22:05:34 GMT):
> But it seems to me that endorsement requests (at least for the same chaincode, same channel) sent to a single peer get serialized. Is that true?
I think that it is serialized indeed.
> is there any obvious technical reason for serializing endorsement requests issues to a single peer for the same chaincode/channel? Thanks!
Not something I can think of.
muralisr (Fri, 13 Oct 2017 22:30:51 GMT):
@minollo requests to a chaincode on a peer is NOT serialized in the peer side
yacovm (Fri, 13 Oct 2017 22:48:06 GMT):
@muralisr aren't they serialized in the shim side though?
muralisr (Fri, 13 Oct 2017 22:48:21 GMT):
nope... shouldn't be
muralisr (Fri, 13 Oct 2017 22:48:35 GMT):
why do you think they are ?
muralisr (Fri, 13 Oct 2017 22:48:52 GMT):
(they used to be in 0.5/0.6 ..... but not in 1.0)
muralisr (Fri, 13 Oct 2017 22:49:42 GMT):
once I get rid of the FSM (which was necessary for serialization in 0.5/0.6), it'll be clearer
muralisr (Fri, 13 Oct 2017 22:52:15 GMT):
off for the day @yacovm
minollo (Fri, 13 Oct 2017 23:16:38 GMT):
@muralisr , @yacovm that's what I noticed in a recent test I run; parallel requests to the same peer, same chaincode ended up serialized; the same to two different peers, same chaincode run in parallel. I may well have been human error; I'll try to reproduce it with straight sdk calls and report back.
jworthington (Sat, 14 Oct 2017 12:59:22 GMT):
Trying to get ccenv docker. docker pull hyperledge/fabric-ccenv:x86_64-1.0.2. Error response from daemon: pull access denied for hyperledge/fabric-ccenv, repository does not exist or may require 'docker login'. What am I doing wrong?
jworthington (Sat, 14 Oct 2017 13:51:13 GMT):
my peer is 1.0.2, but I notice peer chaincode instantiate is trying to pull 1.0.1. Error starting container: Failed to generate platform-specific docker build: Failed to pull hyperledgerhyperledger/fabric-ccenv:x86_64-1.0.1: API error (404): {"message":"pull access denied for hyperledgerhyperledger/fabric-ccenv
jworthington (Sat, 14 Oct 2017 13:52:42 GMT):
iAnd the syntax seems odd to me, but I am not a docker person. hyperledgerhyperledger/fabric-ccenv
jworthington (Sat, 14 Oct 2017 15:05:46 GMT):
well, typo in my manual pull. pulled 1.0.1, 1.0.2, and 1.0.3 fine. But instantiate still shows error: Error starting container: Failed to generate platform-specific docker build: Failed to pull hyperledgerhyperledger/fabric-ccenv:x86_64-1.0.1: API error (404): {"message":"pull access denied for hyperledgerhyperledger/fabric-ccenv, repository does not exist or may require 'docker login'"}
jeffgarratt (Sat, 14 Oct 2017 15:53:21 GMT):
@jworthington those images should also be available from docker hub without issue.
minollo (Sat, 14 Oct 2017 15:55:54 GMT):
@muralisr , @yacovm OK, I understood the problem a bit better. Endorsement against the same chaincode from the same peer, is definitely not serialized; you can indeed run multiple endorsement in parallel - which is great.
But there is indeed a worrisome serialization happening though: while a peer is working on an endorsement (it doesn't matter against which chaincode), any commit operation run by the same peer is blocked. Looking at the log file, that behavior seems to be caused by the fact that, as part of the endorsement, just before running the invoked chaincode function a read lock is acquired on a RWMutex:
`
2017-10-14 14:15:02.335 UTC [lockbasedtxmgr] NewTxSimulator -> DEBU 5c22 constructing new tx simulator
2017-10-14 14:15:02.336 UTC [lockbasedtxmgr] newLockBasedTxSimulator -> DEBU 5c23 constructing new tx simulator [4b4b5b68-4c45-4d6c-95a8-d3fb36e5440a]
2017-10-14 14:15:02.336 UTC [endorser] simulateProposal -> DEBU 5c24 Entry - txid: a548d636e62a5ba1b8f3995607485a92ebf69b1b66c56decdcf7bad9a6cb9c07 channel id: mychannel
2017-10-14 14:15:02.336 UTC [ccprovider] NewCCContext -> DEBU 5c25 NewCCCC (chain=mychannel,chaincode=lscc,version=1.0.1-snapshot-d30b129,txid=a548d636e62a5ba1b8f3995607485a92ebf69b1b66c56decdcf7bad9a6cb9c07,syscc=true,proposal=0xc4220bc5f0,canname=lscc:1.0.1-snapshot-d30b129
2017-10-14 14:15:02.336 UTC [chaincode] Launch -> DEBU 5c26 chaincode is running(no need to launch) : lscc:1.0.1-snapshot-d30b129
NewLockBasedTxSimulator acquites a read lock: txmgr.commitRWLock.RLock()
`
While that transaction is being endorsed, the read lock remains active; at this point I submit a different transaction for endorsement and try to commit it, which ends up doing...
`
2017-10-14 14:15:15.710 UTC [kvledger] Commit -> DEBU 62c5 Channel [mychannel]: Committing block [2] transactions to state database
2017-10-14 14:15:15.710 UTC [lockbasedtxmgr] Commit -> DEBU 62c6 Committing updates to state database
`
Commit tries to acquire a write lock on the same object: txmgr.commitRWLock.Lock().
That lock request waits until the previous endorsement is completed and the read lock is released. That implies that while an endorsement is being "computed", all commit activities by the same peers are locked; other endorsement requests do happen in parallel.
My initial thought that multiple endorsement requests against the same chaincode were serialized was a side effect of using a piece of code that was collecting the endorsement and submitting the commit request in a single logical block.
I suppose the underlying question is whether this is the expected behavior or not. Thanks!
minollo (Sat, 14 Oct 2017 15:55:54 GMT):
@muralisr , @yacovm OK, I understood the problem a bit better. Endorsement against the same chaincode from the same peer, is definitely not serialized; you can indeed run multiple endorsement in parallel - which is great.
But there is indeed a worrisome serialization happening though: while a peer is working on an endorsement (it doesn't matter against which chaincode), any commit operation run by the same peer is blocked. Looking at the log file, that behavior seems to be caused by the fact that, as part of the endorsement, just before running the invoked chaincode function a read lock is acquired on a RWMutex:
2017-10-14 14:15:02.335 UTC [lockbasedtxmgr] NewTxSimulator -> DEBU 5c22 constructing new tx simulator
2017-10-14 14:15:02.336 UTC [lockbasedtxmgr] newLockBasedTxSimulator -> DEBU 5c23 constructing new tx simulator [4b4b5b68-4c45-4d6c-95a8-d3fb36e5440a]
2017-10-14 14:15:02.336 UTC [endorser] simulateProposal -> DEBU 5c24 Entry - txid: a548d636e62a5ba1b8f3995607485a92ebf69b1b66c56decdcf7bad9a6cb9c07 channel id: mychannel
2017-10-14 14:15:02.336 UTC [ccprovider] NewCCContext -> DEBU 5c25 NewCCCC (chain=mychannel,chaincode=lscc,version=1.0.1-snapshot-d30b129,txid=a548d636e62a5ba1b8f3995607485a92ebf69b1b66c56decdcf7bad9a6cb9c07,syscc=true,proposal=0xc4220bc5f0,canname=lscc:1.0.1-snapshot-d30b129
2017-10-14 14:15:02.336 UTC [chaincode] Launch -> DEBU 5c26 chaincode is running(no need to launch) : lscc:1.0.1-snapshot-d30b129
NewLockBasedTxSimulator acquites a read lock: txmgr.commitRWLock.RLock()
While that transaction is being endorsed, the read lock remains active; at this point I submit a different transaction for endorsement and try to commit it, which ends up doing...
2017-10-14 14:15:15.710 UTC [kvledger] Commit -> DEBU 62c5 Channel [mychannel]: Committing block [2] transactions to state database
2017-10-14 14:15:15.710 UTC [lockbasedtxmgr] Commit -> DEBU 62c6 Committing updates to state database
Commit tries to acquire a write lock on the same object: txmgr.commitRWLock.Lock().
That lock request waits until the previous endorsement is completed and the read lock is released. That implies that while an endorsement is being "computed", all commit activities by the same peers are locked; other endorsement requests do happen in parallel.
My initial thought that multiple endorsement requests against the same chaincode were serialized was a side effect of using a piece of code that was collecting the endorsement and submitting the commit request in a single logical block.
I suppose the underlying question is whether this is the expected behavior or not. Thanks!
muralisr (Sat, 14 Oct 2017 16:09:09 GMT):
@minollo the tx simualtor is used to collect RW deltas created by the tx and spans each proposal. @dave.enyeart @manish-sethi any way to optimize this endorser/committer locks ?
dave.enyeart (Sat, 14 Oct 2017 16:23:35 GMT):
@muralisr @minollo @manish-sethi The locks between simulation and commit are indeed expected behavior. Say your simulation does multiple queries, you don't want those queries to return inconsistent results due to on-going commits. There is some research on how to optimize this in the long term, but no 'quick fix' in the short-term.
minollo (Sat, 14 Oct 2017 16:45:47 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=tseCm58DDxdZ4sfZw) @dave.enyeart Thanks @dave.enyeart ; I would have expected that being addressed providing a snapshot of the state stable for the duration of a simulation (either provided by the underlying persistence engine, or by a layer on top of it). I suppose something along those lines is part of the ongoing research you mentioned.
minollo (Sat, 14 Oct 2017 16:45:47 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=tseCm58DDxdZ4sfZw) @dave.enyeart Thanks; I would have expected that being addressed providing a snapshot of the state stable for the duration of a simulation (either provided by the underlying persistence engine, or by a layer on top of it). I suppose something along those lines is part of the ongoing research you mentioned.
manish-sethi (Sun, 15 Oct 2017 02:48:31 GMT):
@minollo Just to clarify further on the lock aspect. The write lock is acquired for a very short duration - Only for committing the final writes to the db. The actual validation of trans (the most time consuming operation) are performed before holding the write locks. So, this write lock should not become performance issue especially, If your simulation are mostly short running trans.
Yes, we also intend to use the snapshot based approach going forward.
manish-sethi (Sun, 15 Oct 2017 02:51:48 GMT):
Also, if you want to discuss these aspects further or want to share some empirical observations about this lock, it would be helpful, if you can share that on fabric-ledger channel.
minollo (Sun, 15 Oct 2017 10:37:58 GMT):
@manish-sethi the problem is not that the write lock is acquired for a short or long duration; the problem is that read locks during endorsement can indeed be acquired for long amounts of time (as long as it takes to invoke a chaincode function) - which implies that *any* commit operation on that peer is blocked during that time.
manish-sethi (Sun, 15 Oct 2017 14:01:22 GMT):
@minollo - I'll move this discussion to fabric-ledger channel for the benefit of others and would post respond there later.
muralisr (Sun, 15 Oct 2017 14:56:10 GMT):
@minollo `read locks during endorsement can indeed be acquired for long amounts of time (as long as it takes to invoke a chaincode function)` not sure what "long amounts of time" means here but application should be layered in such a way - typically - to keep heavy processing business logic out of chaincode. Keep chaincode lean/mean as a maintainer of consented ledger state (and @manish-sethi we can take up further discussion in fabric-ledger as you suggest)
jworthington (Sun, 15 Oct 2017 17:22:47 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=GE4HstnMAyAziGsc8) @jeffgarratt Thanks. Yes. But peer chaincode instantiate is making the call to docker. Not me. So I don't see how to control that. Even after I manually pull, instantiate is erroring on the docker pull attempt.
jeffgarratt (Sun, 15 Oct 2017 18:04:05 GMT):
@jworthington just saw this 'hyperledgerhyperledger/fabric-ccenv'... seems that is one to many hyperledgers
jeffgarratt (Sun, 15 Oct 2017 18:04:21 GMT):
not sure if cut paste issue
jeffgarratt (Sun, 15 Oct 2017 18:04:21 GMT):
not sure if copy paste issue on your post though vs config issue
jworthington (Sun, 15 Oct 2017 19:07:17 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=GgSr79dicPWe4pbNd) @jeffgarratt it can eb tough, I know. I issue the command " peer chaincode instantiate -o providercred-ord.belltane.com:7050 -C channel1 -n marbles -v 0 -c '{"Args":["init","a", "100", "b","200"]}' " and the cleint response is " 2017-10-14 14:51:47.960 UTC [msp/identity] Sign -> DEBU 005 Sign: plaintext: 0ACD070A6608031A0C0883C988CF0510...30300A000A04657363630A0476736363
2017-10-14 14:51:47.960 UTC [msp/identity] Sign -> DEBU 006 Sign: digest: B2EF7A421542D5A00BB4CF7470F2F3928AD5D37334DD09B49EF48A61623E63B1
Error: Error endorsing chaincode: rpc error: code = Unknown desc = Error starting container: Failed to generate platform-specific docker build: Failed to pull hyperledgerhyperledger/fabric-ccenv:x86_64-1.0.1: API error (404): {"message":"pull access denied for hyperledgerhyperledger/fabric-ccenv, repository does not exist or may require 'docker login'"} " and the server log is " 2017-10-14 14:50:42.935 UTC [dockercontroller] Start -> DEBU 74b Start container belltane-providercred-marbles-0
2017-10-14 14:50:42.935 UTC [dockercontroller] createContainer -> DEBU 74c Create container: belltane-providercred-marbles-0
2017-10-14 14:50:42.938 UTC [dockercontroller] Start -> DEBU 74d start-could not find image
jworthington (Sun, 15 Oct 2017 19:10:01 GMT):
I'm using the prebuilt binary from Sept 1. I am pretty sure I used it before OK. But I've also done my own makes so possibly not.
minollo (Sun, 15 Oct 2017 20:43:56 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=EpxkTF3DBJ7Wjc4Gf) @muralisr Sure, we all agree about that; but it's also true we have little (no) control on what users do in a chaincode; and I would assume we want to avoid any bottleneck in the infrastructure which is susceptible to how one part of the user's code takes...
minollo (Sun, 15 Oct 2017 20:43:56 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=EpxkTF3DBJ7Wjc4Gf) @muralisr Sure, we all agree about that; but it's also true we have little (no) control on what users do in a chaincode; and I would assume we want to avoid any bottleneck in the infrastructure which is susceptible to how one part of the user's code behaves...
eabiodun (Sun, 15 Oct 2017 23:38:37 GMT):
Has joined the channel.
luomin (Mon, 16 Oct 2017 08:57:14 GMT):
Has joined the channel.
jworthington (Mon, 16 Oct 2017 13:29:47 GMT):
peer chaincode instantiate error. chaincode install was fine. Error starting container: Failed to generate platform-specific docker build: Error returned from build: 1 "can't load package: package ../../bin/github.com/hyperledger/fabric/chaincode/marbles: open /bin/github.com/hyperledger/fabric/chaincode/marbles: no such file or directory. I see it is looking for a relative directory. relative to what? if the chaincode is installed, why can it not be found for instantiate?
thakkarparth007 (Mon, 16 Oct 2017 19:38:32 GMT):
@minollo while you are right that we have no control over what users do in a chaincode, at least for the "very short duration" argument, my experiments have shown that it hasn't been a real bottleneck. The major bottleneck are still the crypto operations. The wait time of the writers is less than a millisecond, or an order of magnitude lesser (i don't remember currently). And this lock is for the entire block of transactions.
On the other hand, the overall transaction takes 200-500ms (depending upon the load) on a set of 8 peers all connected with very high speed network.
thakkarparth007 (Mon, 16 Oct 2017 19:39:22 GMT):
The commit duration itself takes 100-200ms for leveldb, more for couchdb.
thakkarparth007 (Mon, 16 Oct 2017 19:39:45 GMT):
So currently the locks aren't causing any harm, and are outnumbered by the latency due to other operations.
minollo (Mon, 16 Oct 2017 19:41:16 GMT):
@thakkarparth007 I think the misunderstanding here is that the risk is not how long the write lock is; but how long the read locks (during endorsements) are; if a simulation on peer A lasts, say, 1 second because the user has written a very complex chaincode function, any commit activity on that same peer A (same channel) is locked until the simulation of 1 second completes
thakkarparth007 (Mon, 16 Oct 2017 19:42:20 GMT):
By "wait time of a writer" I meant the time between the time a writer calls "rwMutex.Lock()" and the time when the call returns. I should've clarified that more.
thakkarparth007 (Mon, 16 Oct 2017 19:42:43 GMT):
And yes, if the chaincode is that complex, you'd have such an issue.
minollo (Mon, 16 Oct 2017 19:42:59 GMT):
Yep; that's all I'm saying
minollo (Mon, 16 Oct 2017 19:45:59 GMT):
@thakkarparth007 that said, I'm interested in hearing about other performance bottlenecks you are aware of - and also understanding what kind of work is happening to alleviate them; can you elaborate?
thakkarparth007 (Mon, 16 Oct 2017 19:54:07 GMT):
In my experiments we haven't considered network latency, so I can only talk about peer components. Orderer wasn't becoming a bottleneck before the peers, so we haven't focused on the orderer either (a single kafka-based orderer was sufficient). Given this, we found that:
1. Seriality of channels was a bottleneck. Throughput maxes out pretty soon, before the CPU becomes a bottleneck, since the commit is currently serial. So if you can, try to have multiple channels. With more channels, peers can process more transactions, faster.
2. CPU becomes a bottleneck when there are multiple channels. So you should have enough CPUs to handle more channels, and an overall (across channels) high load of transactions.
3. Underlying database - leveldb is much better.
4. Endorsement policy used - this I'm not too clear about yet, because we didn't use the N-out-of syntax, and instead used complex joins of "AND"s and "OR"s for specifying "3 out of 4 orgs" as the endorsement policy. One thing was clear that if the endorsement policy is complex (long), then that does affect the max throughput limit.
thakkarparth007 (Mon, 16 Oct 2017 19:56:06 GMT):
our experiments consisted of microbenchmarks - though we couldn't really find "long running" smart contracts for benchmarking. Major bottleneck was the commit phase. Endorsement and ordering were scaling well with increasing load.
thakkarparth007 (Mon, 16 Oct 2017 19:59:47 GMT):
Oh, and of course, crypto operations were a major bottleneck. But I think recently a fix for that got merged - the MSP component was optimized to reduce the crypto operations, and that did give a major boost to performance.
thakkarparth007 (Mon, 16 Oct 2017 20:03:38 GMT):
There's also one more thing - latency of transactions matters - not just throughput, in case you have many transactions touching the same keys in the ledger, due to MVCC errors. Currently Fabric creates read-write sets entirely on the endorser, and that happens rather quickly, but there's a considerable delay before the values get committed.
thakkarparth007 (Mon, 16 Oct 2017 20:06:27 GMT):
So in case there are multiple conflicting transactions, it'd reduce the throughput. For example, if you're having a counter key that simply gets incremented every time a user visits a page (stupid example for a 'blockchain' maybe, but serves the demo) - you don't want to wait for 0.5-1s (for previous increment to have committed).
I was personally thinking if we could introduce 'lazy
thakkarparth007 (Mon, 16 Oct 2017 20:06:27 GMT):
So in case there are multiple conflicting transactions, it'd reduce the throughput. For example, if you're having a counter key that simply gets incremented every time a user visits a page (stupid example for a 'blockchain' maybe, but serves the demo) - you don't want to wait for 0.5-1s (for previous increment to have committed).
I was personally thinking if we could introduce 'lazy evaluation' for some special cases, then that'd help solve this problem to a good degree, but I don't have enough info on the use cases, and what sort of 'lazy evaluation' operators could be introduced. This is just a personal thought, and as far as I know there isn't anything going on in this space.
minollo (Mon, 16 Oct 2017 21:06:57 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=TgpRRfsmHS9NMGRCc) @thakkarparth007 Do you have a jira reference about this, so that I can understand more details of this issues - and understand whether I'm using the fixed code or not?
muralisr (Mon, 16 Oct 2017 21:08:13 GMT):
@thakkarparth007 `Major bottleneck was the commit phase.` ... did you try with https://gerrit.hyperledger.org/r/#/c/12849/ ?
muralisr (Mon, 16 Oct 2017 21:08:13 GMT):
@thakkarparth007 `Major bottleneck was the commit phase.` ... did you try with https://gerrit.hyperledger.org/r/#/c/12849/ ? (tagging @aso too)
thakkarparth007 (Tue, 17 Oct 2017 07:07:47 GMT):
@minollo no I don't have. I'd been working on performance aspects of fabric for a while, but haven't gotten about to documenting things properly yet.
thakkarparth007 (Tue, 17 Oct 2017 07:09:04 GMT):
@muralisr I haven't tried with that particular code yet, but I did implement basic version of parallel tx validation, and it did improve the performance. Even then I think commit is still a bottleneck.
thakkarparth007 (Tue, 17 Oct 2017 07:09:38 GMT):
I'll get back with more results and insights in a few days.
thakkarparth007 (Tue, 17 Oct 2017 07:12:22 GMT):
@minollo https://jira.hyperledger.org/browse/FAB-5880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel this is the MSP fix I was talking about.
minollo (Tue, 17 Oct 2017 12:26:08 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=4L98sd37yaDQuyTfB) @thakkarparth007 Thanks!
vdods (Tue, 17 Oct 2017 21:31:08 GMT):
Has joined the channel.
vdods (Tue, 17 Oct 2017 22:05:18 GMT):
I'm getting a very frustrating error `Verify() returned x509: certificate has expired or is not yet valid` when the peer checks the admin cert, and found this code:
```func (msp *bccspmsp) getValidityOptsForCert(cert *x509.Certificate) x509.VerifyOptions {
// First copy the opts to override the CurrentTime field
// in order to make the certificate passing the expiration test
// independently from the real local current time.
// This is a temporary workaround for FAB-3678
var tempOpts x509.VerifyOptions
tempOpts.Roots = msp.opts.Roots
tempOpts.DNSName = msp.opts.DNSName
tempOpts.Intermediates = msp.opts.Intermediates
tempOpts.KeyUsages = msp.opts.KeyUsages
tempOpts.CurrentTime = cert.NotBefore.Add(time.Second)
return tempOpts
}
``` which references this Jira ticket https://jira.hyperledger.org/browse/FAB-3678 . However, even though the cert validity options CurrentTime is being set to one second after the NotBefore time for the cert, the time check is still failing. Is anyone else having this problem?
vdods (Tue, 17 Oct 2017 22:06:33 GMT):
E.g.
```cert.Subject.CommonName = "peer0-admin"
NotBefore = time.Time{sec:63643868520, nsec:0, loc:(*time.Location)(nil)},
NotAfter = time.Time{sec:63675404520, nsec:0, loc:(*time.Location)(nil)},
opts = x509.VerifyOptions{DNSName:"", Intermediates:(*x509.CertPool)(0xc4201e7710), Roots:(*x509.CertPool)(0xc4201e7680), CurrentTime:time.Time{sec:63643868521, nsec:0, loc:(*time.Location)(nil)}, KeyUsages:[]x509.ExtKeyUsage(nil)}
```
vdods (Tue, 17 Oct 2017 22:07:26 GMT):
Noting that indeed, NotBefore < CurrentTime < NotAfter -- here, the CurrentTime is the one in the validity opts
yacovm (Tue, 17 Oct 2017 22:12:45 GMT):
@vdods this belongs to #fabric-crypto can you please move it there?
vdods (Tue, 17 Oct 2017 22:12:55 GMT):
Ok
thakkarparth007 (Wed, 18 Oct 2017 21:08:36 GMT):
If I want add a peer to multiple channels at a time, do I need to take care that the channel-join requests take place one after another?
thakkarparth007 (Wed, 18 Oct 2017 21:10:40 GMT):
Right now, I was adding a peer to 8 channels at once, and got this in peer logs:
```
eived state transfer request for channel ch5 while expecting channel ch6
skipping request...
2017-10-18 21:09:08.978 UTC [gossip/state] directMessage -> WARN 19e Rec
eived state transfer request for channel ch5 while expecting channel ch7
skipping request...
```
thakkarparth007 (Wed, 18 Oct 2017 21:10:40 GMT):
Right now, I was adding a peer to 8 channels at once, and got this in peer logs:
```
2017-10-18 21:09:08.978 UTC [gossip/state] directMessage -> WARN 19f Rec
eived state transfer request for channel ch5 while expecting channel ch6
skipping request...
2017-10-18 21:09:08.978 UTC [gossip/state] directMessage -> WARN 19e Rec
eived state transfer request for channel ch5 while expecting channel ch7
skipping request...
```
thakkarparth007 (Wed, 18 Oct 2017 21:10:40 GMT):
Right now, I was adding a peer to 8 channels at once, and got this in peer logs:
```
2017-10-18 21:09:08.978 UTC [gossip/state] directMessage -> WARN 19f Received state transfer request for channel ch5 while expecting channel ch6 skipping request...
2017-10-18 21:09:08.978 UTC [gossip/state] directMessage -> WARN 19e Received state transfer request for channel ch5 while expecting channel ch7 skipping request...
```
thakkarparth007 (Wed, 18 Oct 2017 21:12:16 GMT):
This seems to have caused a deadlock - as the peer doesn't join any other channels after joining one of the 8
thakkarparth007 (Wed, 18 Oct 2017 21:15:13 GMT):
I guess I should move this to the gossip channel.
yoheiueda (Thu, 19 Oct 2017 08:15:15 GMT):
Has joined the channel.
MeenakshiSingh (Fri, 20 Oct 2017 10:35:41 GMT):
Has joined the channel.
jyellick (Fri, 20 Oct 2017 13:56:01 GMT):
@wy Requiring that an organization is an endorser for a chaincode implies that the chaincode must be invoked by one of that org's peers as part of the transaction
[ ](https://chat.hyperledger.org/channel/fabric-orderer?msg=SovnDw2JY3nkuyD83)
wy (Fri, 20 Oct 2017 13:56:01 GMT):
Has joined the channel.
wy (Fri, 20 Oct 2017 13:56:53 GMT):
@jyellick i was referring to the previous answer given by @kostas
mogamboizer (Sat, 21 Oct 2017 15:15:12 GMT):
Has joined the channel.
steveruckdashel (Mon, 23 Oct 2017 15:07:26 GMT):
Has joined the channel.
outis (Tue, 24 Oct 2017 00:52:17 GMT):
I'm trying to run bft-smart, but stumbled at the very beginning. I did:
1. clone fabric and hyperledger-bftsmart repos
2. check out zeromq branch
3. run `ant` in hyperledger-bftsmart
4. run `./launch4Replicas.sh`,
which gave me 'Could not find or load main class bft.BFTNode'.
What else should I do before running lanuch4Replicas?
chfalak (Tue, 24 Oct 2017 04:49:57 GMT):
Has joined the channel.
chfalak (Tue, 24 Oct 2017 04:51:29 GMT):
How do we make one peer an endorser node? Do we need to set an environment variable in the container of the peer for this?
thakkarparth007 (Tue, 24 Oct 2017 05:39:12 GMT):
Just deploy chaincode to that node and submit transaction proposals to it
Menniti (Tue, 24 Oct 2017 16:20:23 GMT):
Hey guys,
Maybe someone is interested
Hyperledger Course in EdX
https://www.edx.org/course/blockchain-business-introduction-linuxfoundationx-lfs171x
vdods (Tue, 24 Oct 2017 19:01:21 GMT):
Quick question: How does the peer CLI work with respect to already-running peer nodes? E.g. I've got a peer running, then I run the CLI command (in a separate terminal) to create a channel, and now I want to run the command to join that peer to the channel. Is the `peer channel join` process talking with my already-running node? It seems to require its own core.yaml configuration file, yet it's not clear that the `peer channel join` process is really a peer.
C0rWin (Tue, 24 Oct 2017 19:17:27 GMT):
@vdods working with `peer cli` command you do not need `core.yaml` file, everything configured either with command line parameters or environmental variables
vdods (Tue, 24 Oct 2017 19:18:10 GMT):
does it use core.yaml if present?
vdods (Tue, 24 Oct 2017 19:20:47 GMT):
Perhaps a simpler clarifying question: `peer node` is pretty clearly for invoking the peer server. The other commands, such as `peer chaincode`, `peer channel` seem to be operating as a client which talks to an existing peer node (server). I'm thinking in terms of the distinction/separation between the fabric-ca tools `fabric-ca-server` and `fabric-ca-client`.
C0rWin (Tue, 24 Oct 2017 19:20:57 GMT):
`defMaxBlockDistance = 100`
vdods (Wed, 25 Oct 2017 00:03:09 GMT):
Using the same executable for server and client is confusing, especially when it comes to configuration -- which one uses which config vars
vdods (Wed, 25 Oct 2017 00:03:32 GMT):
I'd suggest using peer-server and peer-client, as fabric-ca does
vdods (Wed, 25 Oct 2017 00:14:53 GMT):
@C0rWin Is there an example of which env vars are needed to properly call `peer channel join` (among others)? I'm attempting to do so, but getting
`[main] main -> ERRO 001 Cannot run peer because cannot init crypto, missing /home/vdods/files/gopath/src/github.com/hyperledger/fabric/sampleconfig/generated-artifacts/orgs/org0/fabric-ca-clients/peer0-admin/msp folder` where it's clearly using the default "sampleconfig" path from somewhere, but I'm not sure where.
vdods (Wed, 25 Oct 2017 00:50:11 GMT):
This seems to call for setting FABRIC_CFG_PATH, but then it wants to load a config file like core.yaml, which is precisely what I'm trying to avoid
vdods (Wed, 25 Oct 2017 00:51:50 GMT):
I looked in the fabric source code, and unless you set FABRIC_CFG_PATH, it adds the development config hyperledger/fabric/sampleconfig/core.yaml, which is meant only to be used in a test/dev environment. This is really bad because it's the implicit default behavior, and to do the correct thing in a production environment (i.e. not use the dev config), one must first know about this configuration, and take an explicit step to avoid it.
vdods (Wed, 25 Oct 2017 01:04:54 GMT):
Ok, I'm getting it to work with the following hacks:
- setting FABRIC_CFG_PATH to the dir that contains the MSP of peer-admin (i.e. the account whose cert is in the peer's msp/admincerts dir)
- creating an empty core.yaml file in $FABRIC_CFG_PATH
- copying peer-admin's cert into its own admincerts dir
vdods (Wed, 25 Oct 2017 01:07:39 GMT):
I think these hacks are all due to the fact that the peer server and peer client are conflated into a single executable, and therefore the configuration and execution of each is messy and unclear. It makes sense not to require a config for non-server cli operations such as `peer channel join`, but unless a config file is specified (via setting FABRIC_CFG_PATH), it attempts to load the unsafe dev env config in sampleconfig. It also doesn't make sense for the peer admin account to be its own admin -- it's the admin of the peer, not itself. I think this is due to the MSP loading function always expecting to see msp/admincerts/xyz.pem, even if what is using the MSP has no concept of admin.
indira.kalagara (Wed, 25 Oct 2017 11:15:03 GMT):
Has joined the channel.
yoheiueda (Wed, 25 Oct 2017 11:59:12 GMT):
Can we enable pprof profiling for chaincode? I think we can enable pprof for a peer process by setting CORE_PEER_PROFILE_ENABLED. Is there a similar option for chaincode profiling?
rickr (Wed, 25 Oct 2017 15:15:56 GMT):
@wlahti @muralisr For the new feature https://jira.hyperledger.org/browse/FAB-5481
What is the _context_ that determines the what type blocks that the Peer will notify the client with? Is it the organization the peer belongs to so irregardless of what channel it is wanting block notifications it will only ever be allowed to receive Filter vs Full blocks ? Or, does the specific channel blocks that it wants notification will change what it can receive ?
wlahti (Wed, 25 Oct 2017 15:23:57 GMT):
Since you're talking about blocks/filtered blocks from the new (not yet merged) channel service, the access control policies (which I believe are on a per channel basis) determine which event types a client can receive.
wlahti (Wed, 25 Oct 2017 15:23:57 GMT):
Since you're talking about blocks/filtered blocks from the new (not yet merged, for anyone else interested) channel service, the access control policies (which I believe are on a per channel basis) determine which event types a client can receive.
rickr (Wed, 25 Oct 2017 15:27:07 GMT):
So what is the behavor if a Peer org. on channel A is allowed Full blocks and on channel B its only Filtered blocks and it tries to register for both for Full blocks ? I assume it will get rejected.
wlahti (Wed, 25 Oct 2017 15:29:27 GMT):
yes, the registration request is all or nothing. Assuming registration for only block events on both channels, the client would receive a message stating that registration failed due to not have access to block events on channel B.
rickr (Wed, 25 Oct 2017 15:30:07 GMT):
So it does identify which
wlahti (Wed, 25 Oct 2017 15:30:09 GMT):
that is where the BlockOrFilteredBlock registration type that you requested (aka BlockBest) will come in handy
rickr (Wed, 25 Oct 2017 15:31:40 GMT):
I assume it will get the most restricted block (FilterBlock) if any channel is limited to that type
rickr (Wed, 25 Oct 2017 15:31:40 GMT):
I assume it will get the most restricted block (FilterBlock) if any channel is limited to that type for BlockOrFilteredBlock
wlahti (Wed, 25 Oct 2017 15:32:17 GMT):
the response will have an entry for each registration request and whether any error occurred
wlahti (Wed, 25 Oct 2017 15:33:10 GMT):
yes, correct.
rickr (Wed, 25 Oct 2017 15:35:03 GMT):
Just to make certain we are on the same page .. back to my example if the registration was for BlockOrFilteredBlock on A and B above. The client would only see FilteredBlock for *both* channel A and B.
wlahti (Wed, 25 Oct 2017 15:36:44 GMT):
oh, no, I misread your previous statement. it will receive the maximal information available for each channel. it will receive
wlahti (Wed, 25 Oct 2017 15:36:44 GMT):
oh, no, I misread your previous statement. it will receive the maximal information available for each channel. it will receive block events for channel A and filtered blocks for channel B
rickr (Wed, 25 Oct 2017 15:37:11 GMT):
k thx
aleksandar.likic (Wed, 25 Oct 2017 15:45:37 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=vjbushWom4zYx8Hda) @vdods There is a CR at https://gerrit.hyperledger.org/r/#/c/13851/. This is a simple code split that doesn't go into configuration split (yet), but it should be a good start. It seems there is a strong desire from the community to have the peer split into client and server, but not so much among the maintainers.
aleksandar.likic (Wed, 25 Oct 2017 15:45:37 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=vjbushWom4zYx8Hda) @vdods There is a CR at https://gerrit.hyperledger.org/r/#/c/13851/. This is a simple code split that doesn't go into configuration split (yet), but it should be a good start. It seems there is a strong desire from the community to have the peer split into client and server.
vdods (Wed, 25 Oct 2017 17:33:09 GMT):
@aleksandar.likic Sweet! Thanks for the heads up
aleksandar.likic (Wed, 25 Oct 2017 18:01:21 GMT):
@vdods In order to get it accepted, you (and others interested in having it in) need to lobby with the maintainers. I am not a maintainer (cannot give it +2) and have absolutely no control over its acceptance into the code base.
aleksandar.likic (Wed, 25 Oct 2017 18:01:21 GMT):
@vdods In order to get it accepted, you (and others interested in having it in) need to lobby with the maintainers / release managers. I am not a maintainer (cannot give it +2) and have absolutely no control over its acceptance into the code base.
vdods (Wed, 25 Oct 2017 18:05:54 GMT):
@aleksandar.likic Is there any one in particular? I'm guessing Gari, but is there anyone else?
aleksandar.likic (Wed, 25 Oct 2017 18:38:22 GMT):
@vdods The proposal is at https://jira.hyperledger.org/browse/FAB-6317, it did steer some interest. It currently has one vote. I think it needs five to be considered for the next release. I posted it to fabric-pr-review, which is monitored by the maintainers, but it seems they see it a low priority.
vdods (Wed, 25 Oct 2017 18:39:31 GMT):
Hmm.. ok, well I just voted for it, and messaged Gari about it
vdods (Wed, 25 Oct 2017 18:40:21 GMT):
Because it's essentially a change in API (breaking one exe into two, in addition to whatever internal changes), it would seem that getting it into 1.1 would be a good idea, otherwise it'll have to wait for another 3 months or whatever
aleksandar.likic (Wed, 25 Oct 2017 18:40:36 GMT):
Are you a maintainer? If you are not, your vote doesn't count towards the required five votes.
vdods (Wed, 25 Oct 2017 18:40:43 GMT):
Oh.. haha.. nope!
linzheng (Thu, 26 Oct 2017 04:15:45 GMT):
Has joined the channel.
Selvam_Annamalai (Thu, 26 Oct 2017 09:10:29 GMT):
I have a org with 2 peers. When I try to install a chaincode on the 2 peers, I am getting the below error (Connection refused). Can you please tell me how to resolve this issue?
cli.a.example.com
CORE_PEER_ADDRESS=peer0.a.example.com:7051 peer chaincode install -n relationship -v 1.0 -p relationship && CORE_PEER_ADDRESS=peer1.a.example.com:7051 peer chaincode install -n relationship -v 1.0 -p relationship
2017-10-25 09:24:16.350 UTC [msp] GetLocalMSP -> DEBU 001 Returning existing local MSP
2017-10-25 09:24:16.363 UTC [msp] GetDefaultSigningIdentity -> DEBU 002 Obtaining default signing identity
2017-10-25 09:24:16.398 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 003 Using default escc
2017-10-25 09:24:16.398 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 004 Using default vscc
2017-10-25 09:24:16.668 UTC [golang-platform] getCodeFromFS -> DEBU 005 getCodeFromFS relationship
2017-10-25 09:24:17.722 UTC [golang-platform] func1 -> DEBU 006 Discarding GOROOT package fmt
2017-10-25 09:24:17.722 UTC [golang-platform] func1 -> DEBU 007 Discarding provided package github.com/hyperledger/fabric/core/chaincode/shim
2017-10-25 09:24:17.723 UTC [golang-platform] func1 -> DEBU 008 Discarding provided package github.com/hyperledger/fabric/protos/peer
2017-10-25 09:24:17.723 UTC [golang-platform] func1 -> DEBU 009 Discarding GOROOT package strconv
2017-10-25 09:24:17.723 UTC [golang-platform] GetDeploymentPayload -> DEBU 00a done
2017-10-25 09:24:17.725 UTC [msp/identity] Sign -> DEBU 00b Sign: plaintext: 0AFB060A5C08031A0C08C1B0C1CF0510...3C70FC2B0000FFFF23C7E864001C0000
2017-10-25 09:24:17.725 UTC [msp/identity] Sign -> DEBU 00c Sign: digest: 48535E5AAA200D2FF621CA28A7A90D04E1C7F13EBCE2B7502F9596613552D9BC
2017-10-25 09:24:17.732 UTC [chaincodeCmd] install -> DEBU 00d Installed remotely response:
C0rWin (Thu, 26 Oct 2017 10:53:55 GMT):
@Selvam_Annamalai `peer1.a.example.com` appears as not routable from the host where you executes the install command, hence `peer cli` not able to establish connection and eventually fails
nikit-os (Fri, 27 Oct 2017 12:29:39 GMT):
Has joined the channel.
knagware9 (Fri, 27 Oct 2017 12:57:19 GMT):
Has joined the channel.
AlekNS (Fri, 27 Oct 2017 16:16:14 GMT):
Has joined the channel.
rahulhegde (Sun, 29 Oct 2017 21:17:50 GMT):
I have a public channel with write permission to Org1 and Read permission to rest all Organizations, hence the channel configuration policy. A different chaincode installed on a channel (say channel-1) performs a channel-2-channel query access on the public channel (within the same peer node).
It is seen during channel-2-channel access, the write policy is evaluated and hence channel-2-channel query access fails. Problem Example - Org2 is authorized for write-operation on channel-1 but not on public channel. This endorsement proposal is marked as failed due to write-access check on public channel.
As far as we rememberer, there was always read-access support enabled by Hyperledger Fabric during c-2-c access operations. Is this a defect?
Note: I tried even performing writes in our public chaincode during c-2-c operation (after giving write permission on public channel to Org2) but this was never see in the public ledger.
rahulhegde (Sun, 29 Oct 2017 21:17:50 GMT):
I have a public channel with write permission to Org1 and Read permission to rest all Organizations, hence the channel configuration policy. A different chaincode installed on a channel (say channel-1) performs a channel-2-channel query access on the public channel (within the same peer node).
It is seen during channel-2-channel access, the write policy is evaluated and hence channel-2-channel query access fails. Problem Example - Org2 is authorized for write-operation on channel-1 but not on public channel. This endorsement proposal is marked as failed due to write-access check on public channel.
As far as we rememberer, there was always read-access support enabled by Hyperledger Fabric during c-2-c access operations. Is this a defect?
Note: I tried even performing writes in our public chaincode during c-2-c operation (after giving write permission on public channel to Org2) but this was never see in the public ledger.
https://jira.hyperledger.org/browse/FAB-6816
liurf (Mon, 30 Oct 2017 03:20:53 GMT):
Has joined the channel.
liurf (Mon, 30 Oct 2017 03:21:03 GMT):
hi,all,how to Member management in fabric?
meridian (Mon, 30 Oct 2017 04:35:08 GMT):
Has joined the channel.
david_dornseifer (Mon, 30 Oct 2017 22:53:44 GMT):
Has joined the channel.
kelly_ (Wed, 01 Nov 2017 00:11:29 GMT):
Hello all
kelly_ (Wed, 01 Nov 2017 00:11:50 GMT):
I have a question about when the endorsing peers update their ledger verison number
kelly_ (Wed, 01 Nov 2017 00:12:18 GMT):
Some documents suggest that version numbers should be updated according to 'block height'
kelly_ (Wed, 01 Nov 2017 00:13:30 GMT):
Another document suggests to get high throughput on fabric you should send state deltas rather than a write value, so that multiple transactions can have an impact on the same key's value within a block
kelly_ (Wed, 01 Nov 2017 00:14:22 GMT):
What I'm confused about is this: once the endorser processes the first state delta would it not update it's version number? If it didn't how are these state delta's all written rather than having each one replace the proceeding
asaningmaxchain (Wed, 01 Nov 2017 01:07:11 GMT):
@mastersingh24 can you explain how the fabric distinguish the msp is admin/member
asaningmaxchain (Wed, 01 Nov 2017 01:07:11 GMT):
?
yacovm (Wed, 01 Nov 2017 06:45:43 GMT):
@kelly_ the version is the height + the sequence in block
yacovm (Wed, 01 Nov 2017 06:46:38 GMT):
@asaningmaxchain - the MSP configuration in the local MSP or in the config block of a channel MSP contains the identities of the admins.
The MSP code simply does a comparison whether the raw identity matches one of the admin identities, that's all.
asaningmaxchain (Wed, 01 Nov 2017 06:48:56 GMT):
https://gist.github.com/asaningmaxchain/1814323b465d2d910d07ca9deab61686
asaningmaxchain (Wed, 01 Nov 2017 06:50:29 GMT):
@yacovm it means in the orderer bootstrap,it load the genesis block to config the msp, in the each msp definition which contains the ```admins``` field,
asaningmaxchain (Wed, 01 Nov 2017 06:50:42 GMT):
so the admins is the msp admin?
asaningmaxchain (Wed, 01 Nov 2017 06:50:42 GMT):
so the fields admins is the msp admin?
yacovm (Wed, 01 Nov 2017 06:52:20 GMT):
yes
asaningmaxchain (Wed, 01 Nov 2017 06:57:58 GMT):
@yacovm thx,in the fabric,each component(peer,orderer) contains the local msp,in my mind,the peer/orderer own the keystore and signcerts,it's enough,but in the ```e2e_cli```,when the peer contains so many folder
asaningmaxchain (Wed, 01 Nov 2017 06:58:22 GMT):
https://gist.github.com/asaningmaxchain/ba691bc09850929dd15bcfb751bcf86f
asaningmaxchain (Wed, 01 Nov 2017 09:07:29 GMT):
@jyellick
asaningmaxchain (Wed, 01 Nov 2017 09:07:37 GMT):
@mastersingh24
kayadhami (Wed, 01 Nov 2017 16:00:26 GMT):
Has joined the channel.
aambati (Wed, 01 Nov 2017 16:17:21 GMT):
Hi everyone, I was going to start working on the JIRA https://jira.hyperledger.org/browse/FAB-5604. This defect is a low hanging one and is a good candidate for anyone new to hyperledger, thinking about dabbling with peer code. So, I thought give a chance for someone interested in picking it up. Please assign it yourself and start working on it if you are interested. Thank you.
aambati (Wed, 01 Nov 2017 16:17:21 GMT):
Hi everyone, I was going to start working on the JIRA https://jira.hyperledger.org/browse/FAB-5604. This defect is a low hanging one and is a good candidate for anyone new to hyperledger, thinking about dabbling with peer code. So, I thought to give a chance for someone interested in picking it up. Please assign it yourself and start working on it if you are interested. Thank you.
rahulhegde (Fri, 03 Nov 2017 15:26:51 GMT):
@muralisr
1. During Chaincode Install or Peer Join Operation - is CRL list validated?
2. (if point is Yes) IIf I paste a new CRL list in the localMSP, would the Peer pick this new list or do i need to restart the Peer Node
rahulhegde (Fri, 03 Nov 2017 15:26:51 GMT):
@muralisr
1. During Chaincode Install or Peer Join Operation - is CRL list validated from LocalMSP?
2. (if point is Yes) IIf I paste a new CRL list in the localMSP, would the Peer pick this new list or do i need to restart the Peer Node
rahulhegde (Fri, 03 Nov 2017 15:26:51 GMT):
@muralisr
1. During Chaincode Install or Peer Join Operation - is CRL list validated using the LocalMSP?
2. (if point is Yes) IIf I paste a new CRL list in the localMSP, would the Peer pick this new list or do i need to restart the Peer Node
rahulhegde (Fri, 03 Nov 2017 15:26:51 GMT):
@muralisr
1. During Chaincode Install or Peer Join Operation - is CRL list validated using the LocalMSP?
2. (if point 1 is Yes) IIf I paste a new CRL list in the localMSP, would the Peer pick this new list or do i need to restart the Peer Node
rahulhegde (Fri, 03 Nov 2017 15:26:51 GMT):
@muralisr
1. During Chaincode Install or Peer Join Operation - is CRL list validated using the LocalMSP?
2. (if point 1 is Yes) IIf I paste a new CRL list in the localMSP, would the Peer pick the new CRLlist file or do i need to restart the Peer Node
rahulhegde (Fri, 03 Nov 2017 15:26:51 GMT):
@muralisr
1. During Chaincode Install or Peer Join Operation - is CRL list validated using the LocalMSP?
2. (if point 1 is Yes) IIf I paste a new CRL list in the localMSP, would the Peer pick the new CRLlist file or do i need to restart the Peer Node?
muralisr (Fri, 03 Nov 2017 15:29:53 GMT):
@rahulhegde I don;t know.. let me tag @ale @mastersingh24 @yacovm for help
muralisr (Fri, 03 Nov 2017 15:29:53 GMT):
@rahulhegde I don;t know.. let me tag @aso @mastersingh24 @yacovm for help
yacovm (Fri, 03 Nov 2017 15:30:29 GMT):
of course not
yacovm (Fri, 03 Nov 2017 15:30:34 GMT):
the local MSP is loaded at startup
yacovm (Fri, 03 Nov 2017 15:30:41 GMT):
there are plans to be able to update it
yacovm (Fri, 03 Nov 2017 15:31:04 GMT):
the local MSP also can't validate a CRL of a different organization
yacovm (Fri, 03 Nov 2017 15:31:06 GMT):
how can it do that?
yacovm (Fri, 03 Nov 2017 15:31:13 GMT):
it doesn't have a common issuer...
rahulhegde (Fri, 03 Nov 2017 15:38:22 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=rDrQnJHybEvEhdKWQ) @yacovm
So if the CRL is present in the local MSP - this would be used during certificate validation process during Install and Join operation - is my understanding correct?
rahulhegde (Fri, 03 Nov 2017 15:38:22 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=rDrQnJHybEvEhdKWQ) @yacovm
So if the CRL is present in the local MSP during Peer Boot-up, it would be used during certificate validation process during Install and Join operation - is my understanding correct?
yacovm (Fri, 03 Nov 2017 15:38:58 GMT):
yes
yacovm (Fri, 03 Nov 2017 15:39:06 GMT):
because these are local MSP type operations
rahulhegde (Fri, 03 Nov 2017 15:40:17 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=rnRHhJsuRYCMegiF6) @yacovm
Is this going to be available in 1.0.X release, do we a JIRA for my tracking purpose.
yacovm (Fri, 03 Nov 2017 15:41:17 GMT):
No idea. @mastersingh24 , @adc hold the answers for that
yacovm (Fri, 03 Nov 2017 15:41:45 GMT):
the JIRA is FAB-6254
rahulhegde (Fri, 03 Nov 2017 15:50:02 GMT):
Is there a JIRA, to ask support for Peer CLI to send endorsing proposal request to multiple endorsers? (i could not find and can open one for it)
muralisr (Fri, 03 Nov 2017 16:15:51 GMT):
@rahulhegde ^^^ is on my radar but not sure if there's a JIRA
muralisr (Fri, 03 Nov 2017 16:16:40 GMT):
perhaps just open one and assign it to me... make sure its not a "bug" but an "enhancement"
aso (Fri, 03 Nov 2017 18:16:58 GMT):
second +2 pls on a one-file change... https://gerrit.hyperledger.org/r/#/c/14537/
agiledeveloper (Fri, 03 Nov 2017 19:31:06 GMT):
Has joined the channel.
srongzhe (Sat, 04 Nov 2017 13:24:27 GMT):
Has joined the channel.
snehas (Sun, 05 Nov 2017 10:35:13 GMT):
Has joined the channel.
snehas (Sun, 05 Nov 2017 10:56:13 GMT):
Hi All,
I am not able to instantiate chaincode if TLS is enabled. Below are the chaincode container logs and client logs.
Chaincode container logs:-
2017-11-03 11:14:20.437 UTC [bccsp] initBCCSP -> DEBU 001 Initialize BCCSP [SW]
2017-11-03 11:14:20.439 UTC [shim] userChaincodeStreamGetter -> ERRO 002 Error trying to connect to local peer: x509: cannot validate certificate for 172.27.0.18 because it doesn't contain any IP SANs
2017-11-03 11:14:20.439 UTC [Public/PublicCC] Errorf -> ERRO 003 Error starting chaincode: Error trying to connect to local peer: x509: cannot validate certificate for 172.27.0.18 because it doesn't contain any IP SANs
Client logs:-
2017-11-03 17:37:17.832 UTC [msp/identity] Sign -> DEBU 006 Sign: digest: 58AE6C653B084389522FAEFEE59A62B01AC4B00297D078D1E96D774DF0BC595D
Error: Error endorsing chaincode: rpc error: code = Unknown desc = Timeout expired while starting chaincode public:1.0.0(networkid:dev,peerid:peer01,tx:6a85d46aaef47be9e18cfb65341c15842abe926d3900f681f44123b6402d24bc)
Usage:
peer chaincode instantiate [flags]
Please provide some pointers.
yacovm (Sun, 05 Nov 2017 10:57:45 GMT):
@snehas the problem is that your configuration of the peer's address if an ip address
yacovm (Sun, 05 Nov 2017 10:57:47 GMT):
and not a host name
yacovm (Sun, 05 Nov 2017 10:58:01 GMT):
if you make the peer's address in the core.yaml or in the environment variables (in case of docker) to be its hostname
yacovm (Sun, 05 Nov 2017 10:58:09 GMT):
and if the hostname would match the certificate's SAN
yacovm (Sun, 05 Nov 2017 10:58:11 GMT):
it then would work
terryfernz (Mon, 06 Nov 2017 07:20:17 GMT):
Has joined the channel.
rahulhegde (Mon, 06 Nov 2017 13:07:14 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=yFuaN9DnREJHsrG9g) @muralisr
https://jira.hyperledger.org/browse/FAB-6894
tim_zeng (Tue, 07 Nov 2017 02:35:38 GMT):
Has joined the channel.
asaningmaxchain (Tue, 07 Nov 2017 09:39:47 GMT):
@yacovm @mastersingh24 can you explain the the master branch source code the `protos/msp/msp_principal.proto` add the `CLIENT = 2; // Represents an MSP Client
PEER = 3; // Represents an MSP Peer
ORDERER = 4; // Represents an MSP Orderer` i don't understand can you provide more detail?
asaningmaxchain (Tue, 07 Nov 2017 09:39:47 GMT):
@yacovm @mastersingh24 can you explain the the master branch source code the `protos/msp/msp_principal.proto` add the `CLIENT = 2; // Represents an MSP Client
PEER = 3; // Represents an MSP Peer
ORDERER = 4; // Represents an MSP Orderer` i don't understand can you provide more detail?
asaningmaxchain (Tue, 07 Nov 2017 09:39:47 GMT):
@yacovm @mastersingh24 can you explain the the master branch source code the `protos/msp/msp_principal.proto` add the ```CLIENT = 2; // Represents an MSP Client
PEER = 3; // Represents an MSP Peer
ORDERER = 4; // Represents an MSP Orderer``` i don't understand can you provide more detail?
asaningmaxchain (Tue, 07 Nov 2017 09:39:47 GMT):
@yacovm @mastersingh24 i see the the master branch source code the `protos/msp/msp_principal.proto` add the ```CLIENT = 2; // Represents an MSP Client
PEER = 3; // Represents an MSP Peer
ORDERER = 4; // Represents an MSP Orderer``` i don't understand can you provide more detail?
yacovm (Tue, 07 Nov 2017 09:46:13 GMT):
Yeah
yacovm (Tue, 07 Nov 2017 09:46:51 GMT):
So now an identity can beclassified by whether it is a peer, orserer or client
asaningmaxchain (Tue, 07 Nov 2017 11:07:29 GMT):
it means the identity should meet the peerMSP/ordererMSP?
mastersingh24 (Tue, 07 Nov 2017 11:34:07 GMT):
@asaningmaxchain - there are basically two parts to this:
1) Policies can now be written which can use Org.CLIENT, Org.PEER, Org.ORDERER in addition to the Org.ADMIN and Org.MEMBER supported in v1.0.x
2) Within your MSP, you need to define how to identity a CLIENT,PEER or ORDERER. This can be done by using the NodeOUs section in the MSP config: https://github.com/hyperledger/fabric/blob/master/sampleconfig/msp/config.yaml#L10
mastersingh24 (Tue, 07 Nov 2017 11:34:07 GMT):
@asaningmaxchain - there are basically two parts to this:
1) Policies can now be written which can use Org.CLIENT, Org.PEER, Org.ORDERER in addition to the Org.ADMIN and Org.MEMBER supported in v1.0.x
2) Within your MSP, you need to define how to identity a CLIENT,PEER or ORDERER. This can be done by using the NodeOUs section in the MSP config: https://github.com/hyperledger/fabric/blob/master/sampleconfig/msp/config.yaml#L10. This works by specifying how to map an OU to each of the roles
snehas (Tue, 07 Nov 2017 13:03:02 GMT):
@yacovm
I corrected the the configuration to match peer's host name and certificate SAN. But still not able to instantiate chaincode with TLS enabled.
Below are the logs:-
Chaincode container logs
2017-11-07 17:24:31.581 UTC [bccsp] initBCCSP -> DEBU 001 Initialize BCCSP [SW]
2017-11-07 17:24:34.582 UTC [shim] userChaincodeStreamGetter -> ERRO 002 Error trying to connect to local peer: context deadline exceeded
2017-11-07 17:24:34.582 UTC [Public/PublicCC] Errorf -> ERRO 003 Error starting chaincode: Error trying to connect to local peer: context deadline exceeded
Client logs
2017-11-07 17:24:10.442 UTC [msp] GetLocalMSP -> DEBU 001 Returning existing local MSP
2017-11-07 17:24:10.442 UTC [msp] GetDefaultSigningIdentity -> DEBU 002 Obtaining default signing identity
2017-11-07 17:24:10.446 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 003 Using default escc
2017-11-07 17:24:10.446 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 004 Using default vscc
2017-11-07 17:24:10.447 UTC [msp/identity] Sign -> DEBU 005 Sign: plaintext: 0ADC050A6408031A0C08BAD887D00510...36300A000A04657363630A0476736363
2017-11-07 17:24:10.447 UTC [msp/identity] Sign -> DEBU 006 Sign: digest: 4377270AC917AD0B2CB076E664DCA4702CA3684129970E6FEC057AD0F09814EC
Error: Error endorsing chaincode: rpc error: code = Unknown desc = Timeout expired while starting chaincode public:1.0.0(networkid:dev,peerid:peer01.bgb65.cit.net,tx:e8329efce41d68677f017be1fb1d63115210cf6213c90df9b4d3ef74cbbfa089)
Usage:
peer chaincode instantiate [flags]
Peer container logs
2017-11-07 17:29:31.568 UTC [dockercontroller] stopInternal -> DEBU 797 Removed container dev-peer01.bgb65.cit.net-public-1.0.0
2017-11-07 17:29:31.568 UTC [container] unlockContainer -> DEBU 798 container lock deleted(dev-peer01.bgb65.cit.net-public-1.0.0)
2017-11-07 17:29:31.568 UTC [chaincode] Launch -> ERRO 799 launchAndWaitForRegister failed Timeout expired while starting chaincode public:1.0.0(networkid:dev,peerid:peer01.gb65.cit.net,tx:e8329efce41d68677f017be1fb1d63115210cf6213c90df9b4d3ef74cbbfa089)
2017-11-07 17:29:31.568 UTC [endorser] callChaincode -> DEBU 79a Exit
2017-11-07 17:29:31.568 UTC [endorser] simulateProposal -> ERRO 79b failed to invoke chaincode name:"lscc" on transaction e8329efce41d68677f017be1fb1d63115210cf6213c90df9b4d3ef74cbbfa089, error: Timeout expired while starting chaincode public:1.0.0(networkid:dev,peerid:peer01.gb65.cit.net,tx:e8329efce41d68677f017be1fb1d63115210cf6213c90df9b4d3ef74cbbfa089)
Orderer Logs
2017-11-07 17:23:13.721 UTC [cauthdsl] func2 -> DEBU cc7 0xc420126208 principal evaluation succeeds for identity 0
2017-11-07 17:23:13.721 UTC [cauthdsl] func1 -> DEBU cc8 0xc420126208 gate 1510075393719458339 evaluation succeeds
2017-11-07 17:23:13.721 UTC [orderer/common/sigfilter] Apply -> DEBU cc9 Forwarding validly signed message for policy &{%!s(*common.ImplicitMetaPolicy=&{Readers 0}) %!s(int=1) [%!s(*policies.implicitMetaPolicy=&{0xc420b95f40 1 [0xc42087aca8]}) %!s(*policies.implicitMetaPolicy=&{0xc420b34760 1 [0xc42087ad50 0xc42087adc0 0xc42087ae58 0xc42087aef0]})]}
2017-11-07 17:23:13.721 UTC [orderer/common/deliver] Handle -> DEBU cca [channel: public] Received seekInfo (0xc420abcf40) start:
lmars (Tue, 07 Nov 2017 14:24:59 GMT):
Has joined the channel.
yacovm (Tue, 07 Nov 2017 14:52:35 GMT):
@snehas you need to remove the chaincode images
yacovm (Tue, 07 Nov 2017 14:52:42 GMT):
and then re-instantiate/invoke
yacovm (Tue, 07 Nov 2017 14:52:52 GMT):
so that the chaincode container will be re-created
jmcnevin (Tue, 07 Nov 2017 15:54:04 GMT):
Has joined the channel.
jmcnevin (Tue, 07 Nov 2017 18:21:12 GMT):
would anyone have any thoughts on what might be going wrong here? I've enabled TLS on my peers, but now I get this when trying to install chaincode: `[shim] userChaincodeStreamGetter -> ERRO 002 Error trying to connect to local peer: x509: certificate signed by unknown authority`
yacovm (Tue, 07 Nov 2017 19:11:32 GMT):
Remove the chaincode image @jmcnevin and try again
yacovm (Tue, 07 Nov 2017 19:11:45 GMT):
Sigh... We really need some FAQ
yacovm (Tue, 07 Nov 2017 19:12:30 GMT):
@nickgaski @dave.enyeart is there any troubleshooting section in the docs?
jmcnevin (Tue, 07 Nov 2017 19:18:20 GMT):
hmm, what exactly is the underlying issue here? Is the ca cert from the peer not making it into the chaincode container, or is this a stale chaincode container with some other ca baked in?
nickgaski (Tue, 07 Nov 2017 19:33:07 GMT):
hey yacov. we have some sample-specific FAQs and troubleshooting (e.g. bottom of the BYFN doc). However, the consensus has been to simply post questions/answers on Stack Overflow
steveruckdashel (Tue, 07 Nov 2017 20:04:54 GMT):
Is there anything in the works for managing chaincode images? Is running `docker rm...` really the recommendation? It seams like I'm missing something.
snehas (Wed, 08 Nov 2017 09:42:36 GMT):
@yacovm : Removed the chaincode image, However now am getting Error trying to connect to local peer: x509: cannot validate certificate for 172.25.0.20 because it doesn't contain any IP SANs on instantiating chaincode with TLS enabled.
Attaching logs with peer TLS certificate:
@YashGanthe @rahulhegde
YashGanthe (Wed, 08 Nov 2017 09:42:36 GMT):
Has joined the channel.
snehas (Wed, 08 Nov 2017 09:43:14 GMT):
TLS_Error_Logs.txt
yacovm (Wed, 08 Nov 2017 09:43:22 GMT):
No no dont attach logs
yacovm (Wed, 08 Nov 2017 09:43:32 GMT):
No need
yacovm (Wed, 08 Nov 2017 09:43:54 GMT):
So, you can simply use hostnames
yacovm (Wed, 08 Nov 2017 09:44:00 GMT):
Instead of ip addresses
yacovm (Wed, 08 Nov 2017 09:44:14 GMT):
In the docker environment variables
yacovm (Wed, 08 Nov 2017 09:44:27 GMT):
Or if you dont use docker then in core.yaml
snehas (Wed, 08 Nov 2017 09:44:32 GMT):
yes am using hostname instead of IP Address
yacovm (Wed, 08 Nov 2017 09:44:53 GMT):
What's your core-peer-address?
yacovm (Wed, 08 Nov 2017 09:45:20 GMT):
And core-chaincode-listenaddress
snehas (Wed, 08 Nov 2017 09:45:35 GMT):
CORE_PEER_ADDRESS=peer01.lsbgb65.cit.lsnet:7051
yacovm (Wed, 08 Nov 2017 09:49:25 GMT):
And the other env vars?
yacovm (Wed, 08 Nov 2017 09:49:37 GMT):
Do you have any ip address there?
snehas (Wed, 08 Nov 2017 10:16:59 GMT):
I am not using core-chaincode-listenaddress var
snehas (Wed, 08 Nov 2017 10:18:49 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=rWXcT32K27zxvjnaY) @yacovm
I am not using core-chaincode-listenaddress and also IP address is not used.
yacovm (Wed, 08 Nov 2017 10:31:00 GMT):
This is odd
yacovm (Wed, 08 Nov 2017 10:31:21 GMT):
Open a jira with attached docker compose file
yacovm (Wed, 08 Nov 2017 10:31:39 GMT):
@mastersingh24 @muralisr ^
muralisr (Wed, 08 Nov 2017 13:11:54 GMT):
@snehas best to open a JIRA so we can have all the details collected in one place (including the code level, master or release level) please
a.hyper (Wed, 08 Nov 2017 13:36:01 GMT):
Has joined the channel.
a.hyper (Wed, 08 Nov 2017 13:38:19 GMT):
Hi All - I have a 4 docker container setup running (ordered, CA, peer and couchDB) on 1 server. Everything works great and I opened up all the ports within my LAN. I am trying to connected a second peer to this network. I'm assuming I need to 2 containers to do this (peer and couchdb). Does anyone have instructions on how to do this? I've tried a million things with no success.
bretharrison (Wed, 08 Nov 2017 14:44:34 GMT):
Has left the channel.
swapnilpatil (Wed, 08 Nov 2017 16:07:49 GMT):
Has joined the channel.
rickr (Wed, 08 Nov 2017 16:22:29 GMT):
Anyone know or provide a link to that would show how to configure a peer docker-compose (https://github.com/hyperledger/fabric-sdk-java/blob/0b3e5aaa7b7f9440921f75f488da34b67f6dd606/src/test/fixture/sdkintegration/peer-base/peer-base.yaml#L1) instance so that for grpc it would handle a larger message ?
Something that is equalivant to what is done on the java client side here :
https://github.com/hyperledger/fabric-sdk-java/blob/0b3e5aaa7b7f9440921f75f488da34b67f6dd606/src/test/java/org/hyperledger/fabric/sdkintegration/End2endIT.java#L684
jeffgarratt (Wed, 08 Nov 2017 19:34:57 GMT):
@rickr is it not defaulted to 100MB?
rickr (Wed, 08 Nov 2017 20:02:36 GMT):
I don't know anything on the server side .. I didn't think it was that high which is way too much IMO . I know how to handle it on the client side but I want to know how to configure it on the server side .. We really need to know how to do that
rickr (Wed, 08 Nov 2017 20:03:04 GMT):
@mastersingh24 ^^ ?
asaningmaxchain (Thu, 09 Nov 2017 01:20:08 GMT):
@rickr @jeffgarratt i think the problem is the chaincode server
asaningmaxchain (Thu, 09 Nov 2017 01:20:08 GMT):
@rickr @jeffgarratt i think the problem is the chaincode server,the peer received the sdk request and then the peer to invoke the chaincode server to get the data,i think we should set the config for the chaincode grpc server/client
asaningmaxchain (Thu, 09 Nov 2017 01:40:16 GMT):
@rickr @jeffgarratt @mastersingh24 i see the core/comm the server.go and connection.go it indeed set the ```opts = append(opts, grpc.WithDefaultCallOptions(grpc.MaxCallRecvMsgSize(MaxRecvMsgSize()),
grpc.MaxCallSendMsgSize(MaxSendMsgSize())))```
asaningmaxchain (Thu, 09 Nov 2017 01:40:16 GMT):
@rickr @jeffgarratt @mastersingh24 i see the core/comm the connection.go it indeed set the ```opts = append(opts, grpc.WithDefaultCallOptions(grpc.MaxCallRecvMsgSize(MaxRecvMsgSize()),
grpc.MaxCallSendMsgSize(MaxSendMsgSize())))``` and sever.go ``` serverOpts = append(serverOpts, grpc.MaxSendMsgSize(MaxSendMsgSize()))
serverOpts = append(serverOpts, grpc.MaxRecvMsgSize(MaxRecvMsgSize()))```
asaningmaxchain (Thu, 09 Nov 2017 01:40:16 GMT):
@rickr @jeffgarratt @mastersingh24 i see the core/comm the connection.go it indeed set the ```opts = append(opts, grpc.WithDefaultCallOptions(grpc.MaxCallRecvMsgSize(MaxRecvMsgSize()),
grpc.MaxCallSendMsgSize(MaxSendMsgSize())))``` and sever.go ```serverOpts = append(serverOpts, grpc.MaxSendMsgSize(MaxSendMsgSize()))
serverOpts = append(serverOpts, grpc.MaxRecvMsgSize(MaxRecvMsgSize()))```
asaningmaxchain (Thu, 09 Nov 2017 01:43:25 GMT):
https://github.com/hyperledger/fabric/blob/a454d61767b27f57019711b8ab62a0ad344590cd/core/comm/connection.go#L217
asaningmaxchain (Thu, 09 Nov 2017 01:43:49 GMT):
https://github.com/hyperledger/fabric/blob/a454d61767b27f57019711b8ab62a0ad344590cd/core/comm/server.go#L192
asaningmaxchain (Thu, 09 Nov 2017 02:01:48 GMT):
@jyellick
rickr (Thu, 09 Nov 2017 02:49:24 GMT):
Java grpc by default has no limit on what it can send. Not usually an issue since its the receiving end that needs to protect itself from a DOS from the sender.
rickr (Thu, 09 Nov 2017 02:49:24 GMT):
Java grpc client by *default* has no limit on what it can send. Not usually an issue since its the receiving end that needs to protect itself from a DOS from the sender.
NakaoK (Thu, 09 Nov 2017 05:48:48 GMT):
Has joined the channel.
snehas (Thu, 09 Nov 2017 05:59:23 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=8LrBRTupgAuaSgRge) @yacovm
@yacovm @muralisr @YashGanthe @rahulhegde
https://jira.hyperledger.org/browse/FAB-6937
snehas (Thu, 09 Nov 2017 05:59:23 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=8LrBRTupgAuaSgRge)
@yacovm @muralisr @YashGanthe @rahulhegde
https://jira.hyperledger.org/browse/FAB-6937
yoheiueda (Thu, 09 Nov 2017 08:44:27 GMT):
I read https://jira.hyperledger.org/secure/attachment/10048/gossipArch.md and noticed that the following statement. >>>If a peer's ledger falls behind too much from the rest of its peers, it doesn't use the state transfer mechanism described in this document, but rather falls back to a different specific mechanism of state transfer which will be added in the future.
yoheiueda (Thu, 09 Nov 2017 08:44:27 GMT):
I read https://jira.hyperledger.org/secure/attachment/10048/gossipArch.md and noticed that the following statement. >>> If a peer's ledger falls behind too much from the rest of its peers, it doesn't use the state transfer mechanism described in this document, but rather falls back to a different specific mechanism of state transfer which will be added in the future.
yoheiueda (Thu, 09 Nov 2017 08:44:27 GMT):
I read https://jira.hyperledger.org/secure/attachment/10048/gossipArch.md and noticed that the following statement. > If a peer's ledger falls behind too much from the rest of its peers, it doesn't use the state transfer mechanism described in this document, but rather falls back to a different specific mechanism of state transfer which will be added in the future.
yoheiueda (Thu, 09 Nov 2017 08:44:27 GMT):
I read https://jira.hyperledger.org/secure/attachment/10048/gossipArch.md and noticed that the following statement.
yoheiueda (Thu, 09 Nov 2017 08:45:04 GMT):
> If a peer's ledger falls behind too much from the rest of its peers, it doesn't use the state transfer mechanism described in this document, but rather falls back to a different specific mechanism of state transfer which will be added in the future.
yoheiueda (Thu, 09 Nov 2017 08:45:52 GMT):
Is there any plan to implement the "different specific mechanism". If so, is there a related JIRA item?
C0rWin (Thu, 09 Nov 2017 09:07:08 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=53aMPXPPwFGXRkNqy) @yoheiueda by skimming quickly over the posted document it seems to me a bit outdated, there are three key components of the gossip presented right now:
1. Push or forwarding - whenever peer receives a new block it pick k peers at random and pushes block to them
2. Pulling - once in a while peer exchanges a digest of the blocks it has with neighbors peers and in case it misses something it will request it
3. State transfer - covers basically cases of the newly joined peer or peer healed from the network partitioning, it tries to find a peer with most up to date ledger to sync with it. (there is periodically distributed messages with metadata of current progress for each peer in membership)
if you would like to continue the discussion about gossip protocol and more details, #fabric-gossip channel is more appropriate place of doing so and you are welcome to move current thread there
yoheiueda (Thu, 09 Nov 2017 09:33:49 GMT):
thank you very much!
UtkarshSingh (Thu, 09 Nov 2017 09:38:43 GMT):
Has joined the channel.
shiyj93 (Thu, 09 Nov 2017 12:12:02 GMT):
Has joined the channel.
UtkarshSingh (Thu, 09 Nov 2017 12:35:57 GMT):
How can I add a new peer(of some Organization) in the channel ?
I have tried this :
1). spin up the 2-orgs setup (./byfn.sh -m up)
2). using cryptogen tool, made peer2.org1.example.com in a separate folder(say, crypto1)
3). Replaced some certs from the MSP of peer2.org1.example.com
admincerts, cacerts, tlscacerts folder are replaced with the Org1(of actual one)'s MSP
In tls folder, I have replaced the ca.crt with the Actual Org1's ca.crt
4). run that peer in the docker container
5). fetched the mychannel.block form the orderer
6). tried to join the channel, but getting error :
UtkarshSingh (Thu, 09 Nov 2017 12:37:28 GMT):
2017-11-09 12:37:53.577 UTC [msp] GetLocalMSP -> DEBU 001 Returning existing local MSP
2017-11-09 12:37:53.577 UTC [msp] GetDefaultSigningIdentity -> DEBU 002 Obtaining default signing identity
Error: Error getting endorser client channel: PER:404 - Error trying to connect to local peer
/opt/gopath/src/github.com/hyperledger/fabric/peer/common/common.go:116 github.com/hyperledger/fabric/peer/common.GetEndorserClient
/opt/gopath/src/github.com/hyperledger/fabric/peer/channel/channel.go:149 github.com/hyperledger/fabric/peer/channel.InitCmdFactory
/opt/gopath/src/github.com/hyperledger/fabric/peer/channel/join.go:138 github.com/hyperledger/fabric/peer/channel.join
/opt/gopath/src/github.com/hyperledger/fabric/peer/channel/join.go:42 github.com/hyperledger/fabric/peer/channel.joinCmd.func1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:599 github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).execute
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:689 github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).ExecuteC
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:648 github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).Execute
/opt/gopath/src/github.com/hyperledger/fabric/peer/main.go:118 main.main
/opt/go/src/runtime/proc.go:192 runtime.main
/opt/go/src/runtime/asm_amd64.s:2087 runtime.goexit
Caused by: x509: certificate signed by unknown authority (possibly because of "x509: ECDSA verification failure" while trying to verify candidate authority certificate "tlsca.org1.example.com")
UtkarshSingh (Thu, 09 Nov 2017 12:39:36 GMT):
I know, that, keystore-signcerts (pub/pri key-pair) is unique
And, server.crt & server.key are also unique , for each peer
But, couldn't find what's wrong am I doing here
Vadim (Thu, 09 Nov 2017 12:45:33 GMT):
@UtkarshSingh when you use cryptogen, it generates different root certs for each run
Vadim (Thu, 09 Nov 2017 12:46:06 GMT):
so all the crypto artifacts you generated for peer2 is not compatible with the rest of the network
UtkarshSingh (Thu, 09 Nov 2017 12:47:11 GMT):
Yes, I know,
That is why, I am copying MSP of the Org1(actual one) to the MSP of new peer2.org1.example.com
Vadim (Thu, 09 Nov 2017 12:47:50 GMT):
2). using cryptogen tool, made peer2.org1.example.com in a separate folder(say, crypto1) <- and what is this for?
UtkarshSingh (Thu, 09 Nov 2017 12:48:54 GMT):
I have two folders:
1). crypto-config ---> Actual Org1 is present
2). crypto1 -> in which I will generate one more Org1(not the actual one used in the channel), this is having peer2.org1.example.com
Vadim (Thu, 09 Nov 2017 12:49:34 GMT):
you realise that Org1 from crypto-config and Org1 from crypto1 is not the same, right?
Vadim (Thu, 09 Nov 2017 12:49:55 GMT):
they have different root of trust
Vadim (Thu, 09 Nov 2017 12:50:26 GMT):
so peer's TLS certs will not be trusted from the main network, that what the error you get tells you
UtkarshSingh (Thu, 09 Nov 2017 12:51:47 GMT):
Then I am these things with peer2.org1.example.com :
1). copying MSP of ORG1(actual one) to MSP of peer2.org1.example.com(keeping keystore n signcerts)
2). copying tls folder too(not replacing server.crt & server.key)
3). Now, putting peer2.org1.example.com from Org1(not the actual one) to the Org1(actual one)
UtkarshSingh (Thu, 09 Nov 2017 12:52:13 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=uZa2M2GETGT9PZQXH) @Vadim I am also copying tls certs
Vadim (Thu, 09 Nov 2017 12:53:02 GMT):
@UtkarshSingh the signcert and server.crt are signed by a different CA
Vadim (Thu, 09 Nov 2017 12:53:39 GMT):
copying ca certs won't change this
UtkarshSingh (Thu, 09 Nov 2017 12:55:20 GMT):
inside any peer I have two Folders-> 1. msp ; 2. tls
What's the use of tls folder ? How, ca.crt , server.crt & server.key are related ?
How "tls" folder is different from "msp->tlscacerts" folder ?
Vadim (Thu, 09 Nov 2017 12:55:57 GMT):
TLS is for encrypting connections, ca.crt is the cert of the CA which signed the server.crt
Vadim (Thu, 09 Nov 2017 12:56:32 GMT):
msp is for identifying peers and orderers within the fabric network
Vadim (Thu, 09 Nov 2017 12:58:03 GMT):
what I would do to test dynamic peer adding is that I'd generated certs for 3 peers, then used the first two peers to start the network as usual and then used the remaining certs for peer3 to join it to the network when it's already running
UtkarshSingh (Thu, 09 Nov 2017 13:12:34 GMT):
That won't be dynamic, as there could be much more peers that want to join that channel
UtkarshSingh (Thu, 09 Nov 2017 13:12:45 GMT):
Does fabric-ca solve this ??
UtkarshSingh (Thu, 09 Nov 2017 13:18:09 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=vR2zn4vBaXJ6dWsku) @Vadim server.crt will be used for encrypting the msgs, right ? Then, server.key will be the key signed with the ca.crt ??
These two will be responsible for the end-to-end encryption ? Then, what's the role of Keystore-signcerts(I think, it is the pub/priv key-pair of the peer) ?
Vadim (Thu, 09 Nov 2017 13:19:02 GMT):
@UtkarshSingh server.crt is the certificate (pub key) which is signed by ca.crt, server.key is the private key
UtkarshSingh (Thu, 09 Nov 2017 13:22:32 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=v9kiw2qvGfLgK2uBe) Tell me about keystore-signcerts' role.
server.crt - server.key will be responsible for the end-to-end communication's encryption, right ??
Vadim (Thu, 09 Nov 2017 13:25:45 GMT):
this is for identities, read http://hyperledger-fabric.readthedocs.io/en/latest/msp.html
UtkarshSingh (Thu, 09 Nov 2017 13:47:53 GMT):
and, server.crt - server.key will be responsible for the end-to-end communication's encryption, right ??
Vadim (Thu, 09 Nov 2017 13:48:49 GMT):
@UtkarshSingh yes
UtkarshSingh (Thu, 09 Nov 2017 14:00:29 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=3SmEEBAJSPj8Z3jhS) @Vadim Is signcerts(pub key) signed by CA => server.crt
keystore(private key) signed by CA => server.key ?
Vadim (Thu, 09 Nov 2017 14:01:30 GMT):
private key is not signed, it's a counterpart of a public key (which gets signed)
Vadim (Thu, 09 Nov 2017 14:01:52 GMT):
there is no sense to sign the private key as nobody sees it except its owner
Vadim (Thu, 09 Nov 2017 14:03:28 GMT):
@UtkarshSingh maybe read about PKI to get a better understanding: https://en.wikipedia.org/wiki/Public-key_cryptography
UtkarshSingh (Thu, 09 Nov 2017 14:07:25 GMT):
I know that concept. But, I wonder, then what's the use keystore-signcerts(pub/pri key-pair) ? They should be meant for some cryptographic stuffs..not just for the identities
Vadim (Thu, 09 Nov 2017 14:10:48 GMT):
it's used for signing the messages that peers/orderers/clients exchange
swetha (Fri, 10 Nov 2017 03:28:35 GMT):
Has joined the channel.
yoheiueda (Fri, 10 Nov 2017 08:07:18 GMT):
Hi. I have a question about `core.chaincode.serialSend` in https://github.com/hyperledger/fabric/blob/v1.1.0-preview/core/chaincode/handler.go#L137-L148
yoheiueda (Fri, 10 Nov 2017 08:07:29 GMT):
> //serialSend serializes msgs so gRPC will be happy
yoheiueda (Fri, 10 Nov 2017 08:08:49 GMT):
Why do we need to lock to use gRPC here? Does concurrent use of gRPC here cause some issue?
inatatsu (Fri, 10 Nov 2017 08:48:33 GMT):
Has joined the channel.
yacovm (Fri, 10 Nov 2017 11:22:52 GMT):
gRPC is not thread safe
yoheiueda (Fri, 10 Nov 2017 13:45:39 GMT):
Oh, I see. Thank you very much.
myin2000 (Mon, 13 Nov 2017 20:26:23 GMT):
Has joined the channel.
rajasekharpippalla (Tue, 14 Nov 2017 05:58:30 GMT):
Has joined the channel.
asaningmaxchain (Wed, 15 Nov 2017 07:21:47 GMT):
@manish-sethi @dave.enyeart @C0rWin @jyellick https://gist.github.com/asaningmaxchain/60dcbce2269e13baa35d91a25879098e can you take a look? when i want to test the stability about the peer
C0rWin (Wed, 15 Nov 2017 07:23:48 GMT):
@asaningmaxchain do you have logs from couchdb container?
asaningmaxchain (Wed, 15 Nov 2017 07:25:06 GMT):
https://gist.github.com/asaningmaxchain/8d489998e3a73accf5003f2547fc429e
guoger (Wed, 15 Nov 2017 07:49:28 GMT):
@asaningmaxchain how to reproduce?
asaningmaxchain (Wed, 15 Nov 2017 07:50:18 GMT):
you can send the tx to the peer by multi-thread way
guoger (Wed, 15 Nov 2017 07:57:36 GMT):
what's in erl_crash.dump?
> Crash dump is being written to: erl_crash.dump...done
guoger (Wed, 15 Nov 2017 07:57:36 GMT):
@asaningmaxchain what's in erl_crash.dump?
> Crash dump is being written to: erl_crash.dump...done
asaningmaxchain (Wed, 15 Nov 2017 07:59:16 GMT):
the couchdb container exits
guoger (Wed, 15 Nov 2017 08:00:07 GMT):
but I suppose it's not deleted?
asaningmaxchain (Wed, 15 Nov 2017 08:05:29 GMT):
yes
guoger (Wed, 15 Nov 2017 08:25:33 GMT):
then you could still access it and inspect dump file?
asaningmaxchain (Wed, 15 Nov 2017 08:33:09 GMT):
no,i can't attach it
dave.enyeart (Wed, 15 Nov 2017 11:59:37 GMT):
@asaningmaxchain Please don't spam the same question to multiple channels.
ArnabChatterjee (Thu, 16 Nov 2017 02:37:01 GMT):
Has joined the channel.
ArnabChatterjee (Thu, 16 Nov 2017 02:37:07 GMT):
Can you help me out with some Endorsement policy issues? Actually I am using hyperledger explorer and I dont see my endorsement signatures in the transaction payload? I see only one (one who invoked the transaction)
ArnabChatterjee (Thu, 16 Nov 2017 02:37:39 GMT):
@dave.enyeart any ideas?
ArnabChatterjee (Thu, 16 Nov 2017 02:37:42 GMT):
Thanks
dave.enyeart (Thu, 16 Nov 2017 02:38:49 GMT):
You are probably not looking in the correct place... as the invoker would be in a header rather than in an endorser section
dave.enyeart (Thu, 16 Nov 2017 02:39:12 GMT):
I'm not familiar with how explorer presents things however
ArnabChatterjee (Thu, 16 Nov 2017 02:52:43 GMT):
@dave.enyeart thanks. Would I see the transaction endorsers in the header? (FYI I am looking at the transaction json when I query the transaction by Id)
dave.enyeart (Thu, 16 Nov 2017 02:56:25 GMT):
The endorser will be in the transaction action not in the header
dave.enyeart (Thu, 16 Nov 2017 02:56:55 GMT):
Are you looking at node.js SDK json?
dave.enyeart (Thu, 16 Nov 2017 02:57:53 GMT):
If you are querying a single peer from SDK then there would only be one endorser (the peer)
ArnabChatterjee (Thu, 16 Nov 2017 02:59:43 GMT):
yes. the json returned by node sdk
ArnabChatterjee (Thu, 16 Nov 2017 03:02:02 GMT):
that means I have to query multiple peers to get the transaction by id and each one's payload would contain different endorsers?
ArnabChatterjee (Thu, 16 Nov 2017 03:02:20 GMT):
*btw - I mean the json response by payload
dave.enyeart (Thu, 16 Nov 2017 03:05:04 GMT):
I'm not understanding your intent... endorsers and endorsement policy is important if you are trying to submit a transaction that writes to the ledger. If you are simply querying for a transaction by id then you are not submitting a transaction that writes to the ledger.
ArnabChatterjee (Thu, 16 Nov 2017 03:07:49 GMT):
Sorry for that dave. I am trying to invoke a transaction (with 2 orgs having 2 peers each) with an endorsement policy that says that both orgs (member) must sign it. But when the transaction succeeds, I try to get the transaction json using (getTransactionById). When I see the json response, I want to see that both org has endorsed the transaction at the time of invocation.
ArnabChatterjee (Thu, 16 Nov 2017 03:08:55 GMT):
But I see only one endorsement in the JSON. This endorsement is of the organisation who invoked the transaction (example Org1MSP)
dave.enyeart (Thu, 16 Nov 2017 03:12:33 GMT):
can you upload the json
ArnabChatterjee (Thu, 16 Nov 2017 03:57:06 GMT):
okay. sure.
ArnabChatterjee (Thu, 16 Nov 2017 03:58:21 GMT):
response_json.txt
Vadim (Thu, 16 Nov 2017 08:13:30 GMT):
@ArnabChatterjee I see two endorsements at the end
ArnabChatterjee (Thu, 16 Nov 2017 08:13:36 GMT):
yes
ArnabChatterjee (Thu, 16 Nov 2017 08:13:51 GMT):
Both are from the same org
ArnabChatterjee (Thu, 16 Nov 2017 08:14:00 GMT):
however I had set the below policy
ArnabChatterjee (Thu, 16 Nov 2017 08:14:00 GMT):
however I had set the below policy
ArnabChatterjee (Thu, 16 Nov 2017 08:14:26 GMT):
'endorsement-policy': {
identities: [
{ role: { name: 'member', mspId: 'Org2MSP' }},
{ role: { name: 'member', mspId: 'Org1MSP' }},
{ role: { name: 'admin', mspId: 'Org2MSP' }},
{ role: { name: 'admin', mspId: 'Org1MSP' }}
],
policy: {
'4-of': [{ 'signed-by': 0},
{ 'signed-by': 1}]
}
}
ArnabChatterjee (Thu, 16 Nov 2017 08:15:25 GMT):
sorry, wrong policy. please find below the corrected one.
ArnabChatterjee (Thu, 16 Nov 2017 08:15:26 GMT):
'endorsement-policy': {
identities: [
{ role: { name: 'member', mspId: 'Org2MSP' }},
{ role: { name: 'member', mspId: 'Org1MSP' }}
],
policy: {
'4-of': [{ 'signed-by': 0},
{ 'signed-by': 1}]
}
}
ArnabChatterjee (Thu, 16 Nov 2017 08:15:26 GMT):
`'endorsement-policy': {
identities: [
{ role: { name: 'member', mspId: 'Org2MSP' }},
{ role: { name: 'member', mspId: 'Org1MSP' }}
],
policy: {
'4-of': [{ 'signed-by': 0},
{ 'signed-by': 1}]
}
}`
ArnabChatterjee (Thu, 16 Nov 2017 08:15:26 GMT):
`'endorsement-policy': {
identities: [
{ role: { name: 'member', mspId: 'Org2MSP' }},
{ role: { name: 'member', mspId: 'Org1MSP' }}
],
policy: {
'2-of': [{ 'signed-by': 0},
{ 'signed-by': 1}]
}
}`
Vadim (Thu, 16 Nov 2017 08:17:14 GMT):
are you sure the tx is valid?
ArnabChatterjee (Thu, 16 Nov 2017 08:17:57 GMT):
Yes. I got back a transaction id from the SDK. Can you let me know why you think this transaction is not valid?
Vadim (Thu, 16 Nov 2017 08:18:42 GMT):
did the tx have an effect on the ledger?
ArnabChatterjee (Thu, 16 Nov 2017 08:23:37 GMT):
yes
ArnabChatterjee (Thu, 16 Nov 2017 08:23:43 GMT):
it got committed
ArnabChatterjee (Thu, 16 Nov 2017 08:24:02 GMT):
I get the transaction json when I get the transaction by ID
ArnabChatterjee (Thu, 16 Nov 2017 08:24:14 GMT):
Is that you are asking for?
Vadim (Thu, 16 Nov 2017 08:24:17 GMT):
invalid tx are also committed
ArnabChatterjee (Thu, 16 Nov 2017 08:24:24 GMT):
oh
ArnabChatterjee (Thu, 16 Nov 2017 08:24:31 GMT):
how do I verify that
ArnabChatterjee (Thu, 16 Nov 2017 08:24:37 GMT):
can you let me know?
Vadim (Thu, 16 Nov 2017 08:24:44 GMT):
well if you move some asset, check if it was moved
ArnabChatterjee (Thu, 16 Nov 2017 08:25:12 GMT):
I did not move any asset. I added some key/values in the db
Vadim (Thu, 16 Nov 2017 08:25:26 GMT):
so the tx had no effect?
ArnabChatterjee (Thu, 16 Nov 2017 08:25:27 GMT):
should I go and check my couch db via the fauxton?
Vadim (Thu, 16 Nov 2017 08:26:00 GMT):
if the tx had no effect, then it is invalid, which is logical because your endorsement policy was not met
ArnabChatterjee (Thu, 16 Nov 2017 08:27:04 GMT):
No I mean, I got back the transaction id, and when I query it via the sdk using the id, get the json containing my keys and values
ArnabChatterjee (Thu, 16 Nov 2017 08:27:22 GMT):
is there any other way to verify if its valid or not?
Vadim (Thu, 16 Nov 2017 08:27:56 GMT):
that I don't know, I know that if you listen for committed transactions over event hub, the status is returned over callbacl
Vadim (Thu, 16 Nov 2017 08:27:56 GMT):
that I don't know, I know that if you listen for committed transactions over event hub, the status is returned over callback
ArnabChatterjee (Thu, 16 Nov 2017 08:28:07 GMT):
yes exactly
Vadim (Thu, 16 Nov 2017 08:28:07 GMT):
also, you can check the peer logs it writes it there
ArnabChatterjee (Thu, 16 Nov 2017 08:28:56 GMT):
I get VALID in all responses from events
ArnabChatterjee (Thu, 16 Nov 2017 08:29:05 GMT):
code = 'VALID'
Vadim (Thu, 16 Nov 2017 08:29:40 GMT):
then I don't know
ArnabChatterjee (Thu, 16 Nov 2017 08:29:45 GMT):
`eh.registerTxEvent(transactionID, (tx, code) => {
clearTimeout(handle);
eh.unregisterTxEvent(transactionID);
eh.disconnect();
if (code !== 'VALID') {
logger.error(
'The transaction was invalid, code = ' + code);
reject();
} else {
logger.info(
'The transaction has been committed on peer ' +
eh._ep._endpoint.addr);
resolve();
}
});`
ArnabChatterjee (Thu, 16 Nov 2017 08:29:54 GMT):
you mean this one. Right?
Vadim (Thu, 16 Nov 2017 08:29:57 GMT):
yes
ArnabChatterjee (Thu, 16 Nov 2017 08:31:28 GMT):
Okay. Thanks @Vadim as always for your support. Can you confirm me one thing? How many peers should I send the transaction to if I want to get all endorsements?
ArnabChatterjee (Thu, 16 Nov 2017 08:32:01 GMT):
should I leave out the targets as empty or should I explicitly mentions all peers in all organizations ?
Vadim (Thu, 16 Nov 2017 08:32:08 GMT):
each peer generate one endorsement
Vadim (Thu, 16 Nov 2017 08:32:28 GMT):
if you set targets emtpy, it will use all peers that you initialized the Client with
Vadim (Thu, 16 Nov 2017 08:32:28 GMT):
if you set targets emtpy, it will use all peers that you initialized the Channel with
ArnabChatterjee (Thu, 16 Nov 2017 08:33:36 GMT):
so, for this particular case, if I set my endorsement policy to get response from both orgs members then I need to send it to atleast one peer from each organization
ArnabChatterjee (Thu, 16 Nov 2017 08:33:36 GMT):
so, for this particular case, if I set my endorsement policy to get signature from both orgs members then I need to send it to atleast one peer from each organization
ArnabChatterjee (Thu, 16 Nov 2017 08:33:41 GMT):
is it the case?
Vadim (Thu, 16 Nov 2017 08:34:59 GMT):
seems so
ArnabChatterjee (Thu, 16 Nov 2017 08:35:37 GMT):
:thumbsup:
ArnabChatterjee (Thu, 16 Nov 2017 08:36:06 GMT):
thanks @Vadim again. You cleared my doubt which was lingering for more than a week.
ArnabChatterjee (Thu, 16 Nov 2017 10:57:21 GMT):
Okay. I have one more question. Is there any upper restriction on setting an endorsement policy that I cannot require OK signatures of all the organizations in the network? For example if I have org 1 and org 2 then such kind of an endorsement policy is giving me an error :
`'endorsement-policy': {
identities: [
{ role: { name: 'member', mspId: 'Org2MSP' }},
{ role: { name: 'member', mspId: 'Org1MSP' }}
],
policy: {
'2-of': [{ 'signed-by': 0},
{ 'signed-by': 1}]
}
}`
ArnabChatterjee (Thu, 16 Nov 2017 10:57:21 GMT):
Okay. I have one more question. Is there any upper restriction on setting an endorsement policy that I cannot require OK signatures of all the organizations in the network? For example if I have org 1 and org 2 then such kind of an endorsement policy is giving me an error 'ENDORSEMENT_POLICY_FAILURE' :
`'endorsement-policy': {
identities: [
{ role: { name: 'member', mspId: 'Org2MSP' }},
{ role: { name: 'member', mspId: 'Org1MSP' }}
],
policy: {
'2-of': [{ 'signed-by': 0},
{ 'signed-by': 1}]
}
}`
ArnabChatterjee (Thu, 16 Nov 2017 10:57:21 GMT):
Okay. I have one more question. Is there any upper restriction on setting an endorsement policy that I cannot require OK signatures of all the organizations in the network? For example if I have org 1 and org 2 then such kind of an endorsement policy is giving me an error 'ENDORSEMENT_POLICY_FAILURE' :
'endorsement-policy': {
identities: [
{ role: { name: 'member', mspId: 'Org2MSP' }},
{ role: { name: 'member', mspId: 'Org1MSP' }}
],
policy: {
'2-of': [{ 'signed-by': 0},
{ 'signed-by': 1}]
}
}
ArnabChatterjee (Thu, 16 Nov 2017 10:57:40 GMT):
whereas this is not : 'endorsement-policy': {
identities: [
{ role: { name: 'member', mspId: 'Org2MSP' }},
{ role: { name: 'member', mspId: 'Org1MSP' }}
],
policy: {
'1-of': [{ 'signed-by': 0},
{ 'signed-by': 1}]
}
}
ArnabChatterjee (Thu, 16 Nov 2017 10:57:40 GMT):
whereas this is not :
*'endorsement-policy': {
identities: [
{ role: { name: 'member', mspId: 'Org2MSP' }},
{ role: { name: 'member', mspId: 'Org1MSP' }}
],
policy: {
'1-of': [{ 'signed-by': 0},
{ 'signed-by': 1}]
}
}*
ArnabChatterjee (Thu, 16 Nov 2017 10:57:40 GMT):
whereas this is not :
'endorsement-policy': {
identities: [
{ role: { name: 'member', mspId: 'Org2MSP' }},
{ role: { name: 'member', mspId: 'Org1MSP' }}
],
policy: {
'1-of': [{ 'signed-by': 0},
{ 'signed-by': 1}]
}
}
ArnabChatterjee (Thu, 16 Nov 2017 23:37:22 GMT):
Any thoughts on this @dave.enyeart @Vadim . Thanks :)
ArnabChatterjee (Fri, 17 Nov 2017 05:17:20 GMT):
Okay after struggling for 3 days of understanding endorsement and stuff, this is what I understood. Kindly confirm/correct my understanding. Thanks. :)
ArnabChatterjee (Fri, 17 Nov 2017 05:17:20 GMT):
Okay after struggling for 3 days of understanding endorsement and stuff, this is what I understood. Kindly confirm/correct my understanding. Thanks. :)
```
To instantiate a transaction properly. The instantiation request must be sent to one or more endorsing peers in all the organizations of whom endorsement is required.
During the time of invoke, it is the responsibility of the invoking application to send it to all concerned organization's peers for endorsements.
For example, if we have 2 organizations with 2 endorsing peers in each organization (Org1EP0, Org1EP1, Org2EP0 and Org2EP1) and an endorsement policy as follows:
'endorsement-policy': {
identities: [
{ role: { name: 'member', mspId: 'Org2MSP' }},
{ role: { name: 'member', mspId: 'Org1MSP' }}
],
policy: {
'2-of': [{ 'signed-by': 0},
{ 'signed-by': 1}]
}
}
which requires the signature of both organizations to pass endorsement.
Then it is the responsibility of the application to instantiate the chaincode in all the endorsing peers (Org1EP0, Org1EP1, Org2EP0 and Org2EP1).
During the time of invocation, it would be the responsibility of the application to send transactionProposal to atleast one peer of both organizations ( Org1EP0/Org1EP1 and Org2EP0/Org2EP1)
to get an a valid transaction.
After all the proposal responses has been accumulated in the application, it needs to send all the recieved proposal responses and the proposal itself to the orderer for ordering.
The orderer shall verify the proposal and its responses and then send them to the committing peers for committing in the ledger.
Side Note:
1. In case the transaction fails to be valid in terms of endorsement, it still gets committed in the ledger.
2. All endorsing peers sign the transaction after simulation, hence signature of each endorsing peer (TO WHOM TRANSACTION PROPOSAL WAS SENT) will be present in the transaction
3. Judgement whether transaction is valid is determined by the orderer. Orderer will compare the proposal responses and mark it valid as per the endorsement policy.
This response will be captured by the peers who have subscribed to the events for the given transaction (as event hubs). Only peers belonging to the transaction invoking organization can listen for events.
```
ArnabChatterjee (Fri, 17 Nov 2017 05:17:38 GMT):
```
To instantiate a transaction properly. The instantiation request must be sent to one or more endorsing peers in all the organizations of whom endorsement is required.
During the time of invoke, it is the responsibility of the invoking application to send it to all concerned organization's peers for endorsements.
For example, if we have 2 organizations with 2 endorsing peers in each organization (Org1EP0, Org1EP1, Org2EP0 and Org2EP1) and an endorsement policy as follows:
'endorsement-policy': {
identities: [
{ role: { name: 'member', mspId: 'Org2MSP' }},
{ role: { name: 'member', mspId: 'Org1MSP' }}
],
policy: {
'2-of': [{ 'signed-by': 0},
{ 'signed-by': 1}]
}
}
which requires the signature of both organizations to pass endorsement.
Then it is the responsibility of the application to instantiate the chaincode in all the endorsing peers (Org1EP0, Org1EP1, Org2EP0 and Org2EP1).
During the time of invocation, it would be the responsibility of the application to send transactionProposal to atleast one peer out of both organizations ( Org1EP0/Org1EP1 and Org2EP0/Org2EP1)
to get an a valid transaction.
After all the proposal responses has been accumulated in the application, it needs to send all the recieved proposal responses and the proposal itself to the orderer for ordering.
The orderer shall verify the proposal and its responses and then send them to the committing peers for committing in the ledger.
Side Note:
1. In case the transaction fails to be valid in terms of endorsement, it still gets committed in the ledger.
2. All endorsing peers sign the transaction after simulation, hence signature of each endorsing peer (TO WHOM TRANSACTION PROPOSAL WAS SENT) will be present in the transaction
3. Judgement whether transaction is valid is determined by the orderer. Orderer will compare the proposal responses and mark it valid as per the endorsement policy.
This response will be captured by the peers who have subscribed to the events for the given transaction (as event hubs). Only peers belonging to the transaction invoking organization can listen for events.
```
Vadim (Fri, 17 Nov 2017 08:10:26 GMT):
@ArnabChatterjee 1) YOu need to instantiate only once on any peer, not on each peer. 2) You (or more precisely, an admin of eaach peer) need to install the cc on every peer manually 3) Orderer does not validate the transactions against the policy, each peer does it independently when committing the tx to the ledger 4) peers don't listen to events, an app sdk does.
Vadim (Fri, 17 Nov 2017 08:10:26 GMT):
@ArnabChatterjee 1) YOu need to instantiate only once on any peer, not on each peer. 2) You (or more precisely, an admin of eaach peer) need to install the cc on every peer 3) Orderer does not validate the transactions against the policy, each peer does it independently when committing the tx to the ledger 4) peers don't listen to events, an app sdk does.
ArnabChatterjee (Sat, 18 Nov 2017 07:16:45 GMT):
@Vadim - Thanks for your response. Say if I am using 2 orgs with 2 peers each, then if I dont instantiate it on atleast one peer of org1 and org2, then I get an endorsement policy failure (if custom endorsement policy is set). The initial values that were set for CC on peer of ORG1 and peer of ORG 2 are different and hence endorsement policy failure. But if I do init on both orgs then I get a success.
vdods (Sun, 19 Nov 2017 14:33:09 GMT):
In the fabric peer build (i.e. `make peer` from the fabric project root dir), how do I go about disabling javaenv? I have no intention of using it, and it's just slowing the build down and taking up space on my machine.
ArnabChatterjee (Mon, 20 Nov 2017 05:08:51 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=ve4nAwK8iY5znJWPy) Any ideas @Vadim ?
bjwswang (Tue, 21 Nov 2017 05:47:07 GMT):
Has joined the channel.
vdods (Tue, 21 Nov 2017 19:39:33 GMT):
Hi all, what is the "path" of a ChaincodeID? I'm looking at fabric/protos/peer/chaincode.proto -- I'm apparently able to install differently-versioned or named chaincode to the same path. Does it define where the chaincode appears in the ccenv container filesystem? I.e. $GOPATH/src/chaincode-path ?
vdods (Tue, 21 Nov 2017 19:43:57 GMT):
I'm also getting `"
jojialex2 (Thu, 23 Nov 2017 04:28:46 GMT):
Has joined the channel.
jojialex2 (Thu, 23 Nov 2017 04:37:22 GMT):
Hi, Please help on the following error :
peer chaincode instantiate using kafka orderer giving following error,
←[34;1mpeer0.org1.example.com |←[0m ←[33m2017-11-22 10:47:31.505 UTC [gossip/comm] sendToEndpoint -> WARN 54d←[0m Failed obtaining connection for 172.18.0.15:7051, PKIid:[71 88 115 27 28 222 244 157 196 20 206 87 238 41 173 71 185 195 175 121 236 34 206 183 63 153 178 63 241 226 254 204] reason: x509: cannot validate certificate for 172.18.0.15 because it doesn't contain any IP SANs
jojialex2 (Thu, 23 Nov 2017 04:37:42 GMT):
I am using hostnames in configtx.yaml file. I am not getting any error for channel, join channel, update anchors, and chaincode install, but this getting while chaincode instantiate.
jackeyliliang (Fri, 24 Nov 2017 02:59:57 GMT):
Has joined the channel.
jon_s (Fri, 24 Nov 2017 16:01:16 GMT):
I have followed rest server deploy guide . But after deploying in docker logs i could see logs saying please input the business network name.. how do I pass the business network name. Is any thing missing in documents
rahulhegde (Fri, 24 Nov 2017 22:48:33 GMT):
Hello - is there way in chaincode that can get me channel/chain name, chaincode name?
rahulhegde (Fri, 24 Nov 2017 22:48:33 GMT):
@muralisr
Hello - is there way in chaincode that can get me channel/chain name, chaincode name?
C0rWin (Fri, 24 Nov 2017 23:32:09 GMT):
@rahulhegde you can use `GetSignedProposal() (*pb.SignedProposal, error)` API to get signed proposal, then you can parse it and extract from there channel name, not sure about the chaincode name
yacovm (Sat, 25 Nov 2017 07:51:51 GMT):
@rahulhegde , the channel name is from the channelHeader in the header.
While the chaincode name can be obtained from: https://github.com/hyperledger/fabric/blob/release/protos/utils/proputils.go#L38-L53
rahulhegde (Sat, 25 Nov 2017 15:24:00 GMT):
thanks @yacovm and @C0rWin - let me try it.
UtkarshSingh (Mon, 27 Nov 2017 06:39:34 GMT):
Can anyone tell me, what is the use/role of "Users" present in Organisation's folder ???
snehas (Mon, 27 Nov 2017 16:30:55 GMT):
Hi,
For TLS enabled setup, any reason why we are not setting --tls $CORE_PEER_TLS_ENABLED --cafile $ORDERER_CA on Join channel and install chaincode ?
yacovm (Mon, 27 Nov 2017 16:37:15 GMT):
@snehas of course
yacovm (Mon, 27 Nov 2017 16:37:24 GMT):
these 2 actions don't require you to send a transaction to the orderer ;)
rahulhegde (Tue, 28 Nov 2017 01:10:43 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=ir2KomABCzgc39HQ5) @yacovm
But a Peer CLI acting to request a chaincode source installation per peer and running on a different VM need to send this information securely.
rahulhegde (Tue, 28 Nov 2017 01:10:43 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=ir2KomABCzgc39HQ5) @yacovm
But a Peer CLI acting to request a chaincode source installation per peer node and running on a different VM needs to send this information securely.
snehas (Tue, 28 Nov 2017 13:55:12 GMT):
Thanks @yacovm : And if we set these two fields --tls $CORE_PEER_TLS_ENABLED --cafile $ORDERER_CA for join and install, does it use it or it ignores?
yacovm (Tue, 28 Nov 2017 13:55:43 GMT):
yes
snehas (Tue, 28 Nov 2017 14:06:40 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=r6hodmGYTyGzQYQwp) @yacovm
So does it ignores it?
yacovm (Tue, 28 Nov 2017 14:07:26 GMT):
I said yes
yacovm (Tue, 28 Nov 2017 14:07:35 GMT):
it ignores it
snehas (Tue, 28 Nov 2017 14:08:12 GMT):
ok.. Thanks @yacovm
rahulhegde (Tue, 28 Nov 2017 16:49:34 GMT):
@yacovm - this is regarding https://jira.hyperledger.org/browse/FAB-7137
I have copied you in the JIRA from the above message. I am not sure if Peer CLI uses separate port for non-TLS connectivity with Peer Node. However as per our test carried out, Peer CLI is able to connect to Peer Node w/o specifying those 2 parameters for Join/Install operation where Peer is running in TLS Mode. Does it mean it still use TLS w/o establishing root-of-trust or it does not use TLS yet all?
yacovm (Tue, 28 Nov 2017 16:50:35 GMT):
you're telling me that the peer runs with TLS, and you can connect to it without TLS?
yacovm (Tue, 28 Nov 2017 16:50:49 GMT):
that's not possible
yacovm (Tue, 28 Nov 2017 16:51:05 GMT):
it does not use separate ports, obviously.
rahulhegde (Tue, 28 Nov 2017 16:58:03 GMT):
I just looked at the script once again, may be there is confusion in understanding, So https://github.com/hyperledger/fabric/blob/release/examples/e2e_cli/scripts/script.sh#L36 ==> is the TLS root of trust for Peer Node and ` --cafile ` is the root of trust for orderer node.
rahulhegde (Tue, 28 Nov 2017 16:58:03 GMT):
I just looked at the script once again, may be there is confusion in our understanding, So https://github.com/hyperledger/fabric/blob/release/examples/e2e_cli/scripts/script.sh#L36 ==> is the TLS root of trust for Peer Node and ` --cafile ` is the root of trust for orderer node.
rahulhegde (Tue, 28 Nov 2017 16:59:59 GMT):
And Join and Install are operations explicitly on Peer where orderer is not involed and hence ` --cafile ` is not specified.
rahulhegde (Tue, 28 Nov 2017 16:59:59 GMT):
And Join and Install are operations explicitly on Peer where orderer is not involed and hence ` --cafile ` is not specified. https://github.com/hyperledger/fabric/blob/release/examples/e2e_cli/scripts/script.sh#L91
rahulhegde (Tue, 28 Nov 2017 17:07:48 GMT):
@yacovm once you confirm - I will updated the JIRA with above information to be marked as not a defect.
yacovm (Tue, 28 Nov 2017 17:27:59 GMT):
I am not in frony of a computer
yacovm (Tue, 28 Nov 2017 17:27:59 GMT):
I am not in front of a computer
yacovm (Tue, 28 Nov 2017 17:28:09 GMT):
But basically the peer connection is governed by
yacovm (Tue, 28 Nov 2017 17:28:30 GMT):
CORE_PEER_TLS_ENABLED
yacovm (Tue, 28 Nov 2017 17:29:11 GMT):
And the ca cert by something similar
yacovm (Tue, 28 Nov 2017 17:29:37 GMT):
@rahulhegde
rahulhegde (Tue, 28 Nov 2017 19:57:55 GMT):
@dave.enyeart
we are seeing a mismatch in the JSON document count on couch db. Our test involved restarting couch-db container few times during which Peer Container too went down during Commit Operation
rahulhegde (Tue, 28 Nov 2017 19:57:55 GMT):
@dave.enyeart
we are seeing a mismatch in the JSON document count on couch db. Our test involved restarting couch-db container few times during which Peer Container too went down at the of commit operation
rahulhegde (Tue, 28 Nov 2017 19:57:55 GMT):
@dave.enyeart
we are seeing a mismatch in the JSON document count on couch db. Our test involved restarting couch-db container few times during which Peer Container too went down at the time of commit operation.
rahulhegde (Tue, 28 Nov 2017 19:57:55 GMT):
@dave.enyeart
we are seeing a mismatch in the JSON document count on couch db. Our test involved restarting couch-db container few times during which Peer Container too went down at the time of commit operation.
This is on the fabric-v1.0.4 release.
rahulhegde (Tue, 28 Nov 2017 19:57:55 GMT):
@dave.enyeart
we are seeing a mismatch in the JSON document count on couch db. Our test involved restarting couch-db container few times during which Peer Container too went down at the time of commit operation.
This is on the fabric-v1.0.4 release.
rahulhegde (Tue, 28 Nov 2017 19:57:55 GMT):
@dave.enyeart
we are seeing a mismatch in the JSON document count on couch db. Our test involved restarting couch-db container few times during which Peer Container too went down at the time of commit operation.
This is on the fabric-v1.0.4 release.
I have the peer logs captured and would like to know if there is any additional information that may be required for analysis of this issue.
rahulhegde (Tue, 28 Nov 2017 19:57:55 GMT):
@dave.enyeart @mastersingh24 @muralisr
we are seeing a mismatch in the JSON document count on couch db. Our test involved restarting couch-db container few times during which Peer Container too went down at the time of commit operation.
This is on the fabric-v1.0.4 release.
I have the peer logs captured and would like to know if there is any additional information that may be required for analysis of this issue.
rahulhegde (Tue, 28 Nov 2017 20:08:26 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=97Qe8ChaKJMasSsr6) @yacovm
Please review my message once back.
yacovm (Tue, 28 Nov 2017 20:16:45 GMT):
What do you mean? I responded
rahulhegde (Tue, 28 Nov 2017 20:46:22 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=WYEAxFSJxrRKcixAm) @yacovm
I meant can you confirm our understanding
1. I just looked at the script once again, may be there is confusion in our understanding, So https://github.com/hyperledger/fabric/blob/release/examples/e2e_cli/scripts/script.sh#L36 ==> is the TLS root of trust for Peer CLI Node (for server authentication of Peer Node) and ` --cafile ` is the root of trust for orderer node (acting as a server).
2. And Join and Install are operations explicitly on Peer where orderer is not involed and hence ` --cafile ` is not specified. https://github.com/hyperledger/fabric/blob/release/examples/e2e_cli/scripts/script.sh#L91
rahulhegde (Tue, 28 Nov 2017 20:46:22 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=WYEAxFSJxrRKcixAm) @yacovm
I meant if you can confirm our understanding
1. I just looked at the script once again, may be there is confusion in our understanding, So https://github.com/hyperledger/fabric/blob/release/examples/e2e_cli/scripts/script.sh#L36 ==> is the TLS root of trust for Peer CLI Node (for server authentication of Peer Node) and ` --cafile ` is the root of trust for orderer node (acting as a server).
2. And Join and Install are operations explicitly on Peer where orderer is not involed and hence ` --cafile ` is not specified. https://github.com/hyperledger/fabric/blob/release/examples/e2e_cli/scripts/script.sh#L91
yacovm (Tue, 28 Nov 2017 20:52:56 GMT):
So (1) is correct
yacovm (Tue, 28 Nov 2017 20:53:12 GMT):
And (2) os also correct
toddinpal (Wed, 29 Nov 2017 23:32:00 GMT):
So I've been playing with Composer and ran into a problem that is crashing my peer. Not sure what I have configured incorrectly as I get an MSP mismatch, but I can't figure out where Org1MSP is coming from. Here is the log from the peer:
2017-11-29 22:48:32.242 UTC [nodeCmd] createChaincodeServer -> WARN 001 peer.chaincodeListenAddress is not set, use peer.listenAddress 0.0.0.0:7051
2017-11-29 22:48:32.248 UTC [gossip/gossip] NewGossipService -> WARN 002 External endpoint is empty, peer will not be accessible outside of its organization
2017-11-29 22:59:45.490 UTC [ledgermgmt] CreateLedger -> INFO 003 Creating ledger [composerchannel] with genesis block
2017-11-29 22:59:45.508 UTC [kvledger] Commit -> INFO 004 Channel [composerchannel]: Created block [0] with 1 transaction(s)
2017-11-29 22:59:45.511 UTC [ledgermgmt] CreateLedger -> INFO 005 Created ledger [composerchannel] with genesis block
2017-11-29 22:59:48.517 UTC [ConnProducer] NewConnection -> ERRO 006 Failed connecting to bcsdev:4004 , error: context deadline exceeded
2017-11-29 23:00:14.710 UTC [eventhub_producer] Chat -> ERRO 007 error during Chat, stopping handler: rpc error: code = Canceled desc = context canceled
2017-11-29 23:01:37.299 UTC [kvledger] Commit -> INFO 008 Channel [composerchannel]: Created block [1] with 1 transaction(s)
2017-11-29 23:01:37.346 UTC [eventhub_producer] Chat -> ERRO 009 error during Chat, stopping handler: rpc error: code = Canceled desc = context canceled
2017-11-29 23:16:55.738 UTC [eventhub_producer] Chat -> ERRO 00a Error handling message: event message must be properly signed by an identity from the same organization as the peer: [failed deserializing event creator: [Expected MSP ID OrangeGrowers, received Org1MSP]]
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0xb49700]
goroutine 3186 [running]:
github.com/hyperledger/fabric/core/endorser.(*Endorser).ProcessProposal(0xc4202e1a70, 0x7f4907d58c90, 0xc421b01e60, 0xc421b01f50, 0x0, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:381 +0x110
github.com/hyperledger/fabric/protos/peer._Endorser_ProcessProposal_Handler(0xd934c0, 0xc4202e1a70, 0x7f4907d58c90, 0xc421b01e60, 0xc421862140, 0x0, 0x0, 0x0, 0x8c700a, 0xc42187b8e0)
/opt/gopath/src/github.com/hyperledger/fabric/protos/peer/peer.pb.go:112 +0x28d
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).processUnaryRPC(0xc4200aa500, 0x147dfe0, 0xc421b74000, 0xc420136900, 0xc4201ec720, 0x1459160, 0xc421b01ef0, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:797 +0xc41
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).handleStream(0xc4200aa500, 0x147dfe0, 0xc421b74000, 0xc420136900, 0xc421b01ef0)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:997 +0x15a6
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1(0xc4232add20, 0xc4200aa500, 0x147dfe0, 0xc421b74000, 0xc420136900)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:561 +0xa9
created by github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).serveStreams.func1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:562 +0xa1
muralisr (Thu, 30 Nov 2017 00:47:16 GMT):
@toddinpal what does `peer version` say ?
muralisr (Thu, 30 Nov 2017 00:47:22 GMT):
want to match up line numbers
wininani (Thu, 30 Nov 2017 05:44:03 GMT):
Has joined the channel.
toddinpal (Thu, 30 Nov 2017 18:45:33 GMT):
@muralisr
bash-4.2# peer version
peer:
Version: 1.0.2
Go version: go1.8.3
OS/Arch: linux/amd64
Chaincode:
Base Image Version: 0.3.2
Base Docker Namespace: hyperledger
Base Docker Label: org.hyperledger.fabric
Docker Namespace: hyperledger
toddinpal (Thu, 30 Nov 2017 18:46:03 GMT):
By the way, I've been able to crash the peer in multiple ways. :-(
muralisr (Thu, 30 Nov 2017 18:49:58 GMT):
@toddinpal it would be easier to debug if this happens on master... would that be possible ?
muralisr (Thu, 30 Nov 2017 18:50:32 GMT):
or too much to ask ? :-)
vsadriano (Thu, 30 Nov 2017 18:56:35 GMT):
Has joined the channel.
muralisr (Thu, 30 Nov 2017 19:05:31 GMT):
@toddinpal as far as I could tell, `/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:381 +0x110` does not eval to a line that could throw a `panic: runtime error: invalid memory address or nil pointer dereference` in 1.0.2
muralisr (Thu, 30 Nov 2017 19:06:24 GMT):
don;t know what to tell you....easiest if you can recreate on latest master ...if you can
toddinpal (Thu, 30 Nov 2017 19:23:55 GMT):
Let me see if I can recreate this on master
vsadriano (Thu, 30 Nov 2017 19:30:15 GMT):
Hi! I'm new on Hyperledger Fabric. Why Fabric Peer needs **docker.sock**? Is there any security risk in this approach?
manish-sethi (Thu, 30 Nov 2017 20:12:56 GMT):
@muralisr - here is the CR that I submitted for resource config tx (https://gerrit.hyperledger.org/r/15797). Below is the relevant details about this CR.
1) core/peer/configtx_util.go#26: This is the function that gets called upon receive of a resource-tree update tran and updates the resource bundle that you may want to use for acl stuff now.
2) peer/node/start.go#106: Here I register the new custom tx processor
3) core/peer/configtx_processor.go#90: this code adds entries in the ledger that rscc (system chaincode) puts so that acl stuff can keep working for now.
Once, the acl stuff starts using the resource bundle (in point 1 above), the code pointed out in (3) needs to be removed.
manish-sethi (Thu, 30 Nov 2017 20:14:23 GMT):
Please have a look and see if you would want to take up the acl related changes? Including @dave.enyeart so he can track it from release planning point of view
Vadim (Fri, 01 Dec 2017 06:22:49 GMT):
@vsadriano peer needs docker.sock because it starts chaincodes in containers
vsadriano (Fri, 01 Dec 2017 10:58:49 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=3w6mwPkEqBSMPxAMQ) @Vadim Hi! Is there other approach? Thanks for reply!
Vadim (Fri, 01 Dec 2017 11:39:15 GMT):
@vsadriano I guess you can access docker over http and then put some proxy in between to do some request filtering and api authentication
yacovm (Fri, 01 Dec 2017 11:48:18 GMT):
Yes you can
yacovm (Fri, 01 Dec 2017 11:48:26 GMT):
Look at the commentes out text
yacovm (Fri, 01 Dec 2017 11:48:26 GMT):
Look at the commented out text
vsadriano (Fri, 01 Dec 2017 11:48:37 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=pDkmYpMFBBK85Eq3i) @Vadim Ok! But peer implementation support traffic over http?
yacovm (Fri, 01 Dec 2017 11:48:38 GMT):
In core.yaml
yacovm (Fri, 01 Dec 2017 11:48:44 GMT):
It does
vsadriano (Fri, 01 Dec 2017 11:49:01 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=qj2m86i2ngqKR7YfE) @yacovm Yes! I'll...
yacovm (Fri, 01 Dec 2017 11:49:13 GMT):
You'll what?
vsadriano (Fri, 01 Dec 2017 11:49:29 GMT):
"Look at the commented out text"
muralisr (Fri, 01 Dec 2017 12:57:44 GMT):
@manish-sethi will look at https://gerrit.hyperledger.org/r/15797 today... I'll be at the hackathon next week (and some preparation for that this week). Those are the constraints. But let me look and get back by EOB today please
ashablyg (Fri, 01 Dec 2017 15:07:34 GMT):
Has joined the channel.
ashablyg (Fri, 01 Dec 2017 15:09:00 GMT):
Hey guys, have anyone ran into this error? `Error: peer address is not in the format of host:port: address peer0.****.*****.com:7051:7051: too many colons in address.`
I've double check the docker-compose yaml and everything seems to be in order
ashablyg (Fri, 01 Dec 2017 15:09:00 GMT):
~Hey guys, have anyone ran into this error? `Error: peer address is not in the format of host:port: address peer0.****.*****.com:7051:7051: too many colons in address.` ~ Fixed it.
I've double check the docker-compose yaml and everything seems to be in order
ashablyg (Fri, 01 Dec 2017 15:09:00 GMT):
~Hey guys, have anyone ran into this error? `Error: peer address is not in the format of host:port: address peer0.****.*****.com:7051:7051: too many colons in address.`
I've double check the docker-compose yaml and everything seems to be in order ~ Fixed
ashablyg (Fri, 01 Dec 2017 15:09:00 GMT):
~Hey guys, have anyone ran into this error? `Error: peer address is not in the format of host:port: address peer0.****.*****.com:7051:7051: too many colons in address.` ~
~ I've double check the docker-compose yaml and everything seems to be in order ~ Fixed
rsherwood (Fri, 01 Dec 2017 15:38:08 GMT):
Hi does anyone known which MSP the command "peer chaincode invoke -C testchainid -n cscc -c '{"Args":["GetChannels"]} " will be authenticated against . I believe this is querying the system channel. Would if for example be being authenticated against the local MSP of the peer or would it be MSPs in the system channel ?
jeffgarratt (Fri, 01 Dec 2017 17:41:26 GMT):
@rsherwood It seems to be checking if Role of member of the local MSP org
jeffgarratt (Fri, 01 Dec 2017 17:41:41 GMT):
as I can invoke this using a user with a Cert signed by the MSP Org
jeffgarratt (Fri, 01 Dec 2017 17:43:48 GMT):
``` case GetChannels:
// 2. check local MSP Members policy
jeffgarratt (Fri, 01 Dec 2017 17:44:11 GMT):
that currently seems to be the case... but this will alter once ACL work is completed
toddinpal (Fri, 01 Dec 2017 23:24:14 GMT):
How do I build the peer and other executables as static images, i.e., not linked to any dynamic libraries?
manish-sethi (Sat, 02 Dec 2017 20:57:53 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=Y2bquQFAfed6Twbgd) @muralisr Hi Murali, just to remind you so that it does not slip through your mind.
muralisr (Sat, 02 Dec 2017 20:58:51 GMT):
@manish-sethi no it hasn't, promise :-)
muralisr (Sat, 02 Dec 2017 20:58:59 GMT):
I looked a bit yesterday
muralisr (Sat, 02 Dec 2017 20:59:45 GMT):
your directions above were helpful
bizhenchao1201 (Sun, 03 Dec 2017 09:34:29 GMT):
Has joined the channel.
muralisr (Sun, 03 Dec 2017 13:16:06 GMT):
@manish-sethi I think I understand the CR now... have posted some comments in personal chat. Lets talk there and clarify my understanding please
muralisr (Sun, 03 Dec 2017 13:16:06 GMT):
@manish-sethi I think I understand the CR now... have posted some comments in personal chat. Lets talk there and clarify my understanding please ( @dave.enyeart )
toddinpal (Sun, 03 Dec 2017 14:29:15 GMT):
So I tried to build the peer as a static image without dynamic libraries using CGO_ENABLED=0 for CGO_FLAGS and I get an error trying to build the pkcs11 package:
bccsp/pkcs11/impl.go:81:12: undefined: pkcs11.Ctx
bccsp/pkcs11/impl.go:82:16: undefined: pkcs11.SessionHandle
Any suggestions on how to build the peer linked statically?
rsherwood (Mon, 04 Dec 2017 08:13:36 GMT):
jeffgarratt [ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=HKoXMgZNNTprrKLRa) @jeffgarratt Thanks for the reply . Very clear. Do you have a link that says what the ACL changes are intended to be?
rsherwood (Mon, 04 Dec 2017 08:22:06 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=HKoXMgZNNTprrKLRa) @jeffgarratt Do you know what other operations are checked against a peers local MSP ? So far I know of install chaincode AND join a peer to a channel (local MSP Admin roles), and now list a peers channels (local MSP member roles). Are there any other commands that I have unaware of. I am trying to work out if we have to update the CRL list on a peer as well a on the channels. I was hoping to get away without the update on the peer local MSP, however to do that I need to know what the peer local MSP is being used for.
jeffgarratt (Mon, 04 Dec 2017 14:29:00 GMT):
@rsherwood check for calls to https://github.com/hyperledger/fabric/blob/master/core/policy/policy.go#L47
jeffgarratt (Mon, 04 Dec 2017 14:29:30 GMT):
this indicates that it will generally refer to some local MSP role. This is to be refactored once the ACL work is ready.
steigensonne (Tue, 05 Dec 2017 06:11:58 GMT):
Does fabric consider the case of that the peer(s) can leave the channel where they joined?? I just wonder of they have any ideas on this issue??
snehas (Tue, 05 Dec 2017 06:20:34 GMT):
@yacovm
For fabric TLS setup, Do we need to add CORE_PEER_TLS_KEY_FILE in docker-compose for CLI container? If I don't add this variable for CLI or set incorrect path of the Key file, it still works. Could you please confirm?
yacovm (Tue, 05 Dec 2017 06:21:56 GMT):
Of course it works, the CLI is a TLS client
yacovm (Tue, 05 Dec 2017 06:22:15 GMT):
You dont need a key as long as we dont enforce mutual TLS
rsherwood (Tue, 05 Dec 2017 09:33:10 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=gG53onqg727Q6grau) @jeffgarratt So I have looked and items have found are, in CSCC joinChain, GetChannels; in LSCC Install, GetChaincodes and GetInstalledChaincodes. Have I missed anything?
DarshanBc (Tue, 05 Dec 2017 10:42:15 GMT):
can the world state be shared between 2 channels
jeffgarratt (Tue, 05 Dec 2017 14:33:15 GMT):
@DarshanBc a chaincode can invoke another chaincode to get inforrmation, but this is the only 'sharing' that I am aware of
rsherwood (Tue, 05 Dec 2017 16:14:41 GMT):
In V1.0 for most fabric operations the peer will act as a TLS server. One case I can think of where it would be a client would be when gossiping with another peer. In this case I assume the root of trust for the TLS will be in the channel MSP. Are there any case when a peer acts as TLS client and uses the local MSP as the TLS root of trust ? For example is the peer to running chaincode communication protected by TLS in any way, and if its is what certificate is used and which end is the TLS server and which the client ?
C0rWin (Tue, 05 Dec 2017 16:15:29 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=ZiF3EroBvnjmPwe5H) @rsherwood connecting with ordering service to pull blocks for example
rsherwood (Tue, 05 Dec 2017 16:29:40 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=fiTJB5r2aqMTEvBA9) @C0rWin Will connecting to the order use the localMSP or the orderer definitions in the channel MSP ? I guessed it was the channel as orderer could have a different root of trust than the peer.
dhirendrausa (Tue, 05 Dec 2017 20:29:07 GMT):
Has joined the channel.
dhirendrausa (Tue, 05 Dec 2017 20:45:36 GMT):
Not sure if I am posting my question on the right channel, *Anyone can help me to understand in blockchain how two different institutions communicate with each other and form P2P*?
jeffgarratt (Tue, 05 Dec 2017 21:18:36 GMT):
@dhirendrausa the fabric forms several P2P networks within a system. The orderers are working in concert to provide total ordering and crash fault tolerance. The peers are communicating with the orderers as well as each other (even across organizations if so configured)
ynamiki (Wed, 06 Dec 2017 05:23:47 GMT):
Has left the channel.
rickr (Wed, 06 Dec 2017 13:09:38 GMT):
Is there a means to query a Peer to find out what channels it has joined ?
yacovm (Wed, 06 Dec 2017 13:18:59 GMT):
yes
yacovm (Wed, 06 Dec 2017 13:19:12 GMT):
cscc - GetChannels
jworthington (Wed, 06 Dec 2017 14:38:37 GMT):
Version: 1.1.0-preview. Setting up gossip. 2 Orgs, each with 2 peers. I see how to declare external endpoints and bootstrap within the same org. Where do I say to gossip with the endpoints of a different org? My peers seem to be gossiping within an org, but not between orgs.
In the bootstrap for a peer, do I need to include the local loopback for itself as well as the other peers in its org? 127.0.0.1:7051
jworthington (Wed, 06 Dec 2017 15:33:40 GMT):
I'm trying to understand the env vars on Peers. Which are valid and what do they over ride in core.yaml. Here's what I am using, but not sure which are valid and the setting they override.
jworthington (Wed, 06 Dec 2017 15:33:44 GMT):
CORE_PEER_LOCALMSPDIR set to path to crypto of peer. Is this valid? Needed? If so, what's different about it and CORE_PEER_MSPCONFIGPATH?
CORE_PEER_GENERAL_LOCALMSPID set to MSPID in channel configtx. Overides localMspId in core.yaml?
CORE_PEER_GENERAL_LOCALMSPDIR set to crypto of org (CA admin).
CORE_PEER_MSPCONFIGPATH set to path to crypto of peer. Overrides mspConfigPath in core.yml?
jworthington (Wed, 06 Dec 2017 15:34:39 GMT):
Is there a list of valid env vars and what they over ride?
jeffgarratt (Wed, 06 Dec 2017 15:54:41 GMT):
@jworthington here is an example set from some of my runs
jeffgarratt (Wed, 06 Dec 2017 15:54:43 GMT):
```environment:
CORE_LOGGING_GOSSIP: DEBUG
CORE_LOGGING_LEVEL: DEBUG
CORE_PEER_ADDRESSAUTODETECT: 'true'
CORE_PEER_FILESYSTEMPATH: /var/hyperledger/bddtests/volumes/peer/d0975cb8da2d11e7863e02d158fa0198/peer1/filestore
CORE_PEER_GOSSIP_BOOTSTRAP: peer0:7051
CORE_PEER_GOSSIP_ENDPOINT: peer1:7051
CORE_PEER_GOSSIP_ORGLEADER: 'false'
CORE_PEER_GOSSIP_USELEADERELECTION: 'true'
CORE_PEER_ID: vp1
CORE_PEER_LOCALMSPID: peerOrg0
CORE_PEER_MSPCONFIGPATH: /var/hyperledger/bddtests/volumes/peer/d0975cb8da2d11e7863e02d158fa0198/peer1/localMspConfig
CORE_PEER_NETWORKID: d0975cb8da2d11e7863e02d158fa0198
CORE_PEER_TLS_CERT_FILE: /var/hyperledger/bddtests/volumes/peer/d0975cb8da2d11e7863e02d158fa0198/peer1/tls_config/peer1Signer-peer1-peerOrg0-tls.crt
CORE_PEER_TLS_ENABLED: 'true'
CORE_PEER_TLS_KEY_FILE: /var/hyperledger/bddtests/volumes/peer/d0975cb8da2d11e7863e02d158fa0198/peer1/tls_config/peer1Signer-peer1-peerOrg0-tls.key
CORE_PEER_TLS_ROOTCERT_FILE: /var/hyperledger/bddtests/volumes/peer/d0975cb8da2d11e7863e02d158fa0198/peer1/localMspConfig/cacerts/peerOrg0.pem
CORE_PEER_TLS_SERVERHOSTOVERRIDE: peer1
image: hyperledger/fabric-peer:x86_64-1.0.3
jworthington (Wed, 06 Dec 2017 15:54:56 GMT):
Thx!
jeffgarratt (Wed, 06 Dec 2017 15:55:28 GMT):
you of course do not need to set the gossip level to debug, though the core logging debug is useful
jeffgarratt (Wed, 06 Dec 2017 15:56:17 GMT):
@jworthington btw. your CORE_GENERAL.. seems to be a conflation of peer and orderer config prefixes
jworthington (Wed, 06 Dec 2017 15:58:05 GMT):
That's probably part of my confusion. Thx
jworthington (Wed, 06 Dec 2017 16:12:27 GMT):
So in your example, CORE_PEER_LOCALMSPID: peerOrg0 is the same ID as in the channel configtx. It seems to point to the crypto of the peer? But in the channel configtx it points to the crypto of the Org, no? So a peer channel create has to use the Org crypto? I guess that's kind of the difference between a, so to speak, peer server config and a peer client config? I could point CORE_PEER_MSPCONFIGPATH: to the Org crypto when using as a client and then point it back. Or I think I saw a flag I could use for each client command. Does that all sound about right?
jworthington (Wed, 06 Dec 2017 16:13:17 GMT):
And where do I tell a peer in one org to gossip with peers in other orgs?
jeffgarratt (Wed, 06 Dec 2017 16:44:02 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=DopoS8CjoZ5uhx6kk) @jworthington see anchor peers
jworthington (Wed, 06 Dec 2017 16:49:49 GMT):
Ah. thx. i had set them to the local Org peers and not foreign peers. Thx!
jeffgarratt (Wed, 06 Dec 2017 17:05:56 GMT):
@jworthington you do set them to the local orgs peers. The other peers from other orgs can then leverage this to gossip with other organizations.
jeffgarratt (Wed, 06 Dec 2017 17:06:31 GMT):
meaning... only the Owning org can set its own anchor peers
jeffgarratt (Wed, 06 Dec 2017 17:06:54 GMT):
this information goes into the channel which allows other orgs to have their peers connect to them if so desired
jworthington (Wed, 06 Dec 2017 17:10:48 GMT):
hmm. then a peer reads foreign org gossip definitions from the genesis/channel configtx and knows to use it? And each peer has to set its endpoint to match in core.yaml?
jworthington (Wed, 06 Dec 2017 17:24:20 GMT):
hmm. Well, channel creation succeeded on org1 peers 1 and it got the channel block. All 3 orderers show the new channel. But none of the other 3 peers got the channel block so they could join. Surely that means there's an issue with gossip, no? I assumed the other peers would get the channel block.
wanghhao (Thu, 07 Dec 2017 09:13:19 GMT):
Has joined the channel.
jrosmith (Thu, 07 Dec 2017 15:43:30 GMT):
hey all, is there a way to get visibility into the read write sets for a given block?
jeffgarratt (Thu, 07 Dec 2017 15:44:46 GMT):
@jrosmith that is available in the block information you receive from the peer, or from the orderer if you so choose
jeffgarratt (Thu, 07 Dec 2017 15:45:15 GMT):
ahhh... you mean the actual de-marshaling I presume?
jrosmith (Thu, 07 Dec 2017 15:45:49 GMT):
@jeffgarratt yeah i would like to specifically see what has exactly gone into the set. i don't suppose its as simple as setting a log level?
jeffgarratt (Thu, 07 Dec 2017 15:46:14 GMT):
I don't thin so as that would be possibly a privacy issue
jeffgarratt (Thu, 07 Dec 2017 15:46:52 GMT):
the SDKs may have some enhanced functionality perhaps to get visibility into the TXs
jeffgarratt (Thu, 07 Dec 2017 15:47:10 GMT):
perhaps pose your question to #fabric-sdk-node ?
jrosmith (Thu, 07 Dec 2017 15:47:23 GMT):
@jeffgarratt will do, thanks for your help
jeffgarratt (Thu, 07 Dec 2017 15:47:32 GMT):
your most welcome!! good luck!!
rahulhegde (Thu, 07 Dec 2017 21:59:52 GMT):
@dave.enyeart
Reference https://hyperledger-fabric.readthedocs.io/en/release/chaincode4noah.html#creating-the-package.
1. Specifying option `-S`, the chaincode will be signed using the localMSP to create a binary format signed CDS. Is there a way to lint or view this signed CDS? Can someone retrieve a chaincode source from this CDS?
2. Will the Peer ensure the CDS is not tampered at the time of installation?
rahulhegde (Thu, 07 Dec 2017 21:59:52 GMT):
@dave.enyeart
Reference https://hyperledger-fabric.readthedocs.io/en/release/chaincode4noah.html#creating-the-package.
1. Specifying option `-S`, the chaincode will be signed using the localMSP to create a binary format signed CDS. Is there a way to lint or view this signed CDS? Can someone retrieve a chaincode source from this CDS?
2. Will the Peer ensure the CDS is not tampered at the time of installation?
3. `-i` helps to specify the instantiation policy. However for test i changed to use AND(OrganizationMSP.member). Chaincode upgrade fails if an OrganizationMSP's member user is used however passes if OrganizationMSP's admin user. Am i doing something incorrect?
rahulhegde (Thu, 07 Dec 2017 21:59:52 GMT):
@dave.enyeart
Reference https://hyperledger-fabric.readthedocs.io/en/release/chaincode4noah.html#creating-the-package.
1. Specifying option `-S`, the chaincode will be signed using the localMSP to create a binary format signed CDS. Is there a way to lint or view this signed CDS? Can someone retrieve a chaincode source from this CDS?
2. Will the Peer ensure the CDS is not tampered at the time of installation?
3. `-i` helps to specify the instantiation policy. However for test i changed to use AND(OrganizationMSP.member). Chaincode upgrade fails if an OrganizationMSP's member user is used however passes if OrganizationMSP's admin user. Am i doing something incorrect?
Thanks.
rahulhegde (Thu, 07 Dec 2017 21:59:52 GMT):
@dave.enyeart
Reference https://hyperledger-fabric.readthedocs.io/en/release/chaincode4noah.html#creating-the-package.
1. Specifying option `-S`, the chaincode will be signed using the localMSP to create a binary format signed CDS. Is there a way to lint or view this signed CDS? Can intruder retrieve a chaincode source from this CDS?
2. Will the Peer ensure the CDS is not tampered at the time of installation?
3. `-i` helps to specify the instantiation policy. However for test i changed to use AND(OrganizationMSP.member). Chaincode upgrade fails if an OrganizationMSP's member user is used however passes if OrganizationMSP's admin user. Am i doing something incorrect?
Thanks.
dave.enyeart (Fri, 08 Dec 2017 00:10:45 GMT):
@rahulhegde Let's see what the expert in this area @muralisr thinks
alvaradojl (Sat, 09 Dec 2017 12:47:54 GMT):
Has joined the channel.
ajenie (Tue, 12 Dec 2017 03:43:04 GMT):
Has joined the channel.
guolidong (Tue, 12 Dec 2017 06:03:27 GMT):
Has joined the channel.
vsadriano (Tue, 12 Dec 2017 10:54:15 GMT):
@chill37 I use this command:
```
docker run --rm -w /etc/hyperledger/fabric -v `pwd`:/etc/hyperledger/fabric hyperledger/fabric-tools:x86_64-1.0.2 configtxgen -profile OneOrgChannel -outputAnchorPeersUpdate ./channel-artifacts/OrgMSPanchors.tx -channelID defaultchannel -asOrg OrgMSP
```
chill37 (Tue, 12 Dec 2017 10:54:16 GMT):
Has joined the channel.
chill37 (Tue, 12 Dec 2017 11:02:44 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=zfBvdRBeBL9p7pRnz) @vsadriano Thank you for the reply. but as far as I see/know, this is only setting 1) anchor peer, 2)channel. I still don't see where to set the endorsing peer.
Vadim (Tue, 12 Dec 2017 11:05:19 GMT):
@chill37 there was something in core.yaml related to endorsing peer, but some devs said it's not really working and the best approach is not to install chaincode on a peer if you don't want it to be endorsing
C0rWin (Tue, 12 Dec 2017 11:09:12 GMT):
@chill37, @Vadim is correct, if do not want peer to be an endorsing peer for specific chaincode, you can just avoid installing chaincode on it
chill37 (Tue, 12 Dec 2017 11:16:28 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=ChFPRqvL5mYS2dMdR) @Vadim @C0rWin Thanks! so are you saying that for now, all peers that I am installing/instantiating chaincode is automatically an endorsing node?
Vadim (Tue, 12 Dec 2017 11:16:47 GMT):
yes
chill37 (Tue, 12 Dec 2017 11:19:22 GMT):
@Vadim Ah I see. Thanks again. just last Q: so this core.yaml that you were talking about, would u happen to know where it's located? I was searching but no clue yet. I appreciate your help a lot!
Vadim (Tue, 12 Dec 2017 11:19:46 GMT):
@chill37 I think that flag for endorser/not endorser no longer exists
Vadim (Tue, 12 Dec 2017 11:20:17 GMT):
core.yaml is here: https://github.com/hyperledger/fabric/blob/release/sampleconfig/core.yaml
chill37 (Tue, 12 Dec 2017 11:22:00 GMT):
@Vadim Oh wow. Thanks for everything! I'm new so this was really helpful.
jworthington (Tue, 12 Dec 2017 14:06:27 GMT):
So, I installed and instantiated a chaincode on 4 peers (2 each for 2 orgs). All is well with the default Endorsement Policy. Invokes write and read data. I installed and instantiated the same chaincode (different name, same channel) on all 4 peers, but with a Policy of 1 Org1.member AND 1 Org2.member. All good and I see the lscc and init record in CouchDB on all 4 peers. However invokes do not write. I get an Error - VSCC check failed, policy evaluation failed, err Failed to authenticate policy. There is also WARN 1df6 Block [78541] Transaction index [0] marked as invalid by committer. Reason code [10]. The peers logs do say Saved private data for block [78541], but I believe that to be local state and not world state. I think I understand that the client (in this case the CLI) is responsible for collecting endorsements. If that is true, then how do I get the CLI to get the endorsements? If that is not true, then the peers must need the MSP for the other peers? If so, then how do I tell the peers where the MSP is for the other peers? Or is there something else I am not understanding?
Vadim (Tue, 12 Dec 2017 15:23:33 GMT):
@jworthington cli does not collect endorsements and it only can work with one peer
jworthington (Tue, 12 Dec 2017 15:24:26 GMT):
That's what i was afraid of. Thx.
PetrVlasekCA (Tue, 12 Dec 2017 16:49:27 GMT):
Has joined the channel.
asaningmaxchain (Wed, 13 Dec 2017 02:43:20 GMT):
@jyellick the peer want to join the specified channel,the peer should send a proposal to the all peer and get the proposal response
asaningmaxchain (Wed, 13 Dec 2017 02:43:20 GMT):
@jyellick the peer want to join the specified channel,the peer should send a proposal to the all peer and get the proposal response
asaningmaxchain (Wed, 13 Dec 2017 02:43:20 GMT):
@jyellick the peer want to join the specified channel,the peer should send a proposal to the all peer and get the proposal response,the endorser service work on it
jyellick (Wed, 13 Dec 2017 03:01:27 GMT):
@asaningmaxchain I do not understand
asaningmaxchain (Wed, 13 Dec 2017 03:03:39 GMT):
@jyellick if the peer want to join the channel,it must send the proposal to the peer,however the peer use the endorser service deal with the proposal?
asaningmaxchain (Wed, 13 Dec 2017 03:03:39 GMT):
@jyellick if the peer want to join the channel,it must send the proposal to the peer,however the peer use the endorser service deal with the proposal?so can you tell me where the endorser service invoke the cscc
jyellick (Wed, 13 Dec 2017 03:05:18 GMT):
Are you asking: "Does the peer endorse the proposal it receives to join a channel?"? If so, the answer is yes, the the endorsement is only produced because it is the standard chaincode path. There is no requirement that the client do anything with the response, though it could of course retain the endorsement for non-repudication purposes.
jyellick (Wed, 13 Dec 2017 03:05:18 GMT):
Are you asking: "Does the peer endorse the proposal it receives to join a channel?"? If so, the answer is yes, the the endorsement is only produced because it is the standard chaincode path. There is no requirement that the client do anything with the response, though it could of course retain the endorsement for non-repudiation purposes.
jyellick (Wed, 13 Dec 2017 03:05:18 GMT):
Are you asking: "Does the peer endorse the proposal it receives to join a channel?"? If so, the answer is yes, the endorsement is produced because it is the standard chaincode path. There is no requirement that the client do anything with the response, though it could of course retain the endorsement for non-repudiation purposes.
asaningmaxchain (Wed, 13 Dec 2017 03:06:39 GMT):
so can you tell me where the endorser service invoke the cscc
asaningmaxchain (Wed, 13 Dec 2017 03:11:53 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=q6779o2H2XmJDmjZm) @jyellick yes
Lakshmipadmaja (Wed, 13 Dec 2017 08:50:24 GMT):
User User_1 added by Lakshmipadmaja.
Ashish (Wed, 13 Dec 2017 14:17:27 GMT):
Is there a case, where the chain code invoke works when the policy is like 2 of Role.MEMBER of Org1 *AND* Org2. if I keep it as 2 of Role.ADMIN of Org1 *AND* Org2
Ashish (Wed, 13 Dec 2017 14:17:27 GMT):
Is there a case, where the chain code invoke works when the policy is like 2 of Role.MEMBER of Org1 *AND* Org2. But fails if I keep it as 2 of Role.ADMIN of Org1 *AND* Org2
Ashish (Wed, 13 Dec 2017 14:17:27 GMT):
Is there a case, where the chain code invoke works when the policy is like 2 of Role.MEMBER of Org1 *AND* Org2. But fails if I keep it as 2 of Role.ADMIN of Org1 *AND* Org2?
Ashish (Wed, 13 Dec 2017 14:18:51 GMT):
Using Fabric 1.0.3 and testing using javaSDK
Vadim (Wed, 13 Dec 2017 14:42:48 GMT):
@Ashish I guess because it needs org admin, but gets a signature of org member... How to get endorsement from admin, I don't know.
asaningmaxchain (Wed, 13 Dec 2017 14:46:52 GMT):
@jyellick i use the java sdk to Instantiate chaincode,however i got the error `failed to init chaincode: handler not found for chaincode test:1.0, cause=null}`
asaningmaxchain (Wed, 13 Dec 2017 14:46:52 GMT):
@jyellick i use the java sdk to Instantiate chaincode,however i got the error `failed to init chaincode: handler not found for chaincode test:1.0, cause=null}`the cause is null,so i don't know how to resolve it
Vadim (Wed, 13 Dec 2017 14:48:17 GMT):
@asaningmaxchain have you checked the peer logs?
Vadim (Wed, 13 Dec 2017 14:48:45 GMT):
but seems like the chaincode is not installed
asaningmaxchain (Wed, 13 Dec 2017 14:49:14 GMT):
the chaincode installed successfully
Vadim (Wed, 13 Dec 2017 14:49:28 GMT):
how do you know that?
asaningmaxchain (Wed, 13 Dec 2017 14:50:14 GMT):
because i installed chaincode before the chaincode Instantiate
asaningmaxchain (Wed, 13 Dec 2017 14:50:14 GMT):
because i installed chaincode before the chaincode Instantiate and i see the chaincodes directory exists the chaincode
Ashish (Wed, 13 Dec 2017 14:50:34 GMT):
I guess u are saying because u got status 200
Ashish (Wed, 13 Dec 2017 14:50:39 GMT):
Rite?
Vadim (Wed, 13 Dec 2017 14:50:40 GMT):
have you checked the peer logs?
asaningmaxchain (Wed, 13 Dec 2017 14:50:48 GMT):
wait a moment
asaningmaxchain (Wed, 13 Dec 2017 14:50:57 GMT):
i send it to the pastebin or gist
Ashish (Wed, 13 Dec 2017 14:51:04 GMT):
Then like Vadim says, u should check peer logs
asaningmaxchain (Wed, 13 Dec 2017 14:51:18 GMT):
wait a moment
asaningmaxchain (Wed, 13 Dec 2017 14:53:51 GMT):
i am sorry,i am a chinese,my network is terriable
Ashish (Wed, 13 Dec 2017 14:54:42 GMT):
It's like that everywhere when u need it badly. :(
asaningmaxchain (Wed, 13 Dec 2017 14:55:05 GMT):
please wait a moment
asaningmaxchain (Wed, 13 Dec 2017 14:56:42 GMT):
the gist can't use any more?
asaningmaxchain (Wed, 13 Dec 2017 14:58:48 GMT):
https://pastebin.com/Wmd8tdYy
asaningmaxchain (Wed, 13 Dec 2017 14:59:45 GMT):
@jyellick @Vadim @Ashish can you take a look
Vadim (Wed, 13 Dec 2017 15:02:32 GMT):
@asaningmaxchain and what was in the log before that error came?
asaningmaxchain (Wed, 13 Dec 2017 15:03:02 GMT):
@Vadim i start the peer use the binary not by the docker
asaningmaxchain (Wed, 13 Dec 2017 15:03:02 GMT):
@Vadim i start the peer use the binary not by the docker,and i clear the log before the Instantiate operation
Vadim (Wed, 13 Dec 2017 15:03:13 GMT):
ah soooo
Vadim (Wed, 13 Dec 2017 15:03:20 GMT):
so this is devmode, right?
asaningmaxchain (Wed, 13 Dec 2017 15:03:32 GMT):
yes
asaningmaxchain (Wed, 13 Dec 2017 15:03:32 GMT):
yes
asaningmaxchain (Wed, 13 Dec 2017 15:04:00 GMT):
``` # There are 2 modes: "dev" and "net".
# In dev mode, user runs the chaincode after starting peer from
# command line on local machine.
# In net mode, peer will run chaincode in a docker container.
mode: dev```
asaningmaxchain (Wed, 13 Dec 2017 15:04:10 GMT):
i set the mode = dev
Vadim (Wed, 13 Dec 2017 15:04:30 GMT):
@asaningmaxchain I suppose you followed the tutorial? http://hyperledger-fabric.readthedocs.io/en/latest/chaincode4ade.html
Vadim (Wed, 13 Dec 2017 15:05:20 GMT):
http://hyperledger-fabric.readthedocs.io/en/latest/chaincode4ade.html?highlight=devmode#terminal-1-start-the-network to be precise
asaningmaxchain (Wed, 13 Dec 2017 15:10:29 GMT):
i think i should set the peer-chaincodedev parameter when peer starts
asaningmaxchain (Wed, 13 Dec 2017 15:12:18 GMT):
@Vadim @jyellick why the peer-chaincodedev option doesn't show in the sampleconfig/core.yaml?
asaningmaxchain (Wed, 13 Dec 2017 15:13:18 GMT):
@Vadim @jyellick viper.Set("chaincode.mode", chaincode.DevModeUserRunsChaincode)
asaningmaxchain (Wed, 13 Dec 2017 15:14:09 GMT):
i see the source code,it use just set the chaincode.mode option in the viper,so when i set the chaincode.mode = dev has the same effect
Ashish (Wed, 13 Dec 2017 15:39:38 GMT):
If it's dev mode, you should be able to build it successfully? With a go build command?
Ashish (Wed, 13 Dec 2017 15:39:38 GMT):
@asaningmaxchain If it's dev mode, you should be able to build it successfully? With a go build command?
Ashish (Wed, 13 Dec 2017 15:43:01 GMT):
And will it be possible to include some logger commands in the init function also?
asaningmaxchain (Wed, 13 Dec 2017 15:45:30 GMT):
the chaincode init function seems doesn't execute
asaningmaxchain (Wed, 13 Dec 2017 15:45:30 GMT):
the chaincode init function seems doesn't execute
asaningmaxchain (Wed, 13 Dec 2017 15:46:47 GMT):
@jyellick @Ashish https://pastebin.com/s8C540mu
asaningmaxchain (Wed, 13 Dec 2017 15:46:47 GMT):
@jyellick @Ashish https://pastebin.com/s8C540mu that's all the peer log
asaningmaxchain (Wed, 13 Dec 2017 15:46:47 GMT):
@jyellick @Ashish https://pastebin.com/s8C540mu that's all the peer info log
asaningmaxchain (Wed, 13 Dec 2017 15:53:16 GMT):
https://pastebin.com/5Sb8PKaQ it's debug log
Vadim (Wed, 13 Dec 2017 15:57:48 GMT):
@asaningmaxchain ```2017-12-13 23:41:18.454 CST [ConnProducer] NewConnection -> ERRO 039 Failed connecting to orderer.example.com:7050 , error: context deadline exceeded
Vadim (Wed, 13 Dec 2017 15:57:54 GMT):
is your orderer running?
asaningmaxchain (Wed, 13 Dec 2017 15:58:26 GMT):
yes
asaningmaxchain (Wed, 13 Dec 2017 15:58:39 GMT):
i set the orderer.example.com = localhost
asaningmaxchain (Wed, 13 Dec 2017 15:58:39 GMT):
i set the orderer.example.com = localhost,it still has the error,so i don't know why
Vadim (Wed, 13 Dec 2017 15:59:11 GMT):
did you see the logs? the peer cannot connect to the orderer
asaningmaxchain (Wed, 13 Dec 2017 15:59:33 GMT):
the orderer logs ?
Vadim (Wed, 13 Dec 2017 15:59:33 GMT):
where do you set that? [ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=ssmeuxvvGvGxsSbwP)
asaningmaxchain (Wed, 13 Dec 2017 15:59:47 GMT):
in the hosts file
asaningmaxchain (Wed, 13 Dec 2017 16:00:12 GMT):
i start the peer,orderer in binary mode not use docker
Vadim (Wed, 13 Dec 2017 16:00:40 GMT):
can you do `nc -zv orderer.example.com:7050`?
Vadim (Wed, 13 Dec 2017 16:00:40 GMT):
can you do `nc -zv orderer.example.com 7050`?
asaningmaxchain (Wed, 13 Dec 2017 16:01:00 GMT):
```root@chenxuan-ThinkPad-X240:/etc# more hosts
127.0.0.1 localhost
127.0.1.1 chenxuan-ThinkPad-X240
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
127.0.0.1 orderer.example.com
172.16.10.50 mctserver01
172.16.10.120 server
root@chenxuan-ThinkPad-X240:/etc# lsof -i:7050
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
___ordere 28962 root 3u IPv4 3272990 0t0 TCP localhost:7050 (LISTEN)```
asaningmaxchain (Wed, 13 Dec 2017 16:01:20 GMT):
it's ok
asaningmaxchain (Wed, 13 Dec 2017 16:01:20 GMT):
it's ok, when i execute the `nc -zv orderer.example.com 7050`
Vadim (Wed, 13 Dec 2017 16:01:41 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=8RoAi92THq7muwT7C)
asaningmaxchain (Wed, 13 Dec 2017 16:01:54 GMT):
root@chenxuan-ThinkPad-X240:/etc# nc -zv orderer.example.com 7050`
>
>
>
>
>
>
>
>
Vadim (Wed, 13 Dec 2017 16:02:07 GMT):
so no output?
asaningmaxchain (Wed, 13 Dec 2017 16:02:14 GMT):
no
asaningmaxchain (Wed, 13 Dec 2017 16:02:25 GMT):
no anything output
Vadim (Wed, 13 Dec 2017 16:03:03 GMT):
seems to be a problem, it should print "... is open"
asaningmaxchain (Wed, 13 Dec 2017 16:03:50 GMT):
but when i use the command `lsof -i:7050`
asaningmaxchain (Wed, 13 Dec 2017 16:03:50 GMT):
but when i use the command `lsof -i:7050` the orderer process is alive
Ashish (Wed, 13 Dec 2017 16:04:22 GMT):
:) Good. So we just have to get your peer to talk to orderer
asaningmaxchain (Wed, 13 Dec 2017 16:05:04 GMT):
so what's the problem? can you give me a clue ? @Ashish
Ashish (Wed, 13 Dec 2017 17:59:04 GMT):
How are u running Ur instantiation? U are referring to the Orderer in the command rite?
Ashish (Wed, 13 Dec 2017 18:23:59 GMT):
So if the hosts entry is working, then why is your peer still looking for orderer.example.com, I'm confused :(
asaningmaxchain (Thu, 14 Dec 2017 01:08:22 GMT):
@Ashish i don't understand,can you use simple english?
asaningmaxchain (Thu, 14 Dec 2017 01:49:18 GMT):
@Ashish @Vadim @jyellick i think it's a problem for the peer gossip service
asaningmaxchain (Thu, 14 Dec 2017 02:35:49 GMT):
@Ashish i use the java sdk to instantiate the chaincode
Ashish (Thu, 14 Dec 2017 02:38:08 GMT):
Ther you are adding Orderer to the channel object rite?
asaningmaxchain (Thu, 14 Dec 2017 02:38:18 GMT):
of course
Ashish (Thu, 14 Dec 2017 02:39:00 GMT):
And you are calling channel.initialize() also?
asaningmaxchain (Thu, 14 Dec 2017 02:39:17 GMT):
i paste my java source code
asaningmaxchain (Thu, 14 Dec 2017 02:39:17 GMT):
i paste my java source code,wait a moment
Ashish (Thu, 14 Dec 2017 02:39:23 GMT):
Okay
asaningmaxchain (Thu, 14 Dec 2017 02:40:25 GMT):
https://pastebin.com/XFUjgzbV
asaningmaxchain (Thu, 14 Dec 2017 06:44:11 GMT):
@Ashish @Vadim when the peer join the channel,the gossip should make connection with the orderer node,but it can't build the connection via the orderer node
asaningmaxchain (Thu, 14 Dec 2017 06:47:57 GMT):
@Ashish ```root@chenxuan-ThinkPad-X240:~# nc -zv orderer.example.com 7050
Connection to orderer.example.com 7050 port [tcp/*] succeeded!```
Vadim (Thu, 14 Dec 2017 08:03:02 GMT):
@asaningmaxchain found this, seems to be related to your problem: https://github.com/golang/go/issues/22846
asaningmaxchain (Thu, 14 Dec 2017 08:54:30 GMT):
@Vadim so i should start the go_dns container?
Vadim (Thu, 14 Dec 2017 08:55:18 GMT):
@asaningmaxchain as I understood, you should create /etc/nsswitch.conf with `hosts: files dns` in it
asaningmaxchain (Thu, 14 Dec 2017 09:02:15 GMT):
@Vadim i don't understand, can you give me more clue?
Vadim (Thu, 14 Dec 2017 09:03:12 GMT):
@asaningmaxchain create file: /etc/nsswitch.conf, open it, add there one line: `hosts: files dns`, save it, close it, try running your network again
asaningmaxchain (Thu, 14 Dec 2017 09:04:37 GMT):
should i restart the network?
Vadim (Thu, 14 Dec 2017 09:05:00 GMT):
which network? just restart your orderer and peer
asaningmaxchain (Thu, 14 Dec 2017 09:05:09 GMT):
ok, i try it
asaningmaxchain (Thu, 14 Dec 2017 09:07:46 GMT):
it still contain error
asaningmaxchain (Thu, 14 Dec 2017 09:07:48 GMT):
```2017-12-14 17:07:20.934 CST [chaincode] Launch -> ERRO 036 handler not found for chaincode test:1.0
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).sendReady```
Vadim (Thu, 14 Dec 2017 09:08:27 GMT):
@asaningmaxchain your error is different
Vadim (Thu, 14 Dec 2017 09:08:35 GMT):
this is a cause
Vadim (Thu, 14 Dec 2017 09:08:56 GMT):
maybe try to restart your computer... if that does not work, use localhost instead of orderer.example.com
asaningmaxchain (Thu, 14 Dec 2017 09:18:27 GMT):
i set the orderer.example.com to the localhost but it still has the error
Vadim (Thu, 14 Dec 2017 09:18:49 GMT):
in configtx.yaml too?
asaningmaxchain (Thu, 14 Dec 2017 09:19:22 GMT):
yes
Vadim (Thu, 14 Dec 2017 09:19:27 GMT):
by the way, why don't you use https://github.com/hyperledger/fabric-samples/tree/release/chaincode-docker-devmode?
asaningmaxchain (Thu, 14 Dec 2017 09:20:41 GMT):
i use the docker to start the peer/orderer but i want to debug
asaningmaxchain (Thu, 14 Dec 2017 09:20:41 GMT):
it use the docker to start the peer/orderer but i want to debug
asaningmaxchain (Thu, 14 Dec 2017 09:21:01 GMT):
so i start the peer/orderer in the dev tools
asaningmaxchain (Thu, 14 Dec 2017 09:24:10 GMT):
i have a simple question why the system chaincode doesn't start the docker container?
asaningmaxchain (Thu, 14 Dec 2017 09:24:24 GMT):
@Vadim @Ashish
Vadim (Thu, 14 Dec 2017 09:25:01 GMT):
@asaningmaxchain the simple answer is that it's caused by the fact that the peer cannot connect to the orderer
asaningmaxchain (Thu, 14 Dec 2017 09:28:50 GMT):
peer can get the block from the orderer,so i don't understand why the peer can't connect to the orderer？
Vadim (Thu, 14 Dec 2017 09:29:14 GMT):
@asaningmaxchain how does it get the block if it cannot connect?
asaningmaxchain (Thu, 14 Dec 2017 09:29:42 GMT):
you mean that when the peer startup,it doesn't need orderer,so when the scc
asaningmaxchain (Thu, 14 Dec 2017 09:29:42 GMT):
you mean that when the peer startup,it doesn't need orderer,so when the scc doesn't start the docker container,and when the peer wants to create the channel,it should be specified the orderer address
Vadim (Thu, 14 Dec 2017 09:31:07 GMT):
as I understand, when you instantiate a chaincode, it needs to receive the tx in a block, but there is no block so it fails to start the chaincode
Vadim (Thu, 14 Dec 2017 09:31:39 GMT):
I don't understand what you say
asaningmaxchain (Thu, 14 Dec 2017 09:31:56 GMT):
i got it
asaningmaxchain (Thu, 14 Dec 2017 09:31:56 GMT):
i got it,my english is bad,so wait a moment,i say it again,and i am trying https://github.com/hyperledger/fabric-samples/tree/release/chaincode-docker-devmode
asaningmaxchain (Thu, 14 Dec 2017 09:40:06 GMT):
https://pastebin.com/xvAuCY3d
asaningmaxchain (Thu, 14 Dec 2017 09:40:25 GMT):
i follow the step but i still meet the error
SergeySadon (Thu, 14 Dec 2017 11:28:17 GMT):
Has joined the channel.
asaningmaxchain (Thu, 14 Dec 2017 14:45:20 GMT):
@Vadim @Ashish i use the docker to start the orderer and peer,it's good
asaningmaxchain (Thu, 14 Dec 2017 15:54:50 GMT):
@Vadim @Ashish i use the java sdk to upgrade the chaincode,but i got the follow error
asaningmaxchain (Thu, 14 Dec 2017 15:55:56 GMT):
https://pastebin.com/xz2tyTX4
asaningmaxchain (Thu, 14 Dec 2017 15:56:10 GMT):
```root@a5c0f11fb319:/var/hyperledger/production/chaincodes# ll
total 16
drwxr-xr-x 2 root root 4096 Dec 14 15:31 ./
drwxr-xr-x 5 root root 4096 Dec 14 15:26 ../
-rw-r--r-- 1 root root 1868 Dec 14 15:28 test.1.1
-rw-r--r-- 1 root root 1868 Dec 14 15:31 test.2.0```
Ashish (Thu, 14 Dec 2017 16:52:49 GMT):
The log you have shared talks about chain code 'test' but it doesn't not talk about version. I hope you have specified that too
Ashish (Thu, 14 Dec 2017 16:53:22 GMT):
I mean during the upgrade call.
Ashish (Thu, 14 Dec 2017 16:59:58 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=EzmH5fgrctmAoGCnW) @Vadim Today I tested it with a 1of endorsement policy with only a Role.ADMIN peer in the network. You are rite. It's not able to get the signature from the peer with Admin affiliation. And endorsement failed at the peer while VSCC checked it.
Ashish (Thu, 14 Dec 2017 17:00:59 GMT):
Is this a bug? Is this still open in the 1.1.preview version too? Any idea?
jeffgarratt (Thu, 14 Dec 2017 17:47:03 GMT):
@Ashish you would need to change the signing cert for the peer to also be an ADMIN for the MSP in the channel which seems odd as a requirement
Ashish (Thu, 14 Dec 2017 19:04:39 GMT):
Would it be possible to tell me how please? as in, what to copy ,from where, and where to paste?
Ashish (Thu, 14 Dec 2017 19:04:39 GMT):
Thanks @jeffgarratt , but would it be possible to tell me how please? as in, what to copy ,from where, and where to paste?
jeffgarratt (Thu, 14 Dec 2017 20:18:18 GMT):
@Ashish this would need to be done in the channel config (via confixtgen config)
jeffgarratt (Thu, 14 Dec 2017 20:18:18 GMT):
@Ashish the channel admin cert would need to be copied to the peers $LOCAL_MSP_CONFIG_PATH/signcerts folder I believe
jeffgarratt (Thu, 14 Dec 2017 20:18:18 GMT):
@Ashish the channel admin cert would need to be copied to the peers $CORE_PEER_MSPCONFIGPATH/signcerts folder I believe
jeffgarratt (Thu, 14 Dec 2017 20:34:37 GMT):
as well as the private key would need to go to the peers $CORE_PEER_MSPCONFIGPATH/keystore folder
jeffgarratt (Thu, 14 Dec 2017 20:35:09 GMT):
this would effectively run your peer under the identity of your channel admin (which I would not recommend btw)
jeffgarratt (Thu, 14 Dec 2017 20:36:04 GMT):
or you could create a new cert for the private key you already have that is then placed into the channel ADMINS per the configtxgen mechanism
Ashish (Thu, 14 Dec 2017 20:57:07 GMT):
@jeffgarratt Thanks again Jeff, will give it a try
asaningmaxchain (Fri, 15 Dec 2017 00:30:45 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=A8869MuJMvy8D5Zj3) @Ashish but when i want to upgrade the chaincode,it tell me the error log
asaningmaxchain (Fri, 15 Dec 2017 00:30:45 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=A8869MuJMvy8D5Zj3) @Ashish but when i want to upgrade the chaincode,the chaincode name should be same,it tell me the error log
xmltiger (Fri, 15 Dec 2017 06:53:04 GMT):
Has joined the channel.
Ashish (Fri, 15 Dec 2017 13:26:35 GMT):
@asaningmaxchain correct. To be able to install you have to change the version and install. So if Ur first code is test.1 next version would be test.2.
Ashish (Fri, 15 Dec 2017 13:27:50 GMT):
Then after installing the new code you would upgrade.rite? While upgrading you have to mention the chaincode name as test and the version as 2 rite?
Ashish (Fri, 15 Dec 2017 13:27:59 GMT):
Have you done that too?
asaningmaxchain (Fri, 15 Dec 2017 14:39:53 GMT):
@Ashish i am certainty,i set the name which same as the previous and version is update
asaningmaxchain (Fri, 15 Dec 2017 14:47:06 GMT):
@jyellick @Ashish when the chaincode instantiate,i get the follow error
asaningmaxchain (Fri, 15 Dec 2017 14:47:09 GMT):
``` Failed to pull hyperledger/fabric-ccenv:x86_64-1.1.0-alpha-snapshot-2b428bf3: API error (404): {"message":"manifest for hyperledger/fabric-ccenv:x86_64-1.1.0-alpha-snapshot-2b428bf3 not found"}```
asaningmaxchain (Fri, 15 Dec 2017 14:48:31 GMT):
and then i use the docker images command get the following information
asaningmaxchain (Fri, 15 Dec 2017 14:48:31 GMT):
and then i use the docker images command get the following information,it doesn't has the ccenv images
Ashish (Fri, 15 Dec 2017 14:51:42 GMT):
Then u just have to make sure that you have internet connection. Then as the log indicate, docker would pull the x image
Vadim (Fri, 15 Dec 2017 14:51:42 GMT):
@asaningmaxchain `make docker` should build that image I believe
asaningmaxchain (Fri, 15 Dec 2017 14:51:58 GMT):
i remember i use the make docker
asaningmaxchain (Fri, 15 Dec 2017 14:51:58 GMT):
i remember i use the make docker,but i don't find the ccenv images
Vadim (Fri, 15 Dec 2017 14:52:17 GMT):
do it again
Ashish (Fri, 15 Dec 2017 14:53:46 GMT):
@Vadim for 1.1 preview we do have docker images rite? Not for this situation, this is for me to use
Vadim (Fri, 15 Dec 2017 14:54:07 GMT):
@Ashish yes, they are on dockerhub
asaningmaxchain (Fri, 15 Dec 2017 14:56:46 GMT):
@Vadim @Ashish i have a simple question,when the chaincode instantiate should set the chaincode endorser policy,but when one peer want to upgrade own chaincode,the other peer should sign the envelope ?
asaningmaxchain (Fri, 15 Dec 2017 14:56:46 GMT):
@Vadim @Ashish i have a simple question,when the chaincode instantiate should set the chaincode endorser policy,but when one peer want to upgrade own chaincode,the other peer should sign the envelope ?or what's the process of the upgrade
Vadim (Fri, 15 Dec 2017 14:58:02 GMT):
check http://hyperledger-fabric.readthedocs.io/en/latest/chaincode4noah.html#creating-the-package
asaningmaxchain (Fri, 15 Dec 2017 15:22:52 GMT):
@Vadim @Ashish thx very much
vdods (Sat, 16 Dec 2017 01:02:10 GMT):
Question regarding waiting for chaincode instantiation to complete: I've been encountering errors when instantiating chaincode and then immediately querying it -- say I upgrade an instantiated chaincode. If I query instantiated chaincodes immediately, the recently and successfully instantiated chaincode doesn't yet appear in the response. If I wait 20 seconds to query, it does show up. Is there an event I can listen for to be notified when the instantiation actually goes through? This sort of nondeterministic guess-waiting is not acceptable.
asaningmaxchain (Sat, 16 Dec 2017 01:06:05 GMT):
@vdods it exists the chaincode event
asaningmaxchain (Sat, 16 Dec 2017 01:06:05 GMT):
@vdods it exists the chaincode event,you can do it,i am doing it,because the chaincode instantiate is too long
vdods (Sat, 16 Dec 2017 01:09:25 GMT):
Which chaincode event? Do you have to define a custom one that fires at the end of the chaincode Init function?
asaningmaxchain (Sat, 16 Dec 2017 05:28:40 GMT):
the ccenv images disappear without reason @Vadim @Ashish @jeffgarratt
Ashish (Sat, 16 Dec 2017 05:50:58 GMT):
@vdods How are you upgrading/querying? Using an SDK? Or CLI?
Ashish (Sat, 16 Dec 2017 05:53:17 GMT):
@asaningmaxchain That's weird. Are u running a make everytime? Fabric Docker images once built, need not be rebuilt everytime. Are you sure you don't have another make command or a docker rmi command getting executed by mistake?
asaningmaxchain (Sat, 16 Dec 2017 05:54:29 GMT):
i am sure,i just want to instantiate chaincode by the java sdk and it tell me the error ```Failed to pull hyperledger/fabric-ccenv:x86_64-1.1.0-alpha-snapshot-2b428bf3: API error (404): {"message":"manifest for hyperledger/fabric-ccenv:x86_64-1.1.0-alpha-snapshot-2b428bf3 not found"}```
asaningmaxchain (Sat, 16 Dec 2017 05:54:51 GMT):
and then i use the docker images to look for,the ccenv image doesn't exists
asaningmaxchain (Sat, 16 Dec 2017 05:54:51 GMT):
and then i use the docker images to look for,the ccenv image doesn't exist
vdods (Sat, 16 Dec 2017 07:11:12 GMT):
@Ashish I'm upgrading using an SDK -- in particular, github.com/CognitionFoundry/gohfc
Ashish (Sat, 16 Dec 2017 10:12:46 GMT):
That sounds like a go SDK?
asaningmaxchain (Sat, 16 Dec 2017 15:04:16 GMT):
@Ashish @Vadim @jyellick i think the ChaincodeInfo which locate at the peer/query.proto should return the instantiation policy and endorser policy
vdods (Sun, 17 Dec 2017 00:17:31 GMT):
So it looks like might be an event one can listen for to be notified of the instantiation happening -- I'm seeing an event from chaincode "lscc", but it has no event name or payload (it looks like the Extension field of the peer.ChaincodeAction message is empty, which it looks like means there will be no event name or event payload.
vdods (Sun, 17 Dec 2017 00:17:31 GMT):
So it looks like might be an event one can listen for to be notified of the instantiation happening -- I'm seeing an event from chaincode "lscc", but it has no event name or payload (it looks like the Extension field of the peer.ChaincodeAction message is empty, which it looks like means there will be no event name or event payload).
vdods (Sun, 17 Dec 2017 00:27:57 GMT):
Can anyone confirm that this event from chaincode "lscc" does indeed indicate a successful instantiation? It seems like a bug that there's no indication of what the event is, such as "instantiation of chaincode XYZ version 1.2.3 successful" or something
vdods (Sun, 17 Dec 2017 00:28:32 GMT):
The peer.ChaincodeAction i'm getting is:
```(*peer.ChaincodeAction)(0xc420018f80)(response:
vdods (Sun, 17 Dec 2017 00:50:04 GMT):
Or -- is the payload within the response to be manually unmarshalled by the app?
vdods (Sun, 17 Dec 2017 00:50:23 GMT):
There's no clear documentation in the protos stating the format of the payload
muralisr (Sun, 17 Dec 2017 16:37:58 GMT):
@vdods the "lscc" RWSet is an internal one (part of the fabric chaincode metadata if you will) as opposed to user chaincode RWSet created as part of the instantiation. You shouldn't have to parse it...
vdods (Sun, 17 Dec 2017 19:18:16 GMT):
@muralisr The payload (in the ChaincodeAction) of the event is the RWSet?
vdods (Sun, 17 Dec 2017 19:18:50 GMT):
Regardless, does that event indicate that the instantiation has completed successfully?
muralisr (Sun, 17 Dec 2017 19:22:03 GMT):
actually its not the RWSet (meant to say the ChaincodeAction contains RWSet among other things). the "response" field contains the response to the instantiate from the LSCC
muralisr (Sun, 17 Dec 2017 19:22:03 GMT):
@vdods actually its not the RWSet (meant to say the ChaincodeAction contains RWSet among other things). the "response" field contains the response to the instantiate from the LSCC
muralisr (Sun, 17 Dec 2017 19:22:35 GMT):
and status: 200 implies the endorsemenf ot the instntiate proposal did complete successfully
wanghhao (Mon, 18 Dec 2017 10:06:26 GMT):
Has left the channel.
mzhk (Mon, 18 Dec 2017 13:09:15 GMT):
Has joined the channel.
asaningmaxchain (Mon, 18 Dec 2017 15:43:47 GMT):
@Ashish @Vadim i meet a problem,when i want to invoke a transaction,then i get the following error
asaningmaxchain (Mon, 18 Dec 2017 15:43:47 GMT):
@Ashish @Vadim i meet a problem,when i want to invoke a transaction,then i get the following error, can you take a look?
asaningmaxchain (Mon, 18 Dec 2017 15:45:51 GMT):
https://pastebin.com/VQ8hcGKC
asaningmaxchain (Mon, 18 Dec 2017 15:48:21 GMT):
@Ashish @Vadim another simple question is how can i get the lastest docker logs,i don't get the previous logs
rsherwood (Mon, 18 Dec 2017 17:19:55 GMT):
If a peer has been down and it starts up how will it determine that it is current ? Does it for example provide the order on startup with the last block number it has for each channel , or does the order send it the current channel block height, or does it wait for the next block to be delivered to know that it is missing blocks ?
vdods (Mon, 18 Dec 2017 19:40:33 GMT):
@muralisr Do you know what the type of the marshaled data in the response field is? Presumably it's something defined in a protobuf. I'd like to unmarshal it and examine the data, but there's no indication as to the type.
vdods (Mon, 18 Dec 2017 19:52:23 GMT):
Also, are chaincode and rejection events no longer a thing in v1.0.3? I'm calling stub.SetEvent in my successful invoke transactions, and getting nothing, and that's after registering interest in chaincode events with EventName: ".*" (also tried empty string)
vdods (Mon, 18 Dec 2017 19:53:24 GMT):
I'm also intentionally submitting a bad invoke transaction to test if transaction rejection events are being sent. I see no indication in the peer debug logs that those events are being sent, and no indication in my sdk logs that they're being received.
vdods (Mon, 18 Dec 2017 20:03:40 GMT):
Using EventName equal to the exact event name also doesn't work.
vdods (Mon, 18 Dec 2017 20:12:03 GMT):
I've heard that in Fabric 1.1, there will be only Block events... is this somehow already true for Fabric 1.0.x?
vdods (Mon, 18 Dec 2017 20:12:08 GMT):
I do receive block events.
jon_s (Tue, 19 Dec 2017 04:54:52 GMT):
Has left the channel.
Vadim (Tue, 19 Dec 2017 07:52:16 GMT):
@vdods technically, there are only block events in fabric v1.0 also, the SDKs parse blocks as they come, extract events and trigger listeners if any
Vadim (Tue, 19 Dec 2017 07:52:44 GMT):
for me, the events are working. How do you register your event listeners?
vdods (Tue, 19 Dec 2017 07:56:03 GMT):
Ok, that matches what the author of github.com/CognitionFoundry/gohfc has told me. I'm registering them via code like
```
creator, err := proto.Marshal(&msp.SerializedIdentity{
Mspid: mspId,
IdBytes: pem.EncodeToMemory(&pem.Block{Type: "CERTIFICATE", Bytes: identity.Certificate.Raw})})
if err != nil {
return err
}
interest := &peer.Event{
Event: &peer.Event_Register{
Register: &peer.Register{
Events: []*peer.Interest{
{
EventType: peer.EventType_BLOCK,
}, {
EventType: peer.EventType_CHAINCODE,
RegInfo: &peer.Interest_ChaincodeRegInfo{
ChaincodeRegInfo: &peer.ChaincodeReg{
ChaincodeId: "kvs", // TEMP HACK
EventName: "put", // TEMP HACK
},
},
},
{
EventType: peer.EventType_REJECTION,
},
Creator:creator,
}
evtBytes, err := proto.Marshal(interest)
if err != nil {
return err
}
sb, err := crypto.Sign(evtBytes, identity.PrivateKey)
if err != nil {
return err
}
sigEvent := peer.SignedEvent{EventBytes: evtBytes, Signature: sb}
if err = e.client.Send(&sigEvent); err != nil {
return err
}
return nil
Vadim (Tue, 19 Dec 2017 07:56:47 GMT):
@vdods ok, I'm not familiar with go sdk
vdods (Tue, 19 Dec 2017 07:57:35 GMT):
the gist is that I'm using the event interest registration API in github.com/hyperledger/fabric/protos/peer
vdods (Tue, 19 Dec 2017 07:59:18 GMT):
If block events are really the only thing, then I think that's fine for now. It sounds like the API is just not fully implemented (i.e. registering interest in types of events, possibly including a filter, in order to have minimal network comms regarding events)
vdods (Tue, 19 Dec 2017 07:59:33 GMT):
Thanks, @Vadim
Vadim (Tue, 19 Dec 2017 08:08:10 GMT):
@vdods that's a plan for future releases, there were some tasks in jira about it
zhishui (Tue, 19 Dec 2017 08:12:36 GMT):
Has joined the channel.
ankitkamra (Tue, 19 Dec 2017 11:05:01 GMT):
Has joined the channel.
asaningmaxchain (Tue, 19 Dec 2017 12:46:50 GMT):
@Ashish @Vadim i meet a problem,when i want to invoke a transaction,then i get the following error, can you take a look?
https://pastebin.com/VQ8hcGKC
@Ashish @Vadim another simple question is how can i get the lastest docker logs,i don't get the previous logs
ankitkamra (Tue, 19 Dec 2017 12:52:16 GMT):
@asaningmaxchain you can get docker logs using command:- docker logs
ankitkamra (Tue, 19 Dec 2017 12:52:16 GMT):
@asaningmaxchain you can get docker logs using command:- docker logs
mzhk (Wed, 20 Dec 2017 09:27:26 GMT):
Hi guys, we're experiencing the same issue as in https://jira.hyperledger.org/browse/FAB-3563 i.e. "This identity is not an admin" while trying to join the channel from fabric-cli container (it works from peers). Tried to use the admin identity as suggested in the ticket but still getting the same issue. Can someone suggest what else to check/verify?
mzhk (Wed, 20 Dec 2017 09:27:43 GMT):
(docker-compose part for fabric-cli)
mzhk (Wed, 20 Dec 2017 09:28:16 GMT):
```
cli:
extends:
file: base.yml
service: peer-base
image: "fabric-cli:${TAG}"
container_name: sth-fabric-cli
hostname: cli
environment:
- CORE_PEER_ID=cli
- CORE_PEER_ADDRESS=peer0.dummy.example.com:7051
- CORE_PEER_LOCALMSPID=DummyMSP
volumes:
- /etc/sth/fabric-artifacts/crypto-config:/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/
- /etc/sth/fabric-artifacts/channel-artifacts:/opt/gopath/src/github.com/hyperledger/fabric/peer/channel-artifacts
- /etc/sth/fabric-artifacts/crypto-config/peerOrganizations/dummy.example.com/users/Admin@dummy.example.com/msp:/etc/hyperledger/fabric/msp
- /etc/sth/fabric-artifacts/crypto-config/peerOrganizations/dummy.example.com/users/Admin@dummy.example.com/tls:/etc/hyperledger/fabric/tls
```
mzhk (Wed, 20 Dec 2017 09:28:47 GMT):
on fabric-cli env var `FABRIC_CFG_PATH=/etc/hyperledger/fabric`
mzhk (Wed, 20 Dec 2017 09:29:11 GMT):
( v1.0.5 )
Vadim (Wed, 20 Dec 2017 09:30:08 GMT):
@mzhk CORE_PEER_MSPCONFIGPATH=/etc/hyperledger/fabric/msp
mzhk (Wed, 20 Dec 2017 09:39:36 GMT):
@Vadim thanks, but i'm afraid it did not help. I retested with above suggestion and we also had that in previous layout that was used:
```
environment:
- CORE_PEER_ID=cli
- CORE_PEER_ADDRESS=peer0.dummy.example.com:7051
- CORE_PEER_LOCALMSPID=DummyMSP
- CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/dummy.example.com/users/Admin@dummy.example.com/msp
volumes:
- /etc/sth/fabric-artifacts/crypto-config:/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/
- /etc/sth/fabric-artifacts/channel-artifacts:/opt/gopath/src/github.com/hyperledger/fabric/peer/channel-artifacts
```
Vadim (Wed, 20 Dec 2017 09:40:04 GMT):
it says the identity is not an admin?
mzhk (Wed, 20 Dec 2017 09:41:09 GMT):
```
Error: proposal failed (err: rpc error: code = Unknown desc = chaincode error (status: 500, message: "JoinChain" request failed authorization check for channel [businesschannel]: [Failed verifying that proposal's creator satisfies local MSP principal during channelless check policy with policy [Admins]: [This identity is not an admin]]))
```
Vadim (Wed, 20 Dec 2017 09:42:06 GMT):
can you compare the cert in peer msp/admincerts directory with Admin@dummy.example.com cert?
mzhk (Wed, 20 Dec 2017 09:45:44 GMT):
```
root@cli:/go/src/github.com/hyperledger/fabric# md5sum peer/crypto/peerOrganizations/dummy.example.com/peers/peer0.dummy.example.com/msp/admincerts/Admin\@dummy.example.com-cert.pem
14242cf56f492dc8694f2445f76bf2a1 peer/crypto/peerOrganizations/dummy.example.com/peers/peer0.dummy.example.com/msp/admincerts/Admin@dummy.example.com-cert.pem
root@cli:/go/src/github.com/hyperledger/fabric# md5sum peer/crypto/peerOrganizations/dummy.example.com/users/Admin\@dummy.example.com/msp/admincerts/Admin\@dummy.example.com-cert.pem
14242cf56f492dc8694f2445f76bf2a1 peer/crypto/peerOrganizations/dummy.example.com/users/Admin@dummy.example.com/msp/admincerts/Admin@dummy.example.com-cert.pem
```
mzhk (Wed, 20 Dec 2017 09:46:12 GMT):
(those you meant?)
Vadim (Wed, 20 Dec 2017 09:49:19 GMT):
and on the peer itself which says identity is not an admin?
mzhk (Wed, 20 Dec 2017 09:57:21 GMT):
Ok, confused you a bit, sorry. It doesn't work on the peer as well with the admin user, before i used the default setting which we had, that use the "normal" user and this worked for joining the channel.
mzhk (Wed, 20 Dec 2017 09:57:33 GMT):
```
root@peer0:/go/src/github.com/hyperledger/fabric# md5sum /etc/hyperledger/fabric/admin/msp/admincerts/Admin\@dummy.example.com-cert.pem
14242cf56f492dc8694f2445f76bf2a1 /etc/hyperledger/fabric/admin/msp/admincerts/Admin@dummy.example.com-cert.pem
root@peer0:/go/src/github.com/hyperledger/fabric# md5sum /etc/hyperledger/fabric/msp/admincerts/User1\@dummy.example.com-cert.pem
3e5406bf65fdd943442197b616bec861 /etc/hyperledger/fabric/msp/admincerts/User1@dummy.example.com-cert.pem
```
mzhk (Wed, 20 Dec 2017 09:57:37 GMT):
(on the peer)
Vadim (Wed, 20 Dec 2017 09:58:18 GMT):
is there anything in /etc/hyperledger/fabric/admin/msp/admincerts?
Vadim (Wed, 20 Dec 2017 09:58:32 GMT):
ah, I see the number
Vadim (Wed, 20 Dec 2017 09:59:08 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=FsppxCA7mKwiWmEuM) btw the error message is from the peer, not from the cli
Vadim (Wed, 20 Dec 2017 09:59:18 GMT):
so you say it works with user1?
mzhk (Wed, 20 Dec 2017 09:59:28 GMT):
Yes.
Vadim (Wed, 20 Dec 2017 09:59:42 GMT):
ah so you have several users in msp/admincerts?
mzhk (Wed, 20 Dec 2017 10:01:17 GMT):
Hm, not really
mzhk (Wed, 20 Dec 2017 10:01:27 GMT):
```
oot@peer0:/go/src/github.com/hyperledger/fabric# ls -l /etc/hyperledger/fabric/admin/msp/admincerts/
total 4
-rw-r--r-x. 1 root root 794 Dec 20 09:36 Admin@dummy.example.com-cert.pem
root@peer0:/go/src/github.com/hyperledger/fabric# ls -l /etc/hyperledger/fabric/msp/admincerts/
total 4
-rw-r--r-x. 1 root root 790 Dec 20 09:36 User1@dummy.example.com-cert.pem
```
Vadim (Wed, 20 Dec 2017 10:03:13 GMT):
@mzhk I see your problem, in peer msp the cert User1@dummy.example.com-cert.pem is considered to be an admin cert
Vadim (Wed, 20 Dec 2017 10:04:20 GMT):
this "/etc/hyperledger/fabric/admin/msp/admincerts/" - I don't know what for, peer does not check that folder afaik
mzhk (Wed, 20 Dec 2017 10:06:58 GMT):
Yes, this is our custom, we map a "user certs" to `/etc/hyperledger/fabric/msp` and admin user certs to `/etc/hyperledger/fabric/admin/msp`, and switch the env var `FABRIC_CFG_PATH` if we need some "admin actions" in setup.
Vadim (Wed, 20 Dec 2017 10:07:40 GMT):
@mzhk peer treats admin user from msp/admincerts, and there you have User1
mzhk (Wed, 20 Dec 2017 10:08:32 GMT):
@Vadim ok, and msp/admincerts is relative to `FABRIC_CFG_PATH` right ?
Vadim (Wed, 20 Dec 2017 10:09:21 GMT):
for peer msp, the CORE_PEER_MSPCONFIGPATH is responsible
Vadim (Wed, 20 Dec 2017 10:09:40 GMT):
the local admin cert is in peer msp/admincerts
Vadim (Wed, 20 Dec 2017 10:09:54 GMT):
soo, FABRIC_CFG_PATH does not play a role in this
mzhk (Wed, 20 Dec 2017 10:10:19 GMT):
is it the same for fabric-cli ?
Vadim (Wed, 20 Dec 2017 10:11:19 GMT):
peer config has nothing to do with cli config...
mzhk (Wed, 20 Dec 2017 10:27:12 GMT):
@Vadim Hm, it's getting clearer now, i guess. The naming we have made it confusing.. can you please advise me here for a second still?
So if we create 2 users Name1 and Name2, then if we set one of those user's 'msp' dir in `CORE_PEER_MSPCONFIGPATH` then this user is only allowed to make actions on a peer?
Is there a way or even a case that we have 2 users configured simultaneously on a peer?
Are the 'actions' on a peer somehow being distinguished? That some can be done by admin and other by "normal" user? Or generally, whichever user's certs are configured in `CORE_PEER_MSPCONFIGPATH`, then that particular user is allowed to do all channel/chaincode actions on the peer?
Vadim (Wed, 20 Dec 2017 10:27:43 GMT):
you want to have 2 admin users on peer?
Vadim (Wed, 20 Dec 2017 10:28:01 GMT):
admins are needed to join/install chaincodes
Vadim (Wed, 20 Dec 2017 10:28:01 GMT):
admins are needed to join channels/install chaincodes
iamdm (Wed, 20 Dec 2017 10:29:13 GMT):
Has joined the channel.
Vadim (Wed, 20 Dec 2017 10:29:14 GMT):
CORE_PEER_MSPCONFIGPATH specifies path to local peer msp, from there peer will get its identity and identity of users which can do admin tasks
mzhk (Wed, 20 Dec 2017 10:30:33 GMT):
I want to have one admin and one normal user.
Vadim (Wed, 20 Dec 2017 10:32:05 GMT):
you just need admin, normal users are checked against the root org certs, they don't need to be added explicitly
mzhk (Wed, 20 Dec 2017 10:36:43 GMT):
So just to confirm, the users additional to admin (i.e. User1) generated with cryptogen, their certs don't need to end up on the peer at all ? Just the admin cert needs to be added so that it's defined who's the admin of that peer?
Vadim (Wed, 20 Dec 2017 10:46:26 GMT):
@mzhk that's right
iamdm (Wed, 20 Dec 2017 10:53:08 GMT):
Hi guys, have a question. When we add new org to channel, shall we change policy of instantiated cc in channel to get access new org to invoke it?
mzhk (Wed, 20 Dec 2017 10:54:11 GMT):
@Vadim thanks! That was very helpful!
mzhk (Wed, 20 Dec 2017 10:57:12 GMT):
@Vadim one last thing, is there somewhere some reference doc, where one can see what are the actions allowed only for admin user ?
Vadim (Wed, 20 Dec 2017 10:57:27 GMT):
not sure
Vadim (Wed, 20 Dec 2017 10:57:59 GMT):
thoughout the docs they mention when you need admin, but where it's summarized, I don't know
mzhk (Wed, 20 Dec 2017 11:07:32 GMT):
Ok, thanks!
navdevl (Wed, 20 Dec 2017 13:23:38 GMT):
Has joined the channel.
asaningmaxchain (Wed, 20 Dec 2017 14:55:39 GMT):
@Vadim @jyellick @C0rWin can you tell where the source code invoke the ```func (vscc *ValidatorOneValidSignature) Invoke(stub shim.ChaincodeStubInterface) pb.Response {``` method,becaus i got the follow error
asaningmaxchain (Wed, 20 Dec 2017 14:56:41 GMT):
```2017-12-20 14:24:39.546 UTC [vscc] Invoke -> ERRO 5c1 VSCC error: pProvider.NewPolicy failed, err Error unmarshaling to SignaturePolicy: proto: can't skip unknown wire type 6 for common.SignaturePolicyEnvelope
```
asaningmaxchain (Wed, 20 Dec 2017 14:58:51 GMT):
when i instantiate chaincode,i speified endorser policy
asaningmaxchain (Wed, 20 Dec 2017 14:58:51 GMT):
when i instantiate chaincode,i speified endorser policy,so who can tell me the how the args[2] pass
Vadim (Wed, 20 Dec 2017 15:01:48 GMT):
@asaningmaxchain https://github.com/hyperledger/fabric/blob/master/core/committer/txvalidator/validator.go#L843 [ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=LaWXiNbhkjDoJGGbW)
asaningmaxchain (Wed, 20 Dec 2017 15:05:43 GMT):
@Vadim thx
rahulhegde (Wed, 20 Dec 2017 15:49:24 GMT):
Reposting - @muralisr
Release: Fabric -1.0.4
Reference https://hyperledger-fabric.readthedocs.io/en/release/chaincode4noah.html#creating-the-package.
1. Specifying option `-S`, the chaincode will be signed using the localMSP to create a binary format signed CDS. Is there a way to lint or view this signed CDS? Can intruder retrieve a chaincode source from this CDS?
2. Will the Peer ensure the CDS is not tampered at the time of installation?
3. `-i` helps to specify the instantiation policy. However for test I changed to use ` "AND ('OrganizationMSP.member') "`. Chaincode instantiation fails if an OrganizationMSP's member user is used however passes if OrganizationMSP's admin user. Am I doing something incorrect? It looks now, it is using the Default Instantiation policy i.e. any authorized Organization's Admin user can perform Instantiation.
4: How do I change the instantiation policy set during chancode instantiation (the default policy)?
Thanks.
asaningmaxchain (Thu, 21 Dec 2017 06:12:45 GMT):
@Vadim @jyellick @Ashish when i use the java sdk to get the instantiated chaincode information,it should return the following data structure,however,i don't get the input args ```message ChaincodeInfo {
string name = 1;
string version = 2;
// the path as specified by the install/instantiate transaction
string path = 3;
// the chaincode function upon instantiation and its arguments. This will be
// blank if the query is returning information about installed chaincodes.
string input = 4;
// the name of the ESCC for this chaincode. This will be
// blank if the query is returning information about installed chaincodes.
string escc = 5;
// the name of the VSCC for this chaincode. This will be
// blank if the query is returning information about installed chaincodes.
string vscc = 6;
// the chaincode unique id.
// computed as: H(
// H(name || version) ||
// H(CodePackage)
// )
bytes id = 7;
}```
asaningmaxchain (Thu, 21 Dec 2017 06:21:28 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=ucsMxySTcvH6EqPZu) @Vadim i find the method ```txcc, vscc, policy, err := v.GetInfoForValidate(chdr.TxId, chdr.ChannelId, ns)``` which will get the policy about the application chaincode
varun-raj (Thu, 21 Dec 2017 10:29:21 GMT):
Has joined the channel.
prasadguru.r (Thu, 21 Dec 2017 13:46:43 GMT):
Has joined the channel.
prasadguru.r (Thu, 21 Dec 2017 13:46:57 GMT):
Hi
prasadguru.r (Thu, 21 Dec 2017 13:47:17 GMT):
Im trying to establish peer to peer connection from the private network
prasadguru.r (Thu, 21 Dec 2017 13:49:29 GMT):
I have established network in a mac machine and when im trying to establish peer to peer connection with another machine then i could not able to establish it. Handshake is not happening. is there any link or tutorial to fix
yacovm (Thu, 21 Dec 2017 13:49:52 GMT):
what do you mean "the handshake is not happening"
yacovm (Thu, 21 Dec 2017 13:49:58 GMT):
give more details
yacovm (Thu, 21 Dec 2017 13:50:02 GMT):
are you using TLS?
yacovm (Thu, 21 Dec 2017 13:50:13 GMT):
are you running in docker?
yacovm (Thu, 21 Dec 2017 13:50:33 GMT):
so the peers in 1 machine are running in docker, and on another machine are also running in docker?
prasadguru.r (Thu, 21 Dec 2017 13:53:00 GMT):
I mean,
prasadguru.r (Thu, 21 Dec 2017 13:54:58 GMT):
In Docker Container, If I add another peer for extend service, will someone from other machine who has composer-playground in it and valid participant card, Will they become participant in my business network??
yacovm (Thu, 21 Dec 2017 13:56:24 GMT):
hold on, before the peers
yacovm (Thu, 21 Dec 2017 13:56:29 GMT):
who runs the ordering service? Both machines?
yacovm (Thu, 21 Dec 2017 13:56:31 GMT):
or just 1?
prasadguru.r (Thu, 21 Dec 2017 13:56:43 GMT):
1 machine
prasadguru.r (Thu, 21 Dec 2017 13:58:21 GMT):
we are not using TLS and docker is running on both machine
prasadguru.r (Thu, 21 Dec 2017 13:58:57 GMT):
orderer service is available in business network admin machine
yacovm (Thu, 21 Dec 2017 13:59:23 GMT):
so you have 1 machine with an orderer and some peers
and another machine with only peers?
prasadguru.r (Thu, 21 Dec 2017 13:59:58 GMT):
yes...
yacovm (Thu, 21 Dec 2017 14:00:24 GMT):
oh... hm, so you basically need 2 ordering endpoints then
yacovm (Thu, 21 Dec 2017 14:00:36 GMT):
1 the internal endpoint (docker ip address)
yacovm (Thu, 21 Dec 2017 14:00:46 GMT):
1 the external ip of the machine, with port forwarding to the docker instance
yacovm (Thu, 21 Dec 2017 14:00:57 GMT):
these 2 endpoints - you put in the channel creation
yacovm (Thu, 21 Dec 2017 14:01:10 GMT):
and then when peers will try to connect to the orderer, they will try both and 1 of them would succeed ;)
prasadguru.r (Thu, 21 Dec 2017 14:02:09 GMT):
2 endpoints how to configure
prasadguru.r (Thu, 21 Dec 2017 14:02:16 GMT):
??
yacovm (Thu, 21 Dec 2017 14:02:40 GMT):
in the configtx.yaml
yacovm (Thu, 21 Dec 2017 14:04:29 GMT):
Clipboard - December 21, 2017 4:04 PM
yacovm (Thu, 21 Dec 2017 14:04:35 GMT):
see example ^
prasadguru.r (Thu, 21 Dec 2017 14:06:54 GMT):
Thanks,... I'm configuring
prasadguru.r (Thu, 21 Dec 2017 14:07:12 GMT):
can we talk in the call??
yacovm (Thu, 21 Dec 2017 14:07:35 GMT):
I'm not in the call
yacovm (Thu, 21 Dec 2017 14:07:54 GMT):
post here or in stack overflow
yacovm (Thu, 21 Dec 2017 14:07:59 GMT):
this way others can learn too
prasadguru.r (Thu, 21 Dec 2017 14:08:21 GMT):
Before to that, If I want to introduce one another machine in to the network I have to reconfigure this again??
prasadguru.r (Thu, 21 Dec 2017 14:08:29 GMT):
yea sure... Thanks
yacovm (Thu, 21 Dec 2017 14:08:31 GMT):
yes, every time
prasadguru.r (Thu, 21 Dec 2017 14:08:37 GMT):
Ok
prasadguru.r (Thu, 21 Dec 2017 14:12:53 GMT):
In my machine, on docker-compose.yml I have only one peer, and I name that peer1. Is that enough or I need to configure one another peer to respond when connect from other device with participant card
prasadguru.r (Thu, 21 Dec 2017 14:13:39 GMT):
vp1:
extends:
service: peer1
environment:
- CORE_PEER_ID=vp1
- CORE_PEER_DISCOVERY_ROOTNODE=peer1:30303
links:
- peer1
yacovm (Thu, 21 Dec 2017 14:13:46 GMT):
vp1???
yacovm (Thu, 21 Dec 2017 14:13:54 GMT):
discovery root node?
yacovm (Thu, 21 Dec 2017 14:13:57 GMT):
you're using... v0.6?
prasadguru.r (Thu, 21 Dec 2017 14:14:19 GMT):
just declaring another peer name as vp1
prasadguru.r (Thu, 21 Dec 2017 14:14:23 GMT):
it can be anything
yacovm (Thu, 21 Dec 2017 14:14:31 GMT):
but these environment variables are of version 0.6
yacovm (Thu, 21 Dec 2017 14:14:36 GMT):
not of v1.0
asaningmaxchain (Thu, 21 Dec 2017 14:14:42 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=LaWXiNbhkjDoJGGbW) @yacovm
asaningmaxchain (Thu, 21 Dec 2017 14:15:06 GMT):
```2017-12-20 14:24:39.546 UTC [vscc] Invoke -> ERRO 5c1 VSCC error: pProvider.NewPolicy failed, err Error unmarshaling to SignaturePolicy: proto: can't skip unknown wire type 6 for common.SignaturePolicyEnvelope
```
prasadguru.r (Thu, 21 Dec 2017 14:18:16 GMT):
@yacovm , ok I will check and reply you... Thank you
prasadguru.r (Thu, 21 Dec 2017 14:19:17 GMT):
I am trying the steps side by side..please give me some seconds
yacovm (Thu, 21 Dec 2017 14:20:48 GMT):
no no wait
prasadguru.r (Thu, 21 Dec 2017 14:21:03 GMT):
yes
yacovm (Thu, 21 Dec 2017 14:21:04 GMT):
if you're using v0.6 then these don't apply because you don't have an ordering service in v0.6
yacovm (Thu, 21 Dec 2017 14:21:21 GMT):
if you're using v0.6 then forget what I said and then install v1.0
prasadguru.r (Thu, 21 Dec 2017 14:21:38 GMT):
it's not version number VP1 is peer name
prasadguru.r (Thu, 21 Dec 2017 14:22:00 GMT):
which i set the name like VP1
yacovm (Thu, 21 Dec 2017 14:22:07 GMT):
> CORE_PEER_DISCOVERY_ROOTNODE
Who told you to use this string?
yacovm (Thu, 21 Dec 2017 14:22:11 GMT):
where did you see it
yacovm (Thu, 21 Dec 2017 14:22:15 GMT):
we don't have this in v1.0
prasadguru.r (Thu, 21 Dec 2017 14:23:47 GMT):
we referred this site - https://openblockchain.readthedocs.io/en/latest/Setup/Network-setup/
yacovm (Thu, 21 Dec 2017 14:24:09 GMT):
this is v0.6
yacovm (Thu, 21 Dec 2017 14:24:25 GMT):
read this https://hyperledger-fabric.readthedocs.io/en/latest/getting_started.html
prasadguru.r (Thu, 21 Dec 2017 14:25:40 GMT):
is this the latest version?
prasadguru.r (Thu, 21 Dec 2017 14:25:49 GMT):
so we are using old version?
prasadguru.r (Thu, 21 Dec 2017 14:29:07 GMT):
we have deployed a private chain in one machine. we want another machine to connect to private chain. this is our requirement
prasadguru.r (Thu, 21 Dec 2017 14:31:53 GMT):
Hi @yacovm
yacovm (Thu, 21 Dec 2017 14:32:01 GMT):
hi
prasadguru.r (Thu, 21 Dec 2017 14:34:23 GMT):
any working samples or configuration on the above would be helpful?
yacovm (Thu, 21 Dec 2017 14:35:11 GMT):
I haven't used v0.6 in more than a year and a half or so. I can't help you, sorry.
prasadguru.r (Thu, 21 Dec 2017 14:35:45 GMT):
ok . thanks
prasadguru.r (Thu, 21 Dec 2017 14:36:36 GMT):
can you suggest someone who can help?
yacovm (Thu, 21 Dec 2017 14:39:15 GMT):
unless you have a time machine, no.
yacovm (Thu, 21 Dec 2017 14:39:33 GMT):
look, I really recommend to just use 1.0
yacovm (Thu, 21 Dec 2017 14:39:36 GMT):
and drop 0.6
prasadguru.r (Thu, 21 Dec 2017 14:39:39 GMT):
we are using hyperledger composer(v0.16.2) to build with docker (v 17.09.1)
prasadguru.r (Thu, 21 Dec 2017 14:40:00 GMT):
what does v0.6 point to ?
yacovm (Thu, 21 Dec 2017 14:40:06 GMT):
a fabric version
prasadguru.r (Thu, 21 Dec 2017 14:41:36 GMT):
the tutorial points to v0.6, but we are using fabric v1.x
yacovm (Thu, 21 Dec 2017 14:42:24 GMT):
are you sure?
prasadguru.r (Thu, 21 Dec 2017 14:42:32 GMT):
our version v1.0.5
prasadguru.r (Thu, 21 Dec 2017 14:42:39 GMT):
to be precise
prasadguru.r (Thu, 21 Dec 2017 14:42:51 GMT):
yeah
yacovm (Thu, 21 Dec 2017 14:43:00 GMT):
how did you set an environment of v1.0.5 while using v0.6 documentation?
prasadguru.r (Thu, 21 Dec 2017 14:43:54 GMT):
we haven't set it yet. thats were we needed help
prasadguru.r (Thu, 21 Dec 2017 14:44:20 GMT):
:-)
yacovm (Thu, 21 Dec 2017 14:44:35 GMT):
oh ok then please start with reading https://hyperledger-fabric.readthedocs.io/en/release/
prasadguru.r (Thu, 21 Dec 2017 14:45:30 GMT):
thanks @yacovm :-)
asaningmaxchain (Thu, 21 Dec 2017 15:58:16 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=BMDZ3JAzytAXDjMKS) @guoger
guoger (Thu, 21 Dec 2017 16:02:49 GMT):
so the question is _where is vscc invoked_?
asaningmaxchain (Thu, 21 Dec 2017 16:04:31 GMT):
@guoger no the question is the when i invoke i got the error
asaningmaxchain (Thu, 21 Dec 2017 16:04:35 GMT):
```2017-12-20 14:24:39.546 UTC [vscc] Invoke -> ERRO 5c1 VSCC error: pProvider.NewPolicy failed, err Error unmarshaling to SignaturePolicy: proto: can't skip unknown wire type 6 for common.SignaturePolicyEnvelope```
guoger (Thu, 21 Dec 2017 16:14:57 GMT):
how did you hit this error exactly? pls remember to ask [smart questions](http://www.catb.org/esr/faqs/smart-questions.html).
asaningmaxchain (Fri, 22 Dec 2017 03:04:34 GMT):
@yacovm @Ashish @Vadim @C0rWin https://jira.hyperledger.org/browse/FAB-7545
guoger (Fri, 22 Dec 2017 03:05:48 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=n52pAHd24KGHqWoeS) @asaningmaxchain is it more appropriate to share this in #fabric-sdk-java ?
asaningmaxchain (Fri, 22 Dec 2017 03:06:22 GMT):
@guoger i did it
asaningmaxchain (Fri, 22 Dec 2017 03:06:22 GMT):
@guoger i did it,it's very easy to operate it,the peer also has the error log
guoger (Fri, 22 Dec 2017 03:12:40 GMT):
quickly skimmed your attachment in jira, does you orderer listen on localhost?
asaningmaxchain (Fri, 22 Dec 2017 03:13:10 GMT):
orderer listen?
asaningmaxchain (Fri, 22 Dec 2017 03:13:22 GMT):
the orderer node provide the event?
guoger (Fri, 22 Dec 2017 03:20:08 GMT):
I mean your components are running in docker, and you need to expose listening ports on local host, right?
asaningmaxchain (Fri, 22 Dec 2017 03:23:42 GMT):
yes
asaningmaxchain (Fri, 22 Dec 2017 03:35:17 GMT):
other operation is ok except chaincode invoke
prasadguru.r (Fri, 22 Dec 2017 06:46:22 GMT):
Hi
prasadguru.r (Fri, 22 Dec 2017 06:46:23 GMT):
We have established business network using hyperledger composer and created participant card by creating peers.
When we try to connect the peer in different machine in the local after importing participant card then I'm getting the following error
Error: Error trying login and get user Context. Error: Error trying to enroll user or load channel configuration. Error: Enrollment failed with errors [[{"code":400,"message":"Authorization failure"}]]
Business network is created in the mac machine and both machine are connected in the same wi-fi. Please help us to establish connection.
asaningmaxchain (Fri, 22 Dec 2017 06:53:00 GMT):
@prasadguru.r you can ask in #composer
prasadguru.r (Fri, 22 Dec 2017 06:56:41 GMT):
thanks
prasadguru.r (Fri, 22 Dec 2017 06:56:56 GMT):
im using fabic framework through composer
asaningmaxchain (Sat, 23 Dec 2017 05:19:44 GMT):
@yacovm @jyellick @Ashish @Vadim the chaincode install support the ```SignedChaincodeDeploymentSpec```
asaningmaxchain (Sat, 23 Dec 2017 05:19:44 GMT):
@yacovm @jyellick @Ashish @Vadim the chaincode install support the `SignedChaincodeDeploymentSpec`
asaningmaxchain (Sat, 23 Dec 2017 05:19:44 GMT):
@yacovm @jyellick @Ashish @Vadim the chaincode install support the `SignedChaincodeDeploymentSpec`?
asaningmaxchain (Sat, 23 Dec 2017 05:19:44 GMT):
@yacovm @jyellick @Ashish @Vadim the chaincode install support the `SignedChaincodeDeploymentSpec`? i want to upgrade the chaincode,the old chaincode container exists?
asaningmaxchain (Sun, 24 Dec 2017 02:07:19 GMT):
?
muralisr (Tue, 26 Dec 2017 01:25:53 GMT):
@asaningmaxchain hard to give any help with limited data... any logs from container, peer, debug information, how was the original instantiated before doing the upgrade ?
asaningmaxchain (Tue, 26 Dec 2017 06:47:28 GMT):
@muralisr i have resolve it
vsadriano (Tue, 26 Dec 2017 20:15:39 GMT):
Hi! How can I set log writer on hyperledger/fabric-couchdb? Can I use environments variables for this?
vsadriano (Tue, 26 Dec 2017 20:16:34 GMT):
I need to set this to see messages on my Graylog.
erdiD (Sun, 31 Dec 2017 12:04:31 GMT):
Has joined the channel.
sykesm (Tue, 02 Jan 2018 20:59:01 GMT):
Has joined the channel.
gen_el (Wed, 03 Jan 2018 16:32:50 GMT):
Has joined the channel.
gen_el (Wed, 03 Jan 2018 16:33:01 GMT):
Hello
gen_el (Wed, 03 Jan 2018 16:34:01 GMT):
How do i specify an endorsement policy such that only 1 peer of 1 org endorses a trxn. Currently all 4 peers (2 peers per org) in my network seem to endorsing transactions. That is not what i want.
tkuhrt (Wed, 03 Jan 2018 17:28:27 GMT):
@gen_el : http://hyperledger-fabric.readthedocs.io/en/latest/endorsement-policies.html -- the last example shows the endorsement policy you are most likely looking for.
gen_el (Wed, 03 Jan 2018 17:40:50 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=gha6jBosHDFcvxAtB) @tkuhrt Thank you for the reference.
gen_el (Wed, 03 Jan 2018 17:51:40 GMT):
@tkuhrt Is their a schema for the endorsement-policy file?
gen_el (Wed, 03 Jan 2018 17:51:40 GMT):
@tkuhrt Is there a documented schema for the endorsement-policy file?
gen_el (Wed, 03 Jan 2018 17:52:14 GMT):
@tkuhrt I need to understand the legit format of the rules in a .json policy file
gen_el (Wed, 03 Jan 2018 17:52:14 GMT):
@tkuhrt I need to understand the legit format of the rules, for a .json policy file
tkuhrt (Wed, 03 Jan 2018 18:53:39 GMT):
@gen_el : Looks like https://fabric-sdk-node.github.io/global.html#ChaincodeInstantiateUpgradeRequest__anchor example shows the JSON for what you are looking for. Also this might help: https://fabric-sdk-node.github.io/global.html#Policy__anchor
gen_el (Wed, 03 Jan 2018 22:09:31 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=8Ya5ZjtLvpPHqdpC3) @tkuhrt Thanks
jsrhome (Thu, 04 Jan 2018 03:22:19 GMT):
Has joined the channel.
tennenjl (Thu, 04 Jan 2018 04:06:27 GMT):
Has joined the channel.
pb (Thu, 04 Jan 2018 09:38:43 GMT):
Has joined the channel.
pb (Thu, 04 Jan 2018 09:39:21 GMT):
Found from a tutorial that endorsement policy is deployed along with chaincode. Can you please help to find out where the conditions to be satisfied for endorsement could be listed?
allonblocks21 (Thu, 04 Jan 2018 11:08:45 GMT):
Has joined the channel.
vdods (Fri, 05 Jan 2018 08:04:17 GMT):
Hi all, I'm getting an error while trying to enable TLS for peer-to-orderer communication for channel creation:
```+ peer channel create --orderer localhost:7050 --tls true --logging-level debug --channelID simple-channel --file channel-creation.tx
2018-01-04 23:56:11.382 PST [msp] GetLocalMSP -> DEBU 001 Returning existing local MSP
2018-01-04 23:56:11.382 PST [msp] GetDefaultSigningIdentity -> DEBU 002 Obtaining default signing identity
Error: grpc: no transport security set (use grpc.WithInsecure() explicitly or set credentials)
```
vdods (Fri, 05 Jan 2018 08:05:13 GMT):
I've tried a number of things, including explicitly exporting CORE_PEER_TLS_ROOTCERT_FILE to the file in tlscacerts obtained via enrollment with enrollment.profile tls
vdods (Fri, 05 Jan 2018 08:05:56 GMT):
I'm setting FABRIC_CFG_PATH and some other relevant env vars, and the channel creation works fine without the `--tls true` option.
vdods (Fri, 05 Jan 2018 08:21:38 GMT):
Is it necessary to have a core.yaml file when running the peer as a "client" for e.g. channel creation (i.e. not as a peer in a network)
vdods (Fri, 05 Jan 2018 08:21:38 GMT):
Is it necessary to have a core.yaml file when running the peer as a "client" for e.g. channel creation (i.e. not as a peer in a network)?
vdods (Fri, 05 Jan 2018 08:22:02 GMT):
I've been getting away with no core.yaml file and only setting a few env vars.
yacovm (Fri, 05 Jan 2018 08:24:40 GMT):
@vdods you forgot 1 flag...
yacovm (Fri, 05 Jan 2018 08:24:51 GMT):
--ca or something like that
yacovm (Fri, 05 Jan 2018 08:25:03 GMT):
do `peer channel --help` it will show
vdods (Fri, 05 Jan 2018 08:25:05 GMT):
`--work-perfectly true` ?
yacovm (Fri, 05 Jan 2018 08:25:16 GMT):
there is no such flag in fabric
vdods (Fri, 05 Jan 2018 08:25:26 GMT):
:)
yacovm (Fri, 05 Jan 2018 08:25:28 GMT):
that I know of
vdods (Fri, 05 Jan 2018 08:25:49 GMT):
ah --cafile
vdods (Fri, 05 Jan 2018 08:25:57 GMT):
Wow, I'm not sure how it worked without that before
vdods (Fri, 05 Jan 2018 08:26:23 GMT):
Is that supposed to specify the TLS CA cert?
yacovm (Fri, 05 Jan 2018 08:26:27 GMT):
yes
yacovm (Fri, 05 Jan 2018 08:26:33 GMT):
and now we have mutual TLS too in v1.1
vdods (Fri, 05 Jan 2018 08:26:39 GMT):
Ah ok, that was super unclear in the --help message
yacovm (Fri, 05 Jan 2018 08:26:41 GMT):
so we have more flags that you can forget and be confused
vdods (Fri, 05 Jan 2018 08:26:45 GMT):
haha
vdods (Fri, 05 Jan 2018 08:27:16 GMT):
I'm hoping the proposed split of the peer binary into peer-client and peer-server (or whatever they'll be called) will fix this all up
vdods (Fri, 05 Jan 2018 08:27:25 GMT):
Thanks @yacovm
vdods (Fri, 05 Jan 2018 08:44:47 GMT):
@yacovm I'm now getting `transport: authentication handshake failed: x509: certificate signed by unknown authority` -- I think it may have to do with the fact that I have an intermediate CA below the root CA. Is it possible to specify a cert chain as the argument to --cafile, or otherwise specify intermediate CAs?
vdods (Fri, 05 Jan 2018 08:45:18 GMT):
I guess the help message does say "certificate(s)"
vdods (Fri, 05 Jan 2018 08:50:35 GMT):
Though that should only be trusted root CA certs, not intermediates. The connecting client shouldn't have to provide the cert chain to verify the server's cert.
yacovm (Fri, 05 Jan 2018 08:54:00 GMT):
Try to put a concatenated PEM
yacovm (Fri, 05 Jan 2018 08:54:39 GMT):
Or just the intermediate cert
vdods (Fri, 05 Jan 2018 08:56:22 GMT):
Is that right though? The connecting peer shouldn't need to know the intermediate CA details?
vdods (Fri, 05 Jan 2018 08:56:22 GMT):
Is that right though? The connecting peer shouldn't need to know the intermediate CA details.
vdods (Fri, 05 Jan 2018 08:57:14 GMT):
Like say the orderer org restructures their intermediate CAs, but keeps the same root CA. The peer would then need to have updated intermediate CA certs
vdods (Fri, 05 Jan 2018 09:03:39 GMT):
Oh, perhaps the orderer itself should use a cert chain for its cert?
yacovm (Fri, 05 Jan 2018 09:47:18 GMT):
You are validatong the orderer
yacovm (Fri, 05 Jan 2018 09:47:24 GMT):
*validating
yacovm (Fri, 05 Jan 2018 09:47:38 GMT):
It sends the entire chain i think
yacovm (Fri, 05 Jan 2018 09:48:01 GMT):
Thouh not sure
vdods (Sat, 06 Jan 2018 00:33:47 GMT):
@yacovm Hmm.. I think it probably doesn't. I added another --cafile flag with the intermediate CA cert, and that worked. But, I noticed that in my orderer.yaml, there's no specification of the cert chain like there is in fabric-ca-server-config.yaml (via ca.chainfile)
vdods (Sat, 06 Jan 2018 00:34:04 GMT):
Is there actually an option in orderer.yaml (perhaps not having a default value) for specifying the chain?
vdods (Sat, 06 Jan 2018 02:02:49 GMT):
Setting the orderer cert to the chain (in orderer cert, intermediate CA cert, root CA cert order) works for the channel creation.
vdods (Sat, 06 Jan 2018 02:04:33 GMT):
However, I'm having trouble with `peer channel join` in an odd way where neither the orderer nor the peer seem to be connected to (again, the TLS-disabled versions of these commands have been working fine)
```+ peer channel join --blockpath generated-artifacts/channel-creation/simple-channel/simple-channel.block --logging-level debug --orderer localhost:7050 --tls true --cafile generated-artifacts/orgs/org0/fabric-ca-clients/peer0-admin/tls/tlscacerts/localhost-7054.pem
2018-01-05 18:03:37.025 PST [msp] GetLocalMSP -> DEBU 001 Returning existing local MSP
2018-01-05 18:03:37.025 PST [msp] GetDefaultSigningIdentity -> DEBU 002 Obtaining default signing identity
2018-01-05 18:03:37.025 PST [channelCmd] InitCmdFactory -> INFO 003 Endorser and orderer connections initialized
2018-01-05 18:03:37.025 PST [grpc] Printf -> DEBU 004 transport: http2Client.notifyError got notified that the client transport was broken unexpected EOF.
2018-01-05 18:03:37.025 PST [msp/identity] Sign -> DEBU 005 Sign: plaintext: 0AB7080A5B08011A0B08F9DCC0D20510...6BA97659E4A61A080A000A000A000A00
2018-01-05 18:03:37.025 PST [msp/identity] Sign -> DEBU 006 Sign: digest: FA4288A49E6DE48130D1F3C06819E5D2ABCCD0744F0A1521249A7F67701E6B22
2018-01-05 18:03:37.025 PST [grpc] Printf -> DEBU 007 transport: http2Client.notifyError got notified that the client transport was broken read tcp 127.0.0.1:41572->127.0.0.1:7051: read: connection reset by peer.
Error: proposal failed (err: rpc error: code = Internal desc = transport: write tcp 127.0.0.1:41572->127.0.0.1:7051: write: broken pipe)
2018-01-05 18:03:37.025 PST [grpc] Printf -> DEBU 008 transport: http2Client.notifyError got notified that the client transport was broken read tcp 127.0.0.1:41574->127.0.0.1:7051: read: connection reset by peer.
2018-01-05 18:03:37.026 PST [grpc] Printf -> DEBU 009 transport: http2Client.notifyError got notified that the client transport was broken unexpected EOF.
```
vdods (Sat, 06 Jan 2018 05:57:31 GMT):
Ok, I did some log analysis and code diving, and `peer channel join` doesn't even attempt to use TLS in its GRPC connection, even though the --tls and --cafile options are ostensibly applicable to all commands under `peer channel`. This is clearly wrong, as a TLS-enabled peer will only accept TLS-enabled connections. I think this may be an issue of no one actually ever testing the CLI `peer channel join` with TLS enabled.
vdods (Sat, 06 Jan 2018 06:14:51 GMT):
My guess is that everyone running with TLS enabled uses an SDK to make peers join or list channels.
vdods (Sat, 06 Jan 2018 06:48:05 GMT):
Ok -- using `CORE_PEER_TLS_ENABLED=true` and `CORE_PEER_TLS_ROOTCERT_FILE=path/to/cert` works
vdods (Sat, 06 Jan 2018 06:48:22 GMT):
I've filed a bug https://jira.hyperledger.org/browse/FAB-7630 -- @yacovm Who would be appropriate to assign this to?
yacovm (Sat, 06 Jan 2018 08:19:46 GMT):
@vo
yacovm (Sat, 06 Jan 2018 08:20:49 GMT):
@vdods if peer channel join doesn't use TLS then our integration tests won't pass as the peers use TLS there...
vdods (Sat, 06 Jan 2018 08:23:02 GMT):
Right, they must be using the env vars CORE_PEER_TLS_ENABLED and CORE_PEER_TLS_ROOTCERT_FILE to make that happen, and not the --tls and --cafile commandline options
yacovm (Sat, 06 Jan 2018 08:23:42 GMT):
oh.. hehehe I see the confusion
yacovm (Sat, 06 Jan 2018 08:23:53 GMT):
so the CLI flags --tls, --cafile
yacovm (Sat, 06 Jan 2018 08:24:00 GMT):
they control the orderer's TLS config
yacovm (Sat, 06 Jan 2018 08:24:11 GMT):
the CORE_PEER_* environment variables control the peer
vdods (Sat, 06 Jan 2018 08:24:16 GMT):
Yep
yacovm (Sat, 06 Jan 2018 08:24:25 GMT):
so... that's not a bug
vdods (Sat, 06 Jan 2018 08:24:43 GMT):
Well, if it's not a bug, then the --help message is super misleading
vdods (Sat, 06 Jan 2018 08:25:11 GMT):
I guess it does mention orderer in the help message
yacovm (Sat, 06 Jan 2018 08:25:12 GMT):
it could be. what does it say?
vdods (Sat, 06 Jan 2018 08:26:11 GMT):
Perhaps what's misleading is that the --tls and --cafile options are available for all `peer channel` subcommands, and not just `peer channel create` and `peer channel update`
vdods (Sat, 06 Jan 2018 08:26:39 GMT):
If an option has no effect on a particular subcommand, it shouldn't be available to that subcommand.
yacovm (Sat, 06 Jan 2018 08:28:56 GMT):
oh I see
yacovm (Sat, 06 Jan 2018 08:28:58 GMT):
you're right
vdods (Sat, 06 Jan 2018 08:29:41 GMT):
I think this confusion also stems from the overall confusion over the peer binary acting as a server and a client, and the configuration thereof being correspondingly confusing and entangled.
yacovm (Sat, 06 Jan 2018 08:30:34 GMT):
I don't know where it stems from
yacovm (Sat, 06 Jan 2018 08:31:15 GMT):
I guess you can file an `improvement` (not a bug) JIRA to have these commands now shown in the help of all but `channel create / update`
vdods (Sat, 06 Jan 2018 08:53:26 GMT):
Hmm.. ok
vdods (Sat, 06 Jan 2018 20:57:26 GMT):
I've managed to set everything up, and in one of my orgs I've got 2 peers -- the non-anchor peer has the anchor peer's address as its peer.gossip.bootstrap address. Both peers max out their CPU usage, with the logs repeating messages like the following:
```2018-01-06 12:50:36.219 PST [policies] GetPolicy -> DEBU 40f Returning policy Application/Readers for evaluation
2018-01-06 12:50:36.219 PST [cauthdsl] func1 -> DEBU 410 0xc42241e0a0 gate 1515271836219355929 evaluation starts
2018-01-06 12:50:36.219 PST [cauthdsl] func2 -> DEBU 411 0xc42241e0a0 signed by 0 principal evaluation starts (used [false])
2018-01-06 12:50:36.219 PST [cauthdsl] func2 -> DEBU 412 0xc42241e0a0 processing identity 0 with bytes of 0a076f7267304d535012a2072d2d2d2d2d424547494e202d2d2d2d2d0a4d4949436b7a4343416657674177494241674955566c345a30737a3649526b3970484d6468625972482b2b2f5a377377436759494b6f5a497a6a3045417751770a6654454c4d416b474131554542684d4356564d78437a414a42674e564241674d416b4e424d524977454159445651514b44416c58623256695a576476626d55780a4854416242674e564241734d464739795a7a4167535735305a584a745a5752705958526c49454e424d524977454159445651514444416c7362324e68624768760a63335178476a415942676b71686b6947397730424351455743324e68514739795a7a4175593239744d423458445445344d4445774e6a49774e4455774d466f580a445445354d4445774e6a49774e4455774d466f775854454c4d416b474131554542684d4356564d78467a415642674e5642416754446b3576636e526f49454e680a636d3973615735684d525177456759445651514b457774496558426c636d786c5a47646c636a45504d4130474131554543784d47526d4669636d6c6a4d5134770a4441594456515144457756775a5756794d54425a4d424d4742797147534d34394167454743437147534d343941774548413049414241777469536742694551480a4f664a476b476e5470434a574c43327a684a527161655a37626876637a466161385331356a526e734f3266707948654f4b5669367077593532745a4c504643670a53494330796b4e72474c4f6a637a42784d41344741315564447745422f775145417749486744414d42674e5648524d4241663845416a41414d423047413155640a4467515742425358644c4831652b536d627a7557304535456e6243336e35386a4d44416642674e5648534d45474441576742517a4e704f596e2b617a532f39490a6e497673513934524243497a5454415242674e5648524545436a414967675a7a6257467a61486b77436759494b6f5a497a6a304541775144675973414d4947480a416b456850626374523757364b7662357536496852514d596145436e6d476c6d7a614c6872356a526a3237766a702f4b425342427577687a384b2f68377a784c0a59304d646436776a6a69626e597642687041782b4e71526b61674a43414a6b763955354d714b345873645859382f70485970484b527945355a536e524465554c0a79475151774b7856417a694a38476a4745625a5168506b63343677456c7a4e5a6d367859626c6c7153746c32387557356c6e2b4c0a2d2d2d2d2d454e44202d2d2d2d2d0a
2018-01-06 12:50:36.285 PST [cauthdsl] func2 -> DEBU 413 0xc42241e0a0 principal matched by identity 0
2018-01-06 12:50:36.285 PST [cauthdsl] func2 -> DEBU 414 0xc42241e0a0 principal evaluation succeeds for identity 0
2018-01-06 12:50:36.285 PST [cauthdsl] func1 -> DEBU 415 0xc42241e0a0 gate 1515271836219355929 evaluation succeeds
```
vdods (Sat, 06 Jan 2018 20:58:23 GMT):
Note that zero transactions have been made on the channel -- this is just after having the peers join the channel
vdods (Sat, 06 Jan 2018 21:00:09 GMT):
If I change the peer.gossip.bootstrap address for each peer to point to itself, then the CPU usage is more reasonable (2-4%, though this still seems excessive for a process that is ostensibly doing nothing), but presumably the peers will not gossip blocks back and forth.
yacovm (Sat, 06 Jan 2018 21:21:53 GMT):
@vdods turn of the gossip logging too
yacovm (Sat, 06 Jan 2018 21:22:01 GMT):
For debug
yacovm (Sat, 06 Jan 2018 21:22:12 GMT):
How many CPUs do you have?
vdods (Sat, 06 Jan 2018 21:22:13 GMT):
I tried that, but the CPU usage is still really high
vdods (Sat, 06 Jan 2018 21:22:18 GMT):
8 logical cores
yacovm (Sat, 06 Jan 2018 21:22:34 GMT):
What, how ia that possible that they are maxed
vdods (Sat, 06 Jan 2018 21:22:51 GMT):
Not pinned exactly at 100%, but it varies from 60% - 90%+
yacovm (Sat, 06 Jan 2018 21:22:59 GMT):
:dizzy_face:
vdods (Sat, 06 Jan 2018 21:23:15 GMT):
considering that the peers are handling no transactions or new blocks to gossip, that seems rather high
yacovm (Sat, 06 Jan 2018 21:23:18 GMT):
Gossip logs at debug please
vdods (Sat, 06 Jan 2018 21:23:49 GMT):
Let's see.. I'll need to attach a file, since it's really log
vdods (Sat, 06 Jan 2018 21:23:51 GMT):
*long
yacovm (Sat, 06 Jan 2018 21:24:04 GMT):
What is the frequency of these lines you posted?
vdods (Sat, 06 Jan 2018 21:26:38 GMT):
log
vdods (Sat, 06 Jan 2018 21:27:30 GMT):
the cauthdsl debug messages appear about every 2 seconds
vdods (Sat, 06 Jan 2018 21:27:59 GMT):
BTW, I'm running on v1.0.5
yacovm (Sat, 06 Jan 2018 21:28:10 GMT):
Can you upload to pastebin? Cant open from the phone
vdods (Sat, 06 Jan 2018 21:28:16 GMT):
Ah, ok
vdods (Sat, 06 Jan 2018 21:31:40 GMT):
https://pastebin.com/hWnFRaf0
vdods (Sat, 06 Jan 2018 21:32:16 GMT):
I pasted only about 550 lines of it, due to storage limitations on pastebin.
vdods (Sat, 06 Jan 2018 21:32:48 GMT):
Deleted the 3MB log I uploaded to RocketChat.
yacovm (Sat, 06 Jan 2018 21:33:43 GMT):
Lets do an experiment, ok?
vdods (Sat, 06 Jan 2018 21:33:48 GMT):
Sure
yacovm (Sat, 06 Jan 2018 21:33:57 GMT):
Go to core.yaml and to the gossip section
vdods (Sat, 06 Jan 2018 21:34:03 GMT):
Thanks in advance for your help, btw!
yacovm (Sat, 06 Jan 2018 21:34:09 GMT):
You will see there several times
yacovm (Sat, 06 Jan 2018 21:34:21 GMT):
Something like aliveInterval
vdods (Sat, 06 Jan 2018 21:34:26 GMT):
ok
yacovm (Sat, 06 Jan 2018 21:34:30 GMT):
And pull interval
vdods (Sat, 06 Jan 2018 21:34:38 GMT):
aliveTimeInterval: 5s
vdods (Sat, 06 Jan 2018 21:34:52 GMT):
pullInterval: 4s
yacovm (Sat, 06 Jan 2018 21:34:53 GMT):
What else? What other times are there?
vdods (Sat, 06 Jan 2018 21:36:00 GMT):
maxPropagationBurstLatency: 10ms, requestStateInfoInterval: 4s, publishStateInfoInterval: 4s, publishCertPeriod: 10s, digestWaitTime: 1s, requestWaitTime: 1s, responseWaitTime: 2s, reconnectInterval: 25s
vdods (Sat, 06 Jan 2018 21:36:14 GMT):
There are a few others, but they seemed less relevant to the gossip process than this problem suggests
yacovm (Sat, 06 Jan 2018 21:38:18 GMT):
Try to raise requestStateInfoInterval to 10s . Are you using docker?
vdods (Sat, 06 Jan 2018 21:39:19 GMT):
No, I'm running each service as a daemon process with a monitoring service
yacovm (Sat, 06 Jan 2018 21:39:36 GMT):
Oh ok
yacovm (Sat, 06 Jan 2018 21:39:44 GMT):
So change just in core.yaml
yacovm (Sat, 06 Jan 2018 21:39:49 GMT):
And resfart
yacovm (Sat, 06 Jan 2018 21:39:49 GMT):
And restart
vdods (Sat, 06 Jan 2018 21:39:50 GMT):
Ok
yacovm (Sat, 06 Jan 2018 21:39:53 GMT):
Restart
vdods (Sat, 06 Jan 2018 21:43:35 GMT):
That didn't seem to appreciably change the CPU usage
yacovm (Sat, 06 Jan 2018 21:43:54 GMT):
Thats great
vdods (Sat, 06 Jan 2018 21:44:20 GMT):
What was the expected result?
yacovm (Sat, 06 Jan 2018 21:44:28 GMT):
Now try for the aliveMessageInterval - turn it twice as big
vdods (Sat, 06 Jan 2018 21:44:33 GMT):
ok
yacovm (Sat, 06 Jan 2018 21:46:05 GMT):
Wait, is one of the peers perhaps behind?
yacovm (Sat, 06 Jan 2018 21:46:09 GMT):
In ledger height
yacovm (Sat, 06 Jan 2018 21:46:20 GMT):
Do they have the same height?
vdods (Sat, 06 Jan 2018 21:47:48 GMT):
Hmm.. is there an easy way, say with a peer CLI command, to check that? Or does it show up in the logs
vdods (Sat, 06 Jan 2018 21:48:12 GMT):
Btw -- changing aliveTimeInterval from 5s to 10s slightly reduced the CPU usage.. to about a range of 40-80%
yacovm (Sat, 06 Jan 2018 21:48:41 GMT):
It shows im the logs
yacovm (Sat, 06 Jan 2018 21:49:02 GMT):
Grep for StateInfo or stateInfo
vdods (Sat, 06 Jan 2018 21:50:16 GMT):
`2018-01-06 13:17:00.418 PST [gossip/gossip] handleMessage -> DEBU 27d2 Entering, 127.0.0.1:55946 [213 186 80 212 212 11 160 87 223 32 129 26 216 126 206 170 206 6 80 138 61 138 224 126 45 32 149 34 19 131 199 214] sent us GossipMessage: Channel: simple-channel, nonce: 0, tag: CHAN_OR_ORG StateInfoSnapshot with 2 items, Envelope: 387 bytes, Signature: 0 bytes
`
vdods (Sat, 06 Jan 2018 21:50:16 GMT):
`2018-01-06 13:17:00.418 PST [gossip/gossip] handleMessage -> DEBU 27d2 Entering, 127.0.0.1:55946 [213 186 80 212 212 11 160 87 223 32 129 26 216 126 206 170 206 6 80 138 61 138 224 126 45 32 149 34 19 131 199 214] sent us GossipMessage: Channel: simple-channel, nonce: 0, tag: CHAN_OR_ORG StateInfoSnapshot with 2 items, Envelope: 387 bytes, Signature: 0 bytes`
yacovm (Sat, 06 Jan 2018 21:50:41 GMT):
No, i need stateInfo
yacovm (Sat, 06 Jan 2018 21:50:50 GMT):
Without stapshot
yacovm (Sat, 06 Jan 2018 21:51:00 GMT):
Nothing like that?
vdods (Sat, 06 Jan 2018 21:51:34 GMT):
Nope, that's the only occurrence of StateInfo (case insensitive grep)
yacovm (Sat, 06 Jan 2018 21:52:29 GMT):
Thats impossible :confused: but you can see of they send each other blocks
yacovm (Sat, 06 Jan 2018 21:52:35 GMT):
*if
yacovm (Sat, 06 Jan 2018 21:53:09 GMT):
Can you upload the full log file? i'll take a look
vdods (Sat, 06 Jan 2018 21:53:10 GMT):
All the debug log levels are at debug, except msp, which is at warning
vdods (Sat, 06 Jan 2018 21:53:24 GMT):
Upload here? Or elsewhere?
yacovm (Sat, 06 Jan 2018 21:53:28 GMT):
Here
vdods (Sat, 06 Jan 2018 21:53:37 GMT):
Ok
vdods (Sat, 06 Jan 2018 21:54:18 GMT):
I'm going to truncate it, since most of it will be redundant looping messages
vdods (Sat, 06 Jan 2018 21:56:51 GMT):
log.txt
vdods (Sat, 06 Jan 2018 21:56:51 GMT):
log.txt
yacovm (Sat, 06 Jan 2018 21:59:23 GMT):
`[36m2018-01-06 13:46:48.133 PST [gossip/comm] sendToEndpoint -> DEBU 582[0m Entering, Sending to localhost:7151 , msg: GossipMessage: channel:"simple-channel" tag:CHAN_AND_ORG hello:
yacovm (Sat, 06 Jan 2018 21:59:40 GMT):
they are sending blocks to each other...
yacovm (Sat, 06 Jan 2018 22:00:36 GMT):
oh wait
yacovm (Sat, 06 Jan 2018 22:00:42 GMT):
sorry, that's not a block
vdods (Sat, 06 Jan 2018 22:01:06 GMT):
That's no moon.. that's a space station!
yacovm (Sat, 06 Jan 2018 22:04:35 GMT):
wait a second
yacovm (Sat, 06 Jan 2018 22:04:44 GMT):
`[gossip/gossip] handleMessage -> DEBU 39a[0m Entering, 127.0.0.1:56962`
yacovm (Sat, 06 Jan 2018 22:04:52 GMT):
what's this? why is the remote ip localhost?
yacovm (Sat, 06 Jan 2018 22:05:31 GMT):
`authenticateRemotePeer -> DEBU 35f[0m Authenticated 127.0.0.1:56960`
vdods (Sat, 06 Jan 2018 22:05:34 GMT):
I'm hosting all the peers on my own machine for now.. I need to make sure all the TLS config, peer behavior (especially regarding CPU usage), etc is good before I deploy to the real servers
yacovm (Sat, 06 Jan 2018 22:05:44 GMT):
oh
yacovm (Sat, 06 Jan 2018 22:05:54 GMT):
so you have 2 peers in 1 machine, right?
vdods (Sat, 06 Jan 2018 22:05:58 GMT):
Yep
vdods (Sat, 06 Jan 2018 22:06:33 GMT):
2 peers in 1 org, 1 peer in a second org. But the second org is separate and doesn't interact with the first org except through the orderer, so that one's ok.
yacovm (Sat, 06 Jan 2018 22:08:21 GMT):
1 more question
yacovm (Sat, 06 Jan 2018 22:08:30 GMT):
are you running an orderer inside that machine too?
vdods (Sat, 06 Jan 2018 22:08:34 GMT):
Yeah
yacovm (Sat, 06 Jan 2018 22:08:59 GMT):
and you're sure the peer processes are what's taking the CPU?
yacovm (Sat, 06 Jan 2018 22:09:03 GMT):
not kafka, for instance?
vdods (Sat, 06 Jan 2018 22:10:46 GMT):
Yeah:
```11685 minion0 20 0 747336 65344 14508 S 65.4 0.2 0:21.36 peer-v1.0.5
11664 minion0 20 0 888172 67328 14576 S 57.5 0.2 0:23.20 peer-v1.0.5
10075 minion1 20 0 752132 54864 14212 S 4.0 0.2 0:54.17 peer-v1.0.5```
vdods (Sat, 06 Jan 2018 22:11:21 GMT):
This is the output from top -- minion0 is the org0 user, minion1 is the org1 user. The figures 65.4, 57.5, and 4.0 are the CPU usage percentages
yacovm (Sat, 06 Jan 2018 22:11:32 GMT):
ouch
yacovm (Sat, 06 Jan 2018 22:11:39 GMT):
when I run the e2e_cli I get:
yacovm (Sat, 06 Jan 2018 22:11:47 GMT):
Clipboard - January 7, 2018 12:11 AM
yacovm (Sat, 06 Jan 2018 22:12:08 GMT):
and the vm has 4 cores
vdods (Sat, 06 Jan 2018 22:12:18 GMT):
Hmm.. Maybe I should compare config files
vdods (Sat, 06 Jan 2018 22:12:47 GMT):
I'm using my own hand-rolled network orchestration, and it's been a pretty difficult process getting everything right
yacovm (Sat, 06 Jan 2018 22:13:05 GMT):
nah it's not that hard
vdods (Sat, 06 Jan 2018 22:14:03 GMT):
I imagine if you've designed and written the fabric modules that's true, but I can tell you as an outsider, it's pretty difficult ;)
yacovm (Sat, 06 Jan 2018 22:14:29 GMT):
anyway when the peers are resting they are even less busy on my machine:
yacovm (Sat, 06 Jan 2018 22:14:33 GMT):
Clipboard - January 7, 2018 12:14 AM
vdods (Sat, 06 Jan 2018 22:14:52 GMT):
To be fair, the docs are getting better, and as the tools get better, things will be easier and easier :)
vdods (Sat, 06 Jan 2018 22:15:35 GMT):
Hmm, ok, that's heartening to see that peers should behave well like that. I think I'll need to put my due diligence in and compare with e2e_cli.
vdods (Sat, 06 Jan 2018 22:15:42 GMT):
I really appreciate your time and help!
yacovm (Sat, 06 Jan 2018 22:15:54 GMT):
Clipboard - January 7, 2018 12:15 AM
yacovm (Sat, 06 Jan 2018 22:16:06 GMT):
that's a good idea - if you have docker installed
yacovm (Sat, 06 Jan 2018 22:16:15 GMT):
can you perhaps try to run e2e_cli ?
vdods (Sat, 06 Jan 2018 22:16:24 GMT):
yeah, that sounds like a good plan
vdods (Sat, 06 Jan 2018 22:17:33 GMT):
I've gotta take lunch. I'll let you know how my experiment goes! Ttyl
vdods (Sat, 06 Jan 2018 22:17:37 GMT):
Thanks again!
tfuanig (Tue, 09 Jan 2018 14:56:15 GMT):
Has joined the channel.
tfuanig (Tue, 09 Jan 2018 14:58:40 GMT):
hi, i keep seeing a warning message in peer log
`[33m2018-01-09 13:43:37.496 UTC [blocksProvider] DeliverBlocks -> WARN e001[0m [piichannel] Got error &{SERVICE_UNAVAILABLE}`
it happens to others channels as well
is this something need to be taken care of? thanks!
asaningmaxchain (Tue, 09 Jan 2018 15:00:55 GMT):
@tfuanig can you tell me whether the orderer node is running?
tfuanig (Tue, 09 Jan 2018 15:01:59 GMT):
@asaningmaxchain yes, it is running
asaningmaxchain (Tue, 09 Jan 2018 15:02:34 GMT):
please use `docker ps -a` tell me
tfuanig (Tue, 09 Jan 2018 15:04:15 GMT):
it's not running locally...
```
[33m2018-01-09 13:43:37.496 UTC [blocksProvider] DeliverBlocks -> WARN e001[0m [piichannel] Got error &{SERVICE_UNAVAILABLE}
```
tfuanig (Tue, 09 Jan 2018 15:04:36 GMT):
```
[33m2018-01-09 14:27:17.276 UTC [blocksProvider] DeliverBlocks -> WARN e051[0m [piichannel] Got error &{SERVICE_UNAVAILABLE}
[36m2018-01-09 14:27:27.276 UTC [deliveryClient] Disconnect -> DEBU e052[0m Entering
[36m2018-01-09 14:27:27.277 UTC [deliveryClient] Disconnect -> DEBU e053[0m Exiting
[36m2018-01-09 14:27:27.282 UTC [deliveryClient] connect -> DEBU e054[0m Connected to orderer2.orderer.service.consul:7050
[36m2018-01-09 14:27:27.282 UTC [deliveryClient] connect -> DEBU e055[0m Establishing gRPC stream with orderer2.orderer.service.consul:7050 ...
[36m2018-01-09 14:27:27.282 UTC [deliveryClient] afterConnect -> DEBU e056[0m Entering
```
asaningmaxchain (Tue, 09 Jan 2018 15:04:37 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=pXqi4ekkmhZqfFZnj) @tfuanig how do you know is running
tfuanig (Tue, 09 Jan 2018 15:08:10 GMT):
@asaningmaxchain i am seeing log streaming to orderer
asaningmaxchain (Tue, 09 Jan 2018 15:08:47 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=kjq63TeH9BuKJaiPb) @tfuanig so how you know the orderer is running?
tfuanig (Tue, 09 Jan 2018 15:12:41 GMT):
@asaningmaxchain
```
1ef69f010c12 b17741e7b036 "orderer" 21 hours ago Up 21 hours 10.114.140.235:7050->7050/tcp, 10.114.140.235:7050->7050/udp orderer-dd99feb8-9e91-9e9e-8df9-c2e9e01804e5
```
here the is line for `docker ps`
asaningmaxchain (Tue, 09 Jan 2018 15:13:15 GMT):
can you tell me the peer host can ping the orderer host?
tfuanig (Tue, 09 Jan 2018 15:16:25 GMT):
@asaningmaxchain i docker exec into the peer container and telnet to orderer
```
root@hc-worker-1:~# docker exec -ti 9ccc2a34c765 bash
root@peer0:/# telnet orderer2.orderer.service.consul
Trying 10.114.140.203...
telnet: Unable to connect to remote host: Connection refused
root@peer0:/# telnet orderer2.orderer.service.consul 7050
Trying 10.114.140.203...
Connected to orderer2.orderer.service.consul.
Escape character is '^]'.
```
vdods (Tue, 09 Jan 2018 22:20:36 GMT):
The peer creates a pid file peer.pid in the peer's fileSystemPath, but doesn't delete it when the peer goes down. This seems like a bug -- say you're trying to control the peer with some monitoring service, and you go to stop the peer by issuing a SIGTERM to that pid, only to discover that the peer had already quit, and you just terminated some innocent bystander process that happened to get that address.
vdods (Tue, 09 Jan 2018 22:22:14 GMT):
Can anyone comment on that? Is there some other means to clean up the pid file when the peer goes down? It seems like it may need to be an OS-level thing, since the peer program itself may not be able to catch a signal that kills it in order to clean up its pid file, such as SIGQUIT
vdods (Tue, 09 Jan 2018 22:22:38 GMT):
Or, say the machine hard-reboots, and even the OS has no chance to clean it up.
mogamboizer (Thu, 11 Jan 2018 01:46:41 GMT):
What are the setup/configuration differences between endorsers and committers? My understanding is endorsers have chaincode and are passed a endorsement policy by the client on a particular channel. A peer that is an endorser for channel X can be a committer only for channel Y. Would it be correct to say that the peer role (committer or endorser) depends if the chaincode is present and the endorsement policy is applicable.
sasiedu (Thu, 11 Jan 2018 08:10:01 GMT):
Has joined the channel.
jeffgarratt (Thu, 11 Jan 2018 14:08:20 GMT):
@mogamboizer The role of endorser as well as committer are both within the context of a channel, and requires not just the presence (i.e. installation) but the instantiation of the chaincode on a particular channel. All peers are committers for the channels they have joined. Peers that have the chaincode installed and instantiated can also act as endorsers.
asaningmaxchain (Thu, 11 Jan 2018 14:33:33 GMT):
so the client should send the request to the all peer for endorser?
asaningmaxchain (Thu, 11 Jan 2018 14:33:35 GMT):
@jeffgarratt
asaningmaxchain (Thu, 11 Jan 2018 14:34:10 GMT):
and the peer use the gossip to exchange data each other?
novusopt (Thu, 11 Jan 2018 14:53:02 GMT):
Has joined the channel.
mogamboizer (Thu, 11 Jan 2018 14:58:29 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=6zWWRZGJCy5rX5fbM) @jeffgarratt Thank you that makes it clear.
asaningmaxchain (Thu, 11 Jan 2018 16:51:59 GMT):
@vdods @yacovm i got the error `2018-01-11 16:50:41.672 UTC [gossip/state] queueNewMessage -> WARN 1d7 Failed adding payload: Ledger height is at 294, cannot enqueue block with sequence of 531
2018-01-11 16:50:41.966 UTC [gossip/state] queueNewMessage -> WARN 1d8 Failed adding payload: Ledger height is at 295, cannot enqueue block with sequence of 532` thought it's warning,but can you give me more detail about this?
asaningmaxchain (Thu, 11 Jan 2018 16:51:59 GMT):
@vdods @yacovm i got the error ```2018-01-11 16:50:41.672 UTC [gossip/state] queueNewMessage -> WARN 1d7 Failed adding payload: Ledger height is at 294, cannot enqueue block with sequence of 531
2018-01-11 16:50:41.966 UTC [gossip/state] queueNewMessage -> WARN 1d8 Failed adding payload: Ledger height is at 295, cannot enqueue block with sequence of 532``` thought it's warning,but can you give me more detail about this?
yacovm (Thu, 11 Jan 2018 17:03:20 GMT):
Yes
yacovm (Thu, 11 Jan 2018 17:03:35 GMT):
The peer is behind
asaningmaxchain (Thu, 11 Jan 2018 17:26:01 GMT):
@yacovm can you give more detail
yacovm (Thu, 11 Jan 2018 17:32:44 GMT):
Yeah.. i'm not in the office anymore so a bit hard :smirk: . So, if the peer receives blocks that are to far in the future for its ledger, it doesnt keep that in memory so its memory will not blow up, so it juat drops them instead
rahulhegde (Thu, 11 Jan 2018 18:50:57 GMT):
hello - we are seeing a endorsement failure (500) in peer logs due to `Block not found
rahulhegde (Thu, 11 Jan 2018 18:50:57 GMT):
hello - we are seeing a endorsement failure (500) in peer logs due to `Block not found
rahulhegde (Thu, 11 Jan 2018 18:50:57 GMT):
hello - we saw a endorsement failure (500) in peer logs due to `Block not found
rahulhegde (Thu, 11 Jan 2018 18:50:57 GMT):
hello - we saw a endorsement failure (500) in peer log due to `Block not found
rahulhegde (Thu, 11 Jan 2018 20:05:15 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=yBxD6C9kbk9GJpaDc) Please ignore this as we found the reason, GetBlockByNumber API was called for a different peer (which could be running late).
rickr (Thu, 11 Jan 2018 20:52:35 GMT):
When we send a proposal for a peer to join a channel is it on return ready to instantiate new chaincode/ invoke existing ? Let say there were millions of blocks already on the ledger for this channel. Can we send those endorsements ? If not, is there something that should be waited on to know it ready ?
jeffgarratt (Thu, 11 Jan 2018 21:23:29 GMT):
@rickr you could possibly do a quick deliver from the peer and the orderer and verify equivalence
jeffgarratt (Thu, 11 Jan 2018 21:23:44 GMT):
or at least close :)
AbhijeetPal (Fri, 12 Jan 2018 12:04:39 GMT):
Has joined the channel.
AbhijeetPal (Fri, 12 Jan 2018 13:57:32 GMT):
Hi All
Getting following error in TLS enabled orderer and peers while firing an invoke chaincode command.
`[grpc] Printf -> DEBU 00a transport: http2Client.notifyError got notified that the client transport was broken read tcp $IP1:55078->$IP2:7051: read: connection reset by peer.`
`Error: Error endorsing invoke: rpc error: code = Internal desc = transport is closing -
AbhijeetPal (Fri, 12 Jan 2018 13:57:32 GMT):
Hi All
Getting following error in TLS enabled orderer and peers while firing an invoke chaincode command.
`[grpc] Printf -> DEBU 00a transport: http2Client.notifyError got notified that the client transport was broken read tcp $IP1:55078->$IP2:7051: read: connection reset by peer.`
`Error: Error endorsing invoke: rpc error: code = Internal desc = transport is closing -
bretharrison (Fri, 12 Jan 2018 16:55:27 GMT):
Has joined the channel.
fusanke_roman (Sat, 13 Jan 2018 06:08:25 GMT):
Has joined the channel.
NiketYende (Mon, 15 Jan 2018 05:43:22 GMT):
Hi, i would like to have a deeper understanding of transaction.proto. My aim is to extract a json formatted data from the input field.
The channel.queryBlock(block_num) from the fabric-sdk-node returns a unencoded block apart from input section of the "chaincode_proposal_payload.input".
Temporary solution for this is to use "chaincode_proposal_payload.input.toString('utf8')" to covert input into a more readable string, but this string contains some additional characters which restricts it from being converted to a json object.
Is there any other way to parse chaincode_proposal_payload.input into a json?
NiketYende (Mon, 15 Jan 2018 05:43:22 GMT):
Hi, i would like to have a deeper understanding of transaction.proto. My aim is to extract a json formatted data from the input field.
The channel.queryBlock(block_num) from the fabric-sdk-node returns an unencoded block apart from input section of the "chaincode_proposal_payload.input".
Temporary solution for this is to use "chaincode_proposal_payload.input.toString('utf8')" to covert input into a more readable string, but this string contains some additional characters which restricts it from being converted to a json object.
Is there any other way to parse chaincode_proposal_payload.input into a json?
muralisr (Mon, 15 Jan 2018 17:12:30 GMT):
@NiketYende let me copy this to fabric-sdk-node (don't see it there...)
NiketYende (Tue, 16 Jan 2018 04:49:20 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=G9FRJkxjvvv6pHYCF) @muralisr I was redirected here from fabric-sdk-node channel by @bretharrison
NiketYende (Tue, 16 Jan 2018 09:34:26 GMT):
https://chat.hyperledger.org/channel/fabric-sdk-node?msg=SFHkMozr4wWgaDFut This was the conversation from the other channel.
AbhijeetPal (Tue, 16 Jan 2018 12:33:38 GMT):
Hi All,
I have following setup on 2 VMS
Setup on VM1:
orderers,kafkas,zookeepers, 2 peers,their couchdbs and cli(fabric-tools) on VM1 in a single docker-compose file --> docker-compose-vm1.yaml.
Setup on VM2:
one peer,couchdb and cli in another docker-compose file --> docker-compose-vm2.yaml
Peer on VM2 connects with orderer on VM1 via entry in /etc/hosts of Peer on VM2.
Getting following error while firing invoke command on channel from Peer on VM2.
`[dockercontroller] stopInternal -> DEBU 3493 Kill container dev-peer01.org.example.com-channel-${chaincode-version} `
`(API error (500): {"message":"Cannot kill container dev-peer01.org.example.com-channel-${chaincode-version}: Container ${ContainerID} is not running"}`
`[dockercontroller] Start -> ERRO 3498 start-could not start container: API error (500): {"message":"invalid cluster node while attaching to network"}`
`[chaincode] Launch -> ERRO 349b launchAndWaitForRegister failed Error starting container: API error (500): {"message":"invalid cluster node while attaching to network"}`
`[chaincode] ExecuteChaincode -> ERRO 349c Error executing chaincode: Error starting container: API error (500): {"message":"invalid cluster node while attaching to network"}`
`[endorser] simulateProposal -> ERRO 349e failed to invoke chaincode name:"channel" on transaction ${transactionid}, `
`error: Error executing chaincode: Error starting container: API error (500): {"message":"invalid cluster node while attaching to network"}`
The container dev-peer01.org.example.com-channel-${chaincode-version} gets created, but stays in created state in `docker ps -a`.
PS-Same command when fired over same channel from Peer on VM1 gets successfully executed and reflects in the couchdb of Peer on VM2.
Ratnakar (Tue, 16 Jan 2018 18:51:51 GMT):
Unable to instantiate a chaincode on fabric network (Used Network launcher script from `fabric-test` repo)
This is what is the error I see in chaincode container logs
```
2018-01-16 17:31:38.600 UTC [shim] userChaincodeStreamGetter -> ERRO 001 context deadline exceeded
error trying to connect to local peer
github.com/hyperledger/fabric/core/chaincode/shim.userChaincodeStreamGetter
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/shim/chaincode.go:109
github.com/hyperledger/fabric/core/chaincode/shim.Start
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/shim/chaincode.go:148
main.main
/chaincode/input/src/github.com/example_cc/go/example_cc.go:199
runtime.main
/opt/go/src/runtime/proc.go:185
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:2337
2018-01-16 17:31:38.600 UTC [example_cc0] Errorf -> ERRO 002 Error starting Simple chaincode: error trying to connect to local peer: context deadline exceeded
```
Ratnakar (Tue, 16 Jan 2018 18:52:07 GMT):
any thoughts @yacovm @muralisr ?
Ratnakar (Tue, 16 Jan 2018 18:53:09 GMT):
I made sure I included these lines aswell , but no luck
```
- CORE_PEER_CHAINCODEADDRESS=<
yacovm (Tue, 16 Jan 2018 18:56:03 GMT):
Anything new you're doing?
yacovm (Tue, 16 Jan 2018 18:56:12 GMT):
Tls is on or off?
muralisr (Tue, 16 Jan 2018 18:56:40 GMT):
I was going to ask "what has changed" but lets go wit yours @yacovm :-)
yacovm (Tue, 16 Jan 2018 18:59:12 GMT):
Nah murali frel free to take over the interrogation. I'm not at home or at the office... @Ratnakar if you can provide a docker-compose with scripts i'll hladly look when i get home
yacovm (Tue, 16 Jan 2018 18:59:24 GMT):
*feel
Ratnakar (Tue, 16 Jan 2018 18:59:25 GMT):
TLS is ON
yacovm (Tue, 16 Jan 2018 18:59:34 GMT):
*provide
Ratnakar (Tue, 16 Jan 2018 19:01:17 GMT):
docker-compose.txt
muralisr (Tue, 16 Jan 2018 19:01:31 GMT):
sure @yacovm .. @Ratnakar so anything new ?
Ratnakar (Tue, 16 Jan 2018 19:02:34 GMT):
It is just that Network Launcher tool I have used to launch the network and driving the call through SDK
Ratnakar (Tue, 16 Jan 2018 19:02:34 GMT):
@Murali , It is just that Network Launcher tool I have used to launch the network and driving the call through SDK
Ratnakar (Tue, 16 Jan 2018 19:02:34 GMT):
@muralisr urali , It is just that Network Launcher tool I have used to launch the network and driving the call through SDK
Ratnakar (Tue, 16 Jan 2018 19:02:34 GMT):
@muralisr , It is just that Network Launcher tool I have used to launch the network and driving the call through SDK
muralisr (Tue, 16 Jan 2018 19:02:54 GMT):
ok
Ratnakar (Tue, 16 Jan 2018 19:04:34 GMT):
```
2018-01-16 17:35:20.847 UTC [chaincode] func1 -> DEBU 411 [a8d29f52] getting state for chaincode lscc, key mycc, channel testorgschannel1
2018-01-16 17:35:20.848 UTC [statecouchdb] GetState -> DEBU 412 GetState(). ns=lscc, key=mycc
2018-01-16 17:35:20.848 UTC [couchdb] ReadDoc -> DEBU 413 Entering ReadDoc() id=[lsccmycc]
2018-01-16 17:35:20.848 UTC [couchdb] encodePathElement -> DEBU 414 Entering encodePathElement() string=lsccmycc
2018-01-16 17:35:20.848 UTC [couchdb] encodePathElement -> DEBU 415 Exiting encodePathElement() encodedStr=lscc%00mycc
2018-01-16 17:35:20.848 UTC [couchdb] handleRequest -> DEBU 416 Entering handleRequest() method=GET url=http://couchdb0:5984/testorgschannel1/lscc%00mycc?attachments=true
2018-01-16 17:35:20.849 UTC [couchdb] handleRequest -> DEBU 417 HTTP Request: GET /testorgschannel1/lscc%00mycc?attachments=true HTTP/1.1 | Host: couchdb0:5984 | User-Agent: Go-http-client/1.1 | Accept: multipart/related | Accept-Encoding: gzip | |
2018-01-16 17:35:20.854 UTC [couchdb] handleRequest -> DEBU 418 Couch DB Error:not_found, Status Code:404, Reason:missing
2018-01-16 17:35:20.855 UTC [couchdb] ReadDoc -> DEBU 419 Document not found (404), returning nil value instead of 404 error
2018-01-16 17:35:20.855 UTC [chaincode] func1 -> DEBU 41a [a8d29f52]No state associated with key:
mycc. Sending RESPONSE with an empty payload
```
muralisr (Tue, 16 Jan 2018 19:04:59 GMT):
so `CORE_PEER_CHAINCODEADDRESS=<
muralisr (Tue, 16 Jan 2018 19:06:30 GMT):
this is right at the beginning of chaincode launch... we have to do some basic network level debugging
muralisr (Tue, 16 Jan 2018 19:06:49 GMT):
first make sure peer is listening on 7052 correctly
muralisr (Tue, 16 Jan 2018 19:07:10 GMT):
and next ping from container and check...
muralisr (Tue, 16 Jan 2018 19:07:40 GMT):
Id also try turning TLS off to keep it simple and go frtom ther
Ratnakar (Tue, 16 Jan 2018 19:08:02 GMT):
ok .. I am still figuring out installing ping on peer :)
muralisr (Tue, 16 Jan 2018 19:08:12 GMT):
ah ok :-)
Ratnakar (Tue, 16 Jan 2018 19:08:15 GMT):
Thanks @muralisr for the debug steps
muralisr (Tue, 16 Jan 2018 19:09:03 GMT):
sure thing... let me know (will check back later)
yacovm (Tue, 16 Jan 2018 19:09:38 GMT):
apt-get install iputils-ping
yacovm (Tue, 16 Jan 2018 19:09:44 GMT):
I think
Ratnakar (Tue, 16 Jan 2018 19:09:50 GMT):
yes , I could ping that IP from peer container
yacovm (Tue, 16 Jan 2018 19:17:03 GMT):
What does core peer address say @Ratnakar ?
Ratnakar (Tue, 16 Jan 2018 19:18:04 GMT):
@yacovm
`CORE_PEER_ADDRESS=<
Ratnakar (Tue, 16 Jan 2018 19:18:48 GMT):
My bad I didn;t noticed, but looks like the port 7052 is not exposed for any of the peers
Ratnakar (Tue, 16 Jan 2018 19:18:59 GMT):
I would need to change in the tool and need to retry
yacovm (Tue, 16 Jan 2018 19:24:39 GMT):
Can you telnet to port 7052 from the cc container?
Ratnakar (Tue, 16 Jan 2018 19:33:13 GMT):
cc container exits with the error I pasted on my first message
yacovm (Tue, 16 Jan 2018 19:49:54 GMT):
But you checked ping no?
yacovm (Tue, 16 Jan 2018 19:50:04 GMT):
So can you also check telnet?
Ratnakar (Tue, 16 Jan 2018 20:07:36 GMT):
@yacovm I pinged from peer itself , sorry that sounds silly :(
Ratnakar (Tue, 16 Jan 2018 20:07:54 GMT):
container doesn't comeup it exits immediately
yacovm (Tue, 16 Jan 2018 20:08:05 GMT):
put a sleep in the container
yacovm (Tue, 16 Jan 2018 20:08:22 GMT):
I mean, run it again with a sleep
yacovm (Tue, 16 Jan 2018 20:08:26 GMT):
I think you can do it somehow
Ratnakar (Tue, 16 Jan 2018 20:10:59 GMT):
Are you suggesting to make changes in fabric code to introduce the sleep ?
or is there a way to introduce that sleep from docker-compose ?
muralisr (Tue, 16 Jan 2018 20:59:50 GMT):
`command: /bin/bash -c './scripts/script.sh ${CHANNEL_NAME}; sleep $TIMEOUT'`
muralisr (Tue, 16 Jan 2018 21:00:52 GMT):
thats a sample from your cli @Ratnakar :-)
yacovm (Tue, 16 Jan 2018 21:08:25 GMT):
no, I am suggesting you do `docker exec`
yacovm (Tue, 16 Jan 2018 21:08:29 GMT):
and lift the container
Ratnakar (Tue, 16 Jan 2018 21:24:59 GMT):
@muralisr @yacovm the chaincode container dies immediately. and the container status *Exited*
So I can't do `docker exec` or introduce the delay with any of such commands as I don't have control on the cc container
yacovm (Tue, 16 Jan 2018 21:25:26 GMT):
try docker run?
yacovm (Tue, 16 Jan 2018 21:25:43 GMT):
docker run with sleep
qylixin (Wed, 17 Jan 2018 06:08:13 GMT):
Has joined the channel.
NiketYende (Wed, 17 Jan 2018 11:46:52 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=knqzGrZqnyfLr95sf) Could any one help me with this? I need to know the type of encoding done over the input ("chaincode_proposal_payload.input"). Any help will be appreciated.
NiketYende (Wed, 17 Jan 2018 11:46:52 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=knqzGrZqnyfLr95sf) Could any one help me with this? I need to know the type of encoding done over the input ("chaincode_proposal_payload.input"). Basically the input object should be able to parsed as json. Any help will be appreciated.
muralisr (Wed, 17 Jan 2018 14:34:15 GMT):
@NiketYende suggest follow the `CreateSignedTx` method in fabric/protos/utils/txutils.go and fabric/peer/chaincode/instantiate.go .. the payload comes from the chaincode (in ProposalResponse) so once you unmarshall all the fabric/protos specific specifc stuff, the bytes you'll be left with is output from chaincode
muralisr (Wed, 17 Jan 2018 14:37:26 GMT):
@Ratnakar another approach - start peer in --peer-chaincodedev mode and manually start the chaincode container as "bash" ... then issue the same chainciode command from command line
muralisr (Wed, 17 Jan 2018 14:37:26 GMT):
@Ratnakar another approach - start peer in --peer-chaincodedev mode and manually `docker run ..` the chaincode container as "bash" ... then issue the same chainciode command from command line
muralisr (Wed, 17 Jan 2018 14:37:26 GMT):
@Ratnakar another approach - start peer in --peer-chaincodedev mode and `docker run ..` the chaincode container as "bash" ... then issue the same chainciode command from command line
muralisr (Wed, 17 Jan 2018 14:38:25 GMT):
then you shoud be able to debug to hearts content
Ratnakar (Wed, 17 Jan 2018 14:41:29 GMT):
@muralisr Thanks murali, will check on that now
udaykhambadkone (Wed, 17 Jan 2018 14:46:32 GMT):
Has joined the channel.
alexliu (Thu, 18 Jan 2018 03:21:53 GMT):
Has joined the channel.
Devender_Singh (Thu, 18 Jan 2018 05:16:16 GMT):
Has joined the channel.
daygee (Thu, 18 Jan 2018 09:31:18 GMT):
Has joined the channel.
javrevasandeep (Thu, 18 Jan 2018 11:02:15 GMT):
Has joined the channel.
javrevasandeep (Thu, 18 Jan 2018 11:02:39 GMT):
i am getting the error Failed to invoke chaincode. cause:Error: Problem setting up the event hub :Error: EventHub has been shutdown after storing around 3000 records in blockchain. This error is going away automatically after few minutes and the same error appearing again after storing few more records.
I am using balance transfer example
more information below
[2018-01-18 10:55:14.310] [ERROR] invoke-chaincode - REQUEST_TIMEOUT:localhost:7053
[2018-01-18 10:55:14.314] [ERROR] invoke-chaincode - Problem setting up the event hub :Error: EventHub has been shutdown
[2018-01-18 10:55:14.322] [ERROR] invoke-chaincode - Error: Problem setting up the event hub :Error: EventHub has been shutdown
at eh.registerTxEvent (/home/bteam/go/src/github.com/hyperledger/fabric-samples/smartProperty24Nov/app/invoke-transaction.js:115:14)
at closer (/home/bteam/go/src/github.com/hyperledger/fabric-samples/smartProperty24Nov/node_modules/fabric-client/lib/EventHub.js:433:5)
at EventHub._closeAllCallbacks (/home/bteam/go/src/github.com/hyperledger/fabric-samples/smartProperty24Nov/node_modules/fabric-client/lib/EventHub.js:443:3)
at EventHub._disconnect (/home/bteam/go/src/github.com/hyperledger/fabric-samples/smartProperty24Nov/node_modules/fabric-client/lib/EventHub.js:384:8)
at EventHub.disconnect (/home/bteam/go/src/github.com/hyperledger/fabric-samples/smartProperty24Nov/node_modules/fabric-client/lib/EventHub.js:373:8)
at Timeout.setTimeout (/home/bteam/go/src/github.com/hyperledger/fabric-samples/smartProperty24Nov/app/invoke-transaction.js:93:10)
at ontimeout (timers.js:469:11)
at tryOnTimeout (timers.js:304:5)
at Timer.listOnTimeout (timers.js:264:5)
mffrench (Thu, 18 Jan 2018 11:02:46 GMT):
Hi,
I raised an issue on hlf peer restart which is not able to load the correct config block from the ledger (https://jira.hyperledger.org/browse/FAB-7801). I'm looking for some advice to see how I can restore this configuration (if possible). Can somebody help ?
Thank you !
NiketYende (Thu, 18 Jan 2018 11:13:55 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=WYs6Peu5ZoKbWiiPj) @muralisr Hi, thank you for the reply. The payload data is already unmarshalled by the node-sdk. Also the fabric-sdk-node internally uses the same technique to unmarshall this block payload . We are facing problem only with the input field (chaincode_proposal_payload.input). The input comes as a bytecode. Any way to convert this input into json ?
muralisr (Thu, 18 Jan 2018 14:06:15 GMT):
@NiketYende if I understand you correctly, you are asking about ```message ChaincodeProposalPayload {
// Input contains the arguments for this invocation. If this invocation
// deploys a new chaincode, ESCC/VSCC are part of this field.
// This is usually a marshaled ChaincodeInvocationSpec
bytes input = 1;
// TransientMap contains data (e.g. cryptographic material) that might be used
// to implement some form of application-level confidentiality. The contents
// of this field are supposed to always be omitted from the transaction and
// excluded from the ledger.
map
muralisr (Thu, 18 Jan 2018 14:07:36 GMT):
if that;s correct, `input` is either ChaincodeInvocationSpec or ChaincodeDeploymentSpec
muralisr (Thu, 18 Jan 2018 14:07:36 GMT):
if that;s correct, `input` is either marshalled ChaincodeInvocationSpec or ChaincodeDeploymentSpec
muralisr (Thu, 18 Jan 2018 14:08:19 GMT):
the SDK should have code that goes thru this marshalling at the time of sending the proposal
jeffgarratt (Thu, 18 Jan 2018 15:09:48 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=aqkS69F5NKPyYijkf) @mffrench replied in Jira item
mffrench (Thu, 18 Jan 2018 15:10:25 GMT):
@jeffgarratt : thank you !
jeffgarratt (Thu, 18 Jan 2018 15:14:58 GMT):
@mffrench can you also pull that block and verify it's contents?
mffrench (Thu, 18 Jan 2018 15:15:21 GMT):
I also was reading following doc : https://www.ibm.com/developerworks/cloud/library/cl-add-an-organization-to-your-hyperledger-fabric-blockchain/index.html
mffrench (Thu, 18 Jan 2018 15:15:39 GMT):
this is a new feature to update the configuration
mffrench (Thu, 18 Jan 2018 15:16:21 GMT):
does it mean starting 1.1.1 I will be able to reset a configuration block on top of a ledger is such case ?
mffrench (Thu, 18 Jan 2018 15:16:48 GMT):
or I'm asking too much (because all block should be sync together etc)
mffrench (Thu, 18 Jan 2018 15:17:21 GMT):
@jeffgarratt : yeah I began to do that work yesterday by recompilign the peer
mffrench (Thu, 18 Jan 2018 15:17:43 GMT):
currently I saw that the block was in fact a msg block type not a configuration type.
jeffgarratt (Thu, 18 Jan 2018 15:18:00 GMT):
hmmm, that is strange
mffrench (Thu, 18 Jan 2018 15:18:09 GMT):
yeah
mffrench (Thu, 18 Jan 2018 15:18:28 GMT):
I will add a line in the code to print the block in the logs
jeffgarratt (Thu, 18 Jan 2018 15:18:47 GMT):
can you do the following...
jeffgarratt (Thu, 18 Jan 2018 15:18:58 GMT):
```peer channel fetch --help
jeffgarratt (Thu, 18 Jan 2018 15:19:05 GMT):
fetch the config block for the channel
jeffgarratt (Thu, 18 Jan 2018 15:19:08 GMT):
then inspect it
mffrench (Thu, 18 Jan 2018 15:19:12 GMT):
ok
zhoui13 (Fri, 19 Jan 2018 02:04:57 GMT):
Has joined the channel.
NiketYende (Fri, 19 Jan 2018 06:05:25 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=7RDisku2iHFwL7Yj9) @muralisr Yes that is right.
NiketYende (Fri, 19 Jan 2018 06:46:44 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=AwiYywBeyo77NyQR7) @muralisr As per the code present under "fabric-client/lib/Channel.js".
/**
* Queries the ledger on the target peer for Block by block number.
*
* @param {number} blockNumber - The number of the Block in question.
* @param {Peer} target - Optional. The peer to send this query to. If no target is passed,
* the query is sent to the first peer that was added to the channel object.
* @returns {Promise} A Promise for a {@link Block} at the blockNumber slot in the ledger, fully decoded into an object.
*/
queryBlock(blockNumber, target) {
This should return a fully decoded block, and it does give a decoded block apart from the input field in question.
wanliangbing (Fri, 19 Jan 2018 06:49:15 GMT):
Has joined the channel.
vdods (Fri, 19 Jan 2018 21:14:20 GMT):
I'm having trouble instantiating chaincode on a TLS-enabled peer. When the chaincode container attempts to connect to the peer on port 7051, it (the chaincode container) fails with "Error trying to connect to local peer: x509: certificate signed by unknown authority". However, I've verified that the CORE_PEER_TLS_ROOTCERT_FILE env var is set to the correct path in the docker image (it points to the root CA cert), and I've verified that the peer's cert is correctly set up by successfully connecting to the peer via `openssl s_client -connect
vdods (Fri, 19 Jan 2018 21:16:27 GMT):
All the certs shown by `openssl s_client ...` are as expected, and the connection is established successfully. One other thing I should mention is that I've made my peer cert a cert chain starting with the peer's cert, then the intermediate CA cert, then the root CA cert. Otherwise I found that other TLS connections (e.g. having the peer join the channel) doesn't work because the connecting client doesn't have enough information to verify that the peer's cert is trusted.
yacovm (Fri, 19 Jan 2018 21:16:51 GMT):
why port 7051?
yacovm (Fri, 19 Jan 2018 21:16:53 GMT):
it's 7052
yacovm (Fri, 19 Jan 2018 21:17:12 GMT):
what version are you using?
yacovm (Fri, 19 Jan 2018 21:17:15 GMT):
in v1.1 it's 7052
vdods (Fri, 19 Jan 2018 21:17:17 GMT):
v1.0.5
yacovm (Fri, 19 Jan 2018 21:17:23 GMT):
oh
yacovm (Fri, 19 Jan 2018 21:17:29 GMT):
so it's 7051
yacovm (Fri, 19 Jan 2018 21:17:51 GMT):
and no, no mutual TLS in v1.0.x
yacovm (Fri, 19 Jan 2018 21:18:14 GMT):
and if you had mutual TLS you'd get a different error IMO
vdods (Fri, 19 Jan 2018 21:18:20 GMT):
One more note -- the `openssl s_client ...` connection indicates that the server communicates "acceptable client certificate CA names", which are the root CA, and the intermediate CAs for org0 and org1 (the two orgs in my network)
vdods (Fri, 19 Jan 2018 21:18:26 GMT):
hmm
yacovm (Fri, 19 Jan 2018 21:18:42 GMT):
my guess
yacovm (Fri, 19 Jan 2018 21:18:54 GMT):
if you would delete the chaincode image
yacovm (Fri, 19 Jan 2018 21:18:56 GMT):
that would solve it
vdods (Fri, 19 Jan 2018 21:19:05 GMT):
interesting.. thanks, I'll try that
vdods (Fri, 19 Jan 2018 21:20:41 GMT):
hah.. that totally worked
vdods (Fri, 19 Jan 2018 21:20:54 GMT):
god damn it.. it's like the bad old days of "make clean && make all"
vdods (Fri, 19 Jan 2018 21:21:03 GMT):
to fix an inexplicable error
vdods (Fri, 19 Jan 2018 21:21:19 GMT):
docker is keeping up the tradition
yacovm (Fri, 19 Jan 2018 21:25:28 GMT):
no, it's not docker
yacovm (Fri, 19 Jan 2018 21:25:49 GMT):
it's because in v1.0.x, when the chaincode is built in the first time
yacovm (Fri, 19 Jan 2018 21:26:04 GMT):
it copies some stuff from the peer's file system to the chaincode
yacovm (Fri, 19 Jan 2018 21:26:13 GMT):
and if TLS isn't used I think it doesn't copy some stuff
yacovm (Fri, 19 Jan 2018 21:26:16 GMT):
so when you turn on TLS
yacovm (Fri, 19 Jan 2018 21:26:23 GMT):
you sometimes need to delete the chaincode image
yacovm (Fri, 19 Jan 2018 21:26:51 GMT):
but, worry not - in v1.1 everything works smooth as butter, regardless of what you do ;)
vdods (Fri, 19 Jan 2018 21:28:03 GMT):
Awesome, I'm looking forward to upgrading :)
vdods (Fri, 19 Jan 2018 21:28:26 GMT):
Thanks for your help again.
gauthampamu (Fri, 19 Jan 2018 21:36:04 GMT):
If we have five members in the network. Lets say all five members joined the single channel and we have an endorsement policy where member 2 and member 3 needs to endorse the transactions. So lets say the client of member 1, submits the transaction, does this client need to send the transaction directly to peer of member 2 and 3 or does it need to send the transaction to member 1 peer and it will get forwarded to member 2 peer and 3 peer by gossip protocol ?
silliman (Fri, 19 Jan 2018 21:44:23 GMT):
@gauthampamu My understanding is that the client will need to send the transaction proposals to a peer of member 2 and to a peer of member 3 in your scenario. Gossip is used for peers to send already committed blocks to each other, e.g. those peers connected directly to an orderer via Deliver() use gossip to communicate to those peers that aren't connected directly to an orderer.
gauthampamu (Fri, 19 Jan 2018 21:45:39 GMT):
Even thought you have to sent the transaction to member 2 and 3. I had heard recently from someone that you will send to your peer and it will get forwarded to other peers. So I wanted to confirm it.
vdods (Fri, 19 Jan 2018 21:45:48 GMT):
Yeah, I think the idea is that if one relied on a transaction being gossipped to the other endorsing peers via a single peer, then that peer could probably alter the transaction proposal in some way to its advantage. So it's in the interest of the transacting client to communicate the transaction proposal directly to all peers
gauthampamu (Fri, 19 Jan 2018 21:46:12 GMT):
Thanks @vdods
vdods (Fri, 19 Jan 2018 21:46:19 GMT):
@gauthampamu That's true once the transactions have been ordered and committed to blocks.
vdods (Sat, 20 Jan 2018 01:17:46 GMT):
Hi all, is there a means to query a peer to discover all peers connected to a particular channel? In particular, because a fabric network can change over time, with peers being added or leaving a channel, it doesn't seem practical to have to discover the network architecture via side channel.
vdods (Sat, 20 Jan 2018 01:17:46 GMT):
Hi all, is there a means to query a peer to discover all peers connected to a particular channel? In particular, because a fabric network can change over time, with peers being added or leaving a channel, it doesn't seem practical to have to discover the network architecture via out-of-band communication.
Brucepark (Sat, 20 Jan 2018 06:15:30 GMT):
Has joined the channel.
yacovm (Sat, 20 Jan 2018 07:02:20 GMT):
@vdods wait for v1.2 it might be there
toddinpal (Sun, 21 Jan 2018 14:44:45 GMT):
@yacovm Might? This seems like a significant issue and the gossip protocols know this information, right?
yacovm (Sun, 21 Jan 2018 14:52:58 GMT):
@toddinpal might because I cannot predict the future. This is a significant issue, correct.
Also - the mechanism is indeed going to leverage gossip.
The JIRA item is FAB-5451
If you think this is important to have and want this to be included in 1.2 you are free to comment in the JIRA + vote on the JIRA :)
NiketYende (Mon, 22 Jan 2018 10:18:10 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=mQJ5bL4rXPmzcLQAH) Hi @muralisr, we encounter all these characters. �customs-network�
submitTransaction
�
NiketYende (Mon, 22 Jan 2018 10:19:45 GMT):
How do we parse these characters? We are getting it from "chaincode_proposal_payload.input.toString('utf8');".
vijay5378 (Mon, 22 Jan 2018 15:43:04 GMT):
Has joined the channel.
vijay5378 (Mon, 22 Jan 2018 15:43:48 GMT):
I have instantiated a chaincode with -P "AND ('Org1MSP.member','Org2MSp.member')". I am trying to add a key, value to the ledger using the chaincode. Now even when the transaction is endorsed by just one MSP, it still writes to the ledger...am I missing something?
vijay5378 (Mon, 22 Jan 2018 16:18:06 GMT):
Guess I found the mistake. I had upgraded the chaincode. However, the upgrade transaction did not have any policy defined. Will the endorsement policy need to be specified during the upgrade also?
vijay5378 (Mon, 22 Jan 2018 16:25:25 GMT):
In a related question.... When I submit a transaction for endorsement...can I put a rule at the peer level for endorsement? In another scenario.....if I have orgA and orgB....an application connects to peer0 of orgA and proposes a write transaction. The second org should wait for user to look into this transaction to endorse it. Is it possible to design it this way?
krisava (Mon, 22 Jan 2018 22:05:29 GMT):
Has joined the channel.
krisava (Mon, 22 Jan 2018 22:06:26 GMT):
Hi. I am getting the below error while trying to post the transaction from PeerOrg2. Can you please help?
2018-01-22 14:26:51.614 UTC [kvledger] Commit -> INFO 033[0m Channel [channel]: Created block [27] with 1 transaction(s)
2018-01-22 14:26:51.616 UTC [eventhub_producer] SendProducerBlockEvent -> INFO 034[0m Channel [channel]: Sending event for block number [27]
[33m2018-01-22 15:35:47.203 UTC [vscc] Invoke -> WARN 035[0m Endorsement policy failure for transaction txid=, err: Failed to authenticate policy
[31m2018-01-22 15:35:47.203 UTC [txvalidator] VSCCValidateTxForCC -> ERRO 036[0m VSCC check failed for transaction txid=, error VSCC error: policy evaluation failed, err Failed to authenticate policy
[31m2018-01-22 15:35:47.203 UTC [txvalidator] Validate -> ERRO 037[0m VSCCValidateTx for transaction txId = returned error VSCC error: policy evaluation failed, err Failed to authenticate policy
[33m2018-01-22 15:35:47.203 UTC [statevalidator] ValidateAndPrepareBatch -> WARN 038[0m Block [28] Transaction index [0] marked as invalid by committer. Reason code [10]
jojialex2 (Tue, 23 Jan 2018 05:50:29 GMT):
can you remove all chain code images related to this and place a fresh chain code deployment
chill37 (Tue, 23 Jan 2018 06:25:59 GMT):
Hi. Could anyone point out a documentation about "ANCHOR PEER"? I'm trying to see how it works code-flow-wise, but I found so little about it in the main hyperledger.io document. if anyone could point out a link or so, that would help a lot. thanks!
jojialex2 (Tue, 23 Jan 2018 06:41:28 GMT):
krisava : I had the same issue, because once we deploy a chain code , fabric will create image and copy the certificate from the peer. again If I deploy the chain code with different certificate the image will not recreate and refer the same image .... So I have remove the image and deploy it again and it worked for me.
jojialex2 (Tue, 23 Jan 2018 06:41:28 GMT):
krisava : I had the same issue, because once we deploy a chain code , fabric will create image and copy the certificate from the peer. again If we deploy the chain code with different certificate the image will not recreate and refer the same image .... So I have remove the image and deploy it again and it worked for me.
chill37 (Tue, 23 Jan 2018 10:44:08 GMT):
Anyone have some ideas about ANCHOR PEER workflow? I'm also curious if 'anchor peer' and 'anchor' in the PROPOSE message (`PROPOSE` message is `
yacovm (Tue, 23 Jan 2018 11:00:38 GMT):
it is not
chill37 (Tue, 23 Jan 2018 11:11:45 GMT):
@yacovm I see. I was mistaken there. thanks!
zhmz1326 (Tue, 23 Jan 2018 11:39:38 GMT):
Has joined the channel.
NiketYende (Tue, 23 Jan 2018 11:58:26 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=tSHcwCPerMteffs6k) Some more debugging landed me to this piece of code. Here is the invocation sequence:
NiketYende (Tue, 23 Jan 2018 11:58:26 GMT):
'channel.queryBlock(block_num)' calls the 'BlockDecoder.decode(response.response.payload)' method.
This method internally invokes 'decodeBlockData(proto_block.data, true)'.
NiketYende (Tue, 23 Jan 2018 12:07:35 GMT):
Could you tell me why 'decodeChaincodeActionPayload(payload_bytes)' returns an encoded bytearray instead of a string?
Vadim (Tue, 23 Jan 2018 12:12:29 GMT):
@NiketYende because it's encded as a sequence of bytes: https://github.com/hyperledger/fabric/blob/d9c320297bd2a4eff2eb253ce84dc431ef860972/protos/peer/transaction.proto#L86
Vadim (Tue, 23 Jan 2018 12:12:42 GMT):
I guess then you need to continue further decode it
NiketYende (Tue, 23 Jan 2018 12:13:23 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=eFwgvSKSQBvgfzu2i) @Vadim Which proto is used to decode the "chaincode_proposal_payload.input" further?
Vadim (Tue, 23 Jan 2018 12:21:29 GMT):
@NiketYende I guess it should be https://github.com/hyperledger/fabric/blob/d9c320297bd2a4eff2eb253ce84dc431ef860972/protos/peer/chaincode.proto#L94
krisava (Tue, 23 Jan 2018 15:53:56 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=irsDhXE55hyZQdW6Y) @jojialex2 Thanks @jojialex2. Images you mean peers and re-create them new?
jojialex2 (Wed, 24 Jan 2018 04:21:40 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=BoYfcu67tfJPi5MNf) @krisava
jojialex2 (Wed, 24 Jan 2018 04:22:45 GMT):
krisava : Will you able to deploy chaincode. when are you getting this error..
RobertDiebels (Thu, 25 Jan 2018 11:46:33 GMT):
Has joined the channel.
RobertDiebels (Thu, 25 Jan 2018 11:47:48 GMT):
Hey guys, question about the fabric-peer container. Would I be correct in assuming that if I install and instantiate chain code for a peer that it will create a docker container *inside* the fabric-peer container?
RobertDiebels (Thu, 25 Jan 2018 11:48:33 GMT):
In other words, that would mean that the `fabric-peer` container comes with a docker deamon?
asaningmaxchain123 (Thu, 25 Jan 2018 13:24:35 GMT):
Has joined the channel.
novusopt (Thu, 25 Jan 2018 14:39:44 GMT):
Hi, I have one organization setup with 5 peers, is it possible to define an endorsment policy which says I need 3 out 5 signatures?
novusopt (Thu, 25 Jan 2018 14:39:44 GMT):
Hi, I have one organization setup with 5 peers, is it possible to define an endorsment policy which says I need 3 out of 5 signatures?
jeffgarratt (Thu, 25 Jan 2018 23:09:50 GMT):
@RobertDiebels not necessarily. Most of the sandbox environments actually use the daemon from the containers host environment. But this can be configured as you see fit.
chill37 (Fri, 26 Jan 2018 07:08:30 GMT):
sorry for the repeating questions, but anybody know when the anchor peer's authority is executed? Invoke/Query doesn't need anchor peer to update their block. why do we need anchor peer? (i read the doc but doesn't really come up with scenarios)
mastersingh24 (Fri, 26 Jan 2018 10:21:18 GMT):
@chill37 - anchor peers are only relevant if you want to use cross organization gossip
mastersingh24 (Fri, 26 Jan 2018 10:23:32 GMT):
In Fabric, there is no "central" registry of the peers on the network. So rather than requiring orgs to send their peer addresses to other orgs out of band, you can use the anchor peer setting in the channel config to allow other orgs to know about your peers
chill37 (Fri, 26 Jan 2018 10:23:47 GMT):
@mastersingh24 could you give me an example of the case? I've been testing, and even if I kill the anchor peer of both org and then update the ledger from one peer, the other peer ledger gets updated from the orderer (naturally). so I'm not really sure what cases need anchor peers to work. thanks!
chill37 (Fri, 26 Jan 2018 10:27:11 GMT):
@mastersingh24 I see. but what msgs do they send each other? when I check the logs(from docker logs), it's always the orderer broadcasting and delivering the blocks
chill37 (Fri, 26 Jan 2018 10:27:56 GMT):
@mastersingh24 is it these gossipmessages?
chill37 (Fri, 26 Jan 2018 10:27:59 GMT):
// *GossipMessage_AliveMsg
// *GossipMessage_MemReq
// *GossipMessage_MemRes
// *GossipMessage_DataMsg
// *GossipMessage_Hello
// *GossipMessage_DataDig
// *GossipMessage_DataReq
// *GossipMessage_DataUpdate
// *GossipMessage_Empty
// *GossipMessage_Conn
// *GossipMessage_StateInfo
mastersingh24 (Fri, 26 Jan 2018 10:32:07 GMT):
Currently, we don't archive / prune the ledger on the orderer so it has the entire history of all blocks. And if the orderer is up and running, peers will simply get blocks from the orderer. In the future, we will start pruning / archiving the orderer ledger and in that case if a peer was behind or joins a channel late, it might not be able to get the missing blocks from the orderer and will need to get them from another peer in the network - possibly from another org's peer. In that case, gossip would be used to get the missing blocks.
Today, inter org gossip is mostly a discovery mechanism
chill37 (Fri, 26 Jan 2018 10:41:39 GMT):
@mastersingh24 ooooooh I see. since orderer is just an ORDER-er, you guys plan to make it so that it will only broadcast the recent blocks. Therefore the rest of the ledger will be on peers only and that's when anchor peer comes up-- when by any chance there's not enough peer or ledger within their org, they will hook up with other org anchor peer and get the data.
chill37 (Fri, 26 Jan 2018 10:42:41 GMT):
And Currently, Gossip is used to find out if peer is dead or alive, get channel list and etc., but in the future it will be used to get the missing blocks from other org as well
mastersingh24 (Fri, 26 Jan 2018 10:42:46 GMT):
correct. it's possible today that peer *might* try get missing blocks from a peer in another org, but not very likely and there is really no way to force this
mastersingh24 (Fri, 26 Jan 2018 10:43:05 GMT):
Gossip can get missing blocks from other peers in your org today
mastersingh24 (Fri, 26 Jan 2018 10:43:34 GMT):
And gossip can be used to only connect one peer in your org to the orderer and then gossip will send to the other peers in the org as well
mastersingh24 (Fri, 26 Jan 2018 10:44:05 GMT):
But as you said, using cross org gossip for blocks is really a future thing
chill37 (Fri, 26 Jan 2018 10:45:09 GMT):
yes. I saw the code from anchor_test.go and was trying to somehow try it in actual code but not possible through chaincode (maybe stop orderer during the process but ....)
chill37 (Fri, 26 Jan 2018 10:45:23 GMT):
I guess mechanism is there but doesn't really appear upfront
mastersingh24 (Fri, 26 Jan 2018 10:45:44 GMT):
@yacovm or @C0rWin can add additional details as well if I missed anything or misspoke here
chill37 (Fri, 26 Jan 2018 10:47:39 GMT):
yes thanks a lot! @mastersingh24 any/all help is appreciated :grin:
C0rWin (Fri, 26 Jan 2018 10:53:19 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=gz3xeF8aris4ZPh3P) @chill37 so to makenit a bit clear, each organization has it’s own “leader” peer which responsible to get connected to the ordering service and pull out the blocks to distribute across peers in org network
C0rWin (Fri, 26 Jan 2018 10:55:11 GMT):
The anchor peers as @mastersingh24 already explained used to advertise membership across different orgs and then used to facilitate state transfer and sync of the peers which are lagging behind due to network misbehavior or simply because joined late
chill37 (Fri, 26 Jan 2018 10:58:55 GMT):
@C0rWin I did see the "leader" peer mechanism (via election and IsLeader) but when I see log from orderer, it seems as though they are delivering blocks to all peers.
chill37 (Fri, 26 Jan 2018 10:59:51 GMT):
This is from Tuna-App example. I've modified a bit by : 2 org, 2 peers each org, 1 anchor peer each org, etc
chill37 (Fri, 26 Jan 2018 10:59:54 GMT):
2018-01-26 10:55:57.072 UTC [orderer/common/deliver] deliverBlocks -> DEBU 8d2 [channel: mychannel]
Delivering block for (0xc42036ee20) for 172.18.0.12:58404
chill37 (Fri, 26 Jan 2018 11:00:17 GMT):
I saw 4 of this Log in the orderer side, so i got confused
yacovm (Fri, 26 Jan 2018 11:12:19 GMT):
That's because the tuna app docker-compose.yaml doesn't use leader election
yacovm (Fri, 26 Jan 2018 11:12:24 GMT):
and by default in v1.0 it's false https://github.com/hyperledger/fabric/blob/release/sampleconfig/core.yaml#L123
yacovm (Fri, 26 Jan 2018 11:12:45 GMT):
https://github.com/hyperledger/education/blob/master/LFS171x/fabric-material/basic-network/docker-compose.yml
yacovm (Fri, 26 Jan 2018 11:13:16 GMT):
So, there is another configuration that bypasses leader election and manually defines a peer to be a leader or not
yacovm (Fri, 26 Jan 2018 11:13:31 GMT):
and in v1.0 by default it's set to be a leader manually
chill37 (Fri, 26 Jan 2018 11:15:54 GMT):
@yacovm I see. I didn't pay too much attention to the settings. my bad. Thanks!! I've understood more from this chat-log than last 2 days!
chill37 (Fri, 26 Jan 2018 11:16:51 GMT):
Thanks for all the help @yacovm @C0rWin @mastersingh24
yacovm (Fri, 26 Jan 2018 11:17:11 GMT):
just to complete the picture
yacovm (Fri, 26 Jan 2018 11:17:19 GMT):
look at the fabric e2e_cli docker compose example
yacovm (Fri, 26 Jan 2018 11:17:42 GMT):
https://github.com/hyperledger/fabric/blob/release/examples/e2e_cli/base/peer-base.yaml#L19-L20
chill37 (Fri, 26 Jan 2018 11:27:28 GMT):
ok~ will look at those leader election settings
RobertDiebels (Fri, 26 Jan 2018 20:25:08 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=bHrzGkq22DivsmZ26) @jeffgarratt Thanks for the answer. Can use this :D
DusanKovacevic (Fri, 26 Jan 2018 20:46:07 GMT):
Has joined the channel.
DennisNewel (Fri, 26 Jan 2018 21:01:11 GMT):
Has joined the channel.
DennisNewel (Fri, 26 Jan 2018 21:28:24 GMT):
hey, trying to learn more about how a private, permissioned chain works, and was directed here from #general. I've looked at the documentation but want to make sure i've understood the various type of nodes. How i currently see it, clients would be what users interact with, e.g. on a webpage or a mobile app; peers are the ones who maintain the ledger and there should be at least two, owned by different parties in the network; orderers are more of a service node, that is part of ensuring everything runs as it should, and there could just be one of those in a really small network. Is this a correct understanding?
jeffgarratt (Fri, 26 Jan 2018 21:52:46 GMT):
@DennisNewel Orderer(s) are the only required component in the system, and serve as the bootstrap mechanism for the network.
DennisNewel (Fri, 26 Jan 2018 21:57:20 GMT):
@jeffgarratt hmm...don't you need the peers to actually store the transaction on the ledger?
jeffgarratt (Fri, 26 Jan 2018 21:58:01 GMT):
the creation of a chain does NOT require a peer
jeffgarratt (Fri, 26 Jan 2018 21:59:15 GMT):
the orderer also stores the transaction
jeffgarratt (Fri, 26 Jan 2018 21:59:33 GMT):
the peer adds the additional context of TX result wrt to Validation
jeffgarratt (Fri, 26 Jan 2018 22:00:22 GMT):
I was trying to convey that the orderer actually represents the single most important component
jeffgarratt (Fri, 26 Jan 2018 22:00:31 GMT):
vs the language of a service node :)
DennisNewel (Fri, 26 Jan 2018 22:00:53 GMT):
ah, ok :) not the right phrasing i see
DennisNewel (Fri, 26 Jan 2018 22:01:49 GMT):
my main question right now is, how do i practically add a 3rd party to my (theoretical) network? will they need to setup their own orderer and peers, or just one of them?
jeffgarratt (Fri, 26 Jan 2018 22:01:57 GMT):
peers can come and go, but the chain is completely dependent on orderer(s)
jeffgarratt (Fri, 26 Jan 2018 22:02:10 GMT):
wrt to perpetuation/growth
jeffgarratt (Fri, 26 Jan 2018 22:03:13 GMT):
the concept of adding an org must first be contextualized, i.e. do you mean to an existing channel?
jeffgarratt (Fri, 26 Jan 2018 22:03:27 GMT):
or.. to the consortium from which a channel is to be created?
jeffgarratt (Fri, 26 Jan 2018 22:03:56 GMT):
This is where the term network may be ambiguous
jeffgarratt (Fri, 26 Jan 2018 22:04:33 GMT):
I will presume you mean channel (which is synonymous with chain)
DennisNewel (Fri, 26 Jan 2018 22:04:40 GMT):
ok, i'm probably thinking channel
jeffgarratt (Fri, 26 Jan 2018 22:05:17 GMT):
then orderer(s) are externalized, and the org would generally setup their own peers
DennisNewel (Fri, 26 Jan 2018 22:05:40 GMT):
i'm envisioning a system where X vendors can hand out tokens as proof of a person having completed a task; only vendors can hand out the tokens, but the end users can claim a benefit with the tokens later on
DennisNewel (Fri, 26 Jan 2018 22:07:14 GMT):
by "externalized" you mean reachable by other parties? or that the orderer(s) are managed by different parties?
jeffgarratt (Fri, 26 Jan 2018 22:07:20 GMT):
the latter
DennisNewel (Fri, 26 Jan 2018 22:08:09 GMT):
so in my example, each vendor would setup their own orderer, and perhaps a couple of peers, while the end users would use clients to connect to one of the orderers in order to view their tokens?
DennisNewel (Fri, 26 Jan 2018 22:10:20 GMT):
...and the peers would mainly be endorsing peers?
jeffgarratt (Fri, 26 Jan 2018 22:10:23 GMT):
@DennisNewel you may find #composer and its asset/participant model applicable to your problem
DennisNewel (Fri, 26 Jan 2018 22:11:23 GMT):
yeah, i played with an online sandbox version of that - seemed to be exactly what i was looking for. I'm assuming that still "runs on top of" fabric?
DennisNewel (Fri, 26 Jan 2018 22:14:01 GMT):
i can see i have a lot more to read up on with composer - i'll start with that but might return with more questions :)
DennisNewel (Fri, 26 Jan 2018 22:14:17 GMT):
thank you for you help!
SjirNijssen (Sun, 28 Jan 2018 09:41:32 GMT):
Has joined the channel.
asaningmaxchain123 (Sun, 28 Jan 2018 17:30:43 GMT):
@jeffgarratt @mastersingh24 i use the mac to execute the e2e_cli ,i got the following error,can you take a look?
asaningmaxchain123 (Sun, 28 Jan 2018 17:32:36 GMT):
```Error: Error endorsing chaincode: rpc error: code = Unknown desc = error starting container: Failed to generate platform-specific docker build: Error returned from build: 1 "chaincode/input/src/github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02/chaincode_example02.go:23:2: cannot find package "github.com/hyperledger/fabric/core/chaincode/shim" in any of:
/opt/go/src/github.com/hyperledger/fabric/core/chaincode/shim (from $GOROOT)
/chaincode/input/src/github.com/hyperledger/fabric/core/chaincode/shim (from $GOPATH)
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/shim
chaincode/input/src/github.com/hyperledger/fabric/e```
asaningmaxchain123 (Sun, 28 Jan 2018 17:33:37 GMT):
i set the GOPATH=GOPATH=/Users/chenxuan/go
asaningmaxchain123 (Sun, 28 Jan 2018 17:33:37 GMT):
i set the GOPATH=/Users/chenxuan/go
asaningmaxchain123 (Sun, 28 Jan 2018 17:34:22 GMT):
it seems the peer instantiate chaincode,it use the GOPATH=/opt/gopath
asaningmaxchain123 (Sun, 28 Jan 2018 17:34:22 GMT):
it seems the peer instantiate chaincode,it use the GOPATH=/opt/go
asaningmaxchain123 (Mon, 29 Jan 2018 01:37:48 GMT):
the above is the cli log
asaningmaxchain123 (Mon, 29 Jan 2018 01:38:01 GMT):
the below is the peer logs
asaningmaxchain123 (Mon, 29 Jan 2018 01:38:14 GMT):
```2018-01-28 17:38:51.729 UTC [endorser] simulateProposal -> ERRO 5f7 [mychannel][11ab928d] failed to invoke chaincode name:"lscc" , error: Failed to generate platform-specific docker build: Error returned from build: 1 "chaincode/input/src/github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02/chaincode_example02.go:23:2: cannot find package "github.com/hyperledger/fabric/core/chaincode/shim" in any of:
/opt/go/src/github.com/hyperledger/fabric/core/chaincode/shim (from $GOROOT)
/chaincode/input/src/github.com/hyperledger/fabric/core/chaincode/shim (from $GOPATH)
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/shim
chaincode/input/src/github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02/chaincode_example02.go:24:2: cannot find package "github.com/hyperledger/fabric/protos/peer" in any of:
/opt/go/src/github.com/hyperledger/fabric/protos/peer (from $GOROOT)
/chaincode/input/src/github.com/hyperledger/fabric/protos/peer (from $GOPATH)
/opt/gopath/src/github.com/hyperledger/fabric/protos/peer
"
error starting container
```
AshishMishra 1 (Mon, 29 Jan 2018 09:12:17 GMT):
Has joined the channel.
AshishMishra 1 (Mon, 29 Jan 2018 09:40:25 GMT):
Hi guys, can someone give me an idea what the following arguments do w.r.t to a peer.
- CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer1.org2.example.com:7051
- CORE_PEER_GOSSIP_BOOTSTRAP=peer1.org2.example.com:7051
- CORE_PEER_GOSSIP_USELEADERELECTION=true
- CORE_PEER_GOSSIP_ORGLEADER=false
- CORE_PEER_PROFILE_ENABLED=true
1. For the gossip external endpoint, will be always the identity of that peer itself? If that's the case why do we need an argument at all.
2. What identity to use in the gossipbootstrap ? For eg. I 've a multi-org, multipeer setup. Will it be same across all the peers in the same org?
3. CORE_PEER_GOSSIP_USELEADERELECTION - What's the implication of setting it true or false? and when should I set it to false. Should it be same on all the peers in an Org.
4. CORE_PEER_GOSSIP_ORGLEADER=false and CORE_PEER_PROFILE_ENABLED=true. No idea what they are.
I feel there is a lack of documentation for such arguments.
yacovm (Mon, 29 Jan 2018 11:12:29 GMT):
@AshishMishra 1 https://github.com/hyperledger/fabric/blob/release/sampleconfig/core.yaml#L104-L190
yacovm (Mon, 29 Jan 2018 11:12:35 GMT):
it's all in that file
AshishMishra 1 (Mon, 29 Jan 2018 11:47:30 GMT):
@yacovm , thanks will have a look.
rockleelx (Tue, 30 Jan 2018 04:13:19 GMT):
Has joined the channel.
rake66 (Tue, 30 Jan 2018 14:00:16 GMT):
Has joined the channel.
AshishMishra 1 (Tue, 30 Jan 2018 15:20:30 GMT):
Hi team,
AshishMishra 1 (Tue, 30 Jan 2018 15:22:58 GMT):
Can I have a endorsement policy specific for peers? Say I have a 1 org only n/w and it has 4-5 peers, out of which I want 2 peers to endorse always out of the total 5. Where my peer-id 1 needs to mandatory endorse the transaction. The examples and doc says org.member, so can I be specific here like org.member1 ? Thanks
jeffgarratt (Tue, 30 Jan 2018 15:53:19 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=SRcd8fiszgwsbq6NW) @AshishMishra 1 you can require 2 signatures from the same ORG, in which they must be different
jeffgarratt (Tue, 30 Jan 2018 15:54:03 GMT):
if you wish to require specific peers, then you could add their specific cert to the endorsement policy
AshishMishra 1 (Tue, 30 Jan 2018 16:03:55 GMT):
@jeffgarratt and If I want to mandate a particular peer to endorse it, can I do it?
jeffgarratt (Tue, 30 Jan 2018 16:04:11 GMT):
yes, you need to use a Identity principal vs a Role
jeffgarratt (Tue, 30 Jan 2018 16:04:27 GMT):
and choose the peer's identity cert
jeffgarratt (Tue, 30 Jan 2018 16:04:33 GMT):
in signcerts I believe
AshishMishra 1 (Tue, 30 Jan 2018 16:05:12 GMT):
Sounds interesting.. is there documentation for reference for this?
jeffgarratt (Tue, 30 Jan 2018 16:05:22 GMT):
checking...
jeffgarratt (Tue, 30 Jan 2018 16:05:40 GMT):
http://hyperledger-fabric.readthedocs.io/en/latest/policies.html?highlight=Principal%20Role
jeffgarratt (Tue, 30 Jan 2018 16:07:18 GMT):
specifically -> http://hyperledger-fabric.readthedocs.io/en/latest/policies.html?highlight=Principal%20Role#msp-principals
AshishMishra 1 (Tue, 30 Jan 2018 16:08:57 GMT):
Thanks @jeffgarratt, will have a look. :)
rickr (Tue, 30 Jan 2018 21:19:44 GMT):
Only the peer admin can install cc on peer peers in their own organization. Can they do an instantiate proposal on a peer that's from another org ? Not sure, the need to do that given instantiate needs to be only done once and I assume they could do it on their own peer. But I think I'm seeing it work on a peer (in the channel) but from another organization
rickr (Tue, 30 Jan 2018 21:19:44 GMT):
Only the peer admin can install cc on peers in their own organization. Can they do an instantiate proposal on a peer that's from another org ? Not sure, the need to do that given instantiate needs to be only done once and I assume they could do it on their own peer. But I think I'm seeing it work on a peer (in the channel) but from another organization
jeffgarratt (Tue, 30 Jan 2018 21:59:40 GMT):
@rickr a config admin can endorse the instantiate on other organization's peer(s)
aceyin (Wed, 31 Jan 2018 06:37:54 GMT):
Has joined the channel.
asaningmaxchain123 (Wed, 31 Jan 2018 11:24:25 GMT):
hello everyone,i got the following error when i use java-sdk to test the .new version fabric
asaningmaxchain123 (Wed, 31 Jan 2018 11:24:30 GMT):
``` gRPC failure=Status{code=UNIMPLEMENTED, description=unknown service protos.Endorser, cause=null}```
asaningmaxchain123 (Wed, 31 Jan 2018 16:08:29 GMT):
@jeffgarratt @yacovm in the v1.1 the fabric support the event,
asaningmaxchain123 (Wed, 31 Jan 2018 16:08:29 GMT):
@jeffgarratt @yacovm in the v1.1 the fabric support the event for the peer,it doesn't use the EventHub
asaningmaxchain123 (Wed, 31 Jan 2018 16:08:29 GMT):
@jeffgarratt @yacovm in the v1.1 the fabric support the event for the peer,it doesn't use the EventHub @wlahti
frankz (Thu, 01 Feb 2018 01:18:04 GMT):
Has joined the channel.
vchengsong (Thu, 01 Feb 2018 03:50:54 GMT):
Has joined the channel.
vchengsong (Thu, 01 Feb 2018 03:52:54 GMT):
Is it possible to take a relational database as the statedb, such as postgresql or mysql
rake66 (Thu, 01 Feb 2018 10:39:12 GMT):
no
sghost (Thu, 01 Feb 2018 18:58:25 GMT):
Has joined the channel.
sghost (Thu, 01 Feb 2018 19:07:32 GMT):
Hello Guys, I want to know one thing regarding the server configuration for different peers and organisation in fabric blockchain? Is it always localhost by default?
sghost (Thu, 01 Feb 2018 19:07:58 GMT):
And if this is the case, where exactly we configure it?
rickr (Fri, 02 Feb 2018 02:59:45 GMT):
@wlahti @C0rWin For the new peer eventing service should a peer admin from one organization be able to register to get events from a peer in another organization?
Glen (Fri, 02 Feb 2018 03:15:11 GMT):
Hi @mastersingh24 If I have mutiple endorser peers in my blockchain network, will the chaincode execute the Init function on all peers, or in other words, only need to instantiate it on one peer, the others can't be instantiated repeatedly?
wlahti (Fri, 02 Feb 2018 03:47:48 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=knJnjwqm64RDE5DDH) @rickr Yes, I haven't tried that in my own scenarios but I'd expect that to work.
wlahti (Fri, 02 Feb 2018 03:47:48 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=knJnjwqm64RDE5DDH) @rickr Yes, I haven't tried that in my own scenarios but I'd expect that to work with the default block and filtered block policies (which both default to the channel readers).
rickr (Fri, 02 Feb 2018 04:05:21 GMT):
Thanks Will . I was experiencing an issue and I initially started attributing it to possibly that After deeper exploration I found the real reason and I was able to register a peer from another org.
rickr (Fri, 02 Feb 2018 04:05:21 GMT):
Thanks @wlahti . I was experiencing an issue and I initially started attributing it to possibly that After deeper exploration I found the real reason and I was able to register a peer from another org.
rickr (Fri, 02 Feb 2018 04:21:47 GMT):
BTW the real issue was that I could not register to get events on that peer (for the other org) till it too had joined the channel.
hushun (Fri, 02 Feb 2018 05:27:29 GMT):
Has joined the channel.
C0rWin (Fri, 02 Feb 2018 19:13:19 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=8B3NjAW88Hc6dj8QB) @rickr which is obviously expected behavior, for peer to be able to publish events it has to join the channel.
rickr (Fri, 02 Feb 2018 19:19:21 GMT):
But painful for any user know which organization have joined in
C0rWin (Fri, 02 Feb 2018 19:26:02 GMT):
while this is being true, you cannot expect peer which was not joined the channel to deliver blocks or event on behalf of something he is not part of... once we will have service discovery users life will be easier
rickr (Fri, 02 Feb 2018 19:28:20 GMT):
... and I think many of us working closely with Fabric will understand that .. My gut feel is this will catch many users off guard ...
yacovm (Fri, 02 Feb 2018 19:39:29 GMT):
We have 2 types of access control in fabric - per channel and "per node".
The former is what you use authenticate access to business logic data, and the latter is what you use to authorize administrative operations, like joining a peer to a channel, etc.
yacovm (Fri, 02 Feb 2018 19:39:29 GMT):
We have 2 types of access control in fabric - per channel (which is backed by the blockchain) and "per node" (local configuration).
The former is what you use authenticate access to business logic data, and the latter is what you use to authorize administrative operations, like joining a peer to a channel, etc.
yacovm (Fri, 02 Feb 2018 19:40:17 GMT):
It only makes sense that a user that wants to get data in a channel context, would need to be authenticated by the channel, which means - it needs to be a channel member
yacovm (Fri, 02 Feb 2018 19:43:00 GMT):
> But painful for any user know which organization have joined in
It only needs to know it is inside, no need to know the rest
yacovm (Fri, 02 Feb 2018 19:46:06 GMT):
> BTW the real issue was that I could not register to get events on that peer (for the other org) till it too had joined the channel.
Wait, @rickr are you saying you were not able to register for events for a channel until the peer itself had joined the channel ?
krisava (Sun, 04 Feb 2018 17:24:36 GMT):
Hi, This is regarding the "Blockchain Instance on Bluemix", in the "Blockchain-GUI".
What is the purpose of the "Certificates tab under Members"?
As I could able to post a transaction or read a transaction from the client connecting to the "Peer" without even uploading the "Client side certificate" on to the "Certificates tab under Members".
So, I am not sure what is the purpose of "Certificates tab under Members". And how is it secure to control the client to Post or Read transactions from Blockchain? Thanks.
mastersingh24 (Mon, 05 Feb 2018 12:01:10 GMT):
@krisava - RocketChat is for questions on the open source project only. If you have questions on particular vendor implementations, you'll need to use their communities. For IBM Blockchain, you can post here: https://www.ibm.com/developerworks/community/forums/html/category?id=21b0dce5-e391-4030-bc60-16c17173ea32
rickr (Mon, 05 Feb 2018 13:32:17 GMT):
https://chat.hyperledger.org/channel/fabric-sdk-java?msg=f4Juz8RnZKwd7xoRM And please don't cross post the very same question in numerous channels
krisava (Mon, 05 Feb 2018 14:25:33 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=DRfxdgGRYPwwWXqdn) @mastersingh24 Thanks, @mastersingh24
awattez (Mon, 05 Feb 2018 15:44:32 GMT):
Has joined the channel.
rickr (Wed, 07 Feb 2018 16:01:23 GMT):
For the new peer eventing service what credentials by default are needed ? Only peer admin can register this on all peers that have joined the channel, or can any Fabric CA enrolled user member do this? If member can't, is that just default ACL setting that can be changed?
rickr (Wed, 07 Feb 2018 16:01:23 GMT):
For the new peer eventing service what credentials by default are needed for registration? Only peer admin can register this on all peers that have joined the channel, or can any Fabric CA enrolled user member do this? If member can't, is that just default ACL setting that can be changed?
yacovm (Wed, 07 Feb 2018 16:07:17 GMT):
channel reader by default
yacovm (Wed, 07 Feb 2018 16:07:26 GMT):
unless configured otherwise via acl , from what I know
wlahti (Wed, 07 Feb 2018 17:33:52 GMT):
To expand on what @yacovm wrote, the new peer event services use the BLOCKEVENT and FILTEREDBLOCKEVENT resource policies, which both default to the Channel Readers policy. Those policies can be updated for the channel to allow access for any desired users. I believe the documentation for the new mechanism of setting / updating resource policies is still a work in progress, so I haven't been able to try it out in a real network.
wlahti (Wed, 07 Feb 2018 17:33:52 GMT):
@rickr To expand on what @yacovm wrote, the new peer event services use the BLOCKEVENT and FILTEREDBLOCKEVENT resource policies, which both default to the Channel Readers policy. Those policies can be updated for the channel to allow access for any desired users. I believe the documentation for the new mechanism of setting / updating resource policies is still a work in progress, so I haven't been able to try it out in a real network.
wlahti (Wed, 07 Feb 2018 17:33:52 GMT):
@rickr - To expand on what @yacovm wrote, the new peer event services use the BLOCKEVENT and FILTEREDBLOCKEVENT resource policies, which both default to the Channel Readers policy. Those policies can be updated for the channel to allow access for any desired users. I believe the documentation for the new mechanism of setting / updating resource policies is still a work in progress, so I haven't been able to try it out in a real network.
inatatsu (Thu, 08 Feb 2018 02:40:44 GMT):
Has left the channel.
ohmeraka (Sun, 11 Feb 2018 08:48:57 GMT):
Has joined the channel.
Bchainer (Mon, 12 Feb 2018 05:09:35 GMT):
Has joined the channel.
AshishMishra 1 (Mon, 12 Feb 2018 12:58:00 GMT):
Hi team, today I noticed.. few errors in my peer logs..
2018-02-12 12:18:54.009 UTC [gossip/state] queueNewMessage -> WARN 2b3 Failed adding payload: Ledger height is at 492, cannot enqueue block with sequence of 600
AND
2018-02-12 12:19:02.509 UTC [gossip/state] handleStateResponse -> WARN 2c8 Payload with sequence number 621 wasn't added to payload buffer: Payload with sequence number = 621 has been already processed
What do they imply and should I be worried ? as it's just warning.
I have set the log level to error, then also why I 'm seeing this.
wlahti (Mon, 12 Feb 2018 19:09:49 GMT):
@AshishMishra 1 I can't speak to what the messages imply but in regards to your question about why you see this warning-level error message in the logs, it's due to the override level for CORE_LOGGING_GOSSIP in core.yaml, which defaults to `warning`.
DarshanBc (Tue, 13 Feb 2018 06:01:23 GMT):
each of my transaction is taking around 3 sec any idea why is it?
AshishMishra 1 (Tue, 13 Feb 2018 07:04:56 GMT):
@DarshanBc because of the block time of 2 sec by default. The orderer service will wait for 2 secs or 10 transactions to commit into the peers.
DarshanBc (Tue, 13 Feb 2018 07:07:19 GMT):
blocktime is fine trasaction should be commited ryt block formation is a different process
AshishMishra 1 (Tue, 13 Feb 2018 07:57:16 GMT):
until a block is commited, how can you form a block?
Lucifer (Wed, 14 Feb 2018 05:14:47 GMT):
Has joined the channel.
shalinigpt (Wed, 14 Feb 2018 09:08:58 GMT):
Has joined the channel.
eclairamb (Sat, 17 Feb 2018 18:01:39 GMT):
Has joined the channel.
iamdm (Mon, 19 Feb 2018 11:40:02 GMT):
Hi all! i have some issue about peer. I have next steps:
1. Instantiating chaincode with sdk
2. Invoking chaincode
3. Querying chaincode
Steps 1,2 -ok, but on step 3 i have next error: failed to get my identity: SendTransactionProposal failed: Transaction processor (peer:7051) returned error for txID \'4d488fe0b0958b77ac33c37f729eb46f43105212306c8e63f5c824b633db4a69\': gRPC Transport Status Code: (2) Unknown. Description: error executing chaincode: error chaincode is already launching: network:0.1
iamdm (Mon, 19 Feb 2018 11:40:32 GMT):
I don't understand how I could to invoke chaincode when it's not started?
yacovm (Mon, 19 Feb 2018 11:40:54 GMT):
wait a second
yacovm (Mon, 19 Feb 2018 11:41:03 GMT):
you're saying you invoked the chaincode and then you can't query it?
yacovm (Mon, 19 Feb 2018 11:41:06 GMT):
that doesn't make sense
iamdm (Mon, 19 Feb 2018 11:41:20 GMT):
yes
yacovm (Mon, 19 Feb 2018 11:41:28 GMT):
what do the peer logs say?
iamdm (Mon, 19 Feb 2018 11:41:41 GMT):
i invoked chaincode, i saw that state was changed in logs
iamdm (Mon, 19 Feb 2018 11:41:43 GMT):
ok, sec
vitiko (Mon, 19 Feb 2018 11:45:18 GMT):
Has joined the channel.
iamdm (Mon, 19 Feb 2018 11:57:32 GMT):
This is first successful invoke: https://pastebin.com/5XYnKmBW
iamdm (Mon, 19 Feb 2018 11:57:51 GMT):
And this is unsuccessful query: https://pastebin.com/wZ691Hqj
iamdm (Mon, 19 Feb 2018 12:02:54 GMT):
Maybe, problem in version: 1.1.0-preview? It looks like chaincode restaring after invoke
iamdm (Mon, 19 Feb 2018 12:02:54 GMT):
Maybe, problem in version: 1.1.0-preview? It looks like chaincode restarting after invoke
iamdm (Mon, 19 Feb 2018 13:19:35 GMT):
I changed to 1.1.0-alpha and got next error in instantiation:
`peer_1 | 2018-02-19 13:14:09.240 UTC [chaincode] isValidTxSim -> ERRO f33 [[4bc56fab PUT_STATE ERROR]]No ledger context for %!!(MISSING)s(MISSING). Sending %!!(MISSING)s(MISSING)`
iamdm (Mon, 19 Feb 2018 13:19:43 GMT):
Any ideas?
GaneshSharma (Mon, 19 Feb 2018 16:32:00 GMT):
Has joined the channel.
RobertDiebels (Mon, 19 Feb 2018 17:26:46 GMT):
Has left the channel.
MoulaliMvg (Wed, 21 Feb 2018 12:48:52 GMT):
Has joined the channel.
novusopt (Wed, 21 Feb 2018 16:19:02 GMT):
Hi guys, I am facing TxValidationCode_PHANTOM_READ_CONFLICT. Can someone explain what this validation code mean. Thx
novusopt (Wed, 21 Feb 2018 16:19:02 GMT):
Hi guys, I am facing TxValidationCode_PHANTOM_READ_CONFLICT. Can someone explain what this validation code mean. Thx
silliman (Wed, 21 Feb 2018 16:28:44 GMT):
@novusopt Here is my guess- if you do a rich query in your chaincode a hash of the query's results is put in the R/W set placed in the endorsement response. As the transaction goes through the flow, at validation time the rich query is run again. If the hash of the result at this time doesn't match the hash in the R/W set, you'll get that error.
daanporon (Wed, 21 Feb 2018 16:29:58 GMT):
Has joined the channel.
daanporon (Wed, 21 Feb 2018 16:31:01 GMT):
i'm having issues with an invoke that doesn't want to be accepted, i always get the error 'ENDORSEMENT_POLICY_FAILED' while i don't have a policy set for that chaincode
daanporon (Wed, 21 Feb 2018 16:31:07 GMT):
```
```
daanporon (Wed, 21 Feb 2018 16:31:55 GMT):
log
daanporon (Wed, 21 Feb 2018 16:32:29 GMT):
it says ```2018-02-21 16:28:16.121 UTC [cauthdsl] func1 -> DEBU 2b54 0xc42000fb78 gate 1519230496120153177 evaluation fails``` but i'm not sure why, any idea?
minollo (Wed, 21 Feb 2018 16:34:19 GMT):
Not quite; rich queries are not re-executed at validation time (in the current Fabric code); the error is about validation of *range* queries:
// validateRangeQuery performs a phatom read check i.e., it
// checks whether the results of the range query are still the same when executed on the
// statedb (latest state as of last committed block) + updates (prepared by the writes of preceding valid transactions
// in the current block and yet to be committed as part of group commit at the end of the validation of the block)
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=pdbufZcPsmAXBojeX) @silliman
silliman (Wed, 21 Feb 2018 16:38:07 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=mpoxgxdB6fXkMNQ7R) @minollo
My apologies- you are correct- I used the wrong term- I should have said *range* queries and not *rich* queries. I misquoted from section 4.4 of the recently released paper available from https://arxiv.org/abs/1801.10228v1
novusopt (Wed, 21 Feb 2018 16:47:33 GMT):
@minollo @silliman thx, correct me if I am wrong, as far as I understand it, that means every time I have range query the hash of the query result will be added to the r/w set. In case of a tx which is changing the "range" and immedialtey afterwards a new tx with the same hash will face this issue. Because the hash of the range has changed. is this right?
novusopt (Wed, 21 Feb 2018 16:47:33 GMT):
@minollo @silliman thx, correct me if I am wrong, as far as I understand it, that means every time I query a range the hash of the query result will be added to the r/w set. In case of a tx which is changing the "range" and immedialtey afterwards a new tx with the same hash will face this issue. Because the hash of the range has changed. is this right?
silliman (Wed, 21 Feb 2018 16:56:55 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=G5TLG6gSwJbPJjmLn) @novusopt
I won't correct you because I don't think you are wrong. But if I'm wrong about you not being wrong then somebody can correct me at the same time they correct you.
novusopt (Wed, 21 Feb 2018 16:57:22 GMT):
@silliman ok thanks a lot :)
jrosmith (Thu, 22 Feb 2018 17:13:25 GMT):
hey all, is there a built in health check function for a peer or should i just be pinging its request port to check?
jeffgarratt (Thu, 22 Feb 2018 18:13:27 GMT):
@jrosmith there is a getStatus call on the Admin interface for the peer
jeffgarratt (Thu, 22 Feb 2018 18:14:05 GMT):
and the command 'peer node status' will hit that interface
jrosmith (Thu, 22 Feb 2018 21:17:41 GMT):
@jeffgarratt thank you!
jeffgarratt (Thu, 22 Feb 2018 21:18:00 GMT):
your welcome!
mujji89 (Fri, 23 Feb 2018 18:29:32 GMT):
Has joined the channel.
mujji89 (Fri, 23 Feb 2018 18:31:04 GMT):
Hi guys, I am running java sdk on windows and trying to run End2End test
mujji89 (Fri, 23 Feb 2018 18:31:12 GMT):
I am getting this error any idea what it could be?
mujji89 (Fri, 23 Feb 2018 18:31:14 GMT):
main ERROR Channel:2412 - Sending proposal to peer0.org1.example.com failed because of: gRPC failure=Status{code=UNKNOWN, description=failed to execute transaction: timeout expired while executing transaction
mujji89 (Fri, 23 Feb 2018 18:31:35 GMT):
ORG_HYPERLEDGER_FABRIC_SDK_PROPOSAL_WAIT_TIME=80000 already increased this
jrosmith (Fri, 23 Feb 2018 21:02:46 GMT):
question, after a block gets ordered it gets blasted to all of the committing peers to be appended to the ledger, yes? the peers then alert an sdk about the successful commitment. does this alert happen after being appended to the ledger or after it has been updated in the stateDB?
jrosmith (Fri, 23 Feb 2018 21:02:46 GMT):
question, after a block gets ordered it gets blasted to all of the committing peers to be appended to the ledger, yes? the peers then alert an sdk about the successful commitment. does this alert happen after being appended to the ledger or after the transaction has been inserted into the stateDB?
Brucepark (Sat, 24 Feb 2018 12:30:37 GMT):
When the endorsement policy is `AND (Org1.member, Org2.member)`,
My cli can only connect to peers in Org1.
In this situation, how can my cli obtain the endorsement of Org2?
Brucepark (Sat, 24 Feb 2018 12:30:37 GMT):
The endorsement policy is `AND (Org1.member, Org2.member)`
and my cli can only connect to peers in Org1.
In this situation, how can my cli obtain the endorsement of Org2?
jeffgarratt (Sat, 24 Feb 2018 13:57:36 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=mi5tTAj9RWuofsmZk) @Brucepark this is technically feasible, but seems counter to the standard usage of endorsements (i.e. a client should be able to collect the proper endorsements). However, it may be technically feasible to create a SignedProposal and have the other org get an endorsement and return the ProposalResponse back to you which you could package into a Tx if you so choose. But this would cumbersome comparatively even if technically doable.
jeffgarratt (Sat, 24 Feb 2018 13:59:37 GMT):
@Brucepark not having access to an endorsing peer would represent one way in which a party could reasonably halt activity in a channel. If you don't have access, I assume either a misconfigured system or the other party does not want you to
Brucepark (Mon, 26 Feb 2018 02:12:19 GMT):
Thank you for your reply.
I asked the question because I need to configure the ACL on the network.
There are internal server zone and external server zone.
I thought the client should be inside and peer should be in both zone.
If the client must be connected to another org's peer, it must be in external server zone.
You said that it is technically feasible, but I wonder if it is supported by v1.1.[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=zaXcHwYaCzeRcw3wc) @jeffgarratt
Brucepark (Mon, 26 Feb 2018 02:15:52 GMT):
If the client is in external zone, I need to be concerned about security.
Because it would be a kind of server.
So I want to have a client inside but I wonder if it is possible in current version.
Brucepark (Mon, 26 Feb 2018 02:15:52 GMT):
@jeffgarratt If the client is in external zone, I need to be concerned about security.
Because it would be a kind of server.
So I want to have a client inside but I wonder if it is possible in current version.
Brucepark (Mon, 26 Feb 2018 02:15:52 GMT):
@jeffgarratt If the client is in external zone, I need to be concerned about security.
Because it would be a kind of server.
So I want to locate a client inside but I wonder if it is possible in current version.
Brucepark (Mon, 26 Feb 2018 02:15:52 GMT):
@jeffgarratt If the client is in external zone, I need to be concerned about security because it would be a kind of server.
So I want to locate a client inside but I wonder if it is possible in current version.
ganeshraut (Mon, 26 Feb 2018 06:19:37 GMT):
Has joined the channel.
ganeshraut (Mon, 26 Feb 2018 06:20:29 GMT):
Hi Folks,
can any one guide me how to join new machine in block chain environment. to add peer
ganeshraut (Mon, 26 Feb 2018 06:20:35 GMT):
?
ganeshraut (Mon, 26 Feb 2018 06:20:45 GMT):
thanks in advance
novusopt (Mon, 26 Feb 2018 07:41:59 GMT):
Hi guys, is there a way to check if a peer is still running?
novusopt (Mon, 26 Feb 2018 07:41:59 GMT):
Hi guys, is there a standard way to check if a peer is still running?
novusopt (Mon, 26 Feb 2018 07:42:57 GMT):
(e.g. curl or the like)
wlahti (Mon, 26 Feb 2018 13:29:53 GMT):
@novusopt From CLI, you can use the `peer node status` command (setting CORE_PEER_ADDRESS to point to the peer you're interested in) to check if a peer is still running. Not sure if there's a mechanism to do this from SDKs.
chaitanya (Mon, 26 Feb 2018 15:42:34 GMT):
Has joined the channel.
chaitanya (Mon, 26 Feb 2018 15:43:46 GMT):
I'm getting the following error on using Fabric v1.0.3 images :
```
gRPC failure=Status{code=UNKNOWN, description=Error executing chaincode: premature execution - chaincode is being launched, cause=null}. Was verified:false
```
This shows up when the network is left idle for a bit, and then invokes are sent via SDK. The peer tries to kill the chaincode containers and once they come up again, the invokes start going through again.
Any idea as to whats happening here?
chaitanya (Mon, 26 Feb 2018 15:43:46 GMT):
Hi, I'm getting the following error on using Fabric v1.0.3 images :
```
gRPC failure=Status{code=UNKNOWN, description=Error executing chaincode: premature execution - chaincode is being launched, cause=null}. Was verified:false
```
This shows up when the network is left idle for a bit, and then invokes are sent via SDK. The peer tries to kill the chaincode containers and once they come up again, the invokes start going through again.
Any idea as to whats happening here?
Brucepark (Tue, 27 Feb 2018 04:52:12 GMT):
In an environment with two Orgs and four peers (each org has 2 peers),
During the test, four peers died at the same time.
The error messages are all the same.
Is it a bug?
`
2018-02-27 02:37:35.590 UTC [gossip/state] commitBlock -> ERRO f8a4bf Got error while committing(Invoke VSCC failed for transaction txid=72d936d31215731f58bf0b71b85cb9b7db544eceaa51246d1df1483c39833697, error error executing chaincode: failed to execute transaction: timeout expired while executing transaction
Validation failed
github.com/hyperledger/fabric/gossip/state.(*GossipStateProviderImpl).commitBlock
/opt/gopath/src/github.com/hyperledger/fabric/gossip/state/state.go:778
github.com/hyperledger/fabric/gossip/state.(*GossipStateProviderImpl).deliverPayloads
/opt/gopath/src/github.com/hyperledger/fabric/gossip/state/state.go:561
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:2337)
2018-02-27 02:37:35.631 UTC [gossip/state] deliverPayloads -> CRIT f8a55e Cannot commit block to the ledger due to Invoke VSCC failed for transaction txid=72d936d31215731f58bf0b71b85cb9b7db544eceaa51246d1df1483c39833697, error error executing chaincode: failed to execute transaction: timeout expired while executing transaction
Validation failed
github.com/hyperledger/fabric/gossip/state.(*GossipStateProviderImpl).deliverPayloads
/opt/gopath/src/github.com/hyperledger/fabric/gossip/state/state.go:562
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:2337
panic: Cannot commit block to the ledger due to Invoke VSCC failed for transaction txid=72d936d31215731f58bf0b71b85cb9b7db544eceaa51246d1df1483c39833697, error error executing chaincode: failed to execute transaction: timeout expired while executing transaction
Validation failed
github.com/hyperledger/fabric/gossip/state.(*GossipStateProviderImpl).deliverPayloads
/opt/gopath/src/github.com/hyperledger/fabric/gossip/state/state.go:562
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:2337
goroutine 220 [running]:
github.com/hyperledger/fabric/vendor/github.com/op/go-logging.(*Logger).Panicf(0xc4201bbc50, 0xebf885, 0x2c, 0xc4228be1a0, 0x1, 0x1)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/op/go-logging/logger.go:194 +0x134
github.com/hyperledger/fabric/gossip/state.(*GossipStateProviderImpl).deliverPayloads(0xc4200d1d00)
/opt/gopath/src/github.com/hyperledger/fabric/gossip/state/state.go:562 +0x4c7
created by github.com/hyperledger/fabric/gossip/state.NewGossipStateProvider
/opt/gopath/src/github.com/hyperledger/fabric/gossip/state/state.go:252 +0x6d3
`
Brucepark (Tue, 27 Feb 2018 04:52:12 GMT):
In an environment with two Orgs and four peers (each org has 2 peers),
During the test, four peers died at the same time.
The error messages are all the same.
Is it a bug?
```
2018-02-27 02:37:35.590 UTC [gossip/state] commitBlock -> ERRO f8a4bf Got error while committing(Invoke VSCC failed for transaction txid=72d936d31215731f58bf0b71b85cb9b7db544eceaa51246d1df1483c39833697, error error executing chaincode: failed to execute transaction: timeout expired while executing transaction
Validation failed
github.com/hyperledger/fabric/gossip/state.(*GossipStateProviderImpl).commitBlock
/opt/gopath/src/github.com/hyperledger/fabric/gossip/state/state.go:778
github.com/hyperledger/fabric/gossip/state.(*GossipStateProviderImpl).deliverPayloads
/opt/gopath/src/github.com/hyperledger/fabric/gossip/state/state.go:561
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:2337)
2018-02-27 02:37:35.631 UTC [gossip/state] deliverPayloads -> CRIT f8a55e Cannot commit block to the ledger due to Invoke VSCC failed for transaction txid=72d936d31215731f58bf0b71b85cb9b7db544eceaa51246d1df1483c39833697, error error executing chaincode: failed to execute transaction: timeout expired while executing transaction
Validation failed
github.com/hyperledger/fabric/gossip/state.(*GossipStateProviderImpl).deliverPayloads
/opt/gopath/src/github.com/hyperledger/fabric/gossip/state/state.go:562
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:2337
panic: Cannot commit block to the ledger due to Invoke VSCC failed for transaction txid=72d936d31215731f58bf0b71b85cb9b7db544eceaa51246d1df1483c39833697, error error executing chaincode: failed to execute transaction: timeout expired while executing transaction
Validation failed
github.com/hyperledger/fabric/gossip/state.(*GossipStateProviderImpl).deliverPayloads
/opt/gopath/src/github.com/hyperledger/fabric/gossip/state/state.go:562
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:2337
goroutine 220 [running]:
github.com/hyperledger/fabric/vendor/github.com/op/go-logging.(*Logger).Panicf(0xc4201bbc50, 0xebf885, 0x2c, 0xc4228be1a0, 0x1, 0x1)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/op/go-logging/logger.go:194 +0x134
github.com/hyperledger/fabric/gossip/state.(*GossipStateProviderImpl).deliverPayloads(0xc4200d1d00)
/opt/gopath/src/github.com/hyperledger/fabric/gossip/state/state.go:562 +0x4c7
created by github.com/hyperledger/fabric/gossip/state.NewGossipStateProvider
/opt/gopath/src/github.com/hyperledger/fabric/gossip/state/state.go:252 +0x6d3
```
Brucepark (Tue, 27 Feb 2018 04:58:29 GMT):
Can somebody tell me what is the reason?
Brucepark (Tue, 27 Feb 2018 05:52:27 GMT):
Not only peer but also all dev-peers were dead.
All nodes seem to have died at similar times,
The last log of the dev-peer is:
Brucepark (Tue, 27 Feb 2018 05:52:45 GMT):
```2018-02-27 02:37:35.863 UTC [shim] func1 -> ERRO 003 Received error from server, ending chaincode stream: rpc error: code = Unavailable desc = transport is closing
Error starting Simple chaincode: rpc error: code = Unavailable desc = transport is closing```
Brucepark (Tue, 27 Feb 2018 05:52:45 GMT):
```======== Invoke 1 mspid: Org1MSP
yacovm (Tue, 27 Feb 2018 06:44:31 GMT):
@Brucepark what version of fabric are you using?
Brucepark (Tue, 27 Feb 2018 06:45:55 GMT):
v1.1
yacovm (Tue, 27 Feb 2018 06:46:30 GMT):
Oh no
yacovm (Tue, 27 Feb 2018 06:47:44 GMT):
Ok can you please open a JIRA with details what you did, etc. And tag me in the JIRA, i'll take a look in an hour once i get to the office
Brucepark (Tue, 27 Feb 2018 06:48:03 GMT):
Ok thank you
Brucepark (Tue, 27 Feb 2018 06:56:43 GMT):
@yacovm Oh the version is 1.1.0-preview not v1.1.
yacovm (Tue, 27 Feb 2018 07:08:23 GMT):
Still open the jira
yacovm (Tue, 27 Feb 2018 07:08:28 GMT):
@Brucepark
Brucepark (Tue, 27 Feb 2018 07:08:34 GMT):
Ok
AshishMishra 1 (Tue, 27 Feb 2018 07:22:12 GMT):
Hi Guys, how can I migrate a blockchain/channel from one n/w to another n/w? Eg. I 've 3 peers in network A and 3 peers in network B. In network A, I 've 3 channels 1,2 and 3 and on network B I 've channels 4 and 5. Now I want my channel 3 to be in my network B. Is it possible at all?
yacovm (Tue, 27 Feb 2018 08:16:13 GMT):
@Brucepark can you please attach the peer logs to the JIRA ?
Brucepark (Tue, 27 Feb 2018 08:19:29 GMT):
@yacovm I deleted them already. I will upload it if it is reproduced again.
yacovm (Tue, 27 Feb 2018 08:19:42 GMT):
thanks
yacovm (Tue, 27 Feb 2018 08:19:49 GMT):
please try to reproduce
yacovm (Tue, 27 Feb 2018 08:19:58 GMT):
I think you found something interesting
Brucepark (Tue, 27 Feb 2018 08:20:10 GMT):
Ok :grin:
kostas (Tue, 27 Feb 2018 13:23:06 GMT):
@AshishMishra 1: Unless I'm missing something, this is not something that's feasible.
jrosmith (Tue, 27 Feb 2018 21:16:38 GMT):
hey all, is there an example for what a proposal for a QSCC call would look like? the node sdk does not have a way of creating one to my knowledge, so i want to manually construct a GetChainInfo call and execute it directly against the peer. In the end I'm trying to find a way to set up a heartbeat for the peer using an sdk
kostas (Tue, 27 Feb 2018 21:17:58 GMT):
I'm interested in _documentation_ for this one as well.
jeffgarratt (Wed, 28 Feb 2018 01:10:52 GMT):
@jrosmith -> getChaincodeSpec(cc_type="GOLANG", path="", name=self.system_chaincode_name, args=args)
yacovm (Wed, 28 Feb 2018 09:41:29 GMT):
@Brucepark
yacovm (Wed, 28 Feb 2018 09:41:39 GMT):
what the logs I asked you?
TsuiSauChi (Wed, 28 Feb 2018 12:12:49 GMT):
Has joined the channel.
Brucepark (Wed, 28 Feb 2018 12:54:45 GMT):
Whenever I try stress test, Docker hang is up before reproducing the bug.
so I have failed to get logs.
I do not know how hyperledger fabric makes docker hang.[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=2uaS45BeMaLDpkEL2) @yacovm
yacovm (Wed, 28 Feb 2018 12:55:10 GMT):
:(
jrosmith (Wed, 28 Feb 2018 14:31:50 GMT):
@jeffgarratt thank you so much!
dampuero (Wed, 28 Feb 2018 15:06:29 GMT):
Has joined the channel.
jrosmith (Wed, 28 Feb 2018 15:20:22 GMT):
so lets say i have a situation where a peer has gone down and come back up, is there a way for me to force the peer to start up a chaincode container without sending a transaction through it? maybe an lscc command?
yacovm (Wed, 28 Feb 2018 15:22:11 GMT):
you can make a query
yacovm (Wed, 28 Feb 2018 15:22:13 GMT):
@jrosmith
jrosmith (Wed, 28 Feb 2018 15:25:23 GMT):
@yacovm makes sense. as a follow up, is there a command to get currently running chaincode docker containers? or is that the getChaincodeSpec function jeffgarratt recommended?
yacovm (Wed, 28 Feb 2018 15:25:48 GMT):
`docker ps`?
yacovm (Wed, 28 Feb 2018 15:25:53 GMT):
with grep
jrosmith (Wed, 28 Feb 2018 15:26:03 GMT):
ah im trying to execute it via the sdk
jrosmith (Wed, 28 Feb 2018 15:26:09 GMT):
the node_sdk
yacovm (Wed, 28 Feb 2018 15:26:23 GMT):
you want to know which chaincode containers are running in the peer? why?
jrosmith (Wed, 28 Feb 2018 15:31:34 GMT):
so im trying to implement a health check for the peer to know if it is ready to serve requests.
while testing i've found that if the peer has come back up and transactions are running against it, the first transaction will start the launching of the chaincode but other transactions will fail with a premature execution error.
i want the health check to only report the peer as healthy if both the peer is up and the chaincode container is running, and if the chaincode container is not running i can launch it.
really i'm trying to find a way to avoid the premature execution error so that i can direct traffic to a healthy peer that already has the chaincode running
jrosmith (Wed, 28 Feb 2018 15:31:34 GMT):
so im trying to implement a health check for the peer to know if it is ready to serve requests.
while testing i've found that if the peer has come back up and transactions are running against it, the first transaction will start the launching of the chaincode but other transactions will fail with a premature execution error.
i want the health check to only report the peer as healthy if both the peer is up and the chaincode container is running, and if the chaincode container is not running i want to launch it before directing traffic to it.
really i'm trying to find a way to avoid the premature execution error so that i can direct traffic to a healthy peer that already has the chaincode running
yacovm (Wed, 28 Feb 2018 15:36:38 GMT):
i see. but why can't you just have the health check query the chaincode anyway?
yacovm (Wed, 28 Feb 2018 15:36:43 GMT):
it will bring it up
yacovm (Wed, 28 Feb 2018 15:36:45 GMT):
in case it's down
jrosmith (Wed, 28 Feb 2018 15:42:33 GMT):
that definitely solves my problem and is way easier than what i was trying to implement haha
jrosmith (Wed, 28 Feb 2018 15:42:37 GMT):
thank you @yacovm
yacovm (Wed, 28 Feb 2018 15:42:55 GMT):
np. I like easy and lazy solutions
jrosmith (Wed, 28 Feb 2018 17:28:17 GMT):
@yacovm quick and easy to implement and can confirm it does exactly what i wanted, thanks again
TsuiSauChi (Wed, 28 Feb 2018 21:11:20 GMT):
not really understanding the endorsement process
Is the endorsement done automatically? I created an endorsement policy whereby 2 endorser peer need to endorse the transaction to be consider valid
But whenever I execute a transaction on 1 peer, a block is added to the ledger
Am i doing something wrong?
muralisr (Thu, 01 Mar 2018 00:03:50 GMT):
@TsuiSauChi if you specify an endorsement policy of `orgA and orgB need to sign` but if you send the proposal to only 1 peer (say of OrgA) and submit the response as a TX, then I'd expect the TX to fail
silliman (Thu, 01 Mar 2018 00:21:44 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=9Bmn7yFc6bdbKWCxb) @muralisr
this was posted by @TsuiSauChi in #composer and based on that and the screenshot provided I answered thusly: [ ](https://chat.hyperledger.org/channel/composer?msg=7rS8yvj4yJmMktAED) @TsuiSauChi
Composer will send the transaction for endorsement to each peer defined in the connection profile that your business network card uses. So you've probably got both peers defined and so Composer is getting the necessary endorsements for you
muralisr (Thu, 01 Mar 2018 01:12:12 GMT):
thanks, @silliman
yoheiueda (Thu, 01 Mar 2018 06:57:25 GMT):
Hi. Is there any (practical or theoretical) limit to the number of events that can be registered in EventHub at the same time?
https://fabric-sdk-node.github.io/EventHub.html#registerTxEvent
wlahti (Thu, 01 Mar 2018 13:02:24 GMT):
@yoheiueda As you're referring to the Node SDK documentation, the #fabric-sdk-node channel may be the better source of information given registering for the event for a single transaction ID is implemented by the SDK and not the peer. I definitely wouldn't expect any practical limits
wlahti (Thu, 01 Mar 2018 13:02:24 GMT):
@yoheiueda As you're referring to the Node SDK documentation, the #fabric-sdk-node channel may be the better source of information given registering for the event for a single transaction ID is implemented by the SDK and not the peer. I definitely wouldn't expect any practical limits. Also, which version of Fabric/SDK are you using? In v1.1 (including alpha), there is a new channel event service which uses a different underlying implementation which is much more reliable than the old event hub. If you're using/planning to use v1.1, I'd highly recommend switching to: https://fabric-sdk-node.github.io/ChannelEventHub.html
zhaochy (Fri, 02 Mar 2018 06:54:06 GMT):
Has joined the channel.
zhaochy (Fri, 02 Mar 2018 07:05:05 GMT):
hello, anyone can have a look at this https://jira.hyperledger.org/browse/FAB-8634
toddinpal (Fri, 02 Mar 2018 19:19:37 GMT):
Is there a reason Fabric doesn't distinguish between and invoke and a query?
toddinpal (Fri, 02 Mar 2018 19:19:37 GMT):
Is there a reason Fabric doesn't distinguish between invoke and query in the shim interface?
toddinpal (Fri, 02 Mar 2018 23:39:23 GMT):
@mastersingh24 Any comment on why we're not distinguishing between invoke and query? Seems like query could avoid the generation of the RWset
toddinpal (Fri, 02 Mar 2018 23:41:28 GMT):
As well it would be possible then to impose read-only limits on the world state for queries
AndrewRy 1 (Sat, 03 Mar 2018 05:01:50 GMT):
Has joined the channel.
AndrewRy 1 (Sat, 03 Mar 2018 05:04:09 GMT):
Dear,
How couchdb data folder recovered after it's deleted and restart the peer?
AndrewRy 1 (Sat, 03 Mar 2018 05:04:09 GMT):
Dear,
How couchdb data folder recovered after it's deleted and restart the peer?
which mechanism make it happens
Ryan2 (Mon, 05 Mar 2018 03:04:41 GMT):
Has joined the channel.
Ryan2 (Mon, 05 Mar 2018 03:05:16 GMT):
I have this endorsement policy "AND ('Org0MSP.member')"
is this mean that it require any member of Org0 signs this proposal is OK (just only one member signing is considered valid proposal)
or require all member of Org0 signs this proposal?
ganeshraut (Mon, 05 Mar 2018 06:08:29 GMT):
please guide me how could I connect new peer in existing blockchain
using hyper ledger fabric network
can any one share link for right direction for adding new peer in existing network
akshay.sood (Mon, 05 Mar 2018 15:19:23 GMT):
Has joined the channel.
akshay.sood (Mon, 05 Mar 2018 15:19:29 GMT):
What is the meaning of endorsement in Hyperledger fabric?
wlahti (Mon, 05 Mar 2018 16:28:50 GMT):
@ganeshraut Take a look at this tutorial, which adds a peer (and a new organization) to an existing Fabric network: https://hyperledger-fabric.readthedocs.io/en/master/channel_update_tutorial.html
AndrewRy 1 (Mon, 05 Mar 2018 17:40:17 GMT):
if Peer is endorser peer, I want to this peer become committing peer (not endorser peer anymore) what should I do?
jeffgarratt (Mon, 05 Mar 2018 20:39:27 GMT):
@akshay.sood the simulation and creation of a signed proposal response for a given endorsement request (Signed Proposal)
jeffgarratt (Mon, 05 Mar 2018 20:43:22 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=of7u3j7zsZFouAdBc) @AndrewRy 1 I believe you can simply remove the installed chaincode package from
jeffgarratt (Mon, 05 Mar 2018 20:43:22 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=of7u3j7zsZFouAdBc) @AndrewRy 1 I believe you can simply remove the installed chaincode package from
AndrewRy 1 (Tue, 06 Mar 2018 02:45:05 GMT):
how to check endorser peer simulate transaction log in running docker
AndrewRy 1 (Tue, 06 Mar 2018 02:45:05 GMT):
I have a question that is how to check endorser peer simulate transaction log in running docker?, can someone tell me
sanchezl (Tue, 06 Mar 2018 15:46:51 GMT):
When invoking the peer cli, is there an equivalent to using the `--ordererTLSHostnameOverride` , but for the peer?
sanchezl (Tue, 06 Mar 2018 15:46:51 GMT):
When invoking the peer cli, is there an equivalent to using the `--ordererTLSHostnameOverride` option , but for the peer?
jeffgarratt (Tue, 06 Mar 2018 16:55:04 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=fmy65fZYxiz9SMdqC) @sanchezl CORE_PEER_TLS_SERVERHOSTOVERRIDE
rjones (Tue, 06 Mar 2018 18:15:45 GMT):
dave.enyeart
dave.enyeart (Tue, 06 Mar 2018 20:08:05 GMT):
sykesm
dave.enyeart (Tue, 06 Mar 2018 20:08:13 GMT):
muralisr
dave.enyeart (Tue, 06 Mar 2018 20:09:15 GMT):
wlahti
wlahti (Tue, 06 Mar 2018 20:27:10 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=sTRCyL7xrn23Qdgwq) @AndrewRy 1 You can view the logs for a docker container by using `docker logs
wlahti (Tue, 06 Mar 2018 20:28:25 GMT):
Once you have some logs in front of you, you can look for a similar message to the following, which signals the beginning of the proposal simulation:
```2018-03-06 20:23:57.758 UTC [endorser] simulateProposal -> DEBU 605 [mychannel][2e094b59] Entry chaincode: name:"mycc" ```
wlahti (Tue, 06 Mar 2018 20:28:25 GMT):
Once you have some logs in front of you, you can look for a similar set of messages to the following, which signals the beginning of the proposal simulation:
```2018-03-06 20:23:57.758 UTC [lockbasedtxmgr] newLockBasedTxSimulator -> DEBU 604 constructing new tx simulator txid = [2e094b5946f2985d156d0fc5873edbbec2c50ae1c9ce9def78181475890e795d]
2018-03-06 20:23:57.758 UTC [endorser] simulateProposal -> DEBU 605 [mychannel][2e094b59] Entry chaincode: name:"mycc" ```
wlahti (Tue, 06 Mar 2018 20:28:25 GMT):
Once you have the peer log in front of you, you can look for a similar set of messages to the following, which signals the beginning of the proposal simulation:
```2018-03-06 20:23:57.758 UTC [lockbasedtxmgr] newLockBasedTxSimulator -> DEBU 604 constructing new tx simulator txid = [2e094b5946f2985d156d0fc5873edbbec2c50ae1c9ce9def78181475890e795d]
2018-03-06 20:23:57.758 UTC [endorser] simulateProposal -> DEBU 605 [mychannel][2e094b59] Entry chaincode: name:"mycc" ```
wlahti (Tue, 06 Mar 2018 20:28:25 GMT):
Once you have the peer log in front of you (and assuming you have CORE_LOGGING_LEVEL=debug for the peer), you can look for a similar set of messages to the following, which signals the beginning of the proposal simulation:
```2018-03-06 20:23:57.758 UTC [lockbasedtxmgr] newLockBasedTxSimulator -> DEBU 604 constructing new tx simulator txid = [2e094b5946f2985d156d0fc5873edbbec2c50ae1c9ce9def78181475890e795d]
2018-03-06 20:23:57.758 UTC [endorser] simulateProposal -> DEBU 605 [mychannel][2e094b59] Entry chaincode: name:"mycc" ```
wlahti (Tue, 06 Mar 2018 20:31:23 GMT):
From there, you can follow the logs down to see the different steps, ending with:
```2018-03-06 20:24:07.870 UTC [lockbasedtxmgr] GetTxSimulationResults -> DEBU 69e Simulation completed, getting simulation results
2018-03-06 20:24:07.870 UTC [lockbasedtxmgr] Done -> DEBU 69f Done with transaction simulation / query execution [2e094b5946f2985d156d0fc5873edbbec2c50ae1c9ce9def78181475890e795d]
2018-03-06 20:24:07.870 UTC [endorser] simulateProposal -> DEBU 6a0 [mychannel][2e094b59] Exit```
wlahti (Tue, 06 Mar 2018 22:28:52 GMT):
eyfn
Ryan2 (Wed, 07 Mar 2018 08:28:18 GMT):
thank you very much @wlahti
AndrewRy 1 (Wed, 07 Mar 2018 15:18:24 GMT):
hi, when I update channel, I got the error
" 0xc42002cc00 identity 0 does not satisfy principal: The identity is a member of a different MSP (expected OrdererOrg0MSP, got Org0MSP)"
...
"[orderer/common/broadcast] Handle -> WARN 30f6 Rejecting CONFIG_UPDATE because: Error authorizing update: Error validating DeltaSet: Policy for [Values] /Channel/Orderer/BatchTimeout not satisfied: Failed to reach implicit threshold of 1 sub-policies, required 1 remaining"
Do you guy know how to resolve this one, thank you
AndrewRy 1 (Wed, 07 Mar 2018 16:09:42 GMT):
peer:
Version: 1.0.2
do not have "peer channel signconfigtx ..." command, which version support peer channel signconfigtx?
wlahti (Wed, 07 Mar 2018 16:32:31 GMT):
@AndrewRy 1 Are you following a specific tutorial? If not, this one walks through one scenario (adding an org to a channel) which involves updating the channel: http://hyperledger-fabric.readthedocs.io/en/master/channel_update_tutorial.html?
wlahti (Wed, 07 Mar 2018 16:34:59 GMT):
from your error message, it looks like you need to set the ORDERER_CA environment variable
wlahti (Wed, 07 Mar 2018 16:40:19 GMT):
`signconfigtx` was added in v1.1. I'd recommend updating your code to v1.1.0-rc1
AdnanC (Wed, 07 Mar 2018 21:55:03 GMT):
Has joined the channel.
guoger (Thu, 08 Mar 2018 08:44:24 GMT):
is https://jira.hyperledger.org/browse/FAB-5665 targeting v1.1 or v1.2? thx
raphaelbenoit (Thu, 08 Mar 2018 11:03:41 GMT):
Has joined the channel.
raphaelbenoit (Thu, 08 Mar 2018 11:16:15 GMT):
Hi everyone!
I am new to Hyperledger Fabric and struggle to understand how multiple transactions happening in the same channel can be valid inside a block given that the first transaction in the block woud change the current state of the ledger which means that the second transaction in the block would have a READ value which is not equivalent to the 'new' current state of the ledger.
raphaelbenoit (Thu, 08 Mar 2018 11:17:48 GMT):
World state: (k1,1,v1), (k2,1,v2), (k3,1,v3), (k4,1,v4), (k5,1,v5)
T1 -> Write(k1, v1'), Write(k2, v2')
T2 -> Read(k1), Write(k3, v3')
T3 -> Write(k2, v2'')
T4 -> Write(k2, v2'''), read(k2)
T5 -> Write(k6, v6'), read(k5)
World state: (k1,1,v1), (k2,1,v2), (k3,1,v3), (k4,1,v4), (k5,1,v5)
T1 -> Write(k1, v1'), Write(k2, v2')
T2 -> Read(k1), Write(k3, v3')
T3 -> Write(k2, v2'')
T4 -> Write(k2, v2'''), read(k2)
T5 -> Write(k6, v6'), read(k5)
World state: (k1,1,v1), (k2,1,v2), (k3,1,v3), (k4,1,v4), (k5,1,v5)
T1 -> Write(k1, v1'), Write(k2, v2')
T2 -> Read(k1), Write(k3, v3')
T3 -> Write(k2, v2'')
T4 -> Write(k2, v2'''), read(k2)
T5 -> Write(k6, v6'), read(k5)
This is the example in the documentation.
How can T3 pass even though T1 has already updated the value of k2?
raphaelbenoit (Thu, 08 Mar 2018 11:17:48 GMT):
World state: (k1,1,v1), (k2,1,v2), (k3,1,v3), (k4,1,v4), (k5,1,v5)
T1 -> Write(k1, v1'), Write(k2, v2')
T2 -> Read(k1), Write(k3, v3')
T3 -> Write(k2, v2'')
T4 -> Write(k2, v2'''), read(k2)
T5 -> Write(k6, v6'), read(k5)
This is the example in the documentation.
How can T3 pass even though T1 has already updated the value of k2?
raphaelbenoit (Thu, 08 Mar 2018 11:18:19 GMT):
(sorry for the tripple paste!)
wlahti (Thu, 08 Mar 2018 16:03:39 GMT):
@raphaelbenoit Given the transaction ordering you listed (which would be determined by the orderer), T1 will be marked as a valid transaction and T3 will marked as an invalid transaction by the peers in the network.
wlahti (Thu, 08 Mar 2018 16:03:39 GMT):
@raphaelbenoit ~Given the transaction ordering you listed (which would be determined by the orderer), T1 will be marked as a valid transaction and T3 will marked as an invalid transaction by the peers in the network.~
wlahti (Thu, 08 Mar 2018 16:05:12 GMT):
The application should check for the validity of its transactions and resubmit T3 for processing against the updated world state.
wlahti (Thu, 08 Mar 2018 16:05:12 GMT):
~The application should check for the validity of its transactions and resubmit T3 for processing against the updated world state.~ I was incorrect. See messages below.
wlahti (Thu, 08 Mar 2018 16:05:12 GMT):
~The application should check for the validity of its transactions and resubmit T3 for processing against the updated world state.~ I was incorrect. See message below.
raphaelbenoit (Thu, 08 Mar 2018 16:09:07 GMT):
@wlahti thanks for the reply. That is also how I understood it, but in the documentation is says:
1. T1 passes validation because it does not perform any read. Further, the tuple of keys k1 and k2 in the world state are updated to (k1,2,v1'), (k2,2,v2')
2. T2 fails validation because it reads a key, k1, which was modified by a preceding transaction - T1
3. T3 passes the validation because it does not perform a read. Further the tuple of the key, k2, in the world state is updated to (k2,3,v2'')
4. T4 fails the validation because it reads a key, k2, which was modified by a preceding transaction T1
5. T5 passes validation because it reads a key, k5, which was not modified by any of the preceding transactions
wlahti (Thu, 08 Mar 2018 16:10:06 GMT):
which document are you referring to?
raphaelbenoit (Thu, 08 Mar 2018 16:11:17 GMT):
http://hyperledger-fabric.readthedocs.io/en/latest/readwrite.html
raphaelbenoit (Thu, 08 Mar 2018 16:12:38 GMT):
I think it has something to do with the anchors but I am not sure how the ordering service handles this
wlahti (Thu, 08 Mar 2018 16:27:11 GMT):
I reached out to someone more familiar with the ledger. It turns out this situation is referred to as a "blind write". Often, a chaincode's logic will call `GetState` (aka a read) and then perform a `PutState` (aka a write). However, in a "blind write", the chaincode simply performs a `PutState` to write a new value without reading the current value. In this case, no consistency validation is performed and the last transaction "wins" and has the final say in the value. Obviously, not all applications will/should use blind writing but for certain situations I guess this is a desired behavior.
wlahti (Thu, 08 Mar 2018 16:27:11 GMT):
I reached out to someone more familiar with the ledger. It turns out this situation is referred to as a "blind write". Often, a chaincode's logic will call `GetState` (aka a read) to check the value of a certain key and then perform a `PutState` (aka a write) to modify the value of that key. However, in a "blind write", the chaincode simply performs a `PutState` to write a new value without reading the current value. In this case, no consistency validation is performed and the last transaction "wins" and has the final say in the value. Obviously, not all applications will/should use blind writing but for certain situations I guess this is a desired behavior.
wlahti (Thu, 08 Mar 2018 16:27:11 GMT):
@raphaelbenoit I reached out to someone more familiar with the ledger. It turns out this situation is referred to as a "blind write". Often, a chaincode's logic will call `GetState` (aka a read) to check the value of a certain key and then perform a `PutState` (aka a write) to modify the value of that key. However, in a "blind write", the chaincode simply performs a `PutState` to write a new value without reading the current value. In this case, no consistency validation is performed and the last transaction "wins" and has the final say in the value. Obviously, not all applications will/should use blind writing but for certain situations I guess this is a desired behavior.
wlahti (Thu, 08 Mar 2018 16:27:11 GMT):
@raphaelbenoit I reached out to someone more familiar with the ledger and transaction validation than I am. It turns out this situation is referred to as a "blind write". Often, a chaincode's logic will call `GetState` (aka a read) to check the value of a certain key and then perform a `PutState` (aka a write) to modify the value of that key. However, in a "blind write", the chaincode simply performs a `PutState` to write a new value without reading the current value. In this case, no consistency validation is performed and the last transaction "wins" and has the final say in the value. Obviously, not all applications will/should use blind writing but for certain situations I guess this is a desired behavior.
tkueda (Fri, 09 Mar 2018 05:03:44 GMT):
Has joined the channel.
raphaelbenoit (Fri, 09 Mar 2018 09:31:56 GMT):
@wlahti Thank you for the detailed answer!
So in other words, I cannot have two transactions that modify the same key/value-pair in the same block tagged as VALID. The first one would get tagged as INVALID and included in the peer ledger but not in the validated ledger.
This is somehow against my understading of the validation porcess. I thought that committing peers would always check the readset of a transaction before calling `PutState` and updating the state with the writeset and thereby updating the version of the key (since, how I understood it, transactions within a block are still committed even if not all transactions of the block are committed yet).
The documentation says:
_In the validation phase, a transaction is considered valid if the version of each key present in the read set of the transaction matches the version for the same key in the world state - assuming all the preceding valid transactions (including the preceding transactions in the same block) are committed (committed-state). _
And another question: What are read-transactions good for? Can't I just use the Hyperledger Explorer if I want to query the ledger?
DarshanBc (Fri, 09 Mar 2018 11:27:22 GMT):
I am trying to invoke a chaincode from another chaincode 2 cc are in 2 different channels I am getting this error ```r: [client-utils.js]: sendPeersProposal - Promise is rejected: Error: error executing chaincode: transaction returned with failure: Failed to get policy manager for channel [channel2]
```
muralisr (Fri, 09 Mar 2018 16:04:01 GMT):
@DarshanBc has the peer joined channel2 ?
DarshanBc (Fri, 09 Mar 2018 17:08:40 GMT):
Yes I can execute transactions on both the channels separately
DarshanBc (Fri, 09 Mar 2018 17:16:03 GMT):
But the peer from which I am calling is not the part of channel 2
jeffgarratt (Fri, 09 Mar 2018 17:51:31 GMT):
@DarshanBc you can only invoke the other chaincode if it is installed locally, which requires the executing peer be a member of both channels I believe.
NeerajKumar (Sat, 10 Mar 2018 10:57:11 GMT):
Has joined the channel.
NeerajKumar (Sat, 10 Mar 2018 10:57:36 GMT):
Can somebody help me to find out a documentation which list out all possible configurations for "hyperledger/fabric-peer" docker image, i really want to/ have to tweak some parts of the functionality of the peer through configurations.
liuhaifeng (Sat, 10 Mar 2018 11:58:27 GMT):
Has joined the channel.
rsherwood (Mon, 12 Mar 2018 12:07:26 GMT):
Given https://jira.hyperledger.org/browse/FAB-5288 can you roll over the orderers intermediate endorsement certificates and still successfully join a new peer to an existing channel using Fabric 1.0?
I know you can’t roll over TLS intermediate certificates, but given that the peer is given the channel genesis block and the blocks are then are replayed in order I would assume that this would be OK?
Am I correct?
akshay.sood (Mon, 12 Mar 2018 15:31:30 GMT):
byfn always shows ```ERROR: for peer1.debutinfotech.com Cannot start service peer1.debutinfotech.com: driver failed programming external connectivity on endpoint DebutInfotechPeer1 (f808c3c48dfebbe508c66b81aeaceb137656520998d5089d895b698822910149): Bind for 0.0.0.0:1051 failed: port is already allocated``` even if the ports are changed
baohua (Tue, 13 Mar 2018 02:05:14 GMT):
Has left the channel.
AshishMishra 1 (Wed, 14 Mar 2018 09:36:46 GMT):
Hi experts, can someone tell me what does PHANTOM_READ_CONFLICT means? I 'm getting this while using the SDK on a Fabric network to query the chaincode. I deleted few tx records intentionally from the couchdb. But no error is seen on the peer logs also from fabric CLI container I can invoke the same query and I 'm getting results, which is different on different peers (as I said I intentionally deleted tx data). What is different with SDK here that it knew about some conflict.
novusopt (Wed, 14 Mar 2018 14:57:45 GMT):
Hi, is it possible to set the cpu of the underlying docker container of a chaincode. What I have found is that the set up of memory is possible but not cpu..
RahulSonanis (Fri, 16 Mar 2018 14:42:12 GMT):
Has joined the channel.
Ryan2 (Mon, 19 Mar 2018 02:58:59 GMT):
Hi, I got an issue on the fabric network, that is:
In the NodeJS APP, network-config is configured to send transaction to peer0 and peer1 as follow:
"peers": {
"peer0": {
"requests": "...",
"events": "...",
"server-hostname": "peer0",
"tls_cacerts": "..."
},
"peer1": {
"requests": "...",
"events": "...",
"server-hostname": "peer1",
"tls_cacerts": "..."
}
}
and All peer0 and peer1 I instantiated chaincode with Endorsement policy is " -P "AND ('Org0MSP.member')" "
Ryan2 (Mon, 19 Mar 2018 02:58:59 GMT):
Hi, I got an issue on the fabric network, that is:
In the NodeJS APP, network-config is configured to send transaction to peer0 and peer1 as follow:
"peers": {
"peer0": {
"requests": "...",
"events": "...",
"server-hostname": "peer0",
"tls_cacerts": "..."
},
"peer1": {
"requests": "...",
"events": "...",
"server-hostname": "peer1",
"tls_cacerts": "..."
}
}
and All peer0 and peer1 I instantiated chaincode with Endorsement policy is " -P "AND ('Org0MSP.member')" "
peer0 and peer1 are belong to Org0MSP
When I stop Peer1 then do the transactions from NodeJS App, transaction was failed with exception was "Connection failed to Peer1".
Since the Endorsement policy requires any member of Org0MSP endorsing transaction. and peers was configured into NodeJS,
I want Application has high availability when peer stopped. How I can do in this case, could you guys help?
RahulSonanis (Mon, 19 Mar 2018 04:49:05 GMT):
Hi all, I am getting an error ENDORSEMENT_POLICY_FAILURE at the time of validation even when I have successful endorsements. Please refer this question `https://stackoverflow.com/questions/49302463/endorsement-policy-failure-for-invoke-chaincode-request-even-when-sufficient-end` for the detailed issue.
Unni_1994 (Mon, 19 Mar 2018 11:34:15 GMT):
Has joined the channel.
wjzheng (Tue, 20 Mar 2018 19:08:08 GMT):
Has joined the channel.
ShikarSharma (Tue, 20 Mar 2018 22:44:02 GMT):
Has joined the channel.
crissi (Wed, 21 Mar 2018 16:57:13 GMT):
Has joined the channel.
pb (Thu, 22 Mar 2018 09:06:42 GMT):
Hi
If we have 2 peers A and B, in endorsement policy, we can say either one or both should endorse. But where in code, the criteria for the peer to decide whether to endorse or not is specified?
jeffgarratt (Thu, 22 Mar 2018 15:24:43 GMT):
@pb you can request any peer to endorse a proposal. If it has the chaincode installed and instantiated in the channel, it will respond if you have the appropriate role as the requestor. The validation phase is where each peer determines whether to accept the Tx per the endorsement policy and other criteria.
bourbonkidQ (Thu, 22 Mar 2018 16:03:07 GMT):
Has joined the channel.
bourbonkidQ (Thu, 22 Mar 2018 16:05:52 GMT):
Hi I use docker-compose and i have a probleme for the connection of the peer with the couchdb. When i use peer node start i have this error : 2018-03-22 15:52:35.220 UTC [couchdb] handleRequest -> WARN 015 Retrying couchdb request in 125ms. Attempt:1 Error:Get http://127.0.0.1:5984/: dial tcp 127.0.0.1:5984: getsockopt: connection refused. You can find my docker-compose file here : https://pastebin.com/c8KbgS3U
bourbonkidQ (Thu, 22 Mar 2018 16:05:52 GMT):
Hi I use docker-compose and i have a probleme for the connection of the peer with the couchdb. When i use "peer node start" i have this error : 2018-03-22 15:52:35.220 UTC [couchdb] handleRequest -> WARN 015 Retrying couchdb request in 125ms. Attempt:1 Error:Get http://127.0.0.1:5984/: dial tcp 127.0.0.1:5984: getsockopt: connection refused. You can find my docker-compose file here : https://pastebin.com/c8KbgS3U
pb (Fri, 23 Mar 2018 03:18:06 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=8PG5MpkPtCEKcQfdp) @jeffgarratt
Ok Thanks.Could you please tell me whether the logic for endorsement is written in js files like policy.js within nodemodules?
DRSK (Fri, 23 Mar 2018 06:10:24 GMT):
Has joined the channel.
krisava (Fri, 23 Mar 2018 13:57:09 GMT):
Hi, Is it possible to trigger multiple events from the chaincode?
stub.SetEvent("EVENT-1", eventdata-1)
stub.SetEvent("EVENT-2", eventdata-2)
Looks like the last event (EVENT-2) alone is getting triggered but not both (EVENT-1 and EVENT-2).
Is there any alternative to trigger one or more events at the same time?
jeffgarratt (Fri, 23 Mar 2018 15:10:53 GMT):
@pb endorsement occurs within the peer (golang). see https://github.com/hyperledger/fabric/blob/master/core/endorser/endorser.go#L450
mogamboizer (Fri, 23 Mar 2018 17:42:14 GMT):
Has left the channel.
patelan (Fri, 23 Mar 2018 19:38:23 GMT):
Has joined the channel.
tennenjl (Sun, 25 Mar 2018 22:34:47 GMT):
dynamic
tennenjl (Sun, 25 Mar 2018 22:41:47 GMT):
Dummy question, lets say that for transaction1, I need endorsement by OrgA & Org B, but for transaction2 (using the same chain code), I need endorsement by OrgA & Org C. For both cases, I need at least two peers from each org sending endorsement. Would the client simply use some sort of mechanism to send the request to the appropriate Org/Peers for each request, or is there another best practice which is used to change the endorsing peers for each transaction instance for the same chain code? Thanks!
tennenjl (Sun, 25 Mar 2018 22:41:47 GMT):
Dummy question, lets say that for transaction1, I need endorsement by OrgA & Org B, but for transaction2 (using the same chain code), I need endorsement by OrgA & Org C. For both cases, I need at least two peers from each org sending endorsement. Would the client simply use some sort of mechanism to send the request to the appropriate Org/Peers for each request (OrgA & OrgB for tran1 and OrgA & OrgC for tran2), or is there another best practice which is used to change the endorsing peers for each transaction instance for the same chain code? Thanks!
chenjun-bj (Mon, 26 Mar 2018 01:54:09 GMT):
Has joined the channel.
Brucepark (Mon, 26 Mar 2018 06:04:40 GMT):
When the Fabric endorsement policy is "OR (org1.member org2.member org3.member ... org9.member)"
and org1 is hacked and the chain code is changed by hacker, it will create an invalid Tx.
This incorrect Tx is likely to be made into blocks and propagated to other org and reflected in other org’s ledger.
So it seems very dangerous to use OR Policy solely,
Am I right?
Gerard9494 (Tue, 27 Mar 2018 08:39:14 GMT):
Has joined the channel.
Gerard9494 (Tue, 27 Mar 2018 08:42:43 GMT):
Hello everyone,
I am trying to define my network endorsement-policy, but I do not understand what I am specificating at this document:
{
"identities": [
{
"role": {
"name": "member",
"mspId": "Org1MSP"
}
},
{
"role": {
"name": "member",
"mspId": "Org2MSP"
}
}
],
"policy": {
"2-of": [
{
"signed-by": 0
},
{
"signed-by": 1
}
]
}
}
Somebody know where I can find the information about this document, please? So I can understand it and add a new identity
Thanks! :)
vsadriano (Tue, 27 Mar 2018 17:46:00 GMT):
There's two entities: Or1 member and Org2 member. Both must validate all proposal transaction.
vsadriano (Tue, 27 Mar 2018 18:36:31 GMT):
Hi! I'm trying to instantiate a chaincode and I'm getting the error bellow:
```shell
...
2018-03-27 18:01:45.918 UTC [chaincode-platform] func1 -> ERRO 3da Failed to generate platform-specific docker build: Error returned from build: 1 "can't load package: package chaincode/chaincode_example02: cannot find package "chaincode/chaincode_example02" in any of:
/opt/go/src/chaincode/chaincode_example02 (from $GOROOT)
/chaincode/input/src/chaincode/chaincode_example02 (from $GOPATH)
/opt/gopath/src/chaincode/chaincode_example02
"
...
```
vsadriano (Tue, 27 Mar 2018 18:37:54 GMT):
As you can see, I get install the chaincode:
```shell
$ peer chaincode install -o orderer:7050 -n mycc -v 1.0 -p chaincode/chaincode_example02
2018-03-27 17:57:44.998 UTC [msp] GetLocalMSP -> DEBU 001 Returning existing local MSP
2018-03-27 17:57:44.999 UTC [msp] GetDefaultSigningIdentity -> DEBU 002 Obtaining default signing identity
2018-03-27 17:57:44.999 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 003 Using default escc
2018-03-27 17:57:44.999 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 004 Using default vscc
2018-03-27 17:57:45.171 UTC [golang-platform] getCodeFromFS -> DEBU 005 getCodeFromFS chaincode/chaincode_example02
2018-03-27 17:57:45.566 UTC [golang-platform] func1 -> DEBU 006 Discarding GOROOT package fmt
2018-03-27 17:57:45.567 UTC [golang-platform] func1 -> DEBU 007 Discarding provided package github.com/hyperledger/fabric/core/chaincode/shim
2018-03-27 17:57:45.567 UTC [golang-platform] func1 -> DEBU 008 Discarding provided package github.com/hyperledger/fabric/protos/peer
2018-03-27 17:57:45.567 UTC [golang-platform] func1 -> DEBU 009 Discarding GOROOT package strconv
2018-03-27 17:57:45.567 UTC [golang-platform] GetDeploymentPayload -> DEBU 00a done
2018-03-27 17:57:45.581 UTC [msp/identity] Sign -> DEBU 00b Sign: plaintext: 0A85070A5C08031A0C08998CEAD50510...8C5800080000FFFF2EAFB5EF00040000
2018-03-27 17:57:45.581 UTC [msp/identity] Sign -> DEBU 00c Sign: digest: B9D22DCB00BA6654A543B1F321029A8565129A6B95A05E2364D8C0E6FA59EA50
2018-03-27 17:57:45.606 UTC [chaincodeCmd] install -> DEBU 00d Installed remotely response:
vsadriano (Tue, 27 Mar 2018 18:38:48 GMT):
When I try to instantiate chaincode I get:
```shell
$ peer chaincode instantiate -o orderer:7050 --tls --cafile $ORDERER_TLS_CAFILE -C defaultchannel -n mycc -v 1.0 -c '{"Args":["init","a", "100", "b","200"]}'
2018-03-27 18:01:44.948 UTC [dockercontroller] createContainer -> DEBU 3d6 Create container: peer0-mycc-1.0
2018-03-27 18:01:44.956 UTC [dockercontroller] Start -> DEBU 3d7 start-could not find image
BilalAhmad (Tue, 27 Mar 2018 20:16:53 GMT):
Has joined the channel.
BilalAhmad (Tue, 27 Mar 2018 20:37:49 GMT):
How can we define that a certain peer can only endorse but it should not be able to maintain the state of ledger ?
bjwswang (Wed, 28 Mar 2018 13:01:38 GMT):
I think we can’t...
asaningmaxchain123 (Wed, 28 Mar 2018 14:59:23 GMT):
@jyellick @wlahti @yacovm why the scc doesn't start the docker container?
asaningmaxchain123 (Wed, 28 Mar 2018 14:59:23 GMT):
@jyellick @wlahti @yacovm why the scc doesn't start the docker container? the application chaincode can do it too?
asaningmaxchain123 (Wed, 28 Mar 2018 14:59:23 GMT):
@jyellick @wlahti @yacovm why the scc doesn't start the docker container? the application chaincode can do it too? if it doesn't please tell me the location of the source code
asaningmaxchain123 (Wed, 28 Mar 2018 14:59:23 GMT):
@jyellick @wlahti @yacovm why the scc doesn't start the docker container? the application chaincode can do it too? if it doesn't please tell me the location of the source code?thx
asaningmaxchain123 (Wed, 28 Mar 2018 15:24:06 GMT):
@manish-sethi
asaningmaxchain123 (Wed, 28 Mar 2018 15:24:06 GMT):
@manish-sethi can you take a look the above question?
manish-sethi (Wed, 28 Mar 2018 15:26:29 GMT):
@massiveashok2014 - a system chaincode by definition runs in the peer process. Most of the system chaincodes are peer code only albeit organized in the form of a chaincode.
manish-sethi (Wed, 28 Mar 2018 15:26:29 GMT):
@asaningmaxchain123 - a system chaincode by definition runs in the peer process. Most of the system chaincodes are peer code only albeit organized in the form of a chaincode.
massiveashok2014 (Wed, 28 Mar 2018 15:26:29 GMT):
Has joined the channel.
asaningmaxchain123 (Wed, 28 Mar 2018 15:29:54 GMT):
the application chaincode can't like the scc?
manish-sethi (Wed, 28 Mar 2018 15:46:18 GMT):
You can. But that would require you to make changes in the peer code and recompile.
asaningmaxchain123 (Wed, 28 Mar 2018 16:11:08 GMT):
@manish-sethi how can i do it? please give me more detail
manish-sethi (Wed, 28 Mar 2018 16:15:50 GMT):
In fact, in 1.1 you should be able to register a system chaincode via go-plugin. You can give this a try http://hyperledger-fabric.readthedocs.io/en/release-1.1/systemchaincode.html
asaningmaxchain123 (Wed, 28 Mar 2018 16:16:41 GMT):
@manish-sethi i know,but so ?
asaningmaxchain123 (Wed, 28 Mar 2018 16:16:41 GMT):
@manish-sethi i know,i still the system chaincode,but doesn't work run
asaningmaxchain123 (Wed, 28 Mar 2018 16:16:41 GMT):
@manish-sethi i know,i still the system chaincode,but doesn't work run,i want the user chaincode can run in process way
joaquimpedrooliveira (Wed, 28 Mar 2018 17:58:04 GMT):
Has joined the channel.
troyronda (Thu, 29 Mar 2018 00:29:03 GMT):
@manish-sethi @asaningmaxchain123 you need to build the peer including the Go Tag pluginsenabled to load system chaincode plugins
troyronda (Thu, 29 Mar 2018 00:29:03 GMT):
@manish-sethi @asaningmaxchain123 to enable loading of system chaincode plugins, you need to build the peer including the Go Tag pluginsenabled
troyronda (Thu, 29 Mar 2018 00:29:03 GMT):
@manish-sethi @asaningmaxchain123 to enable loading of system chaincode plugins, you need to build the peer including the go tag "pluginsenabled"
troyronda (Thu, 29 Mar 2018 00:32:28 GMT):
(note: system chaincode plugins is an advanced thing to do -- you really need a good understanding to do it)
ChrisMcQueenDevelopment (Thu, 29 Mar 2018 16:26:00 GMT):
Has joined the channel.
ChrisMcQueenDevelopment (Thu, 29 Mar 2018 16:26:06 GMT):
If anyone can answer my stackoverfllow question, that would be dream:
https://stackoverflow.com/questions/49560791/hyperledger-fabric-endorsement-based-on-specific-parties-involved-in-the-trans
massiveashok2014 (Fri, 30 Mar 2018 07:19:57 GMT):
hyperledger fabric
Ashish (Fri, 30 Mar 2018 15:58:25 GMT):
Reg the Chaincode instantiation, in my understanding/experience with JavaSDK, it would allow us to instantiate only once in a channel and only in one of the peers. Is this understanding correct ? At the end of instantiation, I am able to see one chaincode container up, and the rest do not come up till I actually do a query or invoke..
Ashish (Fri, 30 Mar 2018 15:58:25 GMT):
Hi All, Reg the Chaincode instantiation, in my understanding/experience with JavaSDK, it would allow us to instantiate only once in a channel and only in one of the peers. At the end of instantiation, I am able to see one chaincode container up, and the any other container associated to the same chaincode - but on another Org in the same channel, do not come up till I actually do a query or invoke on that Org's Node. Is this understanding correct ?
Ashish (Fri, 30 Mar 2018 16:01:37 GMT):
As per my understanding, the only endorsement which i can specify during the instantiation is the endorsement policy for the Chaincode Invoke & Query
Ashish (Fri, 30 Mar 2018 16:03:35 GMT):
Is there a way to say on which all node, the Chaincode should be instantiated simultaneously in a channel at the time of instantiation ?
mastersingh24 (Sat, 31 Mar 2018 10:09:22 GMT):
@Ashish pinged me directly, but pasting the response here as well:
mastersingh24 (Sat, 31 Mar 2018 10:09:22 GMT):
@Ashish pinged me directly, but pasting the response here as well:
When you instantiate chaincode, it will only be launched on the peer on which you run the instantiate transaction.
It is then launched on other peers in the channel only when you invoke and/or query as you stated above.
The only way to launch on multiple peers is to send the instantiate request to multiple peers initially. I believe that the sendInstantiationProposal API in the Java SDK allows you to send the request to a collection of peers
muralisr (Sun, 01 Apr 2018 12:35:00 GMT):
@Ashish you can instantiate the same chaincode on multiple channels. However only one container will be created per peer (as you saw, multiple containers come up, one for each peer). The channel context is part of the request (proposal/proposal response) and not part of the running chaincode.
Ashish (Sun, 01 Apr 2018 13:01:08 GMT):
@muralisr Okay. I understand. And I had that concept clear. The question was only in the context of a single channel.
Ashish (Sun, 01 Apr 2018 13:01:13 GMT):
And when I tried out the java SDK first time in November, I had got the chaincode installed in all the peers of all the organisations in a channel. And I had sent the instantiation request to all of them, simultaneously using the sendInstantiationRequest API. But I remember that always only one of them used to come back as successful. Then I went through the documentation and it clearly stated it would be instantiated only once in a channel. And it made sense. And the chaincode containers would come up linked to other peers if I connected to them and tried to query or invoke.
Ashish (Sun, 01 Apr 2018 13:02:39 GMT):
So it would take that 10 sec time for that container to come up but it would and it would have the updated data.
Ashish (Sun, 01 Apr 2018 13:04:11 GMT):
But recently someone mentioned that it's possible to instantiate simultaneously on multiple peers. So I thought it's good to cut down on time. Because I have all the time when I'm installing and instantiating. So why to wait for the first invoke. So I thought of approaching you folks to check.
Ashish (Sun, 01 Apr 2018 13:04:27 GMT):
All the while staying in one single channel
muralisr (Sun, 01 Apr 2018 13:04:58 GMT):
so first of all, I didn't see @mastersingh24 response (for some reason my RC had not refreshed...) and missed some of that context
Ashish (Sun, 01 Apr 2018 13:05:36 GMT):
Thank you for your response anyway Srini. Much appreciated.
muralisr (Sun, 01 Apr 2018 13:06:09 GMT):
`But recently someone mentioned that it's possible to instantiate simultaneously on multiple peers.` - you can send a instantiate proposal to multiple peers just like you can an invoke proposal but in the end the instantiation woukld be done only once per channel
Ashish (Sun, 01 Apr 2018 13:06:27 GMT):
Agreed
muralisr (Sun, 01 Apr 2018 13:06:43 GMT):
the delay in the container coming up - is it a one time thing due to the image getting created ?
Ashish (Sun, 01 Apr 2018 13:06:52 GMT):
Yes.
Ashish (Sun, 01 Apr 2018 13:06:59 GMT):
Only that
muralisr (Sun, 01 Apr 2018 13:07:26 GMT):
that may not be too bad is it ? hopefully you are not going to be doing that all the time ?
Ashish (Sun, 01 Apr 2018 13:09:24 GMT):
It's not, so I didn't give it much of a thought. But someone just asked me , if we can get them up and running not waiting for the first invoke, the business API won't have to..
Ashish (Sun, 01 Apr 2018 13:09:40 GMT):
Hence the whole thing..
muralisr (Sun, 01 Apr 2018 13:12:12 GMT):
right. its just that "bring it up transparently on demand" makes it a tad transparent and lessens user involvement. A trade off that shouldn't cause inconvenience most of the time
muralisr (Sun, 01 Apr 2018 13:12:12 GMT):
right. its just that "bring it up transparently on demand" lessens user involvement. A trade off that shouldn't cause inconvenience most of the time
Ashish (Sun, 01 Apr 2018 13:12:55 GMT):
Agreed to that too. 😊
muralisr (Sun, 01 Apr 2018 13:13:04 GMT):
but I understand the context now, thanks much
Ashish (Sun, 01 Apr 2018 13:13:19 GMT):
One more question. Can I ask?
muralisr (Sun, 01 Apr 2018 13:13:25 GMT):
surely
Ashish (Sun, 01 Apr 2018 13:14:37 GMT):
Is fabric ever planning to give a feature of logs as extractable files in a mapped volume ever ? Like the application volume of a java application? Here instead of the whole application, just that of the chaincode I'm interested in?
Ashish (Sun, 01 Apr 2018 13:14:59 GMT):
Like the application log of a java application. Typo
Ashish (Sun, 01 Apr 2018 13:15:31 GMT):
Docker logs have all. But its a streaming log..
Ashish (Sun, 01 Apr 2018 13:15:53 GMT):
Looking in that is like looking for needlle in haystack
Ashish (Sun, 01 Apr 2018 13:16:39 GMT):
Hence the thought. In production for offline analysis, we have to have something like this
Ashish (Sun, 01 Apr 2018 13:17:22 GMT):
Cos these financial institutions don't give docker user access etc..
muralisr (Sun, 01 Apr 2018 13:18:33 GMT):
agree. there was some mention of providing more options to users for logging. I don't recall what the context was...let me check something.
Ashish (Sun, 01 Apr 2018 13:19:01 GMT):
Okay. Anyway thank you very much for your time. Happy Easter..
muralisr (Sun, 01 Apr 2018 13:21:46 GMT):
I thought there was a JIRA on this but can't find it... let me refer us to @wlahti (perhaps you can open a JIRA and contribute with Will @Ashish ?)
muralisr (Sun, 01 Apr 2018 13:22:07 GMT):
happy Easter!
Ashish (Sun, 01 Apr 2018 13:22:07 GMT):
Sure sure
Ashish (Sun, 01 Apr 2018 13:22:12 GMT):
:)
ganeshraut (Mon, 02 Apr 2018 09:51:36 GMT):
How to integrate kafka + Hyper ledger fabric
please guide me if any one have knowledge about HA environment
I want to set up multiple Orderer with multiple node
patelan (Mon, 02 Apr 2018 21:47:27 GMT):
How to configure grpc.keepalive_time_ms for the peer in fabric#1.0.3 ?
patelan (Mon, 02 Apr 2018 21:48:01 GMT):
We are blocked because of the stability issue. After 15 mins calls are timing out
iamdm (Tue, 03 Apr 2018 12:08:48 GMT):
How to modify channel writers policy to add ability to members to write?
iamdm (Tue, 03 Apr 2018 12:09:14 GMT):
I added member role to MSP policy but it doesn't work
muralisr (Tue, 03 Apr 2018 14:23:11 GMT):
@iamdm can you check in #fabric-orderer please ?
wlahti (Tue, 03 Apr 2018 15:45:35 GMT):
@Ashish @muralisr Sorry for taking a while to get back on this. There is an old item that captures this feature request, FAB-2804. Take a look and feel free to chime in with your thoughts!
wlahti (Tue, 03 Apr 2018 15:45:35 GMT):
@Ashish @muralisr Sorry for taking a while to get back on this. There is an old item that captures this feature request, https://jira.hyperledger.org/browse/FAB-2804. Take a look and feel free to chime in with your thoughts!
Ashish (Tue, 03 Apr 2018 15:47:23 GMT):
@wlahti Sure Will. I will take a look and get back to you.
muralisr (Tue, 03 Apr 2018 15:57:13 GMT):
Thanks @wlahti ... I _knew_ there was a JIRA out there :-)
Ashish (Tue, 03 Apr 2018 16:03:46 GMT):
:wink:
Ryan2 (Wed, 04 Apr 2018 04:39:21 GMT):
hi, I got an issue is that, when transaction was invalid but block was commited
"2018-04-04 04:37:31.334 UTC [statevalidator] ValidateAndPrepareBatch -> WARN 05d Block [7] Transaction index [0] marked as invalid by committer. Reason code [10]
2018-04-04 04:37:31.337 UTC [kvledger] Commit -> INFO 05e Channel [smschannel4]: Created block [7] with 1 transaction(s)
2018-04-04 04:37:31.344 UTC [eventhub_producer] SendProducerBlockEvent -> INFO 05f Channel [smschannel4]: Sending event for block number [7]
"
it should be not commited, why is that happend?
Ryan2 (Wed, 04 Apr 2018 04:39:21 GMT):
hi, I got an issue is that, when transaction was invalid but block was commited
"2018-04-04 04:37:31.334 UTC [statevalidator] ValidateAndPrepareBatch -> WARN 05d Block [7] Transaction index [0] marked as invalid by committer. Reason code [10]
2018-04-04 04:37:31.337 UTC [kvledger] Commit -> INFO 05e Channel [smschannel4]: Created block [7] with 1 transaction(s)
2018-04-04 04:37:31.344 UTC [eventhub_producer] SendProducerBlockEvent -> INFO 05f Channel [mychannel]: Sending event for block number [7]
"
it should be not commited, why is that happend?
Ryan2 (Wed, 04 Apr 2018 04:39:21 GMT):
hi, I got an issue is that, when transaction was invalid but block was commited
"2018-04-04 04:37:31.334 UTC [statevalidator] ValidateAndPrepareBatch -> WARN 05d Block [7] Transaction index [0] marked as invalid by committer. Reason code [10]
2018-04-04 04:37:31.337 UTC [kvledger] Commit -> INFO 05e Channel [mychannel]: Created block [7] with 1 transaction(s)
2018-04-04 04:37:31.344 UTC [eventhub_producer] SendProducerBlockEvent -> INFO 05f Channel [mychannel]: Sending event for block number [7]
"
it should be not commited, why is that happend?
Ryan2 (Wed, 04 Apr 2018 04:39:21 GMT):
hi, I got an issue is that, when transaction was invalid but block was commited
"2018-04-04 04:37:31.334 UTC [statevalidator] ValidateAndPrepareBatch -> WARN 05d Block [7] Transaction index [0] marked as invalid by committer. Reason code [10]
2018-04-04 04:37:31.337 UTC [kvledger] Commit -> INFO 05e Channel [mychannel]: Created block [7] with 1 transaction(s)
2018-04-04 04:37:31.344 UTC [eventhub_producer] SendProducerBlockEvent -> INFO 05f Channel [mychannel]: Sending event for block number [7]
"
"2018-04-04 04:37:31.338 UTC [committer/txvalidator] validateTx -> ERRO 14c VSCCValidateTx for transaction txId = 39796987a0b64fa6511e1f39a4afa0c3d70e7d617372454b024c288cc983f72c returned error: VSCC error: endorsement policy failure, err: signature set did not satisfy policy
2018-04-04 04:37:31.339 UTC [valimpl] preprocessProtoBlock -> WARN 14d Channel [mychannel]: Block [7] Transaction index [0] TxId [39796987a0b64fa6511e1f39a4afa0c3d70e7d617372454b024c288cc983f72c] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]
2018-04-04 04:37:31.347 UTC [kvledger] CommitWithPvtData -> INFO 14e Channel [mychannel]: Committed block [7] with 1 transaction(s)
"
it should be not commited, why is that happend?
muralisr (Wed, 04 Apr 2018 13:47:24 GMT):
@Ryan2 the key is this `marked as invalid by committer.`. The block contains many transactions. Those that failed are marked as invalid. Users can retrieve blocks and see if their TX succeeded or not
richzhao (Wed, 04 Apr 2018 15:56:35 GMT):
Has joined the channel.
Ryan2 (Wed, 04 Apr 2018 21:15:57 GMT):
Hi @muralisr , as the log show, Block7 marked as invaid by committer but Block7 was Created (the log I got from 2 peers separately,) What is Reason code [10] mean?
muralisr (Wed, 04 Apr 2018 21:17:02 GMT):
couple of things @Ryan2
muralisr (Wed, 04 Apr 2018 21:17:21 GMT):
1) see very similar error below `Block [7] Transaction index [0] TxId [39796987a0b64fa6511e1f39a4afa0c3d70e7d617372454b024c288cc983f72c] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]`
muralisr (Wed, 04 Apr 2018 21:17:37 GMT):
so guessing 10 means ENDORSEMENT_POLICY_FAILURE
muralisr (Wed, 04 Apr 2018 21:18:14 GMT):
2) `Block7 marked as invaid by committer` - not quite. ` Block [7] Transaction index [0] marked as invalid by committer`
Ryan2 (Wed, 04 Apr 2018 21:21:40 GMT):
thank you, I quite clear, However,` Why peer not rejecting commit the block which contain the Invalid Transaction`?
Ryan2 (Wed, 04 Apr 2018 21:21:40 GMT):
thank you, I quite clear, However,*` Why peer not rejecting commit the block which contain the Invalid Transaction`*?
Ryan2 (Wed, 04 Apr 2018 21:21:40 GMT):
thank you, I quite clear, However,*` Why peer not reject commitng the block which contain the Invalid Transaction`*?
Ryan2 (Wed, 04 Apr 2018 21:21:40 GMT):
thank you, I quite clear, However,*` Why peer not reject committing the block which contain the Invalid Transaction`*?
qizhang (Fri, 06 Apr 2018 02:05:25 GMT):
Hi guys, I have two questions regarding to the endorsing process:
1. If an endorsing peer tries the endorse a transaction T, which updates
qizhang (Fri, 06 Apr 2018 02:05:25 GMT):
Hi guys, I have two questions regarding to the endorsing process:
1. If an endorsing peer tries the endorse a transaction T, which updates
qizhang (Fri, 06 Apr 2018 02:05:25 GMT):
Hi guys, I have two questions regarding to the endorsing process:
1. If an endorsing peer tries the endorse a transaction T, which updates
qizhang (Fri, 06 Apr 2018 02:05:25 GMT):
Hi guys, I have two questions regarding to the endorsing process:
1. If an endorsing peer tries the endorse a transaction T, which read
qizhang (Fri, 06 Apr 2018 02:05:25 GMT):
Hi guys, I have two questions regarding to the endorsing process:
1. If an endorsing peer tries the endorse a transaction T, which needs to read
kkado (Sat, 07 Apr 2018 04:17:58 GMT):
Has joined the channel.
pankajcheema (Mon, 09 Apr 2018 14:02:22 GMT):
Has joined the channel.
Levilk (Mon, 09 Apr 2018 14:15:53 GMT):
Has joined the channel.
Levilk (Mon, 09 Apr 2018 14:16:27 GMT):
Hello!
I am curious is there any solution for this problem right now:
I've a working network with 1 org, 1 orderer , and 2 peer. I've installed and instantinated succesfully a chaincode on the peers (CC was working perfectly). I decided to add a new peer to the network. Started a new peer image and joined it to the channel. After i installed the same chaincode without any problem i could not instantinate it (CC is already exist). So i removed the cc's containers and deleted the cc's images and the CCs from the peers (/var/hyperledger/production/chaincodes/
C0rWin (Mon, 09 Apr 2018 14:38:42 GMT):
@Levilk `After i installed the same chaincode without any problem i could not instantinate it (CC is already exist)` --> no need to instantiate chaincode twice, once you get it instantiated on first peer the instantiation transaction recorded to the ledger, hence once second peer will get in sync it will catch up with update
asaningmaxchain123 (Mon, 09 Apr 2018 15:19:19 GMT):
@C0rWin @mastersingh24 @manish-sethi the doesn't support the validatation of the tx concurrence
asaningmaxchain123 (Mon, 09 Apr 2018 15:19:19 GMT):
@C0rWin @mastersingh24 @manish-sethi the doesn't support the validatation of the tx concurrence? if one peer ledger deleted by manual,What's going to happen?
C0rWin (Mon, 09 Apr 2018 16:05:08 GMT):
@asaningmaxchain123 can you expand on your question? what doesn't support the validation of the tx concurrence?
asaningmaxchain123 (Tue, 10 Apr 2018 03:31:05 GMT):
@jyellick currently,the committer support the high concurrency
jyellick (Tue, 10 Apr 2018 04:10:21 GMT):
@asaningmaxchain123 If you are referring to parallel transaction validation, this was merged into v1.1.0 and you should see that in a multi-core environment, all CPUs are utilized for transaction validation (rather than just 1 in v1.0.x)
asaningmaxchain123 (Tue, 10 Apr 2018 04:25:06 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=qG6vXyHZtCNGX9SpG) @jyellick can you tell me the location of the source code for `parallel transaction validation` ,is it in the `VSCC`?
DRSK (Tue, 10 Apr 2018 04:55:48 GMT):
Hi,
asaningmaxchain123 (Tue, 10 Apr 2018 05:09:00 GMT):
@jyellick @mastersingh24 @manish-sethi can you tell me the docker file about the `couchdb zookeeper kafka` from the url https://hub.docker.com/r/hyperledger/fabric-kafka/ i don't see it
DRSK (Tue, 10 Apr 2018 05:18:04 GMT):
Hi,
I am working on fabric and found the endorsement policy is mentioned in the starting script as "-P "OR ('Org1MSP.member','Org2MSP.member')" and understood that either of the members of ORG1 or ORG2must endorse the transaction. But I couldn't locate exactly
1) Where and how in code, the members of Org1 or Org2 decide whether it should endorse or not?
2) How can we customize endorsement criteria differently for different endorsers? ( Not who all to endorse, but how it decides whether the proposal could be successfully endorsed or not)
Can anyone please help me out? @muralisr @C0rWin @asaningmaxchain123
DRSK (Tue, 10 Apr 2018 05:18:04 GMT):
Hi,
I am working on fabric and found the endorsement policy is mentioned in the starting script as "-P "OR ('Org1MSP.member','Org2MSP.member')" and understood that either of the members of ORG1 or ORG2must endorse the transaction. But I couldn't locate exactly
1) Where and how in code, the members of Org1 or Org2 decide whether it should endorse or not?
2) How can we customize endorsement criteria differently for different endorsers? ( Not who all to endorse, but how it decides whether the proposal could be successfully endorsed or not)
Can anyone please help me out? @muralisr @C0rWin @asaningmaxchain123 @wlahti
tennenjl (Tue, 10 Apr 2018 12:42:41 GMT):
Dummy question, lets say I have an asset (say a health record) which is associated with two orgs (OrgA and Org B), I need endorsement by OrgA & Org B for a transaction associated with this record, but for transaction2 (using the same chain code), I have a health record which is tied to two different Orgs where I need endorsement by Org C & Org D. For both cases, I need at least two peers from each org sending endorsement. Would the client simply choose and send the request to the appropriate Org/Peers for each request (where the specific Orgs are not part of the endorsement policy) (OrgA & OrgB for tran1 and Org C & Org D for tran2), or is there any way to dynamically specify the endorsing peer signatures required for each transaction instance for the same chain code ? Either way, the client would need to know which endorsing peers they need to send the request to, but I don't think you could specify which peers have to sign it, only the number of peers.
jyellick (Tue, 10 Apr 2018 14:00:53 GMT):
> @jyellick can you tell me the location of the source code for `parallel transaction validation` ,is it in the `VSCC`?
@asaningmaxchain123 https://github.com/hyperledger/fabric/blob/release-1.1/core/committer/txvalidator/validator.go#L169
asaningmaxchain123 (Tue, 10 Apr 2018 14:44:23 GMT):
@jyellick thx very much
naganjaneyulu (Tue, 10 Apr 2018 16:35:03 GMT):
Has joined the channel.
naganjaneyulu (Tue, 10 Apr 2018 16:35:09 GMT):
Hello
naganjaneyulu (Tue, 10 Apr 2018 16:35:50 GMT):
have question on engrossing of transaction received from client applications
naganjaneyulu (Tue, 10 Apr 2018 16:36:16 GMT):
what does meant engrossing and why do we need to do endorsing of transactions.?
naganjaneyulu (Tue, 10 Apr 2018 16:42:04 GMT):
what is job of endorsing peers.?
eabiodun (Tue, 10 Apr 2018 20:45:17 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=PAEQ2pEeZ5hDSNtSC) @naganjaneyulu Highly recommended you read this link.
eabiodun (Tue, 10 Apr 2018 20:45:24 GMT):
http://hyperledger-fabric.readthedocs.io/en/release-1.1/arch-deep-dive.html
naganjaneyulu (Tue, 10 Apr 2018 22:05:26 GMT):
it would be great if someone explains with some simple example
DRSK (Wed, 11 Apr 2018 03:09:50 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=wKvZT9YfuWDqPTJGz) @muralisr When we read transaction from the ledger directly by using transaction id, how can we differentiate if it is a valid or invalid one?
DRSK (Wed, 11 Apr 2018 03:10:36 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=okEmKukiGTn8AiMTH) @muralisr When we read transaction from the ledger directly by using transaction id, how can we differentiate if it is a valid or invalid one?
dsl (Wed, 11 Apr 2018 04:57:18 GMT):
Has joined the channel.
asaningmaxchain123 (Wed, 11 Apr 2018 06:47:29 GMT):
@jyellick what's the different between `ResourceConfig` and `ChannelConfig` for peer
C0rWin (Wed, 11 Apr 2018 11:28:43 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=wrTMEpgPjKSd9SAA3) @DRSK You need to lookup transactions statuses from block metadata and check tx status
jyellick (Wed, 11 Apr 2018 14:08:00 GMT):
@asaningmaxchain123 Resource config was an experimental feature in v1.1, it will likely be removed in v1.2
asaningmaxchain123 (Wed, 11 Apr 2018 14:08:40 GMT):
@jyellick i agree
asaningmaxchain123 (Wed, 11 Apr 2018 14:08:40 GMT):
@jyellick i agree,can you take a look #fabric-peer-endorser-committer
dsl (Thu, 12 Apr 2018 05:39:27 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=ivjqagdn7sCyLCWvh) @C0rWin Ok Got it. Thanks
markthedark (Thu, 12 Apr 2018 13:41:51 GMT):
Has joined the channel.
davidgsmits (Thu, 12 Apr 2018 13:49:55 GMT):
Has joined the channel.
SmartContract2018 (Thu, 12 Apr 2018 21:17:47 GMT):
Has joined the channel.
SmartContract2018 (Thu, 12 Apr 2018 21:24:17 GMT):
Where is the physical ledger file located on my Ubuntu peer node? I am looking for the exact file location. Thanks
also, has anyone tried to deploy a network using Fabric, with a very large number of private ledgers (1000s)? Did you face any issues?
pankajcheema (Mon, 16 Apr 2018 10:39:40 GMT):
Anyone knows this error ```akshay@akshay:~/fabric-material$ peer channel create -o hr.debut.com:7050 -c channel1 -f ./channel-artifacts/channel.tx --tls --cafile '/home/akshay/fabric-material/crypto-config/ordererOrganizations/debut.com/msp/tlscacerts/tlsca.debut.com-cert.pem'
2018-04-16 16:08:27.627 IST [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized
Error: got unexpected status: BAD_REQUEST -- error authorizing update: error validating ReadSet: readset expected key [Group] /Channel/Application at version 0, but got version 1
```
markthedark (Mon, 16 Apr 2018 11:26:57 GMT):
hello. I'm trying to update the configtx.taml configuration file in basic-network sample, but my ca container crashes with: Error: Failed to find private key for certificate in '/etc/hyperledger/fabric-ca-server-config/ca.org1.example.com-cert.pem': Could not find matching private key for SKI: Failed getting key for SKI
I ran the generate.sh script after updating the configuration, do i need to update something else too?
DarshanBc (Tue, 17 Apr 2018 08:54:39 GMT):
what is the criteria in production environment to which peer a transaction request has to submitted to
acombeau (Tue, 17 Apr 2018 10:32:31 GMT):
Has joined the channel.
acombeau (Tue, 17 Apr 2018 10:37:41 GMT):
root@ad5ce3265ff9:/opt/gopath/src/github.com/hyperledger/fabric/peer# peer channel create -o orderer.mydomain.com:7050 -c twochannel -f ./channel-artifacts/twochannel.tx --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/mydomain.com/orderers/orderer.mydomain.com/msp/tlscacerts/tlsca.mydomain.com-cert.pem
2018-04-17 10:37:27.617 UTC [msp] GetLocalMSP -> DEBU 001 Returning existing local MSP
2018-04-17 10:37:27.617 UTC [msp] GetDefaultSigningIdentity -> DEBU 002 Obtaining default signing identity
Error: failed to create deliver client: orderer client failed to connect to orderer.mydomain.com:7050: failed to create new connection: tls: first record does not look like a TLS handshake
acombeau (Tue, 17 Apr 2018 10:38:09 GMT):
Is this error talk to someone ?
jrosmith (Tue, 17 Apr 2018 15:27:43 GMT):
hey all, i've upgrade my system to 1.1 and am trying to install and instantiate my chaincode. i'm able to install but when i go to instantiate i get `premature execution - chaincode (treds:3.3.1) launched and waiting for registration`
i never saw this error in 1.0 before, is there something else i need to before instantiating?
jrosmith (Tue, 17 Apr 2018 15:27:43 GMT):
hey all, i've upgrade my system to 1.1 and am trying to install and instantiate my chaincode. i'm able to install but when i go to instantiate i get `premature execution - chaincode (mycc:3.3.1) launched and waiting for registration`
i never saw this error in 1.0 before, is there something else i need to before instantiating?
jrosmith (Tue, 17 Apr 2018 15:27:43 GMT):
hey all, i've upgrade my system to 1.1 and am trying to install and instantiate my chaincode. i'm able to install but when i go to instantiate i get `premature execution - chaincode (mycc:1.0.0) launched and waiting for registration`
i never saw this error in 1.0 before, is there something else i need to before instantiating?
jrosmith (Tue, 17 Apr 2018 15:28:34 GMT):
hey all, i've upgrade my system to 1.1 and am trying to install and instantiate my chaincode. i'm able to install but when i go to instantiate i get `premature execution - chaincode (mycc:1.0.0) launched and waiting for registration`
i never saw this error in 1.0 before, is there something else i need to before instantiating?
jrosmith (Tue, 17 Apr 2018 15:28:34 GMT):
hey all, i've upgrade my system to 1.1 and am trying to install and instantiate my chaincode. i'm able to install but when i go to instantiate i get `premature execution - chaincode (mycc:1.0.0) launched and waiting for registration`
i never saw this error in 1.0 before, is there something else i need to before instantiating?
as an update, i've tried running instantiate again ~10 minutes later and keep receiving the same error message. what exactly is the registration process doing under the hood?
jrosmith (Tue, 17 Apr 2018 15:59:40 GMT):
figured it out the peer logs gave me the following: `Error starting mycc chaincode: Error trying to connect to local peer: remote error: tls: bad certificate`
which stems from https://jira.hyperledger.org/browse/FAB-8091
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=nm4kyfuxddvy27tXA)
jrosmith (Tue, 17 Apr 2018 15:59:40 GMT):
figured it out. the peer logs gave me the following: `Error starting mycc chaincode: Error trying to connect to local peer: remote error: tls: bad certificate`
which stems from https://jira.hyperledger.org/browse/FAB-8091
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=nm4kyfuxddvy27tXA)
pjjp (Wed, 18 Apr 2018 12:50:14 GMT):
Has joined the channel.
asaningmaxchain123 (Wed, 18 Apr 2018 15:03:14 GMT):
@jyellick what's the relationship between org and msp?
asaningmaxchain123 (Wed, 18 Apr 2018 15:03:14 GMT):
@jyellick @smithbk @wlahti what's the relationship between org and msp?
jyellick (Wed, 18 Apr 2018 15:19:44 GMT):
The relationship is 1-1
asaningmaxchain123 (Wed, 18 Apr 2018 15:30:23 GMT):
@jyellick however in the doc,http://hyperledger-fabric.readthedocs.io/en/release-1.1/msp.html?highlight=msp
asaningmaxchain123 (Wed, 18 Apr 2018 15:30:41 GMT):
in the `Best Practices` section
jyellick (Wed, 18 Apr 2018 15:50:29 GMT):
@asaningmaxchain123 This section is referring to organization more conceptually. Let me replace the word 'organization' with company where it makes sense:
> One organization employing various MSPs
This would become "One company employing various Organizations/MSPs"
> Multiple organizations using a single MSP
This would become "One company using a single Organization/MSP"
jyellick (Wed, 18 Apr 2018 15:51:55 GMT):
In Fabric, the definition of "Organization" is 1-1 with MSP. If you need multiple MSPs for the same entity/organization/company you will need to create multiple Fabric MSPs.
jyellick (Wed, 18 Apr 2018 15:51:55 GMT):
In Fabric, the definition of "Organization" is 1-1 with MSP. If you need multiple MSPs for the same entity/organization/company you will need to create multiple Fabric MSPs (which means creating multiple organizations).
asaningmaxchain123 (Wed, 18 Apr 2018 15:55:42 GMT):
@jyellick can you tell me how to set the multiple Fabric MSPs for One company?
asaningmaxchain123 (Wed, 18 Apr 2018 15:56:20 GMT):
in the examples/e2e it just contains the one Msp for each Org
asaningmaxchain123 (Wed, 18 Apr 2018 15:56:20 GMT):
in the ·examples/e2e· it just contains the one Msp for each Org
asaningmaxchain123 (Wed, 18 Apr 2018 15:56:20 GMT):
in the `examples/e2e` it just contains the one Msp for each Org
jyellick (Wed, 18 Apr 2018 17:42:06 GMT):
@asaningmaxchain123 You would need to create multiple orgs.
Like... Org1Sales, Org1Research, etc.
jyellick (Wed, 18 Apr 2018 17:42:28 GMT):
They would look like multiple organizations to Fabric, but they would all represent a single organization
jrosmith (Wed, 18 Apr 2018 20:45:48 GMT):
in 1.0 i was able to use `GetQueryResult` with a rich query string containing `\"use_index\": \"_design/myIndex\"`, but when I use the same rich query string in 1.1 I get `Couch DB Error:no_usable_index, Status Code:400, Reason:The index specified with "use_index" is not usable for the query.` during transactions endorsement. But `_design/myIndex` definitely exists when I look in Project Fauxton for the database. Was there a change to the way rich queries are executed in the peer?
jrosmith (Wed, 18 Apr 2018 20:45:48 GMT):
in 1.0 i was able to use `GetQueryResult` with a rich query string containing `\"use_index\": \"_design/myIndex\"`, but when I use the same rich query string in 1.1 I get:
```Couch DB Error:no_usable_index, Status Code:400, Reason:The index specified with "use_index" is not usable for the query.```
during transactions endorsement. But `_design/myIndex` definitely exists when I look in Project Fauxton for the database. Was there a change to the way rich queries are executed in the peer?
jrosmith (Wed, 18 Apr 2018 20:45:48 GMT):
in 1.0 i was able to use `GetQueryResult` with a rich query string containing `\"use_index\": \"_design/myIndex\"`, but when I use the same rich query string in 1.1 I get
```Couch DB Error:no_usable_index, Status Code:400, Reason:The index specified with "use_index" is not usable for the query.```
during transactions endorsement. But `_design/myIndex` definitely exists when I look in Project Fauxton for the database. Was there a change to the way rich queries are executed in the peer?
jrosmith (Wed, 18 Apr 2018 20:45:48 GMT):
in 1.0 i was able to use `GetQueryResult` with a rich query string containing `\"use_index\": \"_design/myIndex\"`, but when I use the same rich query string in 1.1 I get
```Couch DB Error:no_usable_index, Status Code:400, Reason:The index specified with "use_index" is not usable for the query.```
during transactions endorsement. But `_design/myIndex` definitely exists when I look in Project Fauxton. Was there a change to the way rich queries are executed in the peer?
asaningmaxchain123 (Wed, 18 Apr 2018 23:14:45 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=uoMbi2cyNYqiCJgwN) @jyellick it uses the same `Msp`?
asaningmaxchain123 (Wed, 18 Apr 2018 23:14:45 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=uoMbi2cyNYqiCJgwN) @jyellick it uses the same `Msp`? so it refers `"One company using a single Organization/MSP"`
jyellick (Thu, 19 Apr 2018 04:46:21 GMT):
@asaningmaxchain123 I do not understand your intent. Please describe concretely your goal
jyellick (Thu, 19 Apr 2018 04:46:21 GMT):
@asaningmaxchain123 I do not understand your intent. Please describe concretely your goal (ideally with an example)
Mihai.A (Thu, 19 Apr 2018 06:31:02 GMT):
Has joined the channel.
rahulhegde (Thu, 19 Apr 2018 12:52:43 GMT):
@jyellick @dave.enyeart
We are getting https://github.com/hyperledger/fabric/blob/v1.0.6/core/chaincode/chaincode_support.go#L598 - is the reason that the HFC client is set a timeout (endorsing request) which is not enough for peer to compile-launch the chaincode image?
rahulhegde (Thu, 19 Apr 2018 12:52:43 GMT):
@jyellick @dave.enyeart
We are getting https://github.com/hyperledger/fabric/blob/v1.0.6/core/chaincode/chaincode_support.go#L598 - is the reason that the HFC client is set a timeout for endorsing request which is not enough for peer to compile-launch the chaincode image? Any other reasons.
rahulhegde (Thu, 19 Apr 2018 12:52:43 GMT):
Hello @jyellick @dave.enyeart - can you help on below query
We sometime get following error @ https://github.com/hyperledger/fabric/blob/v1.0.6/core/chaincode/chaincode_support.go#L598 - is the reason that the HFC client is setting a timeout for an endorsing request that is not enough for peer to compile & launch the chaincode container? Any other reasons.
jyellick (Thu, 19 Apr 2018 17:09:47 GMT):
@rahulhegde The first time a chaincode is queried/invoked, if it is not running already, it will be launched. This acquires a lock which causes all further queries/invokes of that chaincode to be rejected until the launch sequence finishes. I expect what has happened is that your chaincode container has stopped (maybe you restarted the peer? upgraded the chaincoded?), and you have multiple clients which are trying to get endorsements or query it at the same time. I'd love to see this limitation removed in the future, but that is the behavior today.
rahulhegde (Thu, 19 Apr 2018 17:13:47 GMT):
@jyellick the first part is correct - this is specifically in case of new chaincode instantiate/upgrade, never got for the case where peer was restarted and chaincode was in process to launch (may be timing related). I will check the 2nd part - if multiple clients is related to our case.
rahulhegde (Thu, 19 Apr 2018 18:05:37 GMT):
@jyellick - I have confirmed the 2nd part too which occurred in our case. Do you know if there is a hyperledger jira for it - if no, i will open.
jyellick (Thu, 19 Apr 2018 18:06:21 GMT):
I am unaware of any JIRA for it, please do open
rahulhegde (Thu, 19 Apr 2018 18:08:21 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=MHcxFngPqv54Gst4o) @jyellick I will open a JIRA. Thank You.
bourbonkidQ (Mon, 23 Apr 2018 12:29:01 GMT):
Hello could you explain me what the flag `` --peer-defaultchain=false is it used `` for ?
bourbonkidQ (Mon, 23 Apr 2018 12:29:01 GMT):
Hello could you explain me what the flag ` --peer-defaultchain=false is it used` for ?
bourbonkidQ (Mon, 23 Apr 2018 12:29:01 GMT):
Hello could you explain me what the flag ` --peer-defaultchain=false` is it used for ?
bltaylor (Mon, 23 Apr 2018 14:56:12 GMT):
Has joined the channel.
bltaylor (Mon, 23 Apr 2018 14:58:07 GMT):
Does anyone know if the hash of a getQueryResult is included in the read set for VSCC validation in 1.1?
bltaylor (Mon, 23 Apr 2018 17:20:33 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=KLLrLrMvt4Lk7xRY3) As far as I can tell is does not yet;
type nsRWs struct {
readMap map[string]*kvrwset.KVRead //for mvcc validation
writeMap map[string]*kvrwset.KVWrite
rangeQueriesMap map[rangeQueryKey]*kvrwset.RangeQueryInfo //for phantom read validation
rangeQueriesKeys []rangeQueryKey
}
Ryan2 (Tue, 24 Apr 2018 02:41:12 GMT):
hi, when I start peer, peer logged as ` Started peer with ID=[name:"jdoe" ], network ID=[dev], address=[0.0.0.0:7051]`
However I scripted `CORE_PEER_ID=org1-peer1 \`,
how to avoid this one, and peer start with ID defined
CodeReaper (Wed, 25 Apr 2018 10:10:45 GMT):
Has joined the channel.
CodeReaper (Wed, 25 Apr 2018 10:10:53 GMT):
Hi, I tried to do a chaincode query, the query's code is taking it in an infinite loop. Meanwhile I tried doing an invoke(invoke was valid function). What I found was that even the invoke didn't work. It gave the following error-
CodeReaper (Wed, 25 Apr 2018 10:11:18 GMT):
Clipboard - April 25, 2018 3:41 PM
CodeReaper (Wed, 25 Apr 2018 10:11:21 GMT):
Did query close down the eventhub of the invoke??
If so, will loads of invoke a thing to worry about then, one closing the eventhub of another?
Point to note is that 15 second is timeout for any request, invoke timeout much faster than the query itself. Query timed out after 15 seconds only
kerokhin (Wed, 25 Apr 2018 11:00:39 GMT):
Has joined the channel.
Ryan2 (Thu, 26 Apr 2018 01:19:13 GMT):
hi, my network has 2 Orgs A and B, OrgA has 2 peer and OrgB has 2 peers.
what is endorsement policy syntax for the case is
"2 signatures from org A" and "1 signature from org B"
Thanks
SmartContract2018 (Thu, 26 Apr 2018 15:41:51 GMT):
I am working on a fabric based design that can potentially have 1000's of private transactions (as many chaincodes). From data privacy perspective, I am looking to have the optimum design. I can have individual channels for each private communication thus ensuring that only relevant transactions are stored physically on any node. However it means creating 1000s of individual channels. It creates operations/maintenance challenges and network stability. Any feedback would be appreciated.
pankajcheema (Thu, 26 Apr 2018 18:03:36 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=dX2zoXzSWsjFWBCzQ) I also have same situation
pankajcheema (Thu, 26 Apr 2018 18:03:36 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=dX2zoXzSWsjFWBCzQ) I also have same situation. Any suggestion appreciated
Unni_1994 (Fri, 27 Apr 2018 11:30:11 GMT):
Hi Al
Unni_1994 (Fri, 27 Apr 2018 11:30:11 GMT):
Hi All
Unni_1994 (Fri, 27 Apr 2018 11:30:58 GMT):
Is there is any transaction pool concept in hyperledger
yacovm (Fri, 27 Apr 2018 12:14:42 GMT):
@Unni_1994 no, because fabric claims to have a pluggable ordering service
yacovm (Fri, 27 Apr 2018 12:15:24 GMT):
therefore the only guarantees are the API that the service provides.
Unni_1994 (Fri, 27 Apr 2018 13:13:48 GMT):
Thanks @yacovm
chainsaw (Fri, 27 Apr 2018 15:53:20 GMT):
Has joined the channel.
kostas (Fri, 27 Apr 2018 21:58:17 GMT):
Has left the channel.
jastisriradheshyam (Mon, 30 Apr 2018 07:23:04 GMT):
Has joined the channel.
Ed.Curran (Mon, 30 Apr 2018 14:52:17 GMT):
Has joined the channel.
HandsomeRoger (Wed, 02 May 2018 01:36:15 GMT):
Has joined the channel.
HandsomeRoger (Wed, 02 May 2018 01:39:06 GMT):
HI~
Are there some documents about fabric state db and index db? I want to understand restrictions and size about index, view and db. Thanks.
Ryan2 (Wed, 02 May 2018 01:55:02 GMT):
hi @yacovm
can you help on my question:
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=dX2zoXzSWsjFWBCzQ)
Unni_1994 (Wed, 02 May 2018 05:04:39 GMT):
Hi All , Maximum number of transactions in a block?
Unni_1994 (Wed, 02 May 2018 05:04:58 GMT):
I am getting only one transactions per block.
yacovm (Wed, 02 May 2018 11:43:50 GMT):
@Ryan2 - something like:
`AND(AND(OrgA.member, OrgA.member), OrgB.member)`
Ryan2 (Wed, 02 May 2018 12:01:04 GMT):
Thank you @yacovm , like I suppected originally, but not sure
pvrbharg (Wed, 02 May 2018 23:13:21 GMT):
Dear team - I am seeing this error in first-network tutorial and want to know where I can look for understanding and debugging this issue?
pvrbharg (Wed, 02 May 2018 23:13:32 GMT):
Clipboard - May 2, 2018 4:13 PM
pvrbharg (Wed, 02 May 2018 23:14:10 GMT):
This is happening in byfn.sh when peer0 of org1 is trying to do an invoke transaction of moving 10 dollars from A to B. The script reports success oddly when the underlying issue fails.
pvrbharg (Wed, 02 May 2018 23:14:26 GMT):
Clipboard - May 2, 2018 4:14 PM
pvrbharg (Wed, 02 May 2018 23:16:04 GMT):
I am using V1.1.0 release on RHEL platform. Please let me know if it helps to send channel-artifacts. Again this is first-network sample running from fabric-samples repo.
pvrbharg (Thu, 03 May 2018 02:02:28 GMT):
I meant to indicate that the failure peer console log is here - https://pastebin.com/88CseNxk
kevin-s-wang (Thu, 03 May 2018 02:37:15 GMT):
Has joined the channel.
binhn (Thu, 03 May 2018 13:13:12 GMT):
Has left the channel.
latitiah (Thu, 03 May 2018 22:26:08 GMT):
I am seeing an error where the chaincode container is not starting for one of my peers - or to be more exact - the container does not always consistently come up for my peers. When performing an instantiation (using CLI commands for say peer1), I notice that I see a process for what I've labeled peer2 'root 18950 0.4 0.3 70440 15940 ? Ssl 22:09 0:00 chaincode -peer.address=10.0.2.15:8052'
latitiah (Thu, 03 May 2018 22:26:08 GMT):
I am seeing an error where the chaincode container is not starting for one of my peers - or to be more exact - the container does not always consistently come up for my peers. When performing an instantiation (using CLI commands for say peer1), I notice that I see a process for what I've labeled peer2 `root 18950 0.4 0.3 70440 15940 ? Ssl 22:09 0:00 chaincode -peer.address=10.0.2.15:8052`
latitiah (Thu, 03 May 2018 22:26:08 GMT):
I am seeing an error where the chaincode container is not starting for one of my peers - or to be more exact - the container does not always consistently come up for my peers. When performing an instantiation (using CLI commands for say peer1), I notice that I see a process for what I've labeled peer2 ```root 18950 0.4 0.3 70440 15940 ? Ssl 22:09 0:00 chaincode -peer.address=10.0.2.15:8052```
latitiah (Thu, 03 May 2018 22:27:27 GMT):
I then see the following error in the log for peer1:
```[e][peer] 2018-05-03 22:09:36.475 UTC [golang-platform] GenerateDockerBuild -> INFO 032 building chaincode with ldflagsOpt: '-ldflags "-linkmode external -extldflags '-static'"'
[e][peer] 2018-05-03 22:09:36.475 UTC [golang-platform] GenerateDockerBuild -> INFO 033 building chaincode with tags: experimental
[e][peer] 2018-05-03 22:09:46.659 UTC [chaincode-platform] func1 -> ERRO 034 Failed to generate platform-specific docker build: Error returned from build: 137 ""
[e][peer] 2018-05-03 22:09:46.659 UTC [dockercontroller] deployImage -> ERRO 035 Error building images: Failed to generate platform-specific docker build: Error returned from build: 137 ""
[e][peer] 2018-05-03 22:09:46.659 UTC [dockercontroller] deployImage -> ERRO 036 Image Output:
[e][peer] ********************
[e][peer]
[e][peer] ********************
[e][peer] 2018-05-03 22:09:46.684 UTC [chaincode] Launch -> ERRO 037 startAndWiatForReady failed: Failed to generate platform-specific docker build: Error returned from build: 137 ""
[e][peer] error starting container
[e][peer] error starting container
[e][peer] 2018-05-03 22:09:46.684 UTC [chaincode] ExecuteChaincode -> ERRO 038 Failed to generate platform-specific docker build: Error returned from build: 137 ""
[e][peer] error starting container
[e][peer] error starting container
[e][peer] error invoking chaincode
[e][peer] 2018-05-03 22:09:46.684 UTC [endorser] simulateProposal -> ERRO 039 [testchannel][267195f8] failed to invoke chaincode name:"mycc" , error: Failed to generate platform-specific docker build: Error returned from build: 137 ""
[e][peer] error starting container
[e][peer] error starting container
[e][peer] error invoking chaincode```
latitiah (Thu, 03 May 2018 22:28:22 GMT):
This issue is not consistent, but what is consistent is if I see both chaincode processes from the single instantiation, everything works as expected.
latitiah (Thu, 03 May 2018 22:29:29 GMT):
That is, if I see: ```root 29888 0.3 0.3 151312 14616 ? Ssl 20:24 0:00 chaincode -peer.address=10.0.2.15:8052
root 30026 0.8 0.3 69384 14800 ? Ssl 20:25 0:00 chaincode -peer.address=10.0.2.15:7052```
latitiah (Thu, 03 May 2018 22:29:56 GMT):
Thoughts? Ideas?
latitiah (Thu, 03 May 2018 22:33:08 GMT):
BTW: I'm running off of master; commit: 3f782c9740708df3b1ff74efe9c3f4a654721c34
latitiah (Thu, 03 May 2018 22:49:59 GMT):
@muralisr :^^
muralisr (Fri, 04 May 2018 00:15:58 GMT):
@latitiah the `ps` listing are from within the container ?
muralisr (Fri, 04 May 2018 00:18:07 GMT):
I'd need more context
latitiah (Fri, 04 May 2018 01:19:21 GMT):
Ah no, I'm running the peers and orderer locally. The process listing is from my machine
acombeau (Fri, 04 May 2018 10:27:50 GMT):
Anyone now ow is it possible to modify the READ/WRITE access to a peer ? I saw that there are two possibility one on the Chaincode, the other one on the config file. can anyone help me to find the right file?
Is there a link with this ? :
`You can also see that the endorsement policy has been modified to -P "OR ('Org1MSP.peer','Org2MSP.peer','Org3MSP.peer')". `
zhaochy (Mon, 07 May 2018 04:54:02 GMT):
hello, does anyone knows how to enable private data for fabric-peer? even if I build with `EXPERIMENTAL=true`, it seems lscc also think the private channel data feature is not enabled
ShrutiSinha (Mon, 07 May 2018 08:27:27 GMT):
Has joined the channel.
Starseven (Tue, 08 May 2018 11:55:58 GMT):
Has joined the channel.
Amjadnz (Tue, 08 May 2018 15:09:21 GMT):
hi - question being redirected from the node-sdk-forum
Hi! Question on the sendProposal for NODE-SDK (still on Fabric 1.0.5)
My users are doing the following transactions fairly quickly
Transaction 1 - Do an entry in the LEDGER (uisng the chaincodeInvoke at node_js)
Transaction 2 - Do another entry in the LEDGER (using the same chaincodeInvoke at node_js)
The transaction 2 - gets a timeout (of 120 Secs - that is what I set) - then retries again to move forward and succeeds. the end user have to wait for 2 to 3 minutes to get a successful transactions.
My network is TLS Enabled and has 4 Orgs with 2 peers each.
```error: [E2E testing]: transaction proposal was bad
error: [E2E testing]: transaction proposal was bad
error: [E2E testing]: transaction proposal was bad
error: [E2E testing]: transaction proposal was bad
error: [E2E testing]: Failed to send Proposal or receive valid response. Response null or status is not 200. exiting...
error: [E2E testing]: Error: Failed to send Proposal or receive valid response. Response null or status is not 200. exiting...
at promise.then.then.then.then.then (/tts/blockchain/fabric-sdk-node/test/integration/e2e/e2eUtils.js:1212:19)
at
wenjian (Tue, 08 May 2018 18:55:56 GMT):
Has joined the channel.
patelan (Tue, 08 May 2018 20:49:48 GMT):
Hi, Quick question : I am removing peer containers and launching it again and running peer channel list inside peer. It is showing the old channels. How Can I clear the complete cache ? Thanks in advance
Amjadnz (Wed, 09 May 2018 09:03:28 GMT):
Hi guys!
```{"log":"2018-05-09 07:46:02.107 UTC [kvledger] Commit -\u003e INFO 117\u001b[0m Channel [agmchannel]: Created block [75] with 1 transaction(s)\n","stream":"stderr","time":"2018-05-09T07:46:02.112324253Z"}
{"log":"2018-05-09 07:46:42.372 UTC [eventhub_producer] SendProducerBlockEvent -\u003e INFO 118\u001b[0m Channel [agmchannel]: Sending event for block number [75]\n","stream":"stderr","time":"2018-05-09T07:46:42.373476132Z"}```
Why my endorser is taking 44 seconds to send a event for block commit?
Amjadnz (Wed, 09 May 2018 09:03:39 GMT):
Any ideas appreciated
Amjadnz (Wed, 09 May 2018 09:05:19 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=3CBCCf57JPLg23F6s) @patelan - I use the below script to clean off all the working parts and start afresh.
```sudo rm -fR /var/folders/2f
rm -fR /tmp/hfc
rm -fR /var/hyperledger
rm -fR /home/bchadmin/.hfc-key-store/
docker volume rm $(docker volume ls -f 'dangling=true')
docker kill $(docker ps -q)
docker rm $(docker ps -a -q)
docker rmi $(docker images |grep 'dev')```
Amjadnz (Wed, 09 May 2018 09:08:57 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=vy5m7Moku9EdcxM2x) - On the same note - I'm using the couch DB as my state db and I guess that is one part of the slowness. Unfortunately could not see any logs on the couch db side to know any issues.
Amjadnz (Wed, 09 May 2018 09:32:54 GMT):
Another question - my chaincode has multiple PUTSTATEs - can I defer them and commit them together or the changes are gone the momemt put state is called?
Amjadnz (Wed, 09 May 2018 09:33:31 GMT):
I have a feeling that the multiple putstates (actual 5 for transaction records and 5 for index) - is causing the delay in endorsing the transactions.
yacovm (Wed, 09 May 2018 09:34:18 GMT):
no, you can't
yacovm (Wed, 09 May 2018 09:34:27 GMT):
and it's a shame because the ledger has an API for multiple putStates
yacovm (Wed, 09 May 2018 09:34:30 GMT):
but the chaincode doesn't
Amjadnz (Wed, 09 May 2018 09:36:58 GMT):
Hi yacovm - So I should not use the multiple putstates and instruct the app to call each transaction seperately. The issue I merged them that each transaction was taking time and clubbing them improved the initial testing. But now at load testing level - we are observing that the endorsers are very slow in cofirming blocks back.
yacovm (Wed, 09 May 2018 09:37:26 GMT):
confirming blocks?
yacovm (Wed, 09 May 2018 09:37:31 GMT):
what does that mean
Amjadnz (Wed, 09 May 2018 09:37:34 GMT):
confirming transactions
yacovm (Wed, 09 May 2018 09:37:41 GMT):
you mean endorsing?
Amjadnz (Wed, 09 May 2018 09:37:52 GMT):
yes
yacovm (Wed, 09 May 2018 09:38:05 GMT):
well if you have many GetStates or PutStates
yacovm (Wed, 09 May 2018 09:38:19 GMT):
then the chaincode shim plays ping-pong with the peer
yacovm (Wed, 09 May 2018 09:38:32 GMT):
instead of batching everything together :(
yacovm (Wed, 09 May 2018 09:38:34 GMT):
and it is very slow
Amjadnz (Wed, 09 May 2018 09:39:35 GMT):
I c
Amjadnz (Wed, 09 May 2018 09:43:30 GMT):
Phew - atleast something new I learnt - thanks mate.
Probably - that explains that out of 3 transactions ( 2 were single put-states and 1 was multiple putstates)
Amjadnz (Wed, 09 May 2018 09:43:40 GMT):
the last one was taking way too much time
pd93 (Wed, 09 May 2018 10:05:32 GMT):
@yacovm I have a bulk import function in one of my chaincodes. This takes 1000 records at a time, encoded as a string, decodes them and puts each of them into CouchDB with a PutState. This takes around 5 seconds for each bulk. It was my impression that this would be quicker than sending 1000 individual invocations.
However, from what you've just said, this sounds like a bad idea? Could you clarify for me what exactly is bad about multiple PutStates()?
Or is it only bad when used in conjunction with multiple GetStates() as per your ping-pong analogy?
yacovm (Wed, 09 May 2018 10:06:06 GMT):
I feel like i'm hosting an "Ask-Me-Anything" :rolling_eyes:
yacovm (Wed, 09 May 2018 10:06:30 GMT):
Can you use a rich query or a range query @pd93 ?
yacovm (Wed, 09 May 2018 10:06:52 GMT):
oh, you *put* data in?
yacovm (Wed, 09 May 2018 10:06:56 GMT):
not *extract* data?
yacovm (Wed, 09 May 2018 10:09:01 GMT):
it's always faster to send 1 invocation with multiple PutStates than many chaincode invocations...
yacovm (Wed, 09 May 2018 10:09:21 GMT):
in each chaincode invocation there are signature checks, etc. for security
yacovm (Wed, 09 May 2018 10:10:38 GMT):
So yeah - 1000 put-states would mean that the shim sends 1000 messages and wait for responses to/from the peer. It's not that slow since they run in the same computer, but it's still much slower than just passing these 1000 messages in the end of the chaincode invocation...
yacovm (Wed, 09 May 2018 10:10:44 GMT):
@muralisr we should fix this
pd93 (Wed, 09 May 2018 10:12:38 GMT):
Okay, that's really helpful, thanks
pd93 (Wed, 09 May 2018 10:44:43 GMT):
@yacovm If you end up discussing the above as a feature for a future version, would you be so kind as to post a JIRA link? I'd be really interested in tracking that CR as I think it could greatly increase the speed of our imports.
Happy to help create the CR if one does not already exist
yacovm (Wed, 09 May 2018 10:50:41 GMT):
please create a CR anyway
yacovm (Wed, 09 May 2018 10:50:41 GMT):
please create a JIRA anyway
Amjadnz (Wed, 09 May 2018 10:59:34 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=Qg6JNQN59H6iDxZNe) @pd93 - Looks like we are staring the same barrell :relaxed:
pd93 (Wed, 09 May 2018 11:23:42 GMT):
@yacovm @Amjadnz
See JIRA item: FAB-9970
Please feel free to add any thoughts.
Wasn't sure which component this belonged under, so it's in `fabric-peer` for now
Amjadnz (Wed, 09 May 2018 12:25:14 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=Nhi4Pb7knpB8E6oeW) @pd93 Thanks mate - would update it with my comments as well
acombeau (Wed, 09 May 2018 13:13:07 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=o6sFnSWgb5NggrKQo) any idea ?
patelan (Wed, 09 May 2018 17:27:59 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=w3J33GzG37bMR5uiA) @Amjadnz Thanks Amjadnz
Amjadnz (Wed, 09 May 2018 19:45:16 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=YJkwDXmih5B5ySCHD) @yacovm - Just to update once the calls have been broken into single calls - the performance is identical in all the services. So my current issue of 40 secs is no more there.
Would be updating what @pd93 raised in JIRA shortly.
yacovm (Wed, 09 May 2018 19:45:50 GMT):
I don't understand....
yacovm (Wed, 09 May 2018 19:45:52 GMT):
single calls?
Amjadnz (Wed, 09 May 2018 19:49:55 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=tQDctYjaJ5nqTdERJ) @yacovm - I was making combined call with multiple PutStates. On a more complex call - this was taking 2 mins to respond. Other calls were getting response within 300 ms to 500 ms.
Amjadnz (Wed, 09 May 2018 19:50:38 GMT):
once we broke those multiple putstates to single transactions - the process ran fine and we have near identical calls rates.
yacovm (Wed, 09 May 2018 19:50:44 GMT):
and you're saying, that once you broke that call that has `n` put-states, to `n` calls of ` `putState` it is fast?
yacovm (Wed, 09 May 2018 19:50:44 GMT):
and you're saying, that once you broke that call that has `n` put-states, to `n` calls of ` `1` `putState` it is fast?
yacovm (Wed, 09 May 2018 19:50:44 GMT):
and you're saying, that once you broke that call that has `n` put-states, to `n` calls of `1` `putState` it is fast?
yacovm (Wed, 09 May 2018 19:51:11 GMT):
are you doing them in parallel?
yacovm (Wed, 09 May 2018 19:51:13 GMT):
or serially?
Amjadnz (Wed, 09 May 2018 19:51:29 GMT):
yes faster than multiple put states.
Amjadnz (Wed, 09 May 2018 19:51:29 GMT):
yes faster than multiple put states.
yacovm (Wed, 09 May 2018 19:51:49 GMT):
are you doing them in parallel? Or serially?
Amjadnz (Wed, 09 May 2018 19:52:29 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=zrpQKnWDgiJZEgt9P) @yacovm - right now serially. But our next target is doing a full round of load/performance/smoke tests
yacovm (Wed, 09 May 2018 19:52:44 GMT):
holy cow... @muralisr how is that possible? ^
Amjadnz (Wed, 09 May 2018 19:53:29 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=DD5cCFrmjcSB9dJKN) @yacovm - is that a big item - I thought is my performance issue (due to the way my chaincode was structured).
Amjadnz (Wed, 09 May 2018 19:54:11 GMT):
```{"log":"2018-05-09 07:46:02.107 UTC [kvledger] Commit -\u003e INFO 117\u001b[0m Channel [agmchannel]: Created block [75] with 1 transaction(s)\n","stream":"stderr","time":"2018-05-09T07:46:02.112324253Z"}
{"log":"2018-05-09 07:46:42.372 UTC [eventhub_producer] SendProducerBlockEvent -\u003e INFO 118\u001b[0m Channel [agmchannel]: Sending event for block number [75]\n","stream":"stderr","time":"2018-05-09T07:46:42.373476132Z"}```
Amjadnz (Wed, 09 May 2018 19:54:19 GMT):
my older log shoing 42 seconds
Amjadnz (Wed, 09 May 2018 19:54:19 GMT):
my older log showing 42 seconds
yacovm (Wed, 09 May 2018 19:54:31 GMT):
wait....
yacovm (Wed, 09 May 2018 19:54:48 GMT):
that's not what you said
yacovm (Wed, 09 May 2018 19:54:55 GMT):
i thought you meant the *endorsement* is slower
yacovm (Wed, 09 May 2018 19:54:57 GMT):
not the *commit*!
yacovm (Wed, 09 May 2018 19:55:31 GMT):
but - how can the commit take 40 seconds? are you using couchDB?
Amjadnz (Wed, 09 May 2018 19:55:37 GMT):
yes couchdb
yacovm (Wed, 09 May 2018 19:55:52 GMT):
@dave.enyeart ^
yacovm (Wed, 09 May 2018 19:56:08 GMT):
@manish-sethi ^
yacovm (Wed, 09 May 2018 19:56:43 GMT):
what's the endorsement policy @Amjadnz ?
Amjadnz (Wed, 09 May 2018 20:02:28 GMT):
```var request = {
chaincodePath: chaincode_path,
chaincodeId: e2e.chaincodeId,
chaincodeVersion: version,
fcn: 'init',
args: ['a', '100', 'b', '200'],
txId: tx_id,
// use this to demonstrate the following policy:
// 'if signed by org1 admin, then that's the only signature required,
// but if that signature is missing, then the policy can also be fulfilled
// when members (non-admin) from both orgs signed'
'endorsement-policy': {
identities: [
{ role: { name: 'member', mspId: ORGS['dfm'].mspid }},
//{ role: { name: 'member', mspId: ORGS['sca'].mspid }},
//{ role: { name: 'member', mspId: ORGS['adx'].mspid }},
{ role: { name: 'admin', mspId: ORGS['dfm'].mspid }}
],
policy: {
'1-of': [
{ 'signed-by': 2},
{ '2-of': [{ 'signed-by': 0}, { 'signed-by': 1 }]}
]
}
}
};```
Amjadnz (Wed, 09 May 2018 20:02:28 GMT):
```var request = {
chaincodePath: chaincode_path,
chaincodeId: e2e.chaincodeId,
chaincodeVersion: version,
fcn: 'init',
args: ['a', '100', 'b', '200'],
txId: tx_id,
// use this to demonstrate the following policy:
// 'if signed by org1 admin, then that's the only signature required,
// but if that signature is missing, then the policy can also be fulfilled
// when members (non-admin) from both orgs signed'
'endorsement-policy': {
identities: [
{ role: { name: 'member', mspId: ORGS['yyy'].mspid }},
//{ role: { name: 'member', mspId: ORGS['zzz'].mspid }},
//{ role: { name: 'member', mspId: ORGS['aaa'].mspid }},
{ role: { name: 'admin', mspId: ORGS['bbb'].mspid }}
],
policy: {
'1-of': [
{ 'signed-by': 2},
{ '2-of': [{ 'signed-by': 0}, { 'signed-by': 1 }]}
]
}
}
};```
Amjadnz (Wed, 09 May 2018 20:03:46 GMT):
I was trying with many items to the other members are commented, actually - now all are enabled.
yacovm (Wed, 09 May 2018 20:04:20 GMT):
you're giving peers admin certificates, @Amjadnz ?
Amjadnz (Wed, 09 May 2018 20:04:54 GMT):
One the org who is actually the owner of this network is given the admin certs
Amjadnz (Wed, 09 May 2018 20:05:18 GMT):
Anyway that would change - as we are planning to have it transferred to a governing council
yacovm (Wed, 09 May 2018 20:05:22 GMT):
please don't do this
yacovm (Wed, 09 May 2018 20:05:31 GMT):
don't hand out admin certificates to peers
Amjadnz (Wed, 09 May 2018 20:05:45 GMT):
Yes I uderstand - this is just a POC as of now
Amjadnz (Wed, 09 May 2018 20:05:45 GMT):
Yes I understand - this is just a POC as of now
yacovm (Wed, 09 May 2018 20:06:15 GMT):
ok so it's not a huge endorsement policy... it must be couchDB
Amjadnz (Wed, 09 May 2018 20:06:19 GMT):
Proof of concept
Amjadnz (Wed, 09 May 2018 20:08:29 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=aNGYE4C6cxo3LJ48k) @yacovm - But strangely it is fine with the SINGLE transactions at a time. I also got some issues at the couch-db level - but logs here may not be right to discuss
yacovm (Wed, 09 May 2018 20:09:23 GMT):
it's fine because probably it gets split into many blocks
yacovm (Wed, 09 May 2018 20:09:33 GMT):
but i just don't understand how a commit of a block took 40 seconds
yacovm (Wed, 09 May 2018 20:09:40 GMT):
is the couchDB hosted on the moon?
Amjadnz (Wed, 09 May 2018 20:11:14 GMT):
Just to put in right perspective - this is the call logs I had put in another rocket chat (for node-sdk) thinking it is a node sdk specific item.
`Call 1: Sending proposal time is taking as almost 500 milli seconds (ACCPETABLE)`
```info: [11:46:00.230 - E2E testing]: ****** AT CHAIN CODE : Sending Transaction Proposal
info: [11:46:00.781 - E2E testing]: ***** AT CHain code: Recieving results
```
`Call 2: Sending proposal time is taking as almost 450 milli seconds (ACCPETABLE)`
```
info: [11:45:56.359 - E2E testing]: ****** AT CHAIN CODE : Sending Transaction Proposal
info: [11:45:56.803 - E2E testing]: ***** AT CHain code: Recieving results
```
`Call 3: Sending proposal time is taking as almost 40 seconds (This is taking way too long)`
```info: [11:46:04.214 - E2E testing]: ****** AT CHAIN CODE : Sending Transaction Proposal
info: [11:46:43.037 - E2E testing]: ***** AT CHain code: Recieving results ```
Amjadnz (Wed, 09 May 2018 20:38:21 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=pJXfPu2SMN2AfSZ8Y) @yacovm - maybe let me check the couchdb_url :relaxed:
dave.enyeart (Wed, 09 May 2018 21:23:58 GMT):
@Amjadnz If you post a peer debug and highlight the slow transaction I'd be happy to take a look. You could post on fabric-ledger where there is less traffic.
Amjadnz (Thu, 10 May 2018 05:17:58 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=enTh4WqFS6YfMtj5y) @dave.enyeart - Thanks.
Just rewrote the single transactions part and in the process of testing that (and multiple PUTSTATES where an issue). Would be posting it after couple of days - is that fine?
amolpednekar (Thu, 10 May 2018 06:23:09 GMT):
Has joined the channel.
Amjadnz (Thu, 10 May 2018 06:26:55 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=enTh4WqFS6YfMtj5y) @dave.enyeart - done please let me know if you need any other info.
Amjadnz (Thu, 10 May 2018 06:27:40 GMT):
I could not see a slow transaction per se - but the transaction (Multiple PUTSTATE) are taking 40 odd seconds to complete.
SiddharthR (Thu, 10 May 2018 08:58:48 GMT):
Has joined the channel.
SiddharthR (Thu, 10 May 2018 09:20:05 GMT):
I want to create a channel with two organisations and add a transaction to the ledger only if two peers from different organisations sign it. How to do it?
Amjadnz (Thu, 10 May 2018 15:30:15 GMT):
A question with respect to Endorsement policy. If the endorsement policy has a single admin line - what is the impact on the transactions it is submitted or endorsed by the admin node?
Would it be accepted by the orderer?
In my case it is mentioning `validation of endorsement policy failed` and the transaction is not written to the ledger.
Amjadnz (Thu, 10 May 2018 15:30:15 GMT):
A question with respect to Endorsement policy. If the endorsement policy has a single admin line - what is the impact on the transactions it is submitted or endorsed by the admin node?
Would it be accepted by the orderer?
In my case it is mentioning `validation of endorsement policy failed` in the admin node logs and the transaction is not written to the ledger.
Amjadnz (Thu, 10 May 2018 15:32:19 GMT):
Another question is if a transaction proposal is submitted - none of the queries chaincodes are working and gives me a timeout and then after a while (like 60 seconds) retries and gives me the result (may be it is waiting for 140 seconds) - my timeout is 20 secs.
Aswath8687 (Fri, 11 May 2018 01:25:33 GMT):
Has joined the channel.
Amjadnz (Sat, 12 May 2018 17:38:39 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=ZtibRfdwwpiPMc93m) - this issue is now resolved. It was the issue with my configuration and COUCHDB. Once the STATE DB was changed to DEFAULT store (LEVELDB) - all the performance issues went away. Concurrent items and rest all were fine. The requests now are taking less than 500 ms - that was the number we were looking at consistently.
Ryan2 (Mon, 14 May 2018 01:28:59 GMT):
hi I got the issue launching the Chaincode when invoke the chaincode in short period of time (invoking continuously)
`[31m2018-05-11 08:06:04.102 UTC [chaincode] ExecuteChaincode -> ERRO 00eESC[0m Error executing chaincode: premature execution - chaincode (mychannel_CC_001:t4) launched and waiting for registration
[31m2018-05-11 08:06:04.102 UTC [endorser] simulateProposal -> ERRO 00fESC[0m failed to invoke chaincode name:"mychannel_CC_001" on transaction 44e7b7b391fd33491f30cafcffc223d90f8102ff5e5b4baf79aa9e4e8c732da1, error: Error executing chaincode: premature execution - chaincode (mychannel_CC_001:t4) launched and waiting for registration`
But sleep for awhile can avoid this,
Is there any config to adjust so that I can invoke CC continuously?
Ryan2 (Mon, 14 May 2018 01:28:59 GMT):
hi I got the issue launching the Chaincode when invoke the chaincode in short period of time (invoking continuously)
*[31m2018-05-11 08:06:04.102 UTC [chaincode] ExecuteChaincode -> ERRO 00eESC[0m Error executing chaincode: premature execution - chaincode (mychannel_CC_001:t4) launched and waiting for registration
[31m2018-05-11 08:06:04.102 UTC [endorser] simulateProposal -> ERRO 00fESC[0m failed to invoke chaincode name:"mychannel_CC_001" on transaction 44e7b7b391fd33491f30cafcffc223d90f8102ff5e5b4baf79aa9e4e8c732da1, error: Error executing chaincode: premature execution - chaincode (mychannel_CC_001:t4) launched and waiting for registration*
But sleep for awhile can avoid this,
Is there any config to adjust so that I can invoke CC continuously?
Ryan2 (Mon, 14 May 2018 01:28:59 GMT):
hi I got the issue launching the Chaincode when invoke the chaincode in short period of time (invoking continuously)
[31m2018-05-11 08:06:04.102 UTC [chaincode] ExecuteChaincode -> ERRO 00eESC[0m Error executing chaincode: premature execution - chaincode (mychannel_CC_001:t4) launched and waiting for registration
[31m2018-05-11 08:06:04.102 UTC [endorser] simulateProposal -> ERRO 00fESC[0m failed to invoke chaincode name:"mychannel_CC_001" on transaction 44e7b7b391fd33491f30cafcffc223d90f8102ff5e5b4baf79aa9e4e8c732da1, error: Error executing chaincode: premature execution - chaincode (mychannel_CC_001:t4) launched and waiting for registration
But sleep for awhile can avoid this,
Is there any config to adjust so that I can invoke CC continuously?
versus (Mon, 14 May 2018 09:06:47 GMT):
Has joined the channel.
Ryan2 (Mon, 14 May 2018 14:01:25 GMT):
hi I got the issue launching the Chaincode when invoke the chaincode in short period of time (invoking continuously)
[31m2018-05-11 08:06:04.102 UTC [chaincode] ExecuteChaincode -> ERRO 00eESC[0m Error executing chaincode: premature execution - chaincode (mychannel_CC_001:t4) launched and waiting for registration
[31m2018-05-11 08:06:04.102 UTC [endorser] simulateProposal -> ERRO 00fESC[0m failed to invoke chaincode name:"mychannel_CC_001" on transaction 44e7b7b391fd33491f30cafcffc223d90f8102ff5e5b4baf79aa9e4e8c732da1, error: Error executing chaincode: premature execution - chaincode (mychannel_CC_001:t4) launched and waiting for registration
But sleep for awhile can avoid this,
Is there any config to adjust so that I can invoke CC continuously?
jrosmith (Mon, 14 May 2018 14:31:34 GMT):
@Ryan2 are you saying the chaincode container was up and running, you were running transactions against it, and then in the middle of those continuous transactions you got this error?
or had you just instantiated the chaincode and started sending invokes to the peer?
XingqiangMao (Mon, 14 May 2018 17:47:34 GMT):
Has joined the channel.
XingqiangMao (Mon, 14 May 2018 17:48:21 GMT):
Hi Pals, getting issue "failed to create deliver client: orderer client failed to connect to $IP:7050: failed to create new connection: x509: cannot validate certificate for $IP because it doesn't contain any IP SANs"
I am trying to connect orderer from another ip address. It is in the local network.
Any idea what should I do for the certs file
?
Ryan2 (Mon, 14 May 2018 23:14:28 GMT):
Hi @jrosmith , this case: *the chaincode container was up and running, you were running transactions against it, and then in the middle of those continuous transactions you got this error*
acombeau (Tue, 15 May 2018 12:27:33 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=BSuH6QFGfaivTYXdY)
jrosmith (Tue, 15 May 2018 12:36:52 GMT):
@Ryan2 it sounds like the container went down in the middle of transaction processing and then attempted to come back up when the next transaction went through. are there any errors from the peer just before you got the premature execution errors?
alternatively start the process over again and follow the chaincode logs, see what the condition is that causes it to exit
grapebaba (Tue, 15 May 2018 14:23:16 GMT):
Hi guys, we use fabric node sdk and fabric 1.0.2 version, under we heavy load test, peer will got many error during Chat, stopping handler: rpc error: code = Canceled desc = context canceled
grapebaba (Tue, 15 May 2018 14:23:26 GMT):
also in sdk side
grapebaba (Tue, 15 May 2018 14:24:51 GMT):
i merge these two patch https://jira.hyperledger.org/browse/FAB-5464 and https://jira.hyperledger.org/browse/FAB-5775
grapebaba (Tue, 15 May 2018 14:25:06 GMT):
no help
grapebaba (Tue, 15 May 2018 14:32:07 GMT):
any other bug implict there?
dannongruver (Tue, 15 May 2018 17:26:01 GMT):
Has joined the channel.
dannongruver (Tue, 15 May 2018 17:26:09 GMT):
Hi All,Has anyone successfully upgraded a node chaincode? When running the peer chaincode upgrade the command hangs for over 10 mins the gives a timeout error. When running again it returns an error stating that the chaincode is waiting “registration”.
qizhang (Tue, 15 May 2018 18:05:30 GMT):
```
The performance drop rather quickly when you add the second endorser and
the effects of the gossip protocol kicks in. As more endorsers are added to the network, each
endorser has to exchange messages between every other endorsers across the channel which
is why we see a continuous decrease in throughput.
```
qizhang (Tue, 15 May 2018 18:06:05 GMT):
I read this from a report, but why the endorsers need to exchange messages between each other?
rickr (Tue, 15 May 2018 20:42:37 GMT):
I'm seeing a periodic failure with getting the instantiated chaincodes on a peer running the JSDK integration tests. A reverify later and it works.
```
```
peer0.org1.example.com status: 500, message: Authorization for GETCHAINCODES on channel getchaincodes has been denied with error Unmapped policy for lscc/GetInstantiatedChaincodes
```
rickr (Tue, 15 May 2018 20:42:37 GMT):
I'm seeing a periodic failure with getting the instantiated chaincodes on a peer running the JSDK integration tests. A reverify later and it works.
```
peer0.org1.example.com status: 500, message: Authorization for GETCHAINCODES on channel getchaincodes has been denied with error Unmapped policy for lscc/GetInstantiatedChaincodes
```
This test runs against the latest and Fabric v1.0.0 . v1.0.0 never see this issue .. at least I've not seen it yet.
The JSDK code for this has not changed in some time.
rickr (Tue, 15 May 2018 20:45:59 GMT):
@wlahti @muralisr @mastersingh24 ^^^
yacovm (Tue, 15 May 2018 20:46:20 GMT):
@jyellick ^
wlahti (Tue, 15 May 2018 20:46:32 GMT):
The fix was just merged within the last hour or two
wlahti (Tue, 15 May 2018 20:46:32 GMT):
The fix was merged within the last hour or two
wlahti (Tue, 15 May 2018 20:46:32 GMT):
@rickr The fix was merged within the last hour or two: https://gerrit.hyperledger.org/r/c/21829/
rickr (Tue, 15 May 2018 20:47:56 GMT):
ok real life calls .. will try it again later thx
rickr (Wed, 16 May 2018 00:25:14 GMT):
ok seems to be passing now.
davidkhala (Wed, 16 May 2018 01:57:05 GMT):
Has joined the channel.
rickr (Wed, 16 May 2018 12:34:37 GMT):
for deploy chaincode the chaincode running is lscc it has for example these args:
```
Transaction action 1 has chaincode input argument 0 is: deploy
Transaction action 1 has chaincode input argument 1 is: bar
Transaction action 1 has chaincode input argument 2 is: ?E???)??github.com/example_cc??example_cc_go??1????init??a??500?...
Transaction action 1 has chaincode input argument 3 is: ? ??????????????????????????????????????Org1MSP??????Org2MSP????...
```
rickr (Wed, 16 May 2018 12:34:47 GMT):
deploying to channel bar
rickr (Wed, 16 May 2018 12:35:40 GMT):
arg 2, and 3 are serialized what ? sure one is the ChaincodeDeploymentSpec
rickr (Wed, 16 May 2018 13:14:45 GMT):
got help from @dave.enyeart thx
gravity (Wed, 16 May 2018 14:54:46 GMT):
Has joined the channel.
asaningmaxchain123 (Thu, 17 May 2018 00:34:51 GMT):
@yacovm @C0rWin when the peer endorse the request,i see the source code, it contains following code
asaningmaxchain123 (Thu, 17 May 2018 00:34:54 GMT):
Clipboard - May 17, 2018 8:34 AM
asaningmaxchain123 (Thu, 17 May 2018 00:35:03 GMT):
Clipboard - May 17, 2018 8:35 AM
asaningmaxchain123 (Thu, 17 May 2018 00:36:08 GMT):
in my mind,the peer will pull the block from the orderer node,and distribute among the peers,so can you tell me what's the meaning of the above source code
yacovm (Thu, 17 May 2018 06:08:49 GMT):
This is private data distribution, @asaningmaxchain123
asaningmaxchain123 (Thu, 17 May 2018 06:09:32 GMT):
can you provide more detail?
asaningmaxchain123 (Thu, 17 May 2018 06:10:09 GMT):
what's the private data @yacovm
asaningmaxchain123 (Thu, 17 May 2018 06:10:09 GMT):
what's the private data @yacovm
asaningmaxchain123 (Thu, 17 May 2018 06:13:30 GMT):
what's the function of it?
yacovm (Thu, 17 May 2018 06:30:42 GMT):
so let's say you want to send information to another org, but you don't want the ordering service and other orgs to be able to see the information you send
yacovm (Thu, 17 May 2018 06:31:06 GMT):
but they can see the information because it is all plain-text on the public blockchain that everyone sees
yacovm (Thu, 17 May 2018 06:31:19 GMT):
and the orderer, for example - always sees all the blocks
yacovm (Thu, 17 May 2018 06:31:41 GMT):
so instead of putting the data in the simulation results that are sent back to the client
yacovm (Thu, 17 May 2018 06:31:49 GMT):
you put the hash of the data
yacovm (Thu, 17 May 2018 06:32:09 GMT):
and so - the hash of the data, not the data itself is present in the blockchain, and the other organizations can't see what is inside
yacovm (Thu, 17 May 2018 06:32:43 GMT):
now - the peers you endorse on, they send the data itself (the hash's pre-image) to other peers according to some access control policy defined at chaincode instantiation
yacovm (Thu, 17 May 2018 06:32:55 GMT):
this way - only the organizations you want to see the data - see the data
yacovm (Thu, 17 May 2018 06:32:56 GMT):
@asaningmaxchain123
chongxinman (Thu, 17 May 2018 06:37:45 GMT):
Has joined the channel.
asaningmaxchain123 (Thu, 17 May 2018 07:19:37 GMT):
so if i want to send the data the specified org, when the peer endorse the `client request` and get `simulation result` but the `simulation result` doesn't return the client.
asaningmaxchain123 (Thu, 17 May 2018 07:19:37 GMT):
so if i want to send the data the specified org, when the peer endorse the `client data` and get `simulation result` but the `simulation result` doesn't return the client.
asaningmaxchain123 (Thu, 17 May 2018 07:19:37 GMT):
so if i want to send the data the specified org, when the peer endorse the `client data` and get `simulation result` but the `simulation result` doesn't return the client.it use the gossip protocol to distribute it
asaningmaxchain123 (Thu, 17 May 2018 07:19:37 GMT):
so if i want to send the data the specified org, when the peer endorse the `client data` and get `simulation result` but the `simulation result` doesn't return the client. it use the gossip protocol to distribute it
asaningmaxchain123 (Thu, 17 May 2018 07:19:49 GMT):
@yacovm right?
yacovm (Thu, 17 May 2018 07:55:47 GMT):
The simulation result contains hashes
asaningmaxchain123 (Thu, 17 May 2018 10:22:07 GMT):
@yacovm can you tell me the location of the source,it produces the hash of the data
asaningmaxchain123 (Thu, 17 May 2018 10:22:07 GMT):
@yacovm can you tell me the location of the source,it produces the hash of the simulation results
yacovm (Thu, 17 May 2018 10:32:31 GMT):
@manish-sethi can tell you
yacovm (Thu, 17 May 2018 10:32:57 GMT):
ask in #fabric-ledger
asaningmaxchain123 (Thu, 17 May 2018 11:43:37 GMT):
@yacovm @C0rWin when the chaincode instantiate the options the option for ·collections-config·
asaningmaxchain123 (Thu, 17 May 2018 11:43:37 GMT):
@yacovm @C0rWin when the chaincode instantiate the options the option for `collections-config`,i don't understand, can you give me an example
asaningmaxchain123 (Thu, 17 May 2018 11:43:37 GMT):
@yacovm @C0rWin @jyellick when the chaincode instantiate the options the option for `collections-config`,i don't understand, can you give me an example
yacovm (Thu, 17 May 2018 11:55:30 GMT):
take a look here https://gerrit.hyperledger.org/r/#/c/14769/13/examples/e2e_cli/scripts/script_marbles_private.sh @asaningmaxchain123
AshishMishra 1 (Thu, 17 May 2018 12:40:55 GMT):
Hi everyone,
can I run orderer service behind a reverse proxy or a tcp load balancer f ? My peers will connect to the lb or proxy. Is there any harm in doing so ?
yacovm (Thu, 17 May 2018 12:47:40 GMT):
a TCP load balancer would work without a problem
yacovm (Thu, 17 May 2018 12:48:02 GMT):
a reverse proxy - it can work as long as you don't activate client authentication in the TLS (AKA mutual TLS)
yacovm (Thu, 17 May 2018 12:48:17 GMT):
also - make sure the peer and chaincode are running on the same host
yacovm (Thu, 17 May 2018 12:48:31 GMT):
otherwise, the mutual TLS between the peer and chaincode container would break because of the reverse proxy
yacovm (Thu, 17 May 2018 12:49:13 GMT):
you need a reverse proxy that works well with gRPC and TLS - I recommend nghttpx
dave.enyeart (Thu, 17 May 2018 12:51:48 GMT):
@asaningmaxchain123 Please review the Private Data demo playback at the bottom of this page first: https://wiki.hyperledger.org/projects/fabric/playbacks . Then ask any follow-on questions if you still have questions.
AshishMishra 1 (Thu, 17 May 2018 13:01:20 GMT):
@yacovm thanks. So I didn't enter an alien territory. :) I was trying to use envoy, so far it's been bad, do you know about it? I did try with haproxy it worked but i 've some concerns with it. Will give nghttpx a try.
bourbonkidQ (Thu, 17 May 2018 13:01:28 GMT):
Hello, when the nodeSDK try to instantiate the chaincode i have this following error on the peer `2018-05-17 12:49:05.271 UTC [deliveryClient] RequestBlocks -> DEBU 4b1 Starting deliver with block [1] for channel mychannel
2018-05-17 12:49:05.272 UTC [blocksProvider] DeliverBlocks -> WARN 4b2 [mychannel] Got error &{NOT_FOUND} ` to you have any idea ? I have already create the channel on the peer
bourbonkidQ (Thu, 17 May 2018 13:01:28 GMT):
Hello, when the nodeSDK try to instantiate the chaincode i have this following error on the peer `2018-05-17 12:49:05.271 UTC [deliveryClient] RequestBlocks -> DEBU 4b1 Starting deliver with block [1] for channel mychannel 2018-05-17 12:49:05.272 UTC [blocksProvider] DeliverBlocks -> WARN 4b2 [mychannel] Got error &{NOT_FOUND} ` to you have any idea ? I have already create the channel on the peer
yacovm (Thu, 17 May 2018 13:02:30 GMT):
I thought envoy uses nghttpx ?
yacovm (Thu, 17 May 2018 13:03:03 GMT):
i mean they use the same base code in the end, no?
yacovm (Thu, 17 May 2018 13:04:37 GMT):
nghttp2 ?
AshishMishra 1 (Thu, 17 May 2018 13:04:55 GMT):
Maybe same set of libraries, possible. I liked isitio which is based on envoy but it has dependency on k8, which I don't plan to use.
yacovm (Thu, 17 May 2018 13:05:30 GMT):
just don't use these stuff for load balancing
yacovm (Thu, 17 May 2018 13:05:35 GMT):
fabric has load balancing on its own
AshishMishra 1 (Thu, 17 May 2018 13:05:42 GMT):
yes, I think nghttp2 library
AshishMishra 1 (Thu, 17 May 2018 13:06:17 GMT):
Basically I want my entire fabric inside a private subnet.. and I need a gateway for external word to connect to my orderer
AshishMishra 1 (Thu, 17 May 2018 13:06:31 GMT):
world*
yacovm (Thu, 17 May 2018 13:06:32 GMT):
makes sense
yacovm (Thu, 17 May 2018 13:06:40 GMT):
well so i listed what you can do
AshishMishra 1 (Thu, 17 May 2018 13:06:54 GMT):
So I thought of putting a proxy/lb in the public subnet.
AshishMishra 1 (Thu, 17 May 2018 13:07:59 GMT):
Thanks, @yacovm will give nghttpx a shot. Will see how it goes.
rahulhegde (Thu, 17 May 2018 16:53:17 GMT):
Hyperledgr Fabric - 1.0.6
Hello @jyellick
We see following error in fabric peer log `https://github.com/hyperledger/fabric/blob/release-1.0/core/chaincode/chaincode_support.go#L745`. I don't see any error in the chaincode container log for the same time. Now, any endorsement transaction sent by HFC fails with the same error.
Is the connection between chaincode and peer broken, as I don't see any endorsement reaching to the chaincode (from its log). What is the retry mechanism for chaicode container, if the connection gets dropped?
Any other possible cause/reason.
we have the following set `https://github.com/hyperledger/fabric/blob/release-1.0/sampleconfig/core.yaml#L372`.
jyellick (Thu, 17 May 2018 17:41:24 GMT):
@rahulhegde Is the chaincode container running? Do you see it establish a connection in the logs?
rahulhegde (Thu, 17 May 2018 17:43:37 GMT):
We restarted the peer container as we had to patch the system soon. the container logs are available and peer was also running at ERROR level.
rahulhegde (Thu, 17 May 2018 22:59:59 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=iQtQQzwnXdQXs7DTB) @jyellick
We restarted the peer container as we had to patch the system soon. the container logs are available and peer was also running at ERROR level.
rahulhegde (Thu, 17 May 2018 22:59:59 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=iQtQQzwnXdQXs7DTB) @jyellick
Peer and its corresponding chaincode containers were running. There is no Error/Warning of kind during that period except for the above error whenever a endorsement request is sent. Also there were other peers running on the same host however there is nothing like such thing happened to them.
We restarted the peer container as we had to patch the system soon. The chaincode container logs is available at DEBUG level and peer was running at ERROR level. I should have done a `netstat` inside the peer (but did not).
header340 (Fri, 18 May 2018 16:03:07 GMT):
Has joined the channel.
rickr (Mon, 21 May 2018 11:50:19 GMT):
Having issues using private data .. from the peer logs https://ctrlv.it/id/123035/3781050195
rickr (Mon, 21 May 2018 11:50:19 GMT):
Having issues using private data .. from the peer logs https://ctrlv.it/id/123035/3781050195
this is what create the collection policy https://ctrlv.it/id/123037/2230344044
rickr (Mon, 21 May 2018 11:50:19 GMT):
Having issues using private data .. from the peer logs https://ctrlv.it/id/123035/3781050195
this is what create the collection policy https://ctrlv.it/id/123037/2230344044
Chaincode output logs https://ctrlv.it/id/123038/2425840439
rickr (Mon, 21 May 2018 11:50:19 GMT):
Having issues using private data .. from the peer logs https://ctrlv.it/id/123035/3781050195
this is what create the collection policy https://ctrlv.it/id/123037/2230344044
Chaincode output logs https://ctrlv.it/id/123038/2425840439
Actual chaincode --> https://ctrlv.it/id/123039/361718200
rickr (Mon, 21 May 2018 11:56:30 GMT):
@dave.enyeart @C0rWin ^^^
rickr (Mon, 21 May 2018 11:58:28 GMT):
At the moment I don't have gossip worknig but I don't think that would be the issue here. I have two peers I'm sending the endorsements to and both go to the orderer
rickr (Mon, 21 May 2018 11:59:43 GMT):
The init seems to work. The set of both values don't seem to cause a problem. But when I try to retrieve the value from one I get this error
C0rWin (Mon, 21 May 2018 12:00:04 GMT):
well, there is nothing related to dissemination of the data here
rickr (Mon, 21 May 2018 12:00:27 GMT):
does the logs indicate anything why that error ?
C0rWin (Mon, 21 May 2018 12:00:35 GMT):
looking
rickr (Mon, 21 May 2018 12:01:23 GMT):
I filtered out the gossip messages so maybe some info missing here
C0rWin (Mon, 21 May 2018 12:02:07 GMT):
`2018-05-21 11:30:22.051 UTC [chaincode] HandleTransaction -> ERRO a5b6 [709b13c7] Failed to handle GET_STATE. error: Private data matching public hash version is not available. Public hash version = &version.Height{BlockNum:0x10, TxNum:0x0}, Private data version = (*version.Height)(nil)`
rickr (Mon, 21 May 2018 12:02:32 GMT):
I'm sure that means a lot to you .. but not to me :)
C0rWin (Mon, 21 May 2018 12:02:35 GMT):
that looks weird to me
C0rWin (Mon, 21 May 2018 12:03:18 GMT):
``` maximumPeerCount: 0 # the maximum number of peers this collection can be disseminated to.
requiredPeerCount: 0 # the minimum number of peers this collection must be disseminated to.```
C0rWin (Mon, 21 May 2018 12:03:45 GMT):
are you aware that having this means you do not distribute pvt data during endorsement?
rickr (Mon, 21 May 2018 12:04:09 GMT):
ok -- that was what I think @dave.enyeart said he was using for his testing
C0rWin (Mon, 21 May 2018 12:04:10 GMT):
is there particular reason to have these values to zero?
C0rWin (Mon, 21 May 2018 12:04:53 GMT):
he used for test case there he wanted to ensure gossip respect this value and doesn't push pvt data to other peers once pvt tx endorsed
C0rWin (Mon, 21 May 2018 12:05:13 GMT):
asking just to make sure you understand implications of this property, not saying this is related
rickr (Mon, 21 May 2018 12:05:39 GMT):
ok - for my testing I think it's ok .. and gossip isn't really function in it
C0rWin (Mon, 21 May 2018 12:06:20 GMT):
https://ctrlv.it/id/123035/3781050195
C0rWin (Mon, 21 May 2018 12:06:31 GMT):
this output, is it during endorsement?
C0rWin (Mon, 21 May 2018 12:07:08 GMT):
or tx was endorsed, block committed and the output is for subsequent query?
C0rWin (Mon, 21 May 2018 12:09:13 GMT):
```
// Query callback representing the query of a chaincode ===>>> ONLY Query B VALUES
func (t *SimpleChaincode) query(stub shim.ChaincodeStubInterface, args []string) pb.Response {
var A string // Entities
var err error
if len(args) != 1 {
return shim.Error("Incorrect number of arguments. Expecting name of the person to query")
}
A = args[0]
logger.Infof("query for %sn", A)
// Get the state from the ledger
Avalbytes, err := stub.GetPrivateData("COLLECTION_FOR_B", A)
if err != nil {
jsonResp := "{"Error":"Failed to get state for " + A + ""}"
return shim.Error(jsonResp)
}
if Avalbytes == nil {
jsonResp := "{"Error":"Nil amount for " + A + ""}"
return shim.Error(jsonResp)
}
jsonResp := "{"Name":"" + A + "","Amount":"" + string(Avalbytes) + ""}"
logger.Infof("Query Response:%sn", jsonResp)
return shim.Success(Avalbytes)
}```
C0rWin (Mon, 21 May 2018 12:10:06 GMT):
you are querying for data from `COLLECTION_FOR_B`
rickr (Mon, 21 May 2018 12:10:13 GMT):
yes
rickr (Mon, 21 May 2018 12:10:25 GMT):
only want whats going into b
rickr (Mon, 21 May 2018 12:11:21 GMT):
```
2018-05-21 11:45:11.673 UTC [example_cc0] Info -> INFO 001 ########### example_cc Init ###########
2018-05-21 11:45:13.840 UTC [example_cc0] Info -> INFO 002 ########### private_data_cc Invoke ###########
2018-05-21 11:45:13.840 UTC [example_cc0] Info -> INFO 003 invoke function: set
2018-05-21 11:45:13.840 UTC [example_cc0] Infof -> INFO 004 set a = 500, b = 250
2018-05-21 11:45:13.853 UTC [example_cc0] Infof -> INFO 005 set done a = 500, b = 250
2018-05-21 11:45:15.943 UTC [example_cc0] Info -> INFO 006 ########### private_data_cc Invoke ###########
2018-05-21 11:45:15.944 UTC [example_cc0] Info -> INFO 007 invoke function: query
2018-05-21 11:45:15.944 UTC [example_cc0] Infof -> INFO 008 query for b
2018-05-21 11:45:15.948 UTC [shim] handleGetState -> ERRO 009 [5e770c53] GetState received error ERROR
```
rickr (Mon, 21 May 2018 12:11:48 GMT):
the set was invoked ok .. then the query .. as it shows it's for `b`
rickr (Mon, 21 May 2018 12:20:11 GMT):
I would assume both those collections have been set up ok as the `set` operation is not having an issue
dave.enyeart (Mon, 21 May 2018 12:21:26 GMT):
@C0rWin There are two peers in Rick's scenario, and he sends endorsement to both. Therefore it doesn't require any other gossip dissemination, and he sets the dissemination to 0. I do similar things in my tests and it is fine.
dave.enyeart (Mon, 21 May 2018 12:21:51 GMT):
It appears his peers don't commit the private data, I assume because they think they are not eligible.
dave.enyeart (Mon, 21 May 2018 12:22:27 GMT):
I can re-create the same thing and unfortunately there is no debug message stating the peer is ineligible, it just silently ignores the private data.
dave.enyeart (Mon, 21 May 2018 12:22:27 GMT):
I can re-create the same thing when i mis-configure the collection policy, and unfortunately there is no debug message stating the peer is ineligible, it just silently ignores the private data.
dave.enyeart (Mon, 21 May 2018 12:23:02 GMT):
That is why I asked for a clear debug message when peer is ineligible, and probably even a Warning the first time it happens, so that people doing trials without debug can see it
rickr (Mon, 21 May 2018 12:23:49 GMT):
by not being eligible .. is it the signature policy in the collection that determings that ?
dave.enyeart (Mon, 21 May 2018 12:23:58 GMT):
right
C0rWin (Mon, 21 May 2018 12:24:11 GMT):
I'd assume this is something within `stateleveldb` while writing state?
C0rWin (Mon, 21 May 2018 12:24:11 GMT):
I'd assume this is something within `stateleveldb` while writing state? right @dave.enyeart
C0rWin (Mon, 21 May 2018 12:24:11 GMT):
I'd assume this is something within `stateleveldb` while writing state? right @dave.enyeart ?
rickr (Mon, 21 May 2018 12:24:50 GMT):
I tried with both `member` and `peer` roles BTW
dave.enyeart (Mon, 21 May 2018 12:25:06 GMT):
yes, you can probably see the hashes getting written to public state but nothing getting written to private state
dave.enyeart (Mon, 21 May 2018 12:25:28 GMT):
if you have peer debug on
dave.enyeart (Mon, 21 May 2018 12:25:44 GMT):
that's what I see when I mis-configure the collection dissemination signature policy
dave.enyeart (Mon, 21 May 2018 12:26:33 GMT):
A very clear debug message indicating the collection dissemination signature policy and the peer's identity would be valuable
rickr (Mon, 21 May 2018 12:31:32 GMT):
Are there any tools you can use to look at statedb see what's been created ?
C0rWin (Mon, 21 May 2018 12:34:04 GMT):
in case of couchdb you can connect to it's interface and run queries
rickr (Mon, 21 May 2018 12:35:31 GMT):
ok good to know
rickr (Mon, 21 May 2018 12:37:14 GMT):
More than likely I'll admit this is an issue with my setup but it's blocking me from finishing up the private data feature in JSDK
rickr (Mon, 21 May 2018 12:52:31 GMT):
I tried with all four role types .. same result
rickr (Mon, 21 May 2018 13:16:24 GMT):
Is it expected that if the endorsement fails that the response will not be signed ?
rickr (Mon, 21 May 2018 13:17:17 GMT):
I think the client should still see it signed so it knows it can trust it -- I'm not seeing it signed in this case
C0rWin (Mon, 21 May 2018 13:32:44 GMT):
@rickr have you tried to query both peers, btw?
rickr (Mon, 21 May 2018 13:39:44 GMT):
```
ubuntu@hyperledger-devenv:6789db6:/opt/gopath/src/github.com/hyperledger/fabric/sdkintegration/e2e-2Orgs/v1.2$ docker logs dev-peer0.org2.example.com-private_data_cc22_go-1
2018-05-21 13:05:23.767 UTC [example_cc0] Info -> INFO 001 ########### example_cc Init ###########
2018-05-21 13:05:59.535 UTC [example_cc0] Info -> INFO 002 ########### private_data_cc Invoke ###########
2018-05-21 13:05:59.535 UTC [example_cc0] Info -> INFO 003 invoke function: set
2018-05-21 13:05:59.535 UTC [example_cc0] Infof -> INFO 004 set a = 500, b = 250
2018-05-21 13:05:59.539 UTC [example_cc0] Infof -> INFO 005 set done a = 500, b = 250
2018-05-21 13:07:33.047 UTC [example_cc0] Info -> INFO 006 ########### private_data_cc Invoke ###########
2018-05-21 13:07:33.047 UTC [example_cc0] Info -> INFO 007 invoke function: query
2018-05-21 13:07:33.047 UTC [example_cc0] Infof -> INFO 008 query for b
2018-05-21 13:07:33.053 UTC [shim] handleGetState -> ERRO 009 [f1458c9c] GetState received error ERROR
ubuntu@hyperledger-devenv:6789db6:/opt/gopath/src/github.com/hyperledger/fabric/sdkintegration/e2e-2Orgs/v1.2$ docker logs dev-peer1.org2.example.com-private_data_cc22_go-1
2018-05-21 13:05:23.651 UTC [example_cc0] Info -> INFO 001 ########### example_cc Init ###########
2018-05-21 13:05:59.547 UTC [example_cc0] Info -> INFO 002 ########### private_data_cc Invoke ###########
2018-05-21 13:05:59.547 UTC [example_cc0] Info -> INFO 003 invoke function: set
2018-05-21 13:05:59.547 UTC [example_cc0] Infof -> INFO 004 set a = 500, b = 250
2018-05-21 13:05:59.549 UTC [example_cc0] Infof -> INFO 005 set done a = 500, b = 250
2018-05-21 13:07:33.050 UTC [example_cc0] Info -> INFO 006 ########### private_data_cc Invoke ###########
2018-05-21 13:07:33.050 UTC [example_cc0] Info -> INFO 007 invoke function: query
2018-05-21 13:07:33.050 UTC [example_cc0] Infof -> INFO 008 query for b
2018-05-21 13:07:33.051 UTC [shim] handleGetState -> ERRO 009 [f1458c9c] GetState received error ERROR
```
rickr (Mon, 21 May 2018 13:44:06 GMT):
FYI :
```
commit 6789db6ea4a69428a08c86431984f276aa1ed54c (HEAD -> master, origin/master, origin/HEAD)
Date: Mon May 14 02:40:22 2018 +0300
```
rickr (Mon, 21 May 2018 13:53:39 GMT):
I assume the collection is scoped within the chaincode if another chaincode creates the same named collection they won't be the same
yacovm (Mon, 21 May 2018 13:57:58 GMT):
@rickr correct - collection is scoped within a chaincode
rickr (Mon, 21 May 2018 14:02:07 GMT):
@dave.enyeart does the logs show what's being written where ?
jyellick (Mon, 21 May 2018 15:22:02 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=qcb8E2RvLKusB2tYj)
jyellick (Mon, 21 May 2018 15:23:19 GMT):
@rahulhegde If the chaincode container is running, then I would expect for it to have connected successfully. Would it be possible to reproduce with peer logs at debug?
rickr (Mon, 21 May 2018 15:40:09 GMT):
@C0rWin @dave.enyeart here is a more complete log of the peer .. should include install/init/set/query operations
rickr (Mon, 21 May 2018 15:40:11 GMT):
https://ctrlv.it/id/123075/2859149410
rickr (Mon, 21 May 2018 15:56:57 GMT):
```
2018-05-21 15:25:27.512 UTC [gossip/privdata] StoreBlock -> WARN e8a2 Could not fetch all missing collection private write sets from remote peers. Will commit block with missing private write sets: txID: 33c79e340b243bbda3b5e03ced761bb924521e43159eec5b9009b6271fab1377, seq: 0, namespace: private_data_cc25_go, collection: COLLECTION_FOR_A, hash: 03db7ee8121f4f2012ad172d8dc68eb85e3bee5c76b892dca2b78beecc5151f3
txID: 33c79e340b243bbda3b5e03ced761bb924521e43159eec5b9009b6271fab1377, seq: 0, namespace: private_data_cc25_go, collection: COLLECTION_FOR_B, hash: c39b2e208402f5acf9a4491865f8bf54669f0f690f5c87cb340967919c09a07b
```
?
rickr (Mon, 21 May 2018 15:57:39 GMT):
Like I stated gossip isn't really working for me .. so not sure if that's an issue here .. wouldn't think so
rickr (Mon, 21 May 2018 15:59:10 GMT):
```
2018-05-21 15:25:27.512 UTC [gossip/privdata] StoreBlock -> WARN e8a2 Could not fetch all missing collection private write sets from remote peers. Will commit block with missing private write sets: txID: 33c79e340b243bbda3b5e03ced761bb924521e43159eec5b9009b6271fab1377, seq: 0, namespace: private_data_cc25_go, collection: COLLECTION_FOR_A, hash: 03db7ee8121f4f2012ad172d8dc68eb85e3bee5c76b892dca2b78beecc5151f3
txID: 33c79e340b243bbda3b5e03ced761bb924521e43159eec5b9009b6271fab1377, seq: 0, namespace: private_data_cc25_go, collection: COLLECTION_FOR_B, hash: c39b2e208402f5acf9a4491865f8bf54669f0f690f5c87cb340967919c09a07b
```
rickr (Mon, 21 May 2018 15:59:54 GMT):
```
2018-05-21 15:25:27.530 UTC [stateleveldb] ApplyUpdates -> DEBU e8c4 Channel [bar]: Applying key(string)=[private_data_cc25_go$$hCOLLECTION_FOR_B>#\ufffd9YJ3\ufffdOed\ufffd\ufffd4\ufffd\ufffdz\ufffd\ufffd,J\ufffds\ufffd\ufffd\u055c\ufffd] key(bytes)=[[]byte{0x70, 0x72, 0x69, 0x76, 0x61, 0x74, 0x65, 0x5f, 0x64, 0x61, 0x74, 0x61, 0x5f, 0x63, 0x63, 0x32, 0x35, 0x5f, 0x67, 0x6f, 0x24, 0x24, 0x68, 0x43, 0x4f, 0x4c, 0x4c, 0x45, 0x43, 0x54, 0x49, 0x4f, 0x4e, 0x5f, 0x46, 0x4f, 0x52, 0x5f, 0x42, 0x0, 0x3e, 0x23, 0xe8, 0x16, 0x0, 0x39, 0x59, 0x4a, 0x33, 0x89, 0x4f, 0x65, 0x64, 0xe1, 0xb1, 0x34, 0x8b, 0xbd, 0x7a, 0x0, 0x88, 0xd4, 0x2c, 0x4a, 0xcb, 0x73, 0xee, 0xae, 0xd5, 0x9c, 0x0, 0x9d}]
2018-05-21 15:25:27.530 UTC [stateleveldb] ApplyUpdates -> DEBU e8c5 Channel [bar]: Applying key(string)=[private_data_cc25_go$$hCOLLECTION_FOR_A\u0297\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd1\ufffd\ufffd#\ufffdM\ufffd\ufffd\ufffd\ufffd|Nr\ufffd\ufffdw\ufffd\ufffd\ufffdH\ufffd] key(bytes)=[[]byte{0x70, 0x72, 0x69, 0x76, 0x61, 0x74, 0x65, 0x5f, 0x64, 0x61, 0x74, 0x61, 0x5f, 0x63, 0x63, 0x32, 0x35, 0x5f, 0x67, 0x6f, 0x24, 0x24, 0x68, 0x43, 0x4f, 0x4c, 0x4c, 0x45, 0x43, 0x54, 0x49, 0x4f, 0x4e, 0x5f, 0x46, 0x4f, 0x52, 0x5f, 0x41, 0x0, 0xca, 0x97, 0x81, 0x12, 0xca, 0x1b, 0xbd, 0xca, 0xfa, 0xc2, 0x31, 0xb3, 0x9a, 0x23, 0xdc, 0x4d, 0xa7, 0x86, 0xef, 0xf8, 0x14, 0x7c, 0x4e, 0x72, 0xb9, 0x80, 0x77, 0x85, 0xaf, 0xee, 0x48, 0xbb}]
2018-05-21 15:25:27.531 UTC [lockbasedtxmgr] Commit -> DEBU e8c6 Updates committed to state database
2018-05-21 15:25:27.531 UTC [leveldbhelper] GetIterator -> DEBU e8c7 Getting iterator for range [[]byte{0x62, 0x61, 0x72, 0x2f, 0x30, 0x0, 0x31, 0x1, 0x22, 0x0}] - [[]byte{0x62, 0x61, 0x72, 0x2f, 0x30, 0x0, 0x31, 0x1, 0x23, 0x0}]
2018-05-21 15:25:27.531 UTC [kvledger] CommitWithPvtData -> DEBU e8c8 Channel [bar]: Committing block [33] transactions to history database
2018-05-21 15:25:27.531 UTC [historyleveldb] Commit -> DEBU e8c9 Channel [bar]: Updating history database for blockNo [33] with [1] transactions
2018-05-21 15:25:27.532 UTC [historyleveldb] Commit -> DEBU e8ca Channel [bar]: Updates committed to history database for blockNo [33]
```
rickr (Mon, 21 May 2018 16:07:30 GMT):
The key collection match when doing the fetch :
```
2018-05-21 15:25:27.571 UTC [stateleveldb] GetState -> DEBU e90b GetState(). ns=private_data_cc25_go$$hCOLLECTION_FOR_B, key=>#\ufffd9YJ3\ufffdOed\ufffd\ufffd4\ufffd\ufffdz\ufffd\ufffd,J\ufffds\ufffd\ufffd\u055c\ufffd
2018-05-21 15:25:27.571 UTC [chaincode] HandleTransaction -> ERRO e90c [5d2ce10c] Failed to handle GET_STATE. error: Private data matching public hash version is not available. Public hash version = &version.Height{BlockNum:0x21, TxNum:0x0}, Private data version = (*version.Height)(nil)
github.com/hyperledger/fabric/core/chaincode.(*Handler).HandleGetState
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:540
github.com/hyperledger/fabric/core/chaincode.(*Handler).HandleGetState-fm
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:191
github.com/hyperledger/fabric/core/chaincode.(*Handler).HandleTransaction
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:236
```
dave.enyeart (Mon, 21 May 2018 16:18:56 GMT):
@rickr I see what's happening. You are hitting a bug that has been fixed in latest master:
dave.enyeart (Mon, 21 May 2018 16:18:59 GMT):
2018-05-21 15:24:27.466 UTC [gossip/privdata] fetchFromTransientStore -> WARN e80f Failed iterating: proto: rwset.TxPvtReadWriteSet: illegal tag 0 (wire type 0)
dave.enyeart (Mon, 21 May 2018 16:19:06 GMT):
If you grab the latest it should work
dave.enyeart (Mon, 21 May 2018 16:19:32 GMT):
your config appears to be correct... as it appears the peer found it is eligible for the private data
rickr (Mon, 21 May 2018 16:20:19 GMT):
ok will do
rickr (Mon, 21 May 2018 17:05:56 GMT):
Works!
hyperlearner (Tue, 22 May 2018 09:11:09 GMT):
Has joined the channel.
hyperlearner (Tue, 22 May 2018 10:09:19 GMT):
I want 5 peers all to act as endorsers where I have to set a condition if atleast any 2 of them approve,
the tx should happen.
where should I make the changes?
jrosmith (Tue, 22 May 2018 13:06:42 GMT):
@hyperlearner you will need to update your endorsement policy to require at least 2 signatures
rickr (Tue, 22 May 2018 19:04:39 GMT):
I'm seeing more of these lately :
`500, message: failed to execute transaction d0755c373f17fa681de4ec08d427e873b1c2d299cf5f9c7ca97179ee2bfe095d: error sending: timeout expired while executing transaction`
rickr (Tue, 22 May 2018 19:05:32 GMT):
Is there any way to up that in the docker-compose file ? and it doesn't indicate how much time was really allotted :(
yacovm (Tue, 22 May 2018 19:17:34 GMT):
@rickr what chaincode is that? is that node.js CC?
rickr (Tue, 22 May 2018 19:18:22 GMT):
it was go that time
sanchezl (Tue, 22 May 2018 20:38:58 GMT):
`CORE_CHAINCODE_STARTUPTIMEOUT` and `CORE_CHAINCODE_EXECUTETIMEOUT` might help.
sanchezl (Tue, 22 May 2018 20:39:16 GMT):
See `core.yaml` for details.
sanchezl (Tue, 22 May 2018 20:48:02 GMT):
I'm trying to help someone who is getting the following error:
`[chaincode] ExecuteChaincode -> ERRO 000 premature execution - chaincode (xxxxxx:vv) is being launched`
• When is this error expected? For example, if I restart a peer and invoke a chaincode that needs to have its container relauched, I don't get this error.
• At the *info* log level, is it possible to decipher when the various steps in a chaincode lifecycle have been executed? Currently, it seems difficult to determine that indeed an chaincode was invoked before it was launched.
hyperlearner (Wed, 23 May 2018 11:03:36 GMT):
@jrosmith I have changed the endorsement policy..But it is not getting reflected in the code.Could you please elaborate on your response?Exactly in which file i have to change the endorsement policy?
jrosmith (Wed, 23 May 2018 12:21:31 GMT):
@hyperlearner did you upgrade the chaincode and instantiate it with the new endorsement policy? or upgrade the channel with the new policy? its not as simple as changing a file, all members of the network need to know of and agree to the new policy. see here for more info: http://hyperledger-fabric.readthedocs.io/en/release-1.1/endorsement-policies.html
jrosmith (Wed, 23 May 2018 17:28:26 GMT):
hey all, im running into an issue upgrading a channel using fabric 1.1. and following the directions (here) [http://hyperledger-fabric.readthedocs.io/en/release-1.1/channel_update_tutorial.html]. my peer is v1.1.0 with go 1.9.2 running on a centOS machine.
i'm fine following the directions all the way until it comes to signing and submitting the update. when i go to sign i get (these)[https://hastebin.com/emarehewoy.pas] logs. i'm not using intermediate certs so i think the warning statement is fine? but i also don't see any "successfully signed" or "failed to sign" log, just "Exiting.....". does this mean i successfully signed the transaction or should i be expecting some other log output?
jrosmith (Wed, 23 May 2018 17:28:26 GMT):
hey all, im running into an issue upgrading a channel using fabric 1.1. and following the directions [here](http://hyperledger-fabric.readthedocs.io/en/release-1.1/channel_update_tutorial.html). my peer is v1.1.0 with go 1.9.2 running on a centOS machine.
i'm fine following the directions all the way until it comes to signing and submitting the update. when i go to sign i get (these)[https://hastebin.com/emarehewoy.pas] logs. i'm not using intermediate certs so i think the warning statement is fine? but i also don't see any "successfully signed" or "failed to sign" log, just "Exiting.....". does this mean i successfully signed the transaction or should i be expecting some other log output?
jrosmith (Wed, 23 May 2018 17:28:26 GMT):
hey all, im running into an issue upgrading a channel using fabric 1.1. and following the directions [here](http://hyperledger-fabric.readthedocs.io/en/release-1.1/channel_update_tutorial.html). my peer is v1.1.0 with go 1.9.2 running on a centOS machine.
i'm fine following the directions all the way until it comes to signing and submitting the update. when i go to sign i get [these](https://hastebin.com/emarehewoy.pas) logs. i'm not using intermediate certs so i think the warning statement is fine? but i also don't see any "successfully signed" or "failed to sign" log, just "Exiting.....". does this mean i successfully signed the transaction or should i be expecting some other log output?
AnkitSingh5 (Thu, 24 May 2018 06:23:07 GMT):
Has joined the channel.
AnkitSingh5 (Thu, 24 May 2018 06:23:13 GMT):
Hi,
I have installed the chaincode and it got successful but facing this error when trying to instantiate the chaincode -
`ERRO 692 [[e9585782 PUT_STATE ERROR]]No ledger context for %!!(MISSING)s(MISSING). Sending %!!(MISSING)s(MISSING)
ERRO 6a2 [bloqchannel][e9585782] failed to invoke chaincode name:"lscc" , error: timeout expired while executing transaction`
I am using Hyperledger Fabric v1.1.0 preview
I have 2 orgs and 3 peers per org.
AnkitSingh5 (Thu, 24 May 2018 06:23:13 GMT):
Hi,
I have installed the chaincode and it got successful but facing this error when trying to instantiate the chaincode -
`ERRO 692 [[e9585782 PUT_STATE ERROR]]No ledger context for %!!(MISSING)s(MISSING). Sending %!!(MISSING)s(MISSING)`
`ERRO 6a2 [bloqchannel][e9585782] failed to invoke chaincode name:"lscc" , error: timeout expired while executing transaction`
I am using Hyperledger Fabric v1.1.0 preview
I have 2 orgs and 3 peers per org.
acuestareig (Thu, 24 May 2018 15:27:42 GMT):
Has joined the channel.
pankajcheema (Thu, 24 May 2018 16:01:04 GMT):
Any one faced this issue?
pankajcheema (Thu, 24 May 2018 16:01:07 GMT):
```Error: got unexpected status: SERVICE_UNAVAILABLE -- will not enqueue, consenter for this channel hasn't started yet
```
pankajcheema (Thu, 24 May 2018 16:01:20 GMT):
I am trying to execute this command on physical system
pankajcheema (Thu, 24 May 2018 16:01:27 GMT):
```CORE_PEER_LOCALMSPID=debutMSP \
CORE_PEER_TLS_ROOTCERT_FILE=/home/php/debut_network/crypto-config/peerOrganizations/debutinfotech.com/peers/peer1.debutinfotech.com/tls/ca.crt \
CORE_PEER_MSPCONFIGPATH=/home/php/debut_network/crypto-config/peerOrganizations/debutinfotech.com/users/Admin@debutinfotech.com/msp \
CORE_PEER_ADDRESS=peer1.debutinfotech.com:7051 \
peer channel create -o firstorderer.debutinfotech.com:7050 -c debut_asset_channel -f ./channel-artifacts/channel.tx```
jrosmith (Thu, 24 May 2018 20:22:38 GMT):
as a follow up i was able to cat the actually binary file and see that the cert had been concated, leading me to believe the signing process was successful
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=jgfHQ3e2q3Z5SQWxg)
jrosmith (Thu, 24 May 2018 20:22:38 GMT):
as a follow up i was able to cat the actual protobu and see that the cert had been concated, leading me to believe the signing process was successful
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=jgfHQ3e2q3Z5SQWxg)
jrosmith (Thu, 24 May 2018 20:22:38 GMT):
as a follow up i was able to cat the actual protobuf and see that the cert had been concated, leading me to believe the signing process was successful
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=jgfHQ3e2q3Z5SQWxg)
jtclark (Thu, 24 May 2018 20:52:34 GMT):
Has left the channel.
acostarodrigo (Thu, 24 May 2018 21:50:12 GMT):
Has joined the channel.
acostarodrigo (Thu, 24 May 2018 21:58:06 GMT):
hi everyone, hope someone is able to provide a solution for this:
I'm trying to instantiate chaincode with endorsement policy to force peers to endorse chaincode calls.
I'm instantiating it like this:
docker exec -e "CORE_PEER_LOCALMSPID=Org1MSP" -e "CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp" cli peer chaincode instantiate -o orderer.example.com:7050 -C mychannel -n tokenWallet -l node -v 1.0 -c '{"Args":[""]}' -P "OR ('Org1MSP.member','Org2MSP.member')"
However, peers are not endorsing it and chaincode invocations are failing because endorsement policies are not being applied.
I see I need to enable OUs, and I put the flag EnableNodeOUs: true in my crypto-config.yaml file, but still no use.
Any tip someone?
acostarodrigo (Thu, 24 May 2018 21:58:06 GMT):
hi everyone, hope someone is able to provide a solution for this:
I'm trying to instantiate chaincode with endorsement policy to force peers to endorse chaincode calls.
I'm instantiating it like this:
docker exec -e "CORE_PEER_LOCALMSPID=Org1MSP" -e "CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp" cli peer chaincode instantiate -o orderer.example.com:7050 -C mychannel -n tokenWallet -l node -v 1.0 -c '{"Args":[""]}' -P "OR ('Org1MSP.peer','Org2MSP.peer')"
However, peers are not endorsing it and chaincode invocations are failing because endorsement policies are not being applied.
I see I need to enable OUs, and I put the flag EnableNodeOUs: true in my crypto-config.yaml file, but still no use.
Any tip someone?
muralisr (Fri, 25 May 2018 12:39:38 GMT):
@acostarodrigo we'd need more context ...errors from logs for starters
acostarodrigo (Sat, 26 May 2018 02:43:02 GMT):
I just get
2018-05-26 02:37:41.884 UTC [committer/txvalidator] validateTx -> ERRO 043 VSCCValidateTx for transaction txId = db1097652c60c3efc25ceac94f3b2aadd8cbe5e82d91a0f0f402dbff00deffe1 returned error: VSCC error: endorsement policy failure, err: signature set did not satisfy policy
acostarodrigo (Sat, 26 May 2018 02:43:23 GMT):
whenever I instantiate my chaincode with -P "OR ('Org1MSP.peer','Org2MSP.peer')"
acostarodrigo (Sat, 26 May 2018 02:43:41 GMT):
not sure which configuration I should use to have peers as endorsers
acostarodrigo (Sat, 26 May 2018 02:43:48 GMT):
thanks @muralisr
pankajcheema (Mon, 28 May 2018 11:03:55 GMT):
Can anyone tell me difference between Validating peer and Non validatiing peer ?
asaningmaxchain123 (Tue, 29 May 2018 00:10:26 GMT):
@jyellick @mastersingh24 when i use the master branch to build,and run the e2e_cli ,then i got the following error
asaningmaxchain123 (Tue, 29 May 2018 00:10:26 GMT):
@jyellick @mastersingh24 @muralisr when i use the master branch to build,and run the e2e_cli ,then i got the following error
asaningmaxchain123 (Tue, 29 May 2018 00:10:26 GMT):
@jyellick @mastersingh24 @muralisr @AdnanC when i use the master branch to build,and run the e2e_cli ,then i got the following error
asaningmaxchain123 (Tue, 29 May 2018 00:10:26 GMT):
@jyellick @mastersingh24 @muralisr @AdnanC @dave.enyeart when i use the master branch to build,and run the e2e_cli ,then i got the following error
asaningmaxchain123 (Tue, 29 May 2018 00:11:09 GMT):
https://pastebin.com/AeUTae02
yacovm (Tue, 29 May 2018 07:44:01 GMT):
looks like a golang version mismatch
asaningmaxchain123 (Tue, 29 May 2018 08:36:18 GMT):
@yacovm it doesn't matter about the version. i check it
asaningmaxchain123 (Tue, 29 May 2018 08:36:18 GMT):
@yacovm it doesn't matter about the version. i checked it
asaningmaxchain123 (Tue, 29 May 2018 08:38:38 GMT):
it seems the `ccenv` issue
pankajcheema (Tue, 29 May 2018 09:07:25 GMT):
@yacovm How can we define that only a particular peer should endorse the transaction.like if i have 4 peers
1.`peer0.debutinfotech.com`
2.`peer1.debutinfotech.com`
3.`peer2.debutinfotech.com`
4.`peer3.debutinfotech.com`
Now i want that only `peer0.debutinfotech.com` should endorse the transaction.
Thanks in advance
pankajcheema (Tue, 29 May 2018 09:07:25 GMT):
@yacovm How can we define that only a particular peer should endorse the transaction.like if i have 4 peers
1.`peer0.debutinfotech.com`
2.`peer0.debutinfotech.com`
3.`peer0.debutinfotech.com`
4.`peer0.debutinfotech.com`
Now i want that only `peer0.debutinfotech.com` should endorse the transaction.
Thanks in advance
pankajcheema (Tue, 29 May 2018 09:07:25 GMT):
@yacovm How can we define that only a particular peer should endorse the transaction.like if i have 4 peers
```1.peer0.debutinfotech.com
2.peer1.debutinfotech.com
3.peer2.debutinfotech.com
4.peer3.debutinfotech.com ```
Now i want that only `peer0.debutinfotech.com` should endorse the transaction.
Thanks in advance
massiveashok2014 (Tue, 29 May 2018 12:43:50 GMT):
How do i configure any two of my peer as endorsement peers. which yaml file i do this configuration?
pankajcheema (Wed, 30 May 2018 07:55:20 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=xD7EPhqwDxCsP6j69) nayone please
pankajcheema (Wed, 30 May 2018 07:55:20 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=xD7EPhqwDxCsP6j69) anyone please
pankajcheema (Wed, 30 May 2018 07:55:51 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=2Mmp9Ppcuap8pXMPA)
jrosmith (Wed, 30 May 2018 08:06:15 GMT):
@pankajcheema if you only want to get an endorsement from a certain peer, only send the transaction proposal to that peer.
pankajcheema (Wed, 30 May 2018 09:03:04 GMT):
@jrosmith not clear
jrosmith (Wed, 30 May 2018 09:06:27 GMT):
@pankajcheema in order to get a transaction endorsement, you have to send a transaction proposal to a peer. assuming youre using an sdk you can choose which peers you send endorsement proposals to.
jrosmith (Wed, 30 May 2018 09:06:45 GMT):
unless youre asking how to specify an endorsement policy in which on a specific peer should be endorsing transactions
pankajcheema (Wed, 30 May 2018 11:25:11 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=dhZKAcmXhyxpmSBdN) yes am asking about this not from sdk
pankajcheema (Wed, 30 May 2018 11:25:19 GMT):
@jrosmith
rogerwilcos (Wed, 30 May 2018 23:12:27 GMT):
Has joined the channel.
jrosmith (Thu, 31 May 2018 03:31:53 GMT):
@pankajcheema to my knowledge, and someone else please correct me if i'm wrong, endorsement policies are at the organization level, not peer level. if i'm reading [this](http://hyperledger-fabric.readthedocs.io/en/release-1.1/endorsement-policies.html#endorsement-policy-syntax-in-the-cli) properly it seems you can only specify that any peer of a specific organization should sign off on a transaction, not a specific peer within a specific organization. you may need to rework your approach
rbole (Thu, 31 May 2018 05:40:07 GMT):
Has joined the channel.
Ryan2 (Thu, 31 May 2018 07:17:34 GMT):
Hi, regarding `validatorPoolSize`,
https://github.com/hyperledger/fabric/blob/release-1.1/sampleconfig/core.yaml#L382.
I have concerns, please help:
1. by default this value equal to number of cores of server, on which file (I mean on the fabric code files) I can convince myself about this one?
2. to take advantage of parallel validation, it should run peer on multiple core server?
Ryan2 (Thu, 31 May 2018 07:17:34 GMT):
Hi, regarding `validatorPoolSize`,
https://github.com/hyperledger/fabric/blob/release-1.1/sampleconfig/core.yaml#L382.
I have concerns, please help:
1. by default this value equal to number of cores of server, on which file (I mean on the fabric code files) I can convince myself about this one?
pankajcheema (Thu, 31 May 2018 08:49:44 GMT):
@jrosmith Ok I got.
pankajcheema (Thu, 31 May 2018 09:47:05 GMT):
Can anybody provide me idea about event hub.We got some time error that event hub has been shutdown.
pankajcheema (Thu, 31 May 2018 09:47:21 GMT):
in our production environment.
yacovm (Thu, 31 May 2018 09:47:30 GMT):
use the deliver service on the peer instead
yacovm (Thu, 31 May 2018 09:47:31 GMT):
it's better
jrosmith (Thu, 31 May 2018 10:18:17 GMT):
@yacovm for the deliver service service says it sends a stream of blocks to the client after commitment. does commit mean being appended to the ledger file or after appending to the ledger file _and_ insertion into the state db
yacovm (Thu, 31 May 2018 10:18:36 GMT):
you can subscribe to events via the deliver API on the peer...
yacovm (Thu, 31 May 2018 10:18:46 GMT):
it's in v1.1 code base
yacovm (Thu, 31 May 2018 10:19:14 GMT):
> does commit mean being appended to the ledger file or after appending to the ledger file _and_ insertion into the state db
after both
AshishMishra 1 (Thu, 31 May 2018 12:57:31 GMT):
Hi team, is the prom or statsd metrics exported implemented? I did changes in the core.yam... but nothing seems to be exported.
asaningmaxchain123 (Fri, 01 Jun 2018 00:48:11 GMT):
@yacovm https://github.com/hyperledger/fabric/blob/8f79ea1aebdaee1c844d1b5f2c8f89dff18bcffc/core/aclmgmt/defaultaclprovider.go#L90 that is the peer resource,why it uses the based on `channel` policy?
asaningmaxchain123 (Fri, 01 Jun 2018 00:53:55 GMT):
@yacovm @jyellick can you provider example about the `ACL` by using the define in the application section in the config
asaningmaxchain123 (Fri, 01 Jun 2018 01:17:45 GMT):
@yacovm @jyellick
asaningmaxchain123 (Fri, 01 Jun 2018 01:17:46 GMT):
https://gerrit.hyperledger.org/r/#/c/22671/
asaningmaxchain123 (Fri, 01 Jun 2018 01:25:24 GMT):
@yacovm @jyellick can you tell how the jenkins to build the fabric project,i want to test in my local env
hamptonsmith (Fri, 01 Jun 2018 05:29:01 GMT):
Has joined the channel.
hamptonsmith (Fri, 01 Jun 2018 05:33:21 GMT):
Hey folks, having some issues getting my chaincode instantiated on a production installation. During instantiation of my chaincode "wagoncc", seeing a timeout of the "lscc" chaincode:
[endorser] simulateProposal -> ERRO 932 [global][e8c3cb15] failed to invoke chaincode name:"lscc" , error: timeout expired while executing transaction
Full log here: https://pastebin.com/UqTg2J7H
A docker container for the custom chaincode is created. Transaction logs here: https://pastebin.com/9sQnJn3Z
I'm instantiating from the command line using this incantation:
$ peer chaincode instantiate -C global -n wagoncc -v "ghwc.dae6ea59f82662452ba5a79898f8b6c725f6f43b" -c '{"Args":[]}' -P "AND ('BandwagonClientMSP.member')" -o $ORDERER:7050
My current assumption is that I don't have some networking aspect correctly configured and the peer isn't getting the message that the chaincode completed successfully, but I'm uncertain how best to debug such an issue.
AshishMishra 1 (Fri, 01 Jun 2018 06:42:51 GMT):
Hi all, is the prom or statsd metrics exported implemented? I did changes in the core.yaml.. but nothing seems to be exported.
anjalinaik (Fri, 01 Jun 2018 09:08:39 GMT):
Has joined the channel.
anjalinaik (Fri, 01 Jun 2018 09:30:58 GMT):
Hi All, on performing channel update i am getting below error.Can anybody please tell me what is wrong .
Error: Invalid channel create transaction : mismatched channel ID ${2} != mychannel
hamptonsmith (Fri, 01 Jun 2018 16:18:56 GMT):
Have CORE_CHAINCODE_EXECUTETIMEOUT set to 60s. During chaincode instantiation, log gets to this:
```
2018-06-01 16:13:15.280 UTC [chaincode] handleMessage -> DEBU 614 [15c0d343d4680220d39e2a6b5ee0920d10ed3ca44627c79ff2b4fd04f138b8d8]HandleMessage- COMPLETED. Notify
2018-06-01 16:13:15.280 UTC [chaincode] notify -> DEBU 615 notifier Txid:15c0d343d4680220d39e2a6b5ee0920d10ed3ca44627c79ff2b4fd04f138b8d8, channelID: does not exist
```
Then it hangs for the remaining 60 seconds before giving me:
`2018-06-01 16:14:15.279 UTC [endorser] simulateProposal -> ERRO 618 [global][15c0d343] failed to invoke chaincode name:"lscc" , error: timeout expired while executing transaction`
Any thoughts on how the notification that chaincode has completed is getting dropped or how I can get a little more debug info?
AshishMishra 1 (Sat, 02 Jun 2018 04:58:55 GMT):
Can anyone please confirm on this?
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=CfZHM7oqBpHWXvS84)
albert.lacambra (Mon, 04 Jun 2018 05:59:37 GMT):
Has joined the channel.
albert.lacambra (Mon, 04 Jun 2018 06:00:23 GMT):
hi all
albert.lacambra (Mon, 04 Jun 2018 06:02:02 GMT):
Question about valid endorsements: If 2 responses differ in some chars/strings on the payload but read write sets are the same, would it be accepted with an AND policy?
albert.lacambra (Mon, 04 Jun 2018 06:02:28 GMT):
so what is being fetched and saved is exactly the same, but not the response to the user
titoe218 (Mon, 04 Jun 2018 07:15:21 GMT):
Has joined the channel.
asaningmaxchain123 (Mon, 04 Jun 2018 08:53:41 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=hFRupZgPwBefWp8dJ) @hamptonsmith i meet the same problem only see the log to judge where the source of bug
albert.lacambra (Mon, 04 Jun 2018 09:01:53 GMT):
i have had that when palying with versions of java sdk and java chaincode
albert.lacambra (Mon, 04 Jun 2018 09:02:09 GMT):
depending on the versions of sdk, fabric, and shim basically
sanchezl (Mon, 04 Jun 2018 17:12:55 GMT):
pkcs
IgorSim (Tue, 05 Jun 2018 11:32:00 GMT):
Has joined the channel.
anjalinaik (Tue, 05 Jun 2018 11:44:44 GMT):
Hi All .Can somebody please explain what below error is about.*Error from query = access denied: channel [mychannel] creator org [org1]*. I have a vague idea that it is caused due to revoking of certificates, But Along the process of setting up the network i haven't manually revoked any certificates. May i please know why this error is occurring? and also the error is not consistent.
anjalinaik (Wed, 06 Jun 2018 09:49:02 GMT):
Hi All. Can Somebody please help me with below error? `Error: got unexpected status: BAD_REQUEST -- Attempted to include a member which is not in the consortium`
rahulhegde (Wed, 06 Jun 2018 11:21:15 GMT):
Hello @jyellick
rahulhegde (Wed, 06 Jun 2018 11:39:50 GMT):
Hello @jyellick
In our setup fabric v1.0.x - we have 1 PEER per Organization and we are not using any Gossip. But I see some Gossip Logs in the Peer. We don't have anchor Peer defined. Can you review why is this happening.
rahulhegde (Wed, 06 Jun 2018 11:39:50 GMT):
Hello @jyellick
In our setup fabric v1.0.x - we have 1 PEER per Organization and we are not using any Gossip. But I see some Gossip Logs in the Peer. We don't have anchor Peer defined. Can you review why is this happening.
There is log getting printed from `gossip/discovery` and `gossip/gossip` module.
jyellick (Wed, 06 Jun 2018 13:25:23 GMT):
@rahulhegde Sure, even without anchor peers defined, gossip may be configured to work by setting the `peer.gossip.bootstrap`variable to point to an initial set of peers in your org. So, you may simply be seeing the log messages to do with this. The gossip service is in charge of block dissemination, deciding whether to retrieve blocks from ordering or peer to peer. In a 'disabled' state, gossip is actually simply not establishing any links peer-to-peer, and each peer is considered a 'leader', which means it will connect directly to the orderer.
rahulhegde (Wed, 06 Jun 2018 15:42:43 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=ESLWLZZ73QFgShxob) @jyellick
Thanks for the response. We haven't set any gossip related override and peer uses the default value present in the peer application yaml. So for `gossip.bootstrap`, the value set is `127.0.0.1` which means the peer gossip logs are with orderer node to retrieve block.
asaningmaxchain123 (Wed, 06 Jun 2018 16:26:25 GMT):
@jyellick @kostas if the a peer in the Org1,can it communicate with another peer in the Org2?
asaningmaxchain123 (Wed, 06 Jun 2018 16:26:25 GMT):
@jyellick @kostas if the a peer in the Org1,can it communicate with another peer in the Org2? it doesn't the external point
kostas (Wed, 06 Jun 2018 16:26:26 GMT):
Has joined the channel.
jyellick (Wed, 06 Jun 2018 16:29:49 GMT):
@asaningmaxchain123 No
asaningmaxchain123 (Wed, 06 Jun 2018 16:30:41 GMT):
@jyellick so in one Org,it must contain a leader to communicate with the OSN
asaningmaxchain123 (Wed, 06 Jun 2018 16:30:41 GMT):
@jyellick so in one Org,it must contain a leader to communicate with the OSN?
jyellick (Wed, 06 Jun 2018 16:30:57 GMT):
Yes
asaningmaxchain123 (Wed, 06 Jun 2018 16:33:59 GMT):
so how many peers in one org is good?
asaningmaxchain123 (Wed, 06 Jun 2018 16:33:59 GMT):
so how many peers in one org is good?
jyellick (Wed, 06 Jun 2018 16:36:41 GMT):
In general, f+1
asaningmaxchain123 (Wed, 06 Jun 2018 16:36:56 GMT):
what's the f
jyellick (Wed, 06 Jun 2018 16:37:05 GMT):
How many failures you wish to tolerate
asaningmaxchain123 (Wed, 06 Jun 2018 16:37:39 GMT):
so i just keep one alive is ok?
jyellick (Wed, 06 Jun 2018 16:39:15 GMT):
It depends on your application, and what you are attempting to protect against. If you have a channel with a single chaincode, then two peers, joined to that channel, each of which is running the chaincode, would likely be adequate to ensure that you do not experience a service outage. Of course if the chaincode request volume is sufficiently high, you may need additional peers.
asaningmaxchain123 (Wed, 06 Jun 2018 16:42:22 GMT):
what's the request volume
asaningmaxchain123 (Wed, 06 Jun 2018 16:42:35 GMT):
can you give me more detail
vdods (Thu, 07 Jun 2018 00:29:19 GMT):
This may be somewhat of an old question -- I'm currently upgrading to Fabric 1.1 and have found that probably what used to be the "peer events port" 7053 no longer exists. Is this correct? Is it just the peer listen address (default 7051) now?
vdods (Thu, 07 Jun 2018 00:29:19 GMT):
This may be somewhat of an old question -- I'm currently upgrading to Fabric 1.1 (from 1.0.5) and have found that probably what used to be the "peer events port" 7053 no longer exists. Is this correct? Is it just the peer listen address (default 7051) now?
dimaxgl (Thu, 07 Jun 2018 07:50:13 GMT):
Has joined the channel.
dimaxgl (Thu, 07 Jun 2018 07:52:34 GMT):
Hi all! I have a little question - we must to set endorsement policy of cc in production mode, but we don't need to set in dev mode, why? Official tutorial of peer dev mode says policy is optional, isn't it?
TakahiroFujita (Thu, 07 Jun 2018 10:57:46 GMT):
Has joined the channel.
kostas (Thu, 07 Jun 2018 12:32:20 GMT):
Has left the channel.
abraham (Fri, 08 Jun 2018 05:38:27 GMT):
Has joined the channel.
pankajcheema (Fri, 08 Jun 2018 09:11:06 GMT):
Fabric peer taking time to execute query
pankajcheema (Fri, 08 Jun 2018 09:11:20 GMT):
while other peer immidiatly provide the response
pankajcheema (Fri, 08 Jun 2018 09:11:28 GMT):
I have 2 peers up and running
pankajcheema (Fri, 08 Jun 2018 09:11:42 GMT):
`peer0` takes near about 5 seconds to execute a query
pankajcheema (Fri, 08 Jun 2018 09:12:00 GMT):
where as `peer1` takes only 30 ms to execute same query
pankajcheema (Fri, 08 Jun 2018 09:12:08 GMT):
Anyone knows the reason?
pankajcheema (Fri, 08 Jun 2018 09:13:32 GMT):
@Bingguang-Xiang
Bingguang-Xiang (Fri, 08 Jun 2018 09:13:33 GMT):
Has joined the channel.
pankajcheema (Fri, 08 Jun 2018 09:13:36 GMT):
@jyellick
pankajcheema (Fri, 08 Jun 2018 09:13:38 GMT):
@dimaxgl
pankajcheema (Fri, 08 Jun 2018 09:13:54 GMT):
@andkononykhin
andkononykhin (Fri, 08 Jun 2018 09:13:55 GMT):
Has joined the channel.
pankajcheema (Fri, 08 Jun 2018 09:14:07 GMT):
@yacovm
yacovm (Fri, 08 Jun 2018 09:35:57 GMT):
sorry, ran out of psychic power / mana. can you perhaps look at the logs and see what is the difference? what is taking longer in the slower peer?
dimaxgl (Fri, 08 Jun 2018 10:10:00 GMT):
@pankajcheema show logs to us
pankajcheema (Fri, 08 Jun 2018 10:10:22 GMT):
@dimaxgl logs for what?
pankajcheema (Fri, 08 Jun 2018 10:10:31 GMT):
Are you talking about peer logs?
dimaxgl (Fri, 08 Jun 2018 10:10:34 GMT):
for peer0
dimaxgl (Fri, 08 Jun 2018 10:10:36 GMT):
yes
pankajcheema (Fri, 08 Jun 2018 10:10:42 GMT):
please wait
dimaxgl (Fri, 08 Jun 2018 10:10:51 GMT):
i want to know what is he doing for 5 seconds
pankajcheema (Fri, 08 Jun 2018 10:12:14 GMT):
Logs are too long
pankajcheema (Fri, 08 Jun 2018 10:12:23 GMT):
Please find the logs in pastebin
pankajcheema (Fri, 08 Jun 2018 10:12:23 GMT):
https://pastebin.com/wNG5nCCf
pankajcheema (Fri, 08 Jun 2018 10:15:42 GMT):
@dimaxgl Sorry the logs i send you
pankajcheema (Fri, 08 Jun 2018 10:15:53 GMT):
gives me result in 174 ms
pankajcheema (Fri, 08 Jun 2018 10:16:24 GMT):
And now am unable to replicate that time duration(% secs near about).
pankajcheema (Fri, 08 Jun 2018 10:16:24 GMT):
And now am unable to replicate that time duration(5 secs near about).
pankajcheema (Fri, 08 Jun 2018 10:17:32 GMT):
Does cpu usage and memory on the system matters here.
pankajcheema (Fri, 08 Jun 2018 10:17:32 GMT):
Does cpu usage and memory on the system matters here ?
pankajcheema (Fri, 08 Jun 2018 10:18:50 GMT):
We are using peer0 for other prosesses also like `Android Studio` ,`PHP`,`Apche server` i.e.
pankajcheema (Fri, 08 Jun 2018 10:18:50 GMT):
We are using peer0 for other processes also like `Android Studio` ,`PHP`,`Apche server` i.e.
pankajcheema (Fri, 08 Jun 2018 10:18:50 GMT):
We are using peer0 for other processes also like `Android Studio` ,`PHP`,`Apche server` i.e.
pankajcheema (Fri, 08 Jun 2018 10:18:50 GMT):
We are using peer0 for other processes also like `Android Studio ,PHP, Apche server` i.e.
pankajcheema (Fri, 08 Jun 2018 10:18:50 GMT):
We are using peer0 for other processes also like `Android Studio ,PHP, Apache server` i.e.
dimaxgl (Fri, 08 Jun 2018 11:20:18 GMT):
@pankajcheema maybe chaicode in `peer0` wasn't built so at first peer built chaincode and then launched?
pankajcheema (Fri, 08 Jun 2018 11:20:49 GMT):
@dimaxgl
pankajcheema (Fri, 08 Jun 2018 11:20:49 GMT):
@dimaxgl chaincode was already built
pankajcheema (Fri, 08 Jun 2018 11:21:09 GMT):
Every time I was getting response in 5 seconds
dimaxgl (Fri, 08 Jun 2018 11:22:04 GMT):
not every time, now you can't replicate you say :woo:
pankajcheema (Fri, 08 Jun 2018 11:23:42 GMT):
@dimaxgl yes I can not replicate it now. Don't know why. I think fabric is not stable enough
pankajcheema (Fri, 08 Jun 2018 11:23:59 GMT):
My whole project is built on fabric blockchain
dimaxgl (Fri, 08 Jun 2018 11:27:48 GMT):
when you build distributed network you should expect some differences between peer responses time , it's normal situation
niteshsolanki (Fri, 08 Jun 2018 12:14:54 GMT):
ulimit
pankajcheema (Mon, 11 Jun 2018 05:21:01 GMT):
Hi Expert,we are facing issue with slow response from peer for query result.We have a deep look on the logs and found that couchdb is taking 5 sec to handover query result to peer.
Any idea whats going here.
Thanka in Advance
pankajcheema (Mon, 11 Jun 2018 05:21:01 GMT):
Hi Expert,we are facing issue with slow response from peer for query result.We have a deep look on the logs and found that couchdb is taking 5 sec to handover query result to peer.
Any idea whats going here.
Thanks in Advance .
pankajcheema (Mon, 11 Jun 2018 05:21:01 GMT):
Hi Expert,we are facing issue with slow response from peer for query result.We have a deep look on the logs and found that couchdb is taking 5 sec to handover query result to peer.
Any idea what's going here.
Thanks in Advance .
pankajcheema (Mon, 11 Jun 2018 05:21:01 GMT):
Hi Expert,we are facing issue with slow response from peer for query result.We have a deep look on the logs and found that couchdb is taking 5 sec to handover query result to peer.
Any idea what's going here logs >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>https://pastebin.com/mWZuNbHM.
Thanks in Advance .
pankajcheema (Mon, 11 Jun 2018 05:21:01 GMT):
Hi Expert,we are facing issue with slow response from peer for query result.We have a deep look on the logs and found that couchdb is taking 5 sec to handover query result to peer.
Any idea what's happening logs on pastebin >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>https://pastebin.com/mWZuNbHM.
Thanks in Advance .
pankajcheema (Mon, 11 Jun 2018 05:21:01 GMT):
Hi Expert,we are facing issue with slow response from peer for query result.We have a deep look on the logs and found that couchdb is taking 5 sec to handover query result to peer.
Any idea what's happening logs on pastebin >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>https://pastebin.com/mWZuNbHM.
Thanks in Advance . @jyellick @dimaxgl
pankajcheema (Mon, 11 Jun 2018 07:27:01 GMT):
@dimaxgl
pankajcheema (Mon, 11 Jun 2018 07:27:23 GMT):
not it is taking 45 seconds
pankajcheema (Mon, 11 Jun 2018 07:27:38 GMT):
:expressionless:
pankajcheema (Tue, 12 Jun 2018 04:25:15 GMT):
Hi Experts any suggestion for me [ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=N3bhvmfjKTdEwCQur)
Ryan2 (Tue, 12 Jun 2018 04:41:36 GMT):
hi,
I faced this error on the peer, peer cannot be started again (v1.1.0 fabric)
`panic: Error during commit to txmgr:Couch DB Error:illegal_docid, Status Code:400, Reason:Only reserved document ids may start with underscore.`
how to overcome in this situation
Ryan2 (Tue, 12 Jun 2018 04:41:36 GMT):
hi,
I faced this error on the peer, peer cannot be started again (v1.1.0 fabric)
`panic: Error during commit to txmgr:Couch DB Error:illegal_docid, Status Code:400, Reason:Only reserved document ids may start with underscore.`
how to overcome in this situation.
It worked normal until I did some invoking chaincode, then It stopped.
peer log: https://hastebin.com/axeyidogec.go
pankajcheema (Tue, 12 Jun 2018 04:49:50 GMT):
@Ryan2 Are you creating any feild in chaincode or go with _ ?
pankajcheema (Tue, 12 Jun 2018 04:49:50 GMT):
@Ryan2 Are you creating any field in chaincode or go with _ ?
pankajcheema (Tue, 12 Jun 2018 04:49:50 GMT):
@Ryan2 Are you creating any field in chaincode or couchdb with _ ?
Ryan2 (Tue, 12 Jun 2018 04:52:17 GMT):
no, I have not, it was created automatically by code base 1.1.0
pankajcheema (Tue, 12 Jun 2018 04:53:32 GMT):
@Ryan2 Something is there only `_id` and `_rev` are the feilds which can be created with `_ `in couchdb
pankajcheema (Tue, 12 Jun 2018 04:53:32 GMT):
@Ryan2 Something is there, only `_id` and `_rev` are the feilds which can be created with `_ `in couchdb
pankajcheema (Tue, 12 Jun 2018 04:53:32 GMT):
@Ryan2 Something is there, only `_id` and `_rev` are the fields which can be created with `_ `in couchdb
pankajcheema (Tue, 12 Jun 2018 04:54:48 GMT):
and your code is trying to create a field with _
pankajcheema (Tue, 12 Jun 2018 04:55:10 GMT):
Please have a look again.
sandman (Tue, 12 Jun 2018 12:24:52 GMT):
Has joined the channel.
sandman (Tue, 12 Jun 2018 12:28:48 GMT):
Hello, i am trying to join peer to a existing setup. setup containers solo orderer, and a peer belonging to org1, peer and orderer are on different nodes in same network. I am unable to start 2nd peer. Dockerfile for 2nd peer is:
```
sandman (Tue, 12 Jun 2018 12:28:48 GMT):
Hello, i am trying to join peer to a existing setup. setup containers solo orderer, and a peer belonging to org1, peer and orderer are on different nodes in same network. I am unable to start 2nd peer. Dockerfile for 2nd peer is:
FROM hyperledger/fabric-peer:latest
ENV CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
ENV CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE=net_org1-net
ENV CORE_LOGGING_LEVEL=DEBUG
ENV CORE_PEER_TLS_ENABLED=true
ENV CORE_PEER_GOSSIP_USELEADERELECTION=true
ENV CORE_PEER_GOSSIP_ORGLEADER=false
ENV CORE_PEER_PROFILE_ENABLED=true
ENV CORE_PEER_TLS_CERT_FILE=/etc/hyperledger/fabric/tls/server.crt
ENV CORE_PEER_TLS_KEY_FILE=/etc/hyperledger/fabric/tls/server.key
ENV CORE_PEER_TLS_ROOTCERT_FILE=/etc/hyperledger/fabric/tls/ca.crt
ENV CORE_PEER_ID=peer1
ENV CORE_PEER_ADDRESS=peer1:7051
ENV CORE_PEER_GOSSIP_BOOTSTRAP=peer0:7051
ENV CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer1:7051
ENV CORE_PEER_LOCALMSPID=Org1MSP
WORKDIR /opt/gopath/src/github.com/hyperledger/fabric/peer
ENTRYPOINT peer node start
command for starting peer is:- ```
docker run -dit -p 0.0.0.0:7051:7051 -p 0.0.0.0:7053:7053 -v /var/run/:/host/var/run/ -v /home/docker/crypto-config/peerOrganizations/or
g1.example.com/peers/peer1.org1.example.com/msp:/etc/hyperledger/fabric/msp -v /home/docker/crypto-config/peerOrganizations/org1.example.com/peers/peer
1.org1.example.com/tls:/etc/hyperledger/fabric/tls --network net_org1-net --name peer1 bd7bfd7c92bf /bin/bash
```
sandman (Tue, 12 Jun 2018 12:33:44 GMT):
the section with error in logs for this peer are:- ```
2018-06-12 11:53:37.258 UTC [ledgermgmt] initialize -> INFO 01b ledger mgmt initialized
2018-06-12 11:53:37.259 UTC [peer] func1 -> INFO 01c Auto-detected peer address: 10.0.0.30:7051
2018-06-12 11:53:37.259 UTC [peer] func1 -> INFO 01d Returning peer0:7051
2018-06-12 11:53:37.259 UTC [peer] func1 -> INFO 01e Auto-detected peer address: 10.0.0.30:7051
2018-06-12 11:53:37.260 UTC [peer] func1 -> INFO 01f Returning peer0:7051
2018-06-12 11:53:37.262 UTC [nodeCmd] serve -> INFO 020 Starting peer with TLS enabled
2018-06-12 11:53:37.264 UTC [eventhub_producer] AddEventType -> DEBU 021 Registering BLOCK
2018-06-12 11:53:37.264 UTC [eventhub_producer] AddEventType -> DEBU 022 Registering CHAINCODE
2018-06-12 11:53:37.264 UTC [eventhub_producer] AddEventType -> DEBU 023 Registering REJECTION
2018-06-12 11:53:37.264 UTC [eventhub_producer] AddEventType -> DEBU 024 Registering REGISTER
2018-06-12 11:53:37.265 UTC [eventhub_producer] AddEventType -> DEBU 025 Registering FILTEREDBLOCK
2018-06-12 11:53:37.265 UTC [nodeCmd] computeChaincodeEndpoint -> INFO 026 Entering computeChaincodeEndpoint with peerHostname: peer0
2018-06-12 11:53:37.265 UTC [nodeCmd] computeChaincodeEndpoint -> INFO 027 Exit with ccEndpoint: peer0:7052
2018-06-12 11:53:37.266 UTC [nodeCmd] createChaincodeServer -> WARN 028 peer.chaincodeListenAddress is not set, using peer0:7052
2018-06-12 11:53:37.266 UTC [accessControl] newCertKeyPair -> DEBU 029 Classified peer0 as a hostname, adding it as a DNS SAN
2018-06-12 11:53:37.267 UTC [eventhub_producer] start -> INFO 02a Event processor started
2018-06-12 11:53:37.267 UTC [nodeCmd] createChaincodeServer -> ERRO 02b Error creating GRPC server: listen tcp 10.0.0.8:7052: bind: cannot assign requested address
2018-06-12 11:53:37.268 UTC [nodeCmd] serve -> CRIT 02c Failed to create chaincode server: listen tcp 10.0.0.8:7052: bind: cannot assign requested address
panic: Failed to create chaincode server: listen tcp 10.0.0.8:7052: bind: cannot assign requested address
goroutine 1 [running]:
github.com/hyperledger/fabric/vendor/github.com/op/go-logging.(*Logger).Panicf(0xc4201d70e0, 0xf0a90e, 0x25, 0xc4217a0ab0, 0x1, 0x1)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/op/go-logging/logger.go:194 +0x134
github.com/hyperledger/fabric/peer/node.serve(0x16c5708, 0x0, 0x0, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/peer/node/start.go:195 +0x8a9
github.com/hyperledger/fabric/peer/node.glob..func1(0x164ce80, 0x16c5708, 0x0, 0x0, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/peer/node/start.go:87 +0x3f
github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).execute(0x164ce80, 0x16c5708, 0x0, 0x0, 0x164ce80, 0x16c5708)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:599 +0x3e8
github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0x164d4e0, 0x11, 0xc4201bb0d0, 0x5)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:689 +0x2fe
github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).Execute(0x164d4e0, 0x1b, 0xc420014095)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:648 +0x2b
```
```
sandman (Tue, 12 Jun 2018 12:34:45 GMT):
section of focus:-```
CRIT 02c Failed to create chaincode server: listen tcp 10.0.0.8:7052: bind: cannot assign requested address
panic: Failed to create chaincode server: listen tcp 10.0.0.8:7052: bind: cannot assign requested address
```
sandman (Tue, 12 Jun 2018 12:38:15 GMT):
the section with error in logs for this peer are:- ```
2018-06-12 11:53:37.258 UTC [ledgermgmt] initialize -> INFO 01b ledger mgmt initialized
2018-06-12 11:53:37.259 UTC [peer] func1 -> INFO 01c Auto-detected peer address: 10.0.0.30:7051
2018-06-12 11:53:37.259 UTC [peer] func1 -> INFO 01d Returning peer0:7051
2018-06-12 11:53:37.259 UTC [peer] func1 -> INFO 01e Auto-detected peer address: 10.0.0.30:7051
2018-06-12 11:53:37.260 UTC [peer] func1 -> INFO 01f Returning peer0:7051
2018-06-12 11:53:37.262 UTC [nodeCmd] serve -> INFO 020 Starting peer with TLS enabled
2018-06-12 11:53:37.264 UTC [eventhub_producer] AddEventType -> DEBU 021 Registering BLOCK
2018-06-12 11:53:37.264 UTC [eventhub_producer] AddEventType -> DEBU 022 Registering CHAINCODE
2018-06-12 11:53:37.264 UTC [eventhub_producer] AddEventType -> DEBU 023 Registering REJECTION
2018-06-12 11:53:37.264 UTC [eventhub_producer] AddEventType -> DEBU 024 Registering REGISTER
2018-06-12 11:53:37.265 UTC [eventhub_producer] AddEventType -> DEBU 025 Registering FILTEREDBLOCK
2018-06-12 11:53:37.265 UTC [nodeCmd] computeChaincodeEndpoint -> INFO 026 Entering computeChaincodeEndpoint with peerHostname: peer0
2018-06-12 11:53:37.265 UTC [nodeCmd] computeChaincodeEndpoint -> INFO 027 Exit with ccEndpoint: peer0:7052
2018-06-12 11:53:37.266 UTC [nodeCmd] createChaincodeServer -> WARN 028 peer.chaincodeListenAddress is not set, using peer0:7052
2018-06-12 11:53:37.266 UTC [accessControl] newCertKeyPair -> DEBU 029 Classified peer0 as a hostname, adding it as a DNS SAN
2018-06-12 11:53:37.267 UTC [eventhub_producer] start -> INFO 02a Event processor started
2018-06-12 11:53:37.267 UTC [nodeCmd] createChaincodeServer -> ERRO 02b Error creating GRPC server: listen tcp 10.0.0.8:7052: bind: cannot assign requested address
2018-06-12 11:53:37.268 UTC [nodeCmd] serve -> CRIT 02c Failed to create chaincode server: listen tcp 10.0.0.8:7052: bind: cannot assign requested address
panic: Failed to create chaincode server: listen tcp 10.0.0.8:7052: bind: cannot assign requested address
goroutine 1 [running]:
github.com/hyperledger/fabric/vendor/github.com/op/go-logging.(*Logger).Panicf(0xc4201d70e0, 0xf0a90e, 0x25, 0xc4217a0ab0, 0x1, 0x1)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/op/go-logging/logger.go:194 +0x134
github.com/hyperledger/fabric/peer/node.serve(0x16c5708, 0x0, 0x0, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/peer/node/start.go:195 +0x8a9
github.com/hyperledger/fabric/peer/node.glob..func1(0x164ce80, 0x16c5708, 0x0, 0x0, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/peer/node/start.go:87 +0x3f
github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).execute(0x164ce80, 0x16c5708, 0x0, 0x0, 0x164ce80, 0x16c5708)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:599 +0x3e8
github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0x164d4e0, 0x11, 0xc4201bb0d0, 0x5)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:689 +0x2fe
github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).Execute(0x164d4e0, 0x1b, 0xc420014095)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:648 +0x2b
```
```
``````
section of focus:-```
CRIT 02c Failed to create chaincode server: listen tcp 10.0.0.8:7052: bind: cannot assign requested address
panic: Failed to create chaincode server: listen tcp 10.0.0.8:7052: bind: cannot assign requested address
```
```
yacovm (Tue, 12 Jun 2018 12:39:23 GMT):
@sandman try to set `CORE_PEER_CHAINCODELISTENADDRESS=0.0.0.0:7052`
sandman (Tue, 12 Jun 2018 13:34:46 GMT):
@yacovm thanks alot
zimabry (Tue, 12 Jun 2018 17:37:39 GMT):
Has joined the channel.
zimabry (Tue, 12 Jun 2018 17:38:11 GMT):
I am having issues joining my peers to the channel.. I have 4 separate servers(1 is orderer and 3 other peers). The three other peers have DNS created when they spin up.. BYFN script runs on the 3 peers, then a byfn runs on the orderer last.. The error I get on the orderer is: Error: Error getting endorser client channel: endorser client failed to connect to peer0.****.com:7051: failed to create new connection: context deadline exceeded
bh4rtp (Wed, 13 Jun 2018 01:21:55 GMT):
hi, does state-based endorsement function until now?
GowriR (Wed, 13 Jun 2018 03:18:13 GMT):
Has joined the channel.
GowriR (Wed, 13 Jun 2018 08:49:54 GMT):
hello, I am getting this error when i start my containers and network using the chaindev sample code
> DEBU 004 grpc: addrConn.resetTransport failed to create client transport: connection error: desc = "transport: Error while dialing dial tcp: lookup orderer on 127.0.0.11:53: no such host"; Reconnecting to {orderer:7050
GowriR (Wed, 13 Jun 2018 08:49:54 GMT):
hello, I am getting this error when i start my containers and network using the chaindev sample code
> DEBU 004 grpc: addrConn.resetTransport failed to create client transport: connection error: desc = "transport: Error while dialing dial tcp: lookup orderer on 127.0.0.11:53: no such host"; Reconnecting to {orderer:7050
GowriR (Wed, 13 Jun 2018 08:50:23 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=hmw2LZ2hmRM5xPE7G)
GowriR (Wed, 13 Jun 2018 09:11:55 GMT):
Hi all, cli | 2018-06-13 09:10:28.587 UTC [grpc] Printf -> DEBU 004 grpc: addrConn.resetTransport failed to create client transport: connection error: desc = "transport: Error while dialing dial tcp: lookup orderer on 127.0.0.11:53: no such host"; Reconnecting to {orderer:7050
GowriR (Wed, 13 Jun 2018 09:12:27 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=bKMc3c3rFCwhNDJT3) @zimabry my same error
GowriR (Wed, 13 Jun 2018 09:12:41 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=cKkpZdnABNNTjbi5r) Did it get solved?
GowriR (Wed, 13 Jun 2018 09:12:41 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=cKkpZdnABNNTjbi5r) Did it get solved?
sarapara (Wed, 13 Jun 2018 17:25:51 GMT):
Has joined the channel.
sandman (Fri, 15 Jun 2018 06:40:20 GMT):
@GowriR are you able to ping orderer from cli?
sandman (Fri, 15 Jun 2018 06:42:51 GMT):
Hi, If in a fully functional network the anchor peer for an organization goes down, then how will organization adapt to this event? considering there is just one anchor peer for that organization.
paulananth (Fri, 15 Jun 2018 15:52:30 GMT):
Has joined the channel.
rahulhegde (Tue, 19 Jun 2018 11:43:26 GMT):
Fabric v1.0.x
hello - we have set of keys created on the world-state-ledger and need to migrate to a different pattern/structure. The channel has 2 out 3 endorsement policy and the chaincode can be upgraded only by a specific organization admin user (which is a specific organization from the 2 out of 3 endorsement policy).
what is the best way to do this key migration? My understanding - we cannot use the init method in this case as upgrade resulting in RWSet will not meet the Endorsement Policy. The only way is to write a client to perform this key migration process. Any thoughts?
rahulhegde (Tue, 19 Jun 2018 11:43:26 GMT):
Hello. We have set of keys created on the world-state-ledger and need to migrate to a different pattern/structure (this is on Fabric v1.0.x). The channel has 2 out 3 endorsement policy and the chaincode can be upgraded only by a specific organization admin user (which is a specific organization from the 2 out of 3 endorsement policy).
what is the best way to do this key migration? My understanding - we cannot use the init method in this case as upgrade resulting in RWSet will not meet the Endorsement Policy. The only way is to write a client to perform this key migration process. Any Suggestion.
divyank (Tue, 19 Jun 2018 17:49:06 GMT):
Do chaincode invocations happen in parallel?
divyank (Tue, 19 Jun 2018 17:49:06 GMT):
Do chaincode invocations (within a peer) happen in parallel?
yacovm (Tue, 19 Jun 2018 21:37:34 GMT):
@divyank - for the same chaincode - no since there is only a single goroutine that handles a transaction
yacovm (Tue, 19 Jun 2018 21:37:34 GMT):
@divyank - for the same chaincode - no since there is only a single goroutine that handles a transaction inside the shim container
yacovm (Tue, 19 Jun 2018 21:37:40 GMT):
for multiple chaincodes - yes
minollo (Tue, 19 Jun 2018 23:58:26 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=RJAX6BFxGrwBQrd5t) @yacovm Are you positive about that @yacovm ? I remember we had this conversation a few months ago (https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=utGqv7wbkrC2gd3ax) and I finally corrected my tests and realized that invocation of the same chaincode on the same peer is not serialized; @muralisr mentioned the same.
Ryan2 (Wed, 20 Jun 2018 01:52:36 GMT):
I faced this error while continuously invoking chaincode (load test)
`[chaincode] ExecuteChaincode -> ERRO 035 error chaincode is already launching: MYCHANNEL_CC_001:t1`
https://pastebin.com/QPnNcrdF
What is contribute to this issue?
pvrbharg (Wed, 20 Jun 2018 02:06:46 GMT):
Hello, I am trying to setup a local Fabric V1.1.0 network instance running on K8S network with a tutorial example deployed - in addition to composer. Details of this work at the following URL:
https://github.com/IBM-Blockchain/ibm-container-service
This setup works for me correctly when I deploy v1.0.3 release.
This fails to deploy at joinchannel step. Looks like - endorsement policy failures? I need help with how to recover from this issue and some pointers - details are in yaml files or config files or both - per my initial understanding.
My debug traces are here:
https://pastebin.com/26fq4Vr0
https://pastebin.com/afuNCQBh
https://pastebin.com/MDeqCPQb
RobertDiebels (Wed, 20 Jun 2018 10:35:32 GMT):
Has joined the channel.
RobertDiebels (Wed, 20 Jun 2018 10:36:12 GMT):
Hey guys, I'm getting the following error on a fabric-peer: `Failed to generate platform-specific docker build: Error returned from build: 1 "can't load package: package chaincodes/simple: no buildable Go source files in /chaincode/input/src/chaincodes/simple`.
RobertDiebels (Wed, 20 Jun 2018 10:37:22 GMT):
I'm using the NodeSDK to send install and instantiate proposals. The first succeeds the second leads to this error.
RobertDiebels (Wed, 20 Jun 2018 10:37:45 GMT):
Could you tell me where the Peer tries to find the Go files?
bur (Thu, 21 Jun 2018 13:16:58 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=TQYBxvvNkdjqQRygd) @RobertDiebels your chaincode needs a main; when you install your chaincode make sure you give the path to the main
bur (Thu, 21 Jun 2018 13:16:58 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=TQYBxvvNkdjqQRygd) @RobertDiebels your chaincode needs a main; when you install your chaincode make sure you give the path to the main; [edit] just read that you use nodesdk; no idea how to use this
RobertDiebels (Fri, 22 Jun 2018 08:19:28 GMT):
@bur no problem. Thanks for answering anyway. You're the only one who tried so far haha.
bur (Fri, 22 Jun 2018 08:53:54 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=FoE5gGmWDto4D6Buq) @RobertDiebels did you try to install your chaincode using the CLI as described in the docs?
RobertDiebels (Fri, 22 Jun 2018 11:10:07 GMT):
@bur Yes. Installing using the CLI is operational. I tried analyzing why the files aren't found. I can't find them on the path where the peer tries to locate them `/var/hyperledger/production` even-tough the `installChaincode` call via the NodeSDK is succesful.
RobertDiebels (Fri, 22 Jun 2018 11:11:04 GMT):
My assumption there would be that if I use the `installChaincode` method the package is sent to the peer on which it is installed and unpacked in the right directory.
RobertDiebels (Fri, 22 Jun 2018 11:11:04 GMT):
My assumption there would be that if I use the `installChaincode` method the package is sent to the peer and unpacked in the right directory.
nvxtien (Fri, 22 Jun 2018 11:38:52 GMT):
Has joined the channel.
krisava (Fri, 22 Jun 2018 19:12:36 GMT):
Hi. getting the below exact error on multiple attempts, and also on many vm's. any idea if there are any changes at the fabric docker?
2018-06-22 19:06:04.562 UTC [grpc] Printf -> DEBU 040 grpc: addrConn.createTransport failed to connect to {peer0.org1.example.com:7051 0
sureshtedla (Sat, 23 Jun 2018 23:33:44 GMT):
Has joined the channel.
skarim (Mon, 25 Jun 2018 16:20:04 GMT):
Has joined the channel.
sampath06 (Tue, 26 Jun 2018 05:59:56 GMT):
I am looking for some information on the consensus algorithms in fabric. Mainly for the design considerations for moving away from pbft in 1.0?
anjalinaik (Tue, 26 Jun 2018 07:51:06 GMT):
hi All..can anyboy please help me understand below error? `Error: got unexpected status: SERVICE_UNAVAILABLE -- will not enqueue, consenter for this channel hasn't started yet`
C0rWin (Tue, 26 Jun 2018 10:35:00 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=ubkpcfEgTR9cLdxQx) @sampath06 Well, no one really moved away from pbft, consensus or ordering service is a pluggable component and in fact the enablement of BFT based consensus algorithm was just deferred
RobertDiebels (Wed, 27 Jun 2018 08:16:18 GMT):
Has left the channel.
pankajcheema (Wed, 27 Jun 2018 08:52:16 GMT):
Does anyone have any clue about this error ```2018-06-27 14:19:52.893 IST [gossip/discovery] expireDeadMembers -> WARN 347 Closing connection to Endpoint: peer2.debutinfotech.com:7051, InternalEndpoint: peer2.debutinfotech.com:7051, PKI-ID: [124 77 190 220 120 35 230 29 32 38 167 58 247 176 61 160 248 79 149 55 32 208 103 185 133 103 57 52 147 13 130 186], Metadata: []
```
C0rWin (Wed, 27 Jun 2018 13:10:45 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=DMhDAbyYxmE55fuuL) @pankajcheema that's not an error, though. Just a warning message of non active member being removed from the membership
pankajcheema (Wed, 27 Jun 2018 15:48:39 GMT):
@C0rWin yes its a warning. Could you please describe why it is showing me this warning?
C0rWin (Wed, 27 Jun 2018 16:32:05 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=23LcxrTcd8wcXppqa) @pankajcheema peer2 stopped communicate or haven’t been spotted a long time (no alive messages) presumed as dead, eventually clean up after expiration
anjalinaik (Thu, 28 Jun 2018 06:03:12 GMT):
Hi Can anyone please help me with this error : ` Unexpected topic-level metadata error: kafka server: Replication-factor is invalid.`
yacovm (Thu, 28 Jun 2018 06:11:35 GMT):
@anjalinaik - this question is more relevant to #fabric-orderer
yacovm (Thu, 28 Jun 2018 06:12:11 GMT):
but my guess would be that you messed up your kafka configuration somehow
clouddead (Thu, 28 Jun 2018 15:00:33 GMT):
Has joined the channel.
moodysalem (Thu, 28 Jun 2018 21:57:05 GMT):
Has joined the channel.
DivyaAgrawal (Thu, 28 Jun 2018 22:01:32 GMT):
Has joined the channel.
DivyaAgrawal (Thu, 28 Jun 2018 22:02:57 GMT):
Can someone point me to document for Committer sending events to clients after transaction commit. I could not find any detailed documentation on that. TIA
shubhamvrkr (Fri, 29 Jun 2018 06:25:28 GMT):
Has joined the channel.
wlahti (Fri, 29 Jun 2018 14:53:08 GMT):
@DivyaAgrawal Here is the doc for events starting with v1.1: https://hyperledger-fabric.readthedocs.io/en/release-1.1/peer_event_services.html
DivyaAgrawal (Fri, 29 Jun 2018 17:35:00 GMT):
@wlahti Thanks
pvrbharg (Tue, 03 Jul 2018 16:08:45 GMT):
@channel, I am seeing the above shown error when I try to create a channel for a customized tutorial. I can provide more info if needed and hoping someone can help me see what I am doing wrong or missing. Thanks
Error: got unexpected status: SERVICE_UNAVAILABLE -- will not enqueue, consenter for this channel hasn't started yet
pvrbharg (Tue, 03 Jul 2018 16:09:02 GMT):
ServiceUnavailableError.txt
suchith.arodi (Tue, 03 Jul 2018 18:25:56 GMT):
Has joined the channel.
asaningmaxchain123 (Wed, 04 Jul 2018 03:05:05 GMT):
@jyellick https://github.com/hyperledger/fabric/blob/83f18e76ac75fc381ad159b496eaf8a1b7bb20fb/core/aclmgmt/resourceprovider.go#L48 ,currently it just use the application section custom policy by config
asaningmaxchain123 (Wed, 04 Jul 2018 03:06:19 GMT):
but in the sampelconfig/configtx.yml, it supports the channel/orderer policy custom config
AshishMishra 1 (Wed, 04 Jul 2018 08:17:00 GMT):
Hi Guys.. do we have a configuration.. to restrict the CPU on the chaincode containers ? which we can pass an enviroment variable from the docker-compose file?
JayPandya (Thu, 05 Jul 2018 16:09:39 GMT):
Has joined the channel.
JayPandya (Thu, 05 Jul 2018 16:10:55 GMT):
what is best way to handle `MVCC_READ_CONFLICT` error in peer?
JayPandya (Thu, 05 Jul 2018 16:10:55 GMT):
what is the best way to handle `MVCC_READ_CONFLICT` error in peer?
JayPandya (Thu, 05 Jul 2018 16:11:49 GMT):
I'm committing 2 transactions from 2 different machines on peers
merth (Thu, 05 Jul 2018 18:51:40 GMT):
Has joined the channel.
jyellick (Thu, 05 Jul 2018 20:41:25 GMT):
@asaningmaxchain123 The ACLs are peer specific, and they are stored in the application section, but they may reference any policy defined in the channel config.
jyellick (Thu, 05 Jul 2018 20:41:51 GMT):
@JayPandya If an MVCC conflict occurs, usually you may simply re-simulate and submit the failing transaction and it will succeed.
danny_lee (Thu, 05 Jul 2018 22:49:47 GMT):
Has joined the channel.
JayPandya (Fri, 06 Jul 2018 07:49:37 GMT):
@jyellick - yeah that's right but I want to avoid this error so is there any way to do it instead of re-simulate txn?
JayPandya (Fri, 06 Jul 2018 07:50:01 GMT):
I'm trying delay between two txns but its not working properly
pankajcheema (Fri, 06 Jul 2018 12:34:05 GMT):
Is there anything like `admin peer`? I was reading endorsement policies ```'Org0.admin' (any administrator of the Org0 MSP) or 'Org1.member' (any member of the Org1 MSP), 'Org1.client' (any client of the Org1 MSP), and 'Org1.peer' (any peer of the Org1 MSP).```.
Who is client peer?
jyellick (Fri, 06 Jul 2018 19:37:57 GMT):
Peers are generally not clients, nor admins. Clients and admins are principals which are used in the construction of other, non-endorsement policies.
vdods (Sat, 07 Jul 2018 21:02:21 GMT):
Hey all, just wondering what version of golang is supported by Fabric 1.1 and 1.2? At some point there was an issue (with 1.0.5 I think?) where go 1.9 was not supported, so go 1.8 had to be used, and I just want to know if that limitation has been resolved. Thanks!
yacovm (Sat, 07 Jul 2018 21:02:56 GMT):
1.2 is using 1.10
vdods (Sat, 07 Jul 2018 21:03:10 GMT):
@yacovm Awesome, thanks!
yacovm (Sat, 07 Jul 2018 21:03:14 GMT):
I can't remember what's used in v1.1... I think 1.9 but not sure
yacovm (Sat, 07 Jul 2018 21:04:13 GMT):
in general - use 1.2 over v1.1, it has all the bug fixes v1.1.x has and the new features in it are very stable
vdods (Sat, 07 Jul 2018 21:04:14 GMT):
Between go 1.8 and 1.9 there was a minor feature added to encoding/base64 that I used in some code, and it made me really sad to have to give it up to use go 1.8 ;)
vdods (Sat, 07 Jul 2018 21:04:30 GMT):
Cool, noted!
grice_32 (Mon, 09 Jul 2018 14:38:45 GMT):
I'm going to run Fabric on RHEL 7.5 - Does anyone know if it is supported or do only the prerequisites (Docker, Docker Compose, go, node.js) versions matter?
NoLimitHoldem (Wed, 11 Jul 2018 06:19:18 GMT):
Has joined the channel.
jayeshjawale95 (Wed, 11 Jul 2018 07:32:39 GMT):
Has joined the channel.
WadeLu (Thu, 12 Jul 2018 07:34:37 GMT):
Has joined the channel.
ChanderGovindarajan (Thu, 12 Jul 2018 07:59:44 GMT):
Has joined the channel.
ChanderGovindarajan (Thu, 12 Jul 2018 08:02:33 GMT):
@grice_32 only prerequisite versions should matter. In any case, have run Fabric successfully on RHEL 7.2.
asaningmaxchain123 (Thu, 12 Jul 2018 15:26:09 GMT):
@jyellick the chaincode support the start/stop operation?
asaningmaxchain123 (Thu, 12 Jul 2018 15:26:46 GMT):
can i get the number of the chains in the blockchain?
asaningmaxchain123 (Thu, 12 Jul 2018 15:28:02 GMT):
and when the peer producer the event,it just validate the `identity` is a member of the `mspid`? so how to bind the specified channel?
asaningmaxchain123 (Thu, 12 Jul 2018 15:28:26 GMT):
and i can stop the chain?
asaningmaxchain123 (Thu, 12 Jul 2018 15:29:58 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=ze77facMYAFKo5Yo4) @yacovm in the 1.10 go,it is very hard to debug the code
yacovm (Thu, 12 Jul 2018 15:30:47 GMT):
and ... do you expect me to do about it? :thinking:
yacovm (Thu, 12 Jul 2018 15:30:47 GMT):
and ... what do you expect me to do about it? :thinking:
asaningmaxchain123 (Thu, 12 Jul 2018 15:31:39 GMT):
Clipboard - July 12, 2018 11:31 PM
asaningmaxchain123 (Thu, 12 Jul 2018 15:32:11 GMT):
can you resolve it? i google it,but not get the solution
pvrbharg (Sat, 14 Jul 2018 22:38:40 GMT):
@channel - can you please point me to current design document that covers [endorsement or other access control] policies for smart contracts and channels? I am looking for v1.0.x, v1.1.x releases - thanks
AshishMishra 1 (Wed, 18 Jul 2018 05:49:34 GMT):
Hi guys, I have a setup, which was working until today. Since morning I 'm not able to create new channels or install new chaincodes. Existing chaincodes are working.
Getting lscc chaincode timeout error.
Here are the logs, can someone please help?
https://gist.github.com/ashishxooa/2f7d089127d214aeed8f9c1ae34e3131
stone-ch (Wed, 18 Jul 2018 15:51:09 GMT):
Has joined the channel.
rushiraj111 (Thu, 19 Jul 2018 07:13:19 GMT):
Has joined the channel.
nelaturuk (Thu, 19 Jul 2018 18:22:19 GMT):
Has joined the channel.
nelaturuk (Fri, 20 Jul 2018 12:54:09 GMT):
Hi, has anyone come across this error in peer nodes.
2018-07-18 20:16:32.131 UTC [chaincode] Launch -> ERRO 3d4 launchAndWaitForRegister failed: Post http://unix.sock/containers/create?name=dev-peer1.chaincode1-v1.0.2-b3: dial unix /host/var/run/docker.sock: connect: permission denied
error starting container
This is my docker start command for peer:
docker run -itd --name peer1 \
--env CORE_PEER_ADDRESSAUTODETECT=false \
--env CORE_PEER_GOSSIP_SKIPHANDSHAKE=true \
--env CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock \
--env CORE_LOGGING_LEVEL=DEBUG \
--env CORE_PEER_TLS_ENABLED=true \
--env CORE_PEER_ENDORSER_ENABLED=true \
--env CORE_PEER_GOSSIP_ORGLEADER=true \
--env CORE_PEER_GOSSIP_USELEADERELECTION=false \
--env CORE_PEER_PROFILE_ENABLED=true \
--env CORE_PEER_ADDRESS=peer1:7051 \
--env CORE_PEER_CHAINCODEADDRESS=peer1:7051 \
--env CORE_PEER_CHAINCODELISTENADDRESS=0.0.0.0:7052 \
--env CORE_PEER_ID=peer1 \
--env CORE_PEER_MSPCONFIGPATH=/etc/hyperledger/fabric/msp \
--env CORE_PEER_LOCALMSPID=PeerMSP \
--env CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE=host \
--env CORE_PEER_TLS_CERT_FILE=/etc/hyperledger/fabric/tls/server.crt \
--env CORE_PEER_TLS_KEY_FILE=/etc/hyperledger/fabric/tls/server.key \
--env CORE_PEER_TLS_ROOTCERT_FILE=/etc/hyperledger/fabric/tls/ca.crt \
--env CORE_PEER_GOSSIP_EXTERNALENDPOINT=$hostip:7051 \
--env CORE_LEDGER_STATE_STATEDATABASE=CouchDB \
--env CORE_LEDGER_STATE_COUCHDBCONFIG_COUCHDBADDRESS=$hostip:5984 \
--hostname peer1 \
--add-host orderer1:$hostip \
--add-host peer1:$hostip \
--add-host peer2:$hostip \
--workdir /opt/gopath/src/github.com/hyperledger/fabric/peer \
--volume /var/run/:/host/var/run/ \
--volume $PERSISTANCE_ROOT_FOLDER/peer1:/var/hyperledger/production \
--volume ${msp_src}:/etc/hyperledger/fabric/msp \
--volume ${tls_src}:/etc/hyperledger/fabric/tls \
--publish 7051:7051 \
--publish 7053:7053 \
ibmblockchain/fabric-peer peer node start
NareshPai (Mon, 23 Jul 2018 04:25:07 GMT):
Has joined the channel.
hamptonsmith (Mon, 23 Jul 2018 14:32:32 GMT):
Apologies for cross-post from #fabric-chaincode-dev , but I'm not certain if this is a chaincode issue or an endorser issue:
I added a history query to my chaincode. Unit tests pass locally. Attempting to instantiate the code, I see:
```
chaincode/input/src/wagoncc/cc.go:993:38: cannot use entry (type *"github.com/hyperledger/fabric/protos/ledger/queryresult".KeyModification) as type *"wagoncc/vendor/github.com/hyperledger/fabric/protos/ledger/queryresult".KeyModification in argument to marshalHistoryEntry
```
Problem is, there's nothing vendored in my code:
```
$ find $GOPATH -name *vendor*
/* this space blank */
$
```
Nor do there appear to be any hidden cache directories:
```
$ find $GOPATH -name '.*'
/* this space blank */
$
```
My current assumption is that some previously-vendored version of this code is hanging around in a cache somewhere in the network itself, but I've totally torn down the network (while keeping the servers in place--they are very much pets and not cattle at this point), done my best to obliterate all state, ensured that `docker containers ls -a`, `docker image ls -a`, and `docker volume ls` all return nothing, then brought everything up _de novo_, but I still see the issue. I've run out of ideas. Any thoughts on sneaky places I can check or better ways to debug this issue?
hamptonsmith (Mon, 23 Jul 2018 14:47:47 GMT):
Note that I _have_ "in-line vendored" the library in question:
```
$ find $GOPATH -path */queryresult
/opt/gopath/src/github.com/hyperledger/fabric/protos/ledger/queryresult
```
But without this, I see errors during chaincode installation:
```
$ peer chaincode install ...snip...
can't load package: package github.com/hyperledger/fabric/protos/ledger/queryresult: cannot find package "github.com/hyperledger/fabric/protos/ledger/queryresult" in any of:
/opt/go/src/github.com/hyperledger/fabric/protos/ledger/queryresult (from $GOROOT)
/opt/gopath/src/github.com/hyperledger/fabric/protos/ledger/queryresult (from $GOPATH)
```
nelaturuk (Mon, 23 Jul 2018 15:41:53 GMT):
Hi,
I am trying to upgrade all netwokr components to v1.1.0. Except for peers everything else works fine.
I see this error on peer:
panic: Error during state DB recovery:Last committed block=2, block requested=3
goroutine 1 [running]:
github.com/hyperledger/fabric/core/ledger/kvledger.newKVLedger(0xc42121a680, 0xb, 0xc42118bbf0, 0x1b056c0, 0xc4211b3e80, 0x1aff580, 0xc4211bc400, 0xc420225860, 0x326c656e6e616863, 0x613035, ...)
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/kvledger/kv_ledger.go:67 +0x4da
github.com/hyperledger/fabric/core/ledger/kvledger.(*Provider).openInternal(0xc4200902c0, 0xc42121a680, 0xb, 0xc42121e301, 0x0, 0x0, 0x1045415)
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/kvledger/kv_ledger_provider.go:152 +0x170
github.com/hyperledger/fabric/core/ledger/kvledger.(*Provider).Open(0xc4200902c0, 0xc42121a680, 0xb, 0xb, 0x1b563a0, 0x0, 0x1b34760)
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/kvledger/kv_ledger_provider.go:128 +0x130
github.com/hyperledger/fabric/core/ledger/ledgermgmt.OpenLedger(0xc42121a680, 0xb, 0x0, 0x0, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/ledgermgmt/ledger_mgmt.go:110 +0x1d1
github.com/hyperledger/fabric/core/peer.Initialize(0x13f9ba0)
/opt/gopath/src/github.com/hyperledger/fabric/core/peer/peer.go:213 +0x1e6
#!/bin/bash
github.com/hyperledger/fabric/peer/node.serve(0x1b54e68, 0x0, 0x0, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/peer/node/start.go:280 +0x1048
github.com/hyperledger/fabric/peer/node.glob..func1(0x1ae4860, 0x1b54e68, 0x0, 0x0, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/peer/node/start.go:87 +0x3f
github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).execute(0x1ae4860, 0x1b54e68, 0x0, 0x0, 0x1ae4860, 0x1b54e68)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:599 +0x3e8
github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0x1ae4ec0, 0x11, 0xc4202c6520, 0x5)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:689 +0x2fe
github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).Execute(0x1ae4ec0, 0x1b, 0xc420016075)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:648 +0x2b
main.main()
/opt/gopath/src/github.com/hyperledger/fabric/peer/main.go:112 +0x5e1
Can anyone please help me with this ?
rahulhegde (Mon, 23 Jul 2018 16:53:46 GMT):
hello @dave.enyeart - On Fabric v1.0.6
We are facing a issue where the Endorsement Request gives a Execute Timeout to the HFC. We see from the chaincode logs - the endorsement gets processed within 7secs against the default execute timeout (30sec). The peer basically holds the response. The couch database logs are also scrolling indicating the communication between chaincode - peer - couch database is good.
This has happened to two peers. I have restarted 1 peer to increase the logging level to DEBUG however the issue related to Execute Timeout got fixed for it. I have avoided the restart of the other PEER to check if I can get any troubleshooting steps here.
yacovm (Mon, 23 Jul 2018 16:55:00 GMT):
@rahulhegde as a rule of thumb... whenever you restart stuff
yacovm (Mon, 23 Jul 2018 16:55:07 GMT):
if it's possible
yacovm (Mon, 23 Jul 2018 16:55:11 GMT):
use `kill -SIGABRT`
yacovm (Mon, 23 Jul 2018 16:55:22 GMT):
it will make the process crash and dump the stack trace to the logs
yacovm (Mon, 23 Jul 2018 16:55:35 GMT):
that will help for post-mortem analysis
rahulhegde (Mon, 23 Jul 2018 16:58:10 GMT):
I can do it for the current peer which does not send the response to HFC. Anything else we can do to gather more information?
yacovm (Mon, 23 Jul 2018 17:00:27 GMT):
There was someone in the past that proposed to add an RPC to the admin API to dump the goroutines into the logs but he was told it's a worthless idea ;)
yacovm (Mon, 23 Jul 2018 17:00:39 GMT):
so I guess there is no other way than to kill the peer
rahulhegde (Mon, 23 Jul 2018 17:04:25 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=LWNo4XC82WZLWr8zj) @yacovm okay.
dave.enyeart (Mon, 23 Jul 2018 17:08:29 GMT):
@rahulhegde you can enable certain debugs without restarting peer. we'll have to confirm with @wlahti that this was possible in v1.0.x
dave.enyeart (Mon, 23 Jul 2018 17:08:36 GMT):
for example this would be helpful:
dave.enyeart (Mon, 23 Jul 2018 17:08:40 GMT):
```peer logging setlevel chaincode DEBUG
peer logging setlevel endorser DEBUG
peer logging setlevel ledger DEBUG
peer logging setlevel state DEBUG
peer logging setlevel couchdb DEBUG
peer logging setlevel txmgr DEBUG```
dave.enyeart (Mon, 23 Jul 2018 17:09:43 GMT):
it uses regular expression matching against the loggers... what I don't recall is whether that was setup in v1.0.x @wlahti ?
wlahti (Mon, 23 Jul 2018 17:17:47 GMT):
@dave.enyeart Yes, the ability to dynamically set logging levels has been available since v1.0.0. A few minor things have changed since then but the functionality was in place.
rahulhegde (Mon, 23 Jul 2018 17:18:20 GMT):
Cool - I will enable following log level.
rahulhegde (Mon, 23 Jul 2018 18:51:30 GMT):
hello @dave.enyeart - we increased the log level but looks like there is information that can help out
```
ESC[36m2018-07-23 20:32:52.192 CEST [chaincode] processStream -> DEBU da6ESC[0m [a724cefa]Received message COMPLETED from shim
ESC[36m2018-07-23 20:32:52.192 CEST [chaincode] HandleMessage -> DEBU da7ESC[0m [a724cefa]Fabric side Handling ChaincodeMessage of type: COMPLETED in state ready
ESC[36m2018-07-23 20:32:52.192 CEST [chaincode] HandleMessage -> DEBU da8ESC[0m [a724cefaf6517cdf1858aef72dc0e486d25abebd00cfff04674b212d26de41aa]HandleMessage- COMPLETED. Notify
ESC[36m2018-07-23 20:32:52.192 CEST [chaincode] notify -> DEBU da9ESC[0m notifying Txid:a724cefaf6517cdf1858aef72dc0e486d25abebd00cfff04674b212d26de41aa
ESC[36m2018-07-23 20:32:52.192 CEST [chaincode] Execute -> DEBU daaESC[0m Exit
ESC[36m2018-07-23 20:32:52.192 CEST [endorser] callChaincode -> DEBU dabESC[0m Exit
ESC[36m2018-07-23 20:32:52.192 CEST [lockbasedtxmgr] GetTxSimulationResults -> DEBU dacESC[0m Simulation completed, getting simulation results
ESC[36m2018-07-23 20:32:52.192 CEST [lockbasedtxmgr] Done -> DEBU dadESC[0m Done with transaction simulation / query execution [a92a2043-a49e-4a66-9a91-ec04058820d5]
....
ESC[36m2018-07-23 20:33:22.193 CEST [chaincode] Execute -> DEBU de1ESC[0m Exit
ESC[31m2018-07-23 20:33:22.193 CEST [chaincode] ExecuteChaincode -> ERRO de2ESC[0m Error executing chaincode: Failed to execute transaction (Timeout expired while executing transaction)
ESC[36m2018-07-23 20:33:22.193 CEST [endorser] callChaincode -> DEBU de3ESC[0m Exit
```
rahulhegde (Mon, 23 Jul 2018 18:51:30 GMT):
hello @dave.enyeart - we increased the log level but looks like there is no information that can help out
```
ESC[36m2018-07-23 20:32:52.192 CEST [chaincode] processStream -> DEBU da6ESC[0m [a724cefa]Received message COMPLETED from shim
ESC[36m2018-07-23 20:32:52.192 CEST [chaincode] HandleMessage -> DEBU da7ESC[0m [a724cefa]Fabric side Handling ChaincodeMessage of type: COMPLETED in state ready
ESC[36m2018-07-23 20:32:52.192 CEST [chaincode] HandleMessage -> DEBU da8ESC[0m [a724cefaf6517cdf1858aef72dc0e486d25abebd00cfff04674b212d26de41aa]HandleMessage- COMPLETED. Notify
ESC[36m2018-07-23 20:32:52.192 CEST [chaincode] notify -> DEBU da9ESC[0m notifying Txid:a724cefaf6517cdf1858aef72dc0e486d25abebd00cfff04674b212d26de41aa
ESC[36m2018-07-23 20:32:52.192 CEST [chaincode] Execute -> DEBU daaESC[0m Exit
ESC[36m2018-07-23 20:32:52.192 CEST [endorser] callChaincode -> DEBU dabESC[0m Exit
ESC[36m2018-07-23 20:32:52.192 CEST [lockbasedtxmgr] GetTxSimulationResults -> DEBU dacESC[0m Simulation completed, getting simulation results
ESC[36m2018-07-23 20:32:52.192 CEST [lockbasedtxmgr] Done -> DEBU dadESC[0m Done with transaction simulation / query execution [a92a2043-a49e-4a66-9a91-ec04058820d5]
....
ESC[36m2018-07-23 20:33:22.193 CEST [chaincode] Execute -> DEBU de1ESC[0m Exit
ESC[31m2018-07-23 20:33:22.193 CEST [chaincode] ExecuteChaincode -> ERRO de2ESC[0m Error executing chaincode: Failed to execute transaction (Timeout expired while executing transaction)
ESC[36m2018-07-23 20:33:22.193 CEST [endorser] callChaincode -> DEBU de3ESC[0m Exit
```
rahulhegde (Mon, 23 Jul 2018 19:01:49 GMT):
Please let me know if we can have a call for this issue.
rahulhegde (Mon, 23 Jul 2018 19:55:26 GMT):
I have opened a FAB-11273
dave.enyeart (Mon, 23 Jul 2018 19:56:53 GMT):
Here's the relevant code... I'm not sure how the defer "Exit" debug could be printed twice
dave.enyeart (Mon, 23 Jul 2018 19:56:55 GMT):
https://github.com/hyperledger/fabric/blob/release-1.0/core/chaincode/chaincode_support.go#L718-L752
rahulhegde (Mon, 23 Jul 2018 20:22:51 GMT):
there was no 2nd endorsement message in pipeline for that peer.
rahulhegde (Tue, 24 Jul 2018 16:15:44 GMT):
*Second Problem* Fabric Release 1.0.6 @dave.enyeart, @yacovm
we are seeing another problem on same environment where orderer is running on lower block count (5325) and one out of 2 peers (subscribed to the channel) is running +5 block ahead (5330), the other peer (2nd peer) is running with same block count as orderer (#5325).
Setup: Orderer is using kafka consensus.
rahulhegde (Tue, 24 Jul 2018 16:15:44 GMT):
*Second Problem* Fabric Release 1.0.6 @dave.enyeart, @yacovm @jyellick
we are seeing another problem on same environment where orderer is running on lower block count (5325) and one out of 2 peers (subscribed to the channel) is running +5 block ahead (5330), the other peer (2nd peer) is running with same block count as orderer (#5325).
Setup: Orderer is using kafka consensus.
yacovm (Tue, 24 Jul 2018 16:40:21 GMT):
well I'm pretty sure some orderer made the blocks 5326-5330
yacovm (Tue, 24 Jul 2018 16:40:37 GMT):
are you sure there is no such an OSN?
rahulhegde (Tue, 24 Jul 2018 16:41:25 GMT):
Our orderer was running in ERROR mode, bumped to INFO and they gave following across
`2018-07-24 16:29:07.277 CEST [orderer/kafka] newChain -> INFO 003 [channel: xxxxx] Starting chain with last persisted offset 30210 and last recorded block 5325`
rahulhegde (Tue, 24 Jul 2018 16:41:25 GMT):
Our orderer was running in ERROR mode, bumped to INFO and they gave following across
`2018-07-24 16:29:07.277 CEST [orderer/kafka] newChain -> INFO 003 [channel: xxxxx] Starting chain with last persisted offset 30210 and last recorded block 5325`
So used the log content from each orderer to compare the same - `last recorded block 5325`
rahulhegde (Tue, 24 Jul 2018 16:43:04 GMT):
Used the couch database `statedb_statepoint` document to get the block count from the Peer Node.
rahulhegde (Tue, 24 Jul 2018 16:43:04 GMT):
Used the couch database `statedb_statepoint` document to get the block count from the Peer Node. One shows +5 and the other matches with orderer block count.
yacovm (Tue, 24 Jul 2018 16:43:26 GMT):
peers verify signatures on the blocks before they commit them
yacovm (Tue, 24 Jul 2018 16:43:41 GMT):
so.... I'm pretty sure the blocks the peers have isn't fake ;)
yacovm (Tue, 24 Jul 2018 16:43:41 GMT):
so.... I'm pretty sure the blocks the peers have aren't fake ;)
rahulhegde (Tue, 24 Jul 2018 16:46:32 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=KgvxxDdxkKssLYtdX) @yacovm Application Payload from the ledger transaction looks legitimate from the client log that received the extra blocks (+5) from its peer.
rahulhegde (Tue, 24 Jul 2018 16:53:43 GMT):
any theory?
asaningmaxchain123 (Tue, 24 Jul 2018 18:06:16 GMT):
https://jira.hyperledger.org/browse/FAB-11282
asaningmaxchain123 (Tue, 24 Jul 2018 18:06:22 GMT):
@yacovm @jyellick
fabiomolinar (Tue, 24 Jul 2018 18:13:24 GMT):
Has joined the channel.
rahulhegde (Tue, 24 Jul 2018 20:30:12 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=5y5ytpzMMvDwYfgKY) I dont know what changed after OSN restart - we are ok with the setup and the block number are synced across peer + orderer. Thanks.
javrevasandeep (Wed, 25 Jul 2018 06:36:13 GMT):
Hello guys. I am getting issue while invoking the chaincode. For example_chaincode02, value of "a" is not changing even after multiple invokes. I set the OR policy while doing the instantiation. Instantiation happened without any error. However after multiple invoke, when i checked the peer logs, I am able to see some error message related to VSCC endorsemet failure. Below given are the peer0Org1 logs
I am facing issue while doing the invoke. It seems to be VSCC endorsement failure kind of error. Below given are the peer0Org1 logs
2018-07-25 05:59:45.983 UTC [shim] func1 -> DEBU 74d [0ebe1dea]Received message TRANSACTION from shim
2018-07-25 05:59:45.983 UTC [shim] handleMessage -> DEBU 74e [0ebe1dea]Handling ChaincodeMessage of type: TRANSACTION(state:ready)
2018-07-25 05:59:45.984 UTC [shim] beforeTransaction -> DEBU 74f [0ebe1dea]Received TRANSACTION, invoking transaction on chaincode(Src:ready, Dst:ready)
2018-07-25 05:59:45.984 UTC [vscc] Invoke -> DEBU 750 VSCC invoked
2018-07-25 05:59:45.984 UTC [vscc] deduplicateIdentity -> DEBU 751 Signature set is of size 1 out of 1 endorsement(s)
2018-07-25 05:59:45.984 UTC [vscc] Invoke -> WARN 752 Endorsement policy failure for transaction txid=bbae754cdb42ccf121ecb77eecfd51190c618416ffabc59dcce47f02693957a9, err: signature set did not satisfy policy
2018-07-25 05:59:45.984 UTC [shim] func1 -> DEBU 753 [0ebe1dea]Transaction completed. Sending COMPLETED
2018-07-25 05:59:45.984 UTC [shim] func1 -> DEBU 754 [0ebe1dea]Move state message COMPLETED
2018-07-25 05:59:45.985 UTC [shim] handleMessage -> DEBU 755 [0ebe1dea]Handling ChaincodeMessage of type: COMPLETED(state:ready)
2018-07-25 05:59:45.985 UTC [shim] func1 -> DEBU 756 [0ebe1dea]send state message COMPLETED
2018-07-25 05:59:45.985 UTC [chaincode] processStream -> DEBU 757 [0ebe1dea]Received message COMPLETED from shim
2018-07-25 05:59:45.985 UTC [chaincode] handleMessage -> DEBU 758 [0ebe1dea]Fabric side Handling ChaincodeMessage of type: COMPLETED in state ready
2018-07-25 05:59:45.985 UTC [chaincode] handleMessage -> DEBU 759 [0ebe1dea-fd85-43b1-a291-b5aa50093a48]HandleMessage- COMPLETED. Notify
2018-07-25 05:59:45.985 UTC [chaincode] notify -> DEBU 75a notifying Txid:0ebe1dea-fd85-43b1-a291-b5aa50093a48, channelID:mychannel
2018-07-25 05:59:45.985 UTC [chaincode] Execute -> DEBU 75b Exit
2018-07-25 05:59:45.985 UTC [lockbasedtxmgr] Done -> DEBU 75c Done with transaction simulation / query execution [bbae754cdb42ccf121ecb77eecfd51190c618416ffabc59dcce47f02693957a9]
2018-07-25 05:59:45.985 UTC [committer/txvalidator] VSCCValidateTxForCC -> DEBU 75d VSCCValidateTxForCC completes for envbytes 0xc421e98800
2018-07-25 05:59:45.985 UTC [committer/txvalidator] VSCCValidateTx -> DEBU 75e VSCCValidateTx completes for env 0xc423166e10 envbytes 0xc421e98800
*2018-07-25 05:59:45.985 UTC [committer/txvalidator] validateTx -> ERRO 75f VSCCValidateTx for transaction txId = bbae754cdb42ccf121ecb77eecfd51190c618416ffabc59dcce47f02693957a9 returned error: VSCC error: endorsement policy failure, err: signature set did not satisfy policy*
2018-07-25 05:59:45.985 UTC [committer/txvalidator] validateTx -> DEBU 760 validateTx completes for block 0xc42359a640 env 0xc423166e10 txn 0
2018-07-25 05:59:45.986 UTC [committer/txvalidator] Validate -> DEBU 761 got result for idx 0, code 10
2018-07-25 05:59:45.986 UTC [committer/txvalidator] Validate -> DEBU 762 END Block Validation
2018-07-25 05:59:45.987 UTC [kvledger] CommitWithPvtData -> DEBU 763 Channel [mychannel]: Validating state for block [4]
2018-07-25 05:59:45.987 UTC [lockbasedtxmgr] ValidateAndPrepare -> DEBU 764 Validating new block with num trans = [1]
2018-07-25 05:59:45.987 UTC [valimpl] ValidateAndPrepareBatch -> DEBU 765 ValidateAndPrepareBatch() for block number = [4]
2018-07-25 05:59:45.987 UTC [valimpl] ValidateAndPrepareBatch -> DEBU 766 preprocessing ProtoBlock...
*2018-07-25 05:59:45.987 UTC [valimpl] preprocessProtoBlock -> WARN 767 Channel [mychannel]: Block [4] Transaction index [0] TxId [bbae754cdb42ccf121ecb77eecfd51190c618416ffabc59dcce47f02693957a9] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]*
javrevasandeep (Wed, 25 Jul 2018 06:36:13 GMT):
Hello guys. I am getting issue while invoking the chaincode. For example_chaincode02, value of "a" is not changing even after multiple invokes. I set the OR policy while doing the instantiation. Instantiation happened without any error. However after multiple invoke, when i checked the peer logs, I am able to see some error message related to VSCC endorsemet failure. Below given are the peer0Org1 logs
2018-07-25 05:59:45.983 UTC [shim] func1 -> DEBU 74d [0ebe1dea]Received message TRANSACTION from shim
2018-07-25 05:59:45.983 UTC [shim] handleMessage -> DEBU 74e [0ebe1dea]Handling ChaincodeMessage of type: TRANSACTION(state:ready)
2018-07-25 05:59:45.984 UTC [shim] beforeTransaction -> DEBU 74f [0ebe1dea]Received TRANSACTION, invoking transaction on chaincode(Src:ready, Dst:ready)
2018-07-25 05:59:45.984 UTC [vscc] Invoke -> DEBU 750 VSCC invoked
2018-07-25 05:59:45.984 UTC [vscc] deduplicateIdentity -> DEBU 751 Signature set is of size 1 out of 1 endorsement(s)
2018-07-25 05:59:45.984 UTC [vscc] Invoke -> WARN 752 Endorsement policy failure for transaction txid=bbae754cdb42ccf121ecb77eecfd51190c618416ffabc59dcce47f02693957a9, err: signature set did not satisfy policy
2018-07-25 05:59:45.984 UTC [shim] func1 -> DEBU 753 [0ebe1dea]Transaction completed. Sending COMPLETED
2018-07-25 05:59:45.984 UTC [shim] func1 -> DEBU 754 [0ebe1dea]Move state message COMPLETED
2018-07-25 05:59:45.985 UTC [shim] handleMessage -> DEBU 755 [0ebe1dea]Handling ChaincodeMessage of type: COMPLETED(state:ready)
2018-07-25 05:59:45.985 UTC [shim] func1 -> DEBU 756 [0ebe1dea]send state message COMPLETED
2018-07-25 05:59:45.985 UTC [chaincode] processStream -> DEBU 757 [0ebe1dea]Received message COMPLETED from shim
2018-07-25 05:59:45.985 UTC [chaincode] handleMessage -> DEBU 758 [0ebe1dea]Fabric side Handling ChaincodeMessage of type: COMPLETED in state ready
2018-07-25 05:59:45.985 UTC [chaincode] handleMessage -> DEBU 759 [0ebe1dea-fd85-43b1-a291-b5aa50093a48]HandleMessage- COMPLETED. Notify
2018-07-25 05:59:45.985 UTC [chaincode] notify -> DEBU 75a notifying Txid:0ebe1dea-fd85-43b1-a291-b5aa50093a48, channelID:mychannel
2018-07-25 05:59:45.985 UTC [chaincode] Execute -> DEBU 75b Exit
2018-07-25 05:59:45.985 UTC [lockbasedtxmgr] Done -> DEBU 75c Done with transaction simulation / query execution [bbae754cdb42ccf121ecb77eecfd51190c618416ffabc59dcce47f02693957a9]
2018-07-25 05:59:45.985 UTC [committer/txvalidator] VSCCValidateTxForCC -> DEBU 75d VSCCValidateTxForCC completes for envbytes 0xc421e98800
2018-07-25 05:59:45.985 UTC [committer/txvalidator] VSCCValidateTx -> DEBU 75e VSCCValidateTx completes for env 0xc423166e10 envbytes 0xc421e98800
*2018-07-25 05:59:45.985 UTC [committer/txvalidator] validateTx -> ERRO 75f VSCCValidateTx for transaction txId = bbae754cdb42ccf121ecb77eecfd51190c618416ffabc59dcce47f02693957a9 returned error: VSCC error: endorsement policy failure, err: signature set did not satisfy policy*
2018-07-25 05:59:45.985 UTC [committer/txvalidator] validateTx -> DEBU 760 validateTx completes for block 0xc42359a640 env 0xc423166e10 txn 0
2018-07-25 05:59:45.986 UTC [committer/txvalidator] Validate -> DEBU 761 got result for idx 0, code 10
2018-07-25 05:59:45.986 UTC [committer/txvalidator] Validate -> DEBU 762 END Block Validation
2018-07-25 05:59:45.987 UTC [kvledger] CommitWithPvtData -> DEBU 763 Channel [mychannel]: Validating state for block [4]
2018-07-25 05:59:45.987 UTC [lockbasedtxmgr] ValidateAndPrepare -> DEBU 764 Validating new block with num trans = [1]
2018-07-25 05:59:45.987 UTC [valimpl] ValidateAndPrepareBatch -> DEBU 765 ValidateAndPrepareBatch() for block number = [4]
2018-07-25 05:59:45.987 UTC [valimpl] ValidateAndPrepareBatch -> DEBU 766 preprocessing ProtoBlock...
*2018-07-25 05:59:45.987 UTC [valimpl] preprocessProtoBlock -> WARN 767 Channel [mychannel]: Block [4] Transaction index [0] TxId [bbae754cdb42ccf121ecb77eecfd51190c618416ffabc59dcce47f02693957a9] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]*
pankajcheema (Wed, 25 Jul 2018 07:48:30 GMT):
Hi Experts , I overrirde a polic in ACL in application as `peer/Propose: /Channel/Application/PankajPoilicy1` and didn't define the policy .But i was able to invoke the chaincode but not able to query at the time of query error was ```Error: error endorsing query: rpc error: code = Unknown desc = failed evaluating policy on signed data during check policy [/Channel/Application/PankajPoilicy1]: [policy /Channel/Application/PankajPoilicy1 not found] - proposal response:
pankajcheema (Wed, 25 Jul 2018 07:48:30 GMT):
Hi Experts , I overrirde a policy in ACL in application as `peer/Propose: /Channel/Application/PankajPoilicy1` and didn't define the policy .But i was able to invoke the chaincode but not able to query at the time of query error was ```Error: error endorsing query: rpc error: code = Unknown desc = failed evaluating policy on signed data during check policy [/Channel/Application/PankajPoilicy1]: [policy /Channel/Application/PankajPoilicy1 not found] - proposal response:
pankajcheema (Wed, 25 Jul 2018 07:48:30 GMT):
Hi Experts , I overrirde a policy in ACL in application as `peer/Propose: /Channel/Application/PankajPoilicy1` and didn't define the policy .But i was able to invoke the chaincode, but not able to query at the time of query error was ```Error: error endorsing query: rpc error: code = Unknown desc = failed evaluating policy on signed data during check policy [/Channel/Application/PankajPoilicy1]: [policy /Channel/Application/PankajPoilicy1 not found] - proposal response:
pankajcheema (Wed, 25 Jul 2018 08:51:40 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=NvPJQModRSZLDKCwS) @dave.enyeart
pankajcheema (Wed, 25 Jul 2018 10:50:26 GMT):
https://stackoverflow.com/questions/51517076/hyperledger-fabric-acl-in-configtx-yaml
qizhang (Thu, 26 Jul 2018 04:59:55 GMT):
Can anyone point me to the Fabric code where the peer spawns a chaincode container? Thanks
yacovm (Thu, 26 Jul 2018 06:06:31 GMT):
@qizhang start looking at chaincode_support.go
yacovm (Thu, 26 Jul 2018 06:06:48 GMT):
What are you up to now @qizhang ?
rsherwood (Thu, 26 Jul 2018 07:43:53 GMT):
Hi, we have a channel where only one org is allowed to update , but many orgs can query , but we only need to have that performed as cross chanincode calls. In R 1.0 you used to have all organization in the channel write policy to allow the cross chain code calls. In R1.2 I see there is a peer/Propose policy AND a peer/ChaincodeToChaincode. Can achieve what I want in 1.2 by adding all orgs to the policy reference in peer/ChaincodeToChaincode and only the one org I want to have write access to the peer/Propose ?
Unni_1994 (Fri, 27 Jul 2018 10:24:49 GMT):
Hi all, I am getting an error while bringing up the first network. Instantiate is success, while querying it showing some error (Multihost setup)
Unni_1994 (Fri, 27 Jul 2018 10:25:09 GMT):
query-error.png
thiyagucse01 (Fri, 27 Jul 2018 10:45:36 GMT):
Has joined the channel.
qizhang (Mon, 30 Jul 2018 00:36:36 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=b6646c7a-6585-41cd-b3cb-6007a38c764c) @yacovm Thanks @yacovm, will check it.
Another question, when a transaction is committed into the ledger, who will notify the client that the transaction has been successfully committed？Since multiple peers will commit the same block (i.e. transactions), I am wondering which peer will send out such notification to the client?
qizhang (Mon, 30 Jul 2018 00:36:36 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=b6646c7a-6585-41cd-b3cb-6007a38c764c) Thanks @yacovm, will check it.
Another question, when a transaction is committed into the ledger, who will notify the client that the transaction has been successfully committed？Since multiple peers will commit the same block (i.e. transactions), I am wondering which peer will send out such notification to the client?
asaningmaxchain123 (Mon, 30 Jul 2018 00:49:02 GMT):
@jyellick the `peer` cmd should provider the sub cmd to get the block from the peer
asaningmaxchain123 (Mon, 30 Jul 2018 00:49:51 GMT):
like the `peer channel fetch` it retrieves the block from the orderer, but for the client,get block from peer node seems more important
asaningmaxchain123 (Mon, 30 Jul 2018 00:50:19 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=gfmKuECbYY7t82TNK) @qizhang you can use the event hub to listen it
qizhang (Mon, 30 Jul 2018 01:13:21 GMT):
@asaningmaxchain123 Thanks! But still, even though the client can listen to the event hub, who should create the event indicating that a tx has been committed?
asaningmaxchain123 (Mon, 30 Jul 2018 02:51:17 GMT):
@qizhang you can see the ` //Events
Event_Block = "event/Block"
Event_FilteredBlock = "event/FilteredBlock"`
asaningmaxchain123 (Mon, 30 Jul 2018 02:51:17 GMT):
@qizhang you can see the ```//Events
Event_Block = "event/Block"
Event_FilteredBlock = "event/FilteredBlock"```
pankajcheema (Mon, 30 Jul 2018 07:41:46 GMT):
in this command of first network endorsement is happenning or not ? ```peer chaincode instantiate -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C $CHANNEL_NAME -n mycc -v 1.0 -c '{"Args":["init","a", "100", "b","200"]}' -P "AND ('Org1MSP.peer','Org2MSP.peer')"
```
pankajcheema (Mon, 30 Jul 2018 07:42:02 GMT):
using binaries 1.2
pankajcheema (Mon, 30 Jul 2018 07:42:19 GMT):
My answer is yes
pankajcheema (Mon, 30 Jul 2018 07:42:33 GMT):
if am wrong somewhere please correct me.
pankajcheema (Mon, 30 Jul 2018 07:42:51 GMT):
@yacovm @dave.enyeart @jyellick
richzhao (Mon, 30 Jul 2018 08:19:53 GMT):
if a peer doesn't hold private data in its own private temp db, during validation phrase, it needs to fetch private data from others, does it need to store private data after validation or after committing? @dave.enyeart @yacovm @jyellick
yacovm (Mon, 30 Jul 2018 08:22:29 GMT):
it doesn't do it during validation
yacovm (Mon, 30 Jul 2018 08:22:39 GMT):
it first validates and then pulls data before the commit
yacovm (Mon, 30 Jul 2018 08:22:48 GMT):
so we have:
1) validation
2) pull data
3) commit
richzhao (Mon, 30 Jul 2018 09:06:19 GMT):
only pull data, but doesn't save to its owner private team db?
yacovm (Mon, 30 Jul 2018 10:40:59 GMT):
of course it saves
JayPandya (Mon, 30 Jul 2018 14:04:14 GMT):
I've configured TLS in Fabric network but when I try to install chaincode on that network it always get timeout
```
2018-07-30 12:38:34.920 UTC [chaincode] launchAndWaitForRegister -> DEBU 612 stopping due to error while launching: timeout expired while starting chaincode example:2.6.1(networkid:dev,peerid:peer0.org1.example.com,tx:22a5e0ec55f666bd7da2254d0df20af7cd73bf932dd991a770f89160cca14776)
```
I've also tried to increase chaincode execute time out but its the same
satyajitdeshmukh (Mon, 30 Jul 2018 14:53:40 GMT):
Has joined the channel.
richzhao (Tue, 31 Jul 2018 06:37:14 GMT):
thanks for answering my question. @yacovm but I am confused, if the validation peer saves private data, how to keep private data private?
dave.enyeart (Tue, 31 Jul 2018 11:18:20 GMT):
@richzhao Collection non-members do not retrieve the private data, they validate the public hash of private data only, e.g. to ensure the version of the hashed key hasn't changed since simulation time. Collection members retrieve the actual private data and store it in their temp db (if it wasn't pushed to them at endorsement time) and validate the hash version and that the private data matches the public hash. If everything validates, the private data is removed from temp db and is committed to the private data storage and state db.
dave.enyeart (Tue, 31 Jul 2018 11:18:20 GMT):
@richzhao Collection non-members do not retrieve the private data, they validate the public hash of private data only, e.g. to ensure the version of the hashed key hasn't changed since simulation time. Collection members retrieve the actual private data (if it wasn't pushed to them at endorsement time) and validate the hash version and that the private data matches the public hash.
richzhao (Tue, 31 Jul 2018 12:32:18 GMT):
thank you very much. this sounds a great solution @dave.enyeart
asaningmaxchain123 (Tue, 31 Jul 2018 15:50:56 GMT):
@yacovm how to set the address when initialize chaincode,
asaningmaxchain123 (Tue, 31 Jul 2018 15:50:56 GMT):
@yacovm how to set the peer address when initialize chaincode,
asaningmaxchain123 (Tue, 31 Jul 2018 15:50:56 GMT):
@jyellick @yacovm how to set the peer address when initialize chaincode,
asaningmaxchain123 (Tue, 31 Jul 2018 15:52:11 GMT):
Clipboard - July 31, 2018 11:52 PM
yacovm (Tue, 31 Jul 2018 17:05:44 GMT):
i don't understand what you're asking
yacovm (Tue, 31 Jul 2018 17:06:11 GMT):
but probably the answer is `CORE_PEER_ADDRESS`
abhishek.s (Wed, 01 Aug 2018 06:19:16 GMT):
Has joined the channel.
Rachit_gaur (Wed, 01 Aug 2018 09:02:18 GMT):
Has joined the channel.
Rachit_gaur (Wed, 01 Aug 2018 09:04:36 GMT):
How to create a new user using fabri node sdk?
yoheiueda (Wed, 01 Aug 2018 09:51:09 GMT):
I have a question about CHAINCODE_VERSION_CONFLICT. https://github.com/hyperledger/fabric/blob/v1.2.0/core/committer/txvalidator/validator.go#L490
If I correctly understand the source code, the validation process invalidates all transactions of a chaincode in a block that contains an upgrade transaction for it. I think invalidating transactions AFTER the upgrade transaction is enough. Is there any reason to invalidate transactions BEFORE the upgrade transaction?
Unni_1994 (Thu, 02 Aug 2018 14:00:45 GMT):
Hi All, While invoking a chaincode function I am getting this error *2018-08-02 13:51:50.908 UTC [vscc] Invoke -> WARN 723 Endorsement policy failure for transaction txid=f8a20d4e828130170e6dd2bef79a0b24e6417c318f944ad73e75abf304f4379c, err: signature set did not satisfy policy*
2018-08-02 13:51:50.908 UTC [shim] func1 -> DEBU 724 [57812fce]Transaction completed. Sending COMPLETED
2018-08-02 13:51:50.908 UTC [shim] func1 -> DEBU 725 [57812fce]Move state message COMPLETED
2018-08-02 13:51:50.908 UTC [shim] handleMessage -> DEBU 726 [57812fce]Handling ChaincodeMessage of type: COMPLETED(state:ready)
2018-08-02 13:51:50.908 UTC [shim] func1 -> DEBU 727 [57812fce]send state message COMPLETED
2018-08-02 13:51:50.908 UTC [chaincode] processStream -> DEBU 728 [57812fce]Received message COMPLETED from shim
2018-08-02 13:51:50.908 UTC [chaincode] handleMessage -> DEBU 729 [57812fce]Fabric side Handling ChaincodeMessage of type: COMPLETED in state ready
2018-08-02 13:51:50.908 UTC [chaincode] handleMessage -> DEBU 72a [57812fce-1a63-4925-a4de-87cc1b9456eb]HandleMessage- COMPLETED. Notify
2018-08-02 13:51:50.908 UTC [chaincode] notify -> DEBU 72b notifying Txid:57812fce-1a63-4925-a4de-87cc1b9456eb, channelID:mychannel
2018-08-02 13:51:50.908 UTC [chaincode] Execute -> DEBU 72c Exit
2018-08-02 13:51:50.909 UTC [lockbasedtxmgr] Done -> DEBU 72d Done with transaction simulation / query execution [f8a20d4e828130170e6dd2bef79a0b24e6417c318f944ad73e75abf304f4379c]
2018-08-02 13:51:50.909 UTC [committer/txvalidator] VSCCValidateTxForCC -> DEBU 72e VSCCValidateTxForCC completes for envbytes 0xc421746000
2018-08-02 13:51:50.909 UTC [committer/txvalidator] VSCCValidateTx -> DEBU 72f VSCCValidateTx completes for env 0xc421a56000 envbytes 0xc421746000
2018-08-02 13:51:50.909 UTC [committer/txvalidator] validateTx -> ERRO 730 VSCCValidateTx for transaction txId = f8a20d4e828130170e6dd2bef79a0b24e6417c318f944ad73e75abf304f4379c returned error: VSCC error: endorsement policy failure, err: signature set did not satisfy policy
2018-08-02 13:51:50.909 UTC [committer/txvalidator] validateTx -> DEBU 731 validateTx completes for block 0xc421b0d3a0 env 0xc421a56000 txn 0
2018-08-02 13:51:50.909 UTC [committer/txvalidator] Validate -> DEBU 732 got result for idx 0, code 10
2018-08-02 13:51:50.909 UTC [committer/txvalidator] Validate -> DEBU 733 END Block Validation
2018-08-02 13:51:50.909 UTC [kvledger] CommitWithPvtData -> DEBU 734 Channel [mychannel]: Validating state for block [3]
2018-08-02 13:51:50.910 UTC [lockbasedtxmgr] ValidateAndPrepare -> DEBU 735 Validating new block with num trans = [1]
2018-08-02 13:51:50.910 UTC [valimpl] ValidateAndPrepareBatch -> DEBU 736 ValidateAndPrepareBatch() for block number = [3]
2018-08-02 13:51:50.910 UTC [valimpl] ValidateAndPrepareBatch -> DEBU 737 preprocessing ProtoBlock...
**2018-08-02 13:51:50.910 UTC [valimpl] preprocessProtoBlock -> WARN 738 Channel [mychannel]: Block [3] Transaction index [0] TxId [f8a20d4e828130170e6dd2bef79a0b24e6417c318f944ad73e75abf304f4379c] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE*]*
2018-08-02 13:51:50.910 UTC [valimpl] ValidateAndPrepareBatch -> DEBU 739 validating rwset...
2018-08-02 13:51:50.910 UTC [valimpl] ValidateAndPrepareBatch -> DEBU 73a postprocessing ProtoBlock...
2018-08-02 13:51:50.910 UTC [valimpl] ValidateAndPrepareBatch -> DEBU 73b ValidateAndPrepareBatch() complete
2018-08-02 13:51:50.910 UTC [kvledger] CommitWithPvtData -> DEBU 73c Channel [mychannel]: Committing block [3] to storage
Unni_1994 (Thu, 02 Aug 2018 14:01:55 GMT):
Endorsment policy
Unni_1994 (Thu, 02 Aug 2018 14:02:02 GMT):
*peer chaincode instantiate -o orderer0.example.com:7050 --tls true --cafile $ORDERER_CA -C mychannel -n mycc -l golang -v 1.0 -c '{"Args":["init","a","100"]}' -P "OR ('Org1MSP.peer','Org2MSP.peer')"*
pankajcheema (Fri, 03 Aug 2018 10:41:45 GMT):
Hi Experts
pankajcheema (Fri, 03 Aug 2018 10:41:46 GMT):
Is there any way to prevent commands like `peer channel create`, `peer channel join`, `peer chaincode install` and instantiate and so on using ACL?
vladyslavmunin (Fri, 03 Aug 2018 12:58:17 GMT):
Has joined the channel.
vladyslavmunin (Fri, 03 Aug 2018 13:06:52 GMT):
Hi guys , I'm not sure that I should ask question in this channel , but I do.
What I tried to implement 'client signing ' proposal functionality , I generated key pair and certificates at browser side , successfully enrolled user directly via ca and build the proposal , then signed this proposal in browser and sent back to the server.
Then I tried to send signed proposal via Node SDK to peer. but gor error '2Unknown access denied ;channel[mychannel] creator[org1]'
Does anyone face with this error before? ( Early I faced by it wrong mspID , but now I'm sure that it's correct)
vladyslavmunin (Fri, 03 Aug 2018 13:06:52 GMT):
Hi guys , I'm not sure that I should ask question in this channel , but I do.
I tried to implement 'client signing ' proposal functionality , I generated key pair and certificates at browser side , successfully enrolled user directly via ca and build the proposal , then signed this proposal in browser and sent back to the server.
Then I tried to send signed proposal via Node SDK to peer. but gor error '2Unknown access denied ;channel[mychannel] creator[org1]'
Does anyone face with this error before? ( Early I faced by it wrong mspID , but now I'm sure that it's correct)
zmaro (Fri, 03 Aug 2018 15:22:32 GMT):
Has joined the channel.
muralisr (Sat, 04 Aug 2018 17:54:53 GMT):
https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=nuGLNj2XKcQnaJ9QY
muralisr (Sat, 04 Aug 2018 17:55:41 GMT):
@pankajcheema trying to understand the question...can you elaborate/clarify ? Which "ACL" are you referring to ? How do you mean `prevent commands..`
muralisr (Sat, 04 Aug 2018 18:08:12 GMT):
@vladyslavmunin `... build the proposal , then signed this proposal in browser and sent back to the server...` - so the browser is seing a signed protobuf proposal to the SDK which just sends it of as-is to the peer ?
muralisr (Sat, 04 Aug 2018 18:08:12 GMT):
@vladyslavmunin `... build the proposal , then signed this proposal in browser and sent back to the server...` - so the browser is sending a signed protobuf proposal to the SDK which just sends it of as-is to the peer ? if that is correct, I'd make sure your signing identity is correct (right MSPID and crypto)
muralisr (Sat, 04 Aug 2018 18:10:56 GMT):
also would make sure the node SDK is not doing additional proposal construction on top of what you are sending
pankajcheema (Sat, 04 Aug 2018 19:13:26 GMT):
@muralisr I was saying I want an organization to prevent from installing chaincode. Is it possible usinh ACL?
pankajcheema (Sat, 04 Aug 2018 19:13:57 GMT):
The org1 should not be able to use 'peer Chaincode install'
pankajcheema (Sat, 04 Aug 2018 19:14:01 GMT):
Command
dave.enyeart (Sat, 04 Aug 2018 21:08:31 GMT):
@pankajcheema Each peer's admin must install chaincode to the peer. Only the peer's admin (as defined by the peer's local MSP) has privilege to install chaincode on the peer. Then somebody meeting the chaincode instantiation policy (as specified within the chaincode package) may instantiate the chaincode on a channel to enable it on the channel. Neither of these privileges are defined in the channel's ACL. I'll point you to http://hyperledger-fabric.readthedocs.io/en/latest/chaincode4noah.html for more details on the chaincode lifecycle and permissions.
dave.enyeart (Sat, 04 Aug 2018 21:09:55 GMT):
I've created a Jira https://jira.hyperledger.org/browse/FAB-11461 to make this more clear in the docs.
pankajcheema (Sun, 05 Aug 2018 07:13:03 GMT):
@dave.enyeart so this means that its not possible to limit these functionality using ACL
adarshsaraf123 (Sun, 05 Aug 2018 07:52:30 GMT):
Has joined the channel.
dave.enyeart (Sun, 05 Aug 2018 12:18:54 GMT):
right - the functionality is restricted based on other policies, not through the ACL
bh4rtp (Sun, 05 Aug 2018 12:36:16 GMT):
the policy is so complicated, is there a tutorial?
muralisr (Sun, 05 Aug 2018 14:56:36 GMT):
@pankajcheema adding to @dave.enyeart .. resource based ACL applies to channel specific activities. Install is across channels
pankajcheema (Sun, 05 Aug 2018 15:46:01 GMT):
@dave.enyeart @muralisr how to add such policy?
pankajcheema (Sun, 05 Aug 2018 15:46:46 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=qkKeL6ssC9tnCkZC9) correct!! The official tutorial does not helped me. Just Hit & Trial helped me
muralisr (Sun, 05 Aug 2018 15:50:22 GMT):
@pankajcheema which tutorial are you referring to ... wanted to make sure we are talking about the same thing
pankajcheema (Sun, 05 Aug 2018 15:50:49 GMT):
wait
pankajcheema (Sun, 05 Aug 2018 15:51:16 GMT):
this one http://hyperledger-fabric.readthedocs.io/en/latest/access_control.html
pankajcheema (Sun, 05 Aug 2018 15:52:37 GMT):
@muralisr Is there any way to specify such rule that a particular org can only install and instantiate the chaincode on network?
muralisr (Sun, 05 Aug 2018 15:57:00 GMT):
install is outside the scope of these resource based policies as they are not channel specific (as mentioned earlier)
pankajcheema (Sun, 05 Aug 2018 15:59:57 GMT):
ok
muralisr (Sun, 05 Aug 2018 16:01:59 GMT):
as for instantiate, it is channel specific, and can be controlled via "peer/Propose" resource. However it'll affect all proposals to the channel (not just the instantiate Proposal)
DivyaAgrawal (Mon, 06 Aug 2018 08:26:19 GMT):
Hi All, Can anyone shed some light on how do we change the endorsing peers in a network. I am using caliper and the endorsing peers seems to be fix. What i have understood from surfing the net so far is we need to change the profile in the configtx.yaml so that the chaincode is instantiated accordingly. But am not finding any documentation on that. If anyone has already done that or knows how to do it . It will be a great help. Thanks in advance.
gravity (Mon, 06 Aug 2018 08:42:21 GMT):
Has left the channel.
asaningmaxchain123 (Mon, 06 Aug 2018 12:59:23 GMT):
@dave.enyeart can you tell me what's the relationship transaction and txrwset?
asaningmaxchain123 (Mon, 06 Aug 2018 12:59:37 GMT):
one transaction has multiple txrwset
dave.enyeart (Mon, 06 Aug 2018 13:02:20 GMT):
Each transaction has one txrwset. txrwset can have multiple chaincode (namespace) read-write sets. See example at http://hyperledger-fabric.readthedocs.io/en/latest/readwrite.html
dave.enyeart (Mon, 06 Aug 2018 13:02:20 GMT):
Each transaction has one txrwset. txrwset can have multiple chaincode (namespace) read-write sets (in the case of chaincode calling chaincode). See example at http://hyperledger-fabric.readthedocs.io/en/latest/readwrite.html
asaningmaxchain123 (Mon, 06 Aug 2018 13:08:00 GMT):
so when the peer commit block, it write the twset into the blockfile?
vladyslavmunin (Mon, 06 Aug 2018 15:21:08 GMT):
@muralisr Signing identity was correct (MSPID and crypto) , I generated key and x509 on the browser side.Problem was in different digest result in client and browser side (maybe specific implementation of sha256..) but I found correct one, and all works great!
vladyslavmunin (Mon, 06 Aug 2018 15:21:08 GMT):
@muralisr Signing identity was correct (MSPID and crypto) , I generated key and x509 on the browser side.Problem was in different digest result on server and browser side (maybe specific implementation of sha256..) but I found correct one, and all works great!
rahulhegde (Tue, 07 Aug 2018 13:15:12 GMT):
hello @dave.enyeart. what is the right way to verify if chaincode in instantiated on the channel (for v1.0.x and v1.2.x)
1. using peer CLI approach to verify if the chaincode is instantiated on the channel
2. using couch database information - is it by checking if lscc
rahulhegde (Tue, 07 Aug 2018 13:15:12 GMT):
hello @dave.enyeart. what is the right way to verify if chaincode in instantiated on the channel (for v1.0.x and v1.2.x)
1. using peer CLI approach
2. using couch database information - is it by checking if lscc
dave.enyeart (Tue, 07 Aug 2018 14:28:44 GMT):
http://hyperledger-fabric.readthedocs.io/en/latest/commands/peerchaincode.html#peer-chaincode-list
dave.enyeart (Tue, 07 Aug 2018 14:28:44 GMT):
Use the CLI command, yes it will provide the chaincodes/versions instantiated on the channel: http://hyperledger-fabric.readthedocs.io/en/latest/commands/peerchaincode.html#peer-chaincode-list
vudathasaiomkar (Wed, 08 Aug 2018 12:31:05 GMT):
Has joined the channel.
asaningmaxchain123 (Wed, 08 Aug 2018 15:08:39 GMT):
@dave.enyeart when i use the couchdb as the world state db,and then i write a bad query statement,the cc is down?
asaningmaxchain123 (Wed, 08 Aug 2018 15:09:24 GMT):
so i think the fabric world should check it
r808silva (Wed, 08 Aug 2018 15:29:25 GMT):
Has joined the channel.
dave.enyeart (Wed, 08 Aug 2018 18:06:34 GMT):
@asaningmaxchain123 it's up to the chaincode developer to test their query statements
asaningmaxchain123 (Thu, 09 Aug 2018 15:13:33 GMT):
@jyellick if i want to modify the /Channel/OrdererAddress and add an Org at a time,can you tell me how to sign it?
asaningmaxchain123 (Thu, 09 Aug 2018 15:14:05 GMT):
if you can provide example for me,i am very greatly appreciated
HellBoy_23 (Thu, 09 Aug 2018 18:07:32 GMT):
Has joined the channel.
ChunTung (Fri, 10 Aug 2018 09:24:23 GMT):
Has joined the channel.
sheetal-hlf (Fri, 10 Aug 2018 10:40:09 GMT):
Has joined the channel.
mastersingh24 (Sat, 11 Aug 2018 12:47:02 GMT):
@asaningmaxchain123 - have you looked at http://hyperledger-fabric.readthedocs.io/en/release-1.2/channel_update_tutorial.html ?
gmb 2 (Sun, 12 Aug 2018 04:41:06 GMT):
Has joined the channel.
asaningmaxchain123 (Sun, 12 Aug 2018 08:12:14 GMT):
@mastersingh24 i have seen, can you tell me how to modify the multiple properties `at a time`
asaningmaxchain123 (Sun, 12 Aug 2018 08:13:20 GMT):
like if i want to modify the `/Channel/OrdererAddress` and addd an `Org` it needs different `admin` to sign it, so how to do it
asaningmaxchain123 (Sun, 12 Aug 2018 08:14:32 GMT):
i have seen the examples location at `https://github.com/hyperledger/fabric/tree/release-1.2/examples/configtxupdate`
asaningmaxchain123 (Sun, 12 Aug 2018 10:57:07 GMT):
@mastersingh24 i got it
asaningmaxchain123 (Sun, 12 Aug 2018 10:57:07 GMT):
@mastersingh24 i got it,can you tell me how to decide the signature orderer?
vdods (Sun, 12 Aug 2018 22:28:26 GMT):
Hi all, I've got a question regarding private collections -- say there are 3 orgs: org1, org2, and org3, and there's a private collection defined that includes all of them. Now say a transaction proposal which contains private data meant to end up in the private collection is sent only to org1 and org2, is endorsed, ordered, and is committed. Does org3 automatically receive the private data from org1 and/or org2's peers? Or does org3 never end up with the private data because it didn't have a peer that endorsed that transaction proposal?
yacovm (Sun, 12 Aug 2018 22:35:35 GMT):
in v1.2 it fetches the data upon commit
yacovm (Sun, 12 Aug 2018 22:35:35 GMT):
in v1.2 it fetches the data upon commit from some peer that should have it.
yacovm (Sun, 12 Aug 2018 22:35:50 GMT):
well, actually also in v1.1
yacovm (Sun, 12 Aug 2018 22:36:18 GMT):
it might, however - fail to fetch if it can't connect to any peer for a long time
yacovm (Sun, 12 Aug 2018 22:36:36 GMT):
in v1.3 it will re-sync the missing data even if it skipped it in the past, @vdods
dave.enyeart (Sun, 12 Aug 2018 22:49:21 GMT):
note that it is documented in more detail here: http://hyperledger-fabric.readthedocs.io/en/latest/private-data/private-data.html#transaction-flow-with-private-data
vdods (Sun, 12 Aug 2018 23:26:51 GMT):
So to state more concisely, the orgs defined in the "policy" of the private collection are exactly the orgs whose peers will replicate that private data?
vdods (Sun, 12 Aug 2018 23:26:51 GMT):
So to state more concisely, the orgs defined in the "policy" of the private collection are exactly the orgs whose peers will replicate that private data?
yacovm (Sun, 12 Aug 2018 23:30:45 GMT):
yes
pankaj9310 (Mon, 13 Aug 2018 14:43:57 GMT):
Has joined the channel.
thiyagucse01 (Tue, 14 Aug 2018 09:10:02 GMT):
Hi , I started learning hyperledger-fabric for creating my own business application but, I still have a question
In practice, there is only one machine with docker and whole bna, or every member must have his own docker with bna?
If only one, then it turns out to be a centralized application. Am I right?
HellBoy_23 (Thu, 16 Aug 2018 12:20:04 GMT):
Hi all, I am getting this error : Promise is rejected: Error: GET_STATE_BY_RANGE failed: transaction ID: ee097a157bb5db4b8551aaa071477c11053c5eb7c1b8631a07358f4ccb0cc0d2: Tx [ee097a157bb5db4b8551aaa071477c11053c5eb7c1b8631a07358f4ccb0cc0d2]: Queries on pvt data is supported only in a read-only transaction
Tony (Thu, 16 Aug 2018 12:39:17 GMT):
Has joined the channel.
pankajcheema (Fri, 17 Aug 2018 09:36:05 GMT):
Any idea how to set Gossip log to INFO for a peer in Docker
pankajcheema (Fri, 17 Aug 2018 09:36:30 GMT):
@yacovm @dave.enyeart @jyellick
dave.enyeart (Fri, 17 Aug 2018 11:39:24 GMT):
CORE_LOGGING_GOSSIP=INFO
asaningmaxchain123 (Fri, 17 Aug 2018 13:32:05 GMT):
@dave.enyeart in the peer it use the `leveldb` to store the data, so the index can work with it?
dave.enyeart (Fri, 17 Aug 2018 14:27:33 GMT):
leveldb is key/value store. the value is bytes only. the database doesn't know about the value bytes content therefore index is not applicable for leveldb content. leveldb has implicit internal index for the key, which enables efficient key and key range queries out of the box. if you want to query value content, you'll need to use couchdb with json content.
asaningmaxchain123 (Fri, 17 Aug 2018 16:25:01 GMT):
@dave.enyeart my question is in the fabric source code it use the `leveldb` to store the data, and could provide index file to index it? in my mind, the index file is only used for the `couchdb`
asaningmaxchain123 (Fri, 17 Aug 2018 16:25:01 GMT):
@dave.enyeart my question is in the fabric source code it use the `leveldb` to store the private data, and could provide index file to index it? in my mind, the index file is only used for the `couchdb`
asaningmaxchain123 (Fri, 17 Aug 2018 16:25:01 GMT):
@dave.enyeart my question is in the fabric source code it use the `leveldb` to store the private data, but could provide index file to index it? in my mind, the index file is only used for the `couchdb`
dave.enyeart (Fri, 17 Aug 2018 18:42:41 GMT):
@asaningmaxchain123 there are different types of indexes. fabric has some implicit indexes implemented in leveldb in the source code for keeping track of block data. do not confuse these indexes with the chaincode indexes for couchdb that enable chaincode couchdb rich queries. both public state data and private state database can be stored in couchdb, for query from chaincode.
dave.enyeart (Fri, 17 Aug 2018 18:42:41 GMT):
@asaningmaxchain123 there are different types of indexes. fabric has some internal indexes implemented in leveldb in the source code for keeping track of block data. do not confuse these indexes with the chaincode indexes for couchdb that enable chaincode couchdb rich queries. both public state data and private state database can be stored in couchdb, for query from chaincode.
dave.enyeart (Fri, 17 Aug 2018 18:42:41 GMT):
@asaningmaxchain123 there are different types of indexes. fabric has some internal indexes implemented in leveldb in the source code for keeping track of block data. do not confuse these indexes with the chaincode indexes for couchdb that enable chaincode couchdb rich queries. both public state data and private state data can be stored in couchdb, for query from chaincode.
vdods (Sat, 18 Aug 2018 00:10:59 GMT):
Hi all, I've read a bit about how when a key/value pair is stored in the private ledger, Fabric automatically (?) also computes and stores the hash of the private value so that it can be verified later. Is there documentation somewhere that elaborates on this? I'm asking because I need to know how to 1) determine if the existing hash scheme is sufficient for what I want to do, and if so 2) access those hash values
dave.enyeart (Sat, 18 Aug 2018 02:49:02 GMT):
Private data docs:
dave.enyeart (Sat, 18 Aug 2018 02:49:04 GMT):
https://hyperledger-fabric.readthedocs.io/en/latest/private-data/private-data.html
dave.enyeart (Sat, 18 Aug 2018 02:49:16 GMT):
https://hyperledger-fabric.readthedocs.io/en/latest/private-data-arch.html
dave.enyeart (Sat, 18 Aug 2018 02:49:45 GMT):
The hashes will be in the public writeset, which can be obtained by querying for the transaction by id
dave.enyeart (Sat, 18 Aug 2018 02:51:45 GMT):
You'll find in there a SHA-256 hash of the private key and the private value
larry618 (Sun, 19 Aug 2018 07:44:13 GMT):
Has joined the channel.
vdods (Sun, 19 Aug 2018 21:05:12 GMT):
Thanks!
vdods (Sun, 19 Aug 2018 21:13:57 GMT):
A further question on the implementation -- is it the plain hash of the document data, or is there a nonce prepended to the document data before computing the hash? While not an easy vulnerability to exploit, if there is no nonce used in computing the hash, then someone could [spend a lot of resources] pre-computing a hash collision (e.g. two legal contracts -- one that the two contract-negotiators agree to, and one modified to the attacker's advantage), and then submit the forged document to private storage (that in the legal contract example would be unsealed for review by a judge in a legal dispute).
yacovm (Sun, 19 Aug 2018 21:23:14 GMT):
@vdods it's the hash of the key, and the hash of the value.
you're right about the weakness - if the key and value come from a low entropy distribution, you can do an exhaustive search over the space of the keys/values and guess.
however - nothing prevents you from adding your own custom salt (random padding) to the key and value.
yacovm (Sun, 19 Aug 2018 21:23:14 GMT):
@vdods it's the hash of the key, and the hash of the value.
regarding the weakness - if the key and value come from a low entropy distribution, you can do an exhaustive search over the space of the keys/values and guess.
however - nothing prevents you from adding your own custom salt (random padding) to the key and value.
yacovm (Sun, 19 Aug 2018 21:27:27 GMT):
> if there is no nonce used in computing the hash, then someone could [spend a lot of resources] pre-computing a hash collision (e.g. two legal contracts -- one that the two contract-negotiators agree to, and one modified to the attacker's advantage), and then submit the forged document to private storage (that in the legal contract example would be unsealed for review by a judge in a legal dispute).
that's not a hash collision, that's a "pre-image attack". Specifically "second preimage attack". A collision, is to find *any* 2 values that map to the same hash.
yacovm (Sun, 19 Aug 2018 21:29:18 GMT):
If the hash function is secure then doing a pre-image attack is not feasible
vdods (Mon, 20 Aug 2018 20:52:38 GMT):
@yacovm Thanks! Right -- I mixed up the terminology.
bh4rtp (Tue, 21 Aug 2018 00:37:44 GMT):
@dave.enyeart with CORE_LOGGING_GOSSIP=INFO set, must i disable CORE_LOGGING_LEVEL=DEBUG?
bdjidi (Tue, 21 Aug 2018 22:48:36 GMT):
Has joined the channel.
Ryan2 (Wed, 22 Aug 2018 08:16:47 GMT):
hi, I faced the issue while installing chaincode on the peer like below
`Error: Error endorsing chaincode: rpc error: code = Unavailable desc = transport: write tcp 173.32.1.142:33766->173.32.1.142:7051: write: broken pipe`
peer-log:
`2018-08-22 08:13:45.589 UTC [grpc] Printf -> DEBU 95a grpc: Server.Serve failed to complete security handshake from "173.32.1.142:33766": tls: first record does not look like a TLS handshake
`
In run the peer in TLS enabled mode, start peer successfully.
how can I fix this problem,
Thanks
Ryan2 (Wed, 22 Aug 2018 08:16:47 GMT):
hi, I faced the issue while installing chaincode on the peer like below
`Error: Error endorsing chaincode: rpc error: code = Unavailable desc = transport: write tcp 173.32.1.142:33766->173.32.1.142:7051: write: broken pipe`
peer-log:
`2018-08-22 08:13:45.589 UTC [grpc] Printf -> DEBU 95a grpc: Server.Serve failed to complete security handshake from "173.32.1.142:33766": tls: first record does not look like a TLS handshake`
In run the peer in TLS enabled mode, start peer successfully.
how can I fix this problem,
Thanks
Ryan2 (Wed, 22 Aug 2018 08:16:47 GMT):
hi, I faced the issue while installing chaincode on the peer like below (running peer cli command )
`Error: Error endorsing chaincode: rpc error: code = Unavailable desc = transport: write tcp 173.32.1.142:33766->173.32.1.142:7051: write: broken pipe`
peer-log:
`2018-08-22 08:13:45.589 UTC [grpc] Printf -> DEBU 95a grpc: Server.Serve failed to complete security handshake from "173.32.1.142:33766": tls: first record does not look like a TLS handshake`
In run the peer in TLS enabled mode, start peer successfully.
(I'm using peer v1.1.1)
how can I fix this problem,
Thanks
rahulhegde (Wed, 22 Aug 2018 13:48:57 GMT):
hello @dave.enyeart @mastersingh24
In fabric-v1.0.6, we see there are connection refused message on the event hub port for the HFC. Is there a limitation on the number of event hub connection that is allowed or configured per peer?
Ryan2 (Thu, 23 Aug 2018 01:53:33 GMT):
I cannot install Chaincode on binary peer which is running with TLS enabled
`2018-08-23 01:50:09.739 UTC [grpc] Printf -> DEBU a12 grpc: Server.Serve failed to complete security handshake from "127.0.0.1:58330": tls: first record does not look like a TLS handshake`
Can someone help.
script start peer (https://hastebin.com/efutuvicog.makefile)
cmd install CC: `peer chaincode install -n SMS_CC_001 -v t1 -p github.com/hyperledger/MY_CC_001 --tls --cafile /home/ubuntu/conf/crypto-config/ordererOrganizations/ordererorg0/orderers/orderer.ordererorg0/msp/tlscacerts/tlsca.ordererorg0-cert.pem`
Ryan2 (Thu, 23 Aug 2018 01:53:33 GMT):
I cannot install Chaincode on binary peer which is running with TLS enabled
`2018-08-23 01:50:09.739 UTC [grpc] Printf -> DEBU a12 grpc: Server.Serve failed to complete security handshake from "127.0.0.1:58330": tls: first record does not look like a TLS handshake`
Can someone help.
script start peer (https://hastebin.com/efutuvicog.makefile)
cmd install CC: `peer chaincode install -n MY_CC_001 -v t1 -p github.com/hyperledger/MY_CC_001 --tls --cafile /home/ubuntu/conf/crypto-config/ordererOrganizations/ordererorg0/orderers/orderer.ordererorg0/msp/tlscacerts/tlsca.ordererorg0-cert.pem`
Ryan2 (Thu, 23 Aug 2018 01:53:33 GMT):
I cannot install Chaincode on binary peer which is running with TLS enabled
`2018-08-23 01:50:09.739 UTC [grpc] Printf -> DEBU a12 grpc: Server.Serve failed to complete security handshake from "127.0.0.1:58330": tls: first record does not look like a TLS handshake`
Can someone help.
script start peer (https://hastebin.com/efutuvicog.makefile)
cmd install CC: `peer chaincode install -n MY_CC_001 -v t1 -p github.com/hyperledger/MY_CC_001 --tls --cafile /home/ubuntu/conf/crypto-config/ordererOrganizations/ordererorg0/orderers/orderer.ordererorg0/msp/tlscacerts/tlsca.ordererorg0-cert.pem`
thrown error `Error: Error endorsing chaincode: rpc error: code = Unavailable desc = transport: write tcp 127.0.0.1:58318->127.0.0.1:7051: write: broken pipe`
thiyagucse01 (Thu, 23 Aug 2018 07:31:00 GMT):
Hi , am beginner for hyperledger and I little bit understand the hyperledger keyconcepts, So anyone suggest me to How to create multiple peers , channels , multiple organisation and MSP , Can anyone suggest a tutorial for same ?
markthedark (Thu, 23 Aug 2018 12:59:18 GMT):
Hello, is there a limit as to how big the outgoing transaction can be?
I'm trying to modify my chaincode to accept an array of JSON objects, instead of just one, but the transaction proposal fails with the following error on the peer:
`2018-08-23 12:43:12.992 UTC [chaincode] processStream -> ERRO 0b6 Error handling chaincode support stream: rpc error: code = Canceled desc = context canceled
Rachit_gaur (Fri, 24 Aug 2018 11:03:37 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=mPykoThM3NmmtjZE9) @thiyagucse01 refer to the official documentation
Rachit_gaur (Fri, 24 Aug 2018 11:05:25 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=WTviFaHDKh3MSo5Hw) @markthedark You can increase the message size by changing the orderer settings from configtx.yaml
Ryan2 (Fri, 24 Aug 2018 12:30:21 GMT):
hi @Rachit_gaur could you help on my issue https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=H2Xj36r8KL7oBepzd
Rachit_gaur (Fri, 24 Aug 2018 12:55:16 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=q3dSPbSpuMijDLLG6) @Ryan2 This error generally occurs when hostname in the TLS cert used by membership services is not matching the hostname you are using to connect to membersrvcs
set the peer.pki.tls.serverhostoverride property to the value of the common name used in the cert you are using in membersvcs (in membersrvc.yaml - server.tls.certfile)
Rachit_gaur (Mon, 27 Aug 2018 05:26:25 GMT):
I am running the Marbles_private example provided by hyperledger to get my hands on with the private db concept, i have anchor peer0 of both orgs joined to a channel and if i execute query from peer1 it results into endorsement failure
Later i added peer1 as well to the channel and then the query works fine...
Does that mean i have to add all the peers to the channel or just the anchor peers? did i miss something? the gossip protocol was enabled to be dynamic when i faced this issue
qiangjiyi (Tue, 28 Aug 2018 02:12:38 GMT):
Has joined the channel.
Rachit_gaur (Tue, 28 Aug 2018 06:23:35 GMT):
I want to save my key values dynamically from my JSON response , Is there a way to do so?
AshishMishra 1 (Tue, 28 Aug 2018 07:17:19 GMT):
Hi guys, I 'm using fabric 1.2 and using node SDK to communicate with the Fabric n/w. Off late I 'm getting lot of event hub closed error and unless I restart the peer nodes, I can't invoke any transaction on the channel.
gravity (Tue, 28 Aug 2018 10:41:49 GMT):
Has joined the channel.
gravity (Tue, 28 Aug 2018 10:44:14 GMT):
hello
After the network upgrade to a v1.2.0, docker-compose is spamming logs with gossip messages like this:
https://ctrlv.it/text/145064/1363749086
is it possible to turn off these logs without decreasing overall debug level from debug to info?
pankajcheema (Tue, 28 Aug 2018 11:12:22 GMT):
Hi Experts
pankajcheema (Tue, 28 Aug 2018 11:12:48 GMT):
My orderer port is changed from 7050 to 30001. But peer keeps throwing an error and warning ```2018-08-28 11:08:14.142 UTC [deliveryClient] connect -> ERRO 036 Failed obtaining connection: Could not connect to any of the endpoints: [orderer0.orderer.com:7050]
2018-08-28 11:08:14.143 UTC [deliveryClient] try -> WARN 037 Got error: Could not connect to any of the endpoints: [orderer0.orderer.com:7050] , at 5 attempt. Retrying in 16s```
pankajcheema (Tue, 28 Aug 2018 11:13:04 GMT):
Anyone knows from where I can mention in peer to use updated port
pankajcheema (Tue, 28 Aug 2018 11:13:05 GMT):
?
Rachit_gaur (Wed, 29 Aug 2018 05:08:51 GMT):
Hi guys,
Is there some parameter to change just the display name of the organizations org1 and org2 instead of changing every occurrence of them?
Regards
albert.lacambra (Thu, 30 Aug 2018 18:21:32 GMT):
Hi people
albert.lacambra (Thu, 30 Aug 2018 18:21:58 GMT):
can someone tell me what needs to be done to satisfy a policy like {"role": {"name": "admin", "mspId": "lacambraMSP"}}
albert.lacambra (Thu, 30 Aug 2018 18:22:10 GMT):
when using "member" works fine
albert.lacambra (Thu, 30 Aug 2018 18:22:37 GMT):
but with admin I have an ENDORSEMENT_POLICY_FAILURE
albert.lacambra (Thu, 30 Aug 2018 18:23:14 GMT):
question 1 is who is the admin: a user or a peer itself
albert.lacambra (Thu, 30 Aug 2018 18:23:33 GMT):
question 2: in case of peer how do I indicate that a peer is acting as an admin
albert.lacambra (Thu, 30 Aug 2018 18:24:07 GMT):
in config.yaml file I am already indicating "AdminPrincipal: Role.ADMIN"
Rachit_gaur (Fri, 31 Aug 2018 06:55:18 GMT):
I'd like to backtrace from my latest transaction such that i can get all the status of previous transaction, How can i do this?
Rachit_gaur (Fri, 31 Aug 2018 10:42:51 GMT):
block is created after every transaction even when the orderer settings are modified to support more size and timeouts
Can someone help me with this?
jrosmith (Fri, 31 Aug 2018 17:57:14 GMT):
@Rachit_gaur are you asking about finding the history for a certain transaction? as for you second question please post links to your configuration changes
Rachit_gaur (Mon, 03 Sep 2018 05:07:18 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=GgKzHixjv4ctSqbwW) @jrosmith when i invoke something on a chaincode a transaction id is returned in response...What i would like to do is to use that transaction id and get the previous states or previous transaction id's ..such as if a sends 100 to b and later b sends 50 to a ..i want to trace back the initial balance of both of them using my last id
Rachit_gaur (Mon, 03 Sep 2018 05:09:32 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=GgKzHixjv4ctSqbwW) @jrosmith These are my orderer settings..only one transaction is making a block
BatchTimeout: 50s
BatchSize:
MaxMessageCount: 200
AbsoluteMaxBytes: 120
PreferredMaxBytes: 40 MB
IgorSim (Mon, 03 Sep 2018 09:22:01 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=WbDtjA538G4EF3JHX) @gravity Did you figure this out how it can be done? Is it possible at all?
gravity (Mon, 03 Sep 2018 09:49:03 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=EPa9apvrEXMJqwtyN) @IgorSim no, I didn't.
switched to INFO level atm
Rachit_gaur (Tue, 04 Sep 2018 10:26:43 GMT):
I have a scenario where i am calling stub GetHistoryForKey from another chaincode using stub.InvokeChaincode() but it returns value only when on same channel else empty response is returned without error..can someone help??
jrosmith (Tue, 04 Sep 2018 13:05:11 GMT):
@Rachit_gaur i responded to you backtrace question in #fabric-chaincode-dev
at what rate are you submitting transactions and how large are they? based on the settings you have posted either one transaction is committed every 50s or the transaction payload is so large that it exceeds the absolute max bytes of 120
MikeEmery (Tue, 04 Sep 2018 16:05:10 GMT):
Has joined the channel.
MikeEmery (Tue, 04 Sep 2018 16:07:46 GMT):
Hey - From a question over on #fabric-orderer - is it still not possible to have a peer leave a channel? Willing to take any reasonable manual steps to make that happen
iramiller (Tue, 04 Sep 2018 20:09:14 GMT):
Has joined the channel.
iramiller (Tue, 04 Sep 2018 20:10:25 GMT):
Question from #fabric-chaincode-dev ... Can anyone shed some light on the platform chaincode build process design methodology? The concept of performing a build in a container in a production environment then using the results to tag an image for chaincode invocation by peers seems far more complex and error prone, not to mention less secure than using a seperate dedicated build environment to create strongly versioned container releases for chaincode...
yacovm (Tue, 04 Sep 2018 20:11:40 GMT):
I can see why it's error prone
yacovm (Tue, 04 Sep 2018 20:11:44 GMT):
but why is it less secure?
yacovm (Tue, 04 Sep 2018 20:12:06 GMT):
if the docker daemon is secure... and the build is secure because you only build code you sanitized
yacovm (Tue, 04 Sep 2018 20:12:13 GMT):
what is the concern?
iramiller (Tue, 04 Sep 2018 20:12:21 GMT):
Using Docker.sock at all requires a privledged container... while this isn’t the only use it is one of them...
yacovm (Tue, 04 Sep 2018 20:12:47 GMT):
so run your peer in a VM
iramiller (Tue, 04 Sep 2018 20:12:51 GMT):
Also running npm install pulls lots of code in
yacovm (Tue, 04 Sep 2018 20:12:59 GMT):
ah, you use node.js chaincode
yacovm (Tue, 04 Sep 2018 20:13:15 GMT):
there you go
iramiller (Tue, 04 Sep 2018 20:13:56 GMT):
But we could have a scanned container that is audited and verified independently before using in production...
yacovm (Tue, 04 Sep 2018 20:14:12 GMT):
so if you use golang chaincode then you only package stuff that you pre-scanned
iramiller (Tue, 04 Sep 2018 20:14:29 GMT):
That applies to go as well.. and running all out integration tests and shipping the exact same resulting binaries...
yacovm (Tue, 04 Sep 2018 20:14:30 GMT):
and it's compiled in a container which you have control over its image
yacovm (Tue, 04 Sep 2018 20:14:41 GMT):
no... golang doesn't download stuff from the internet at its build time
iramiller (Tue, 04 Sep 2018 20:15:04 GMT):
So you are saying the go build will be completely deterministic
yacovm (Tue, 04 Sep 2018 20:15:13 GMT):
no
yacovm (Tue, 04 Sep 2018 20:15:21 GMT):
i am saying the go build doesn't download anything from the internet
yacovm (Tue, 04 Sep 2018 20:15:30 GMT):
I don't know if the golang compiler doesn't toss coins
iramiller (Tue, 04 Sep 2018 20:16:02 GMT):
Ok... so backing up... why would we not want to specify a specific container image perhaps with hash when instantiating the chain code ?
yacovm (Tue, 04 Sep 2018 20:16:11 GMT):
you can do that can't you?
yacovm (Tue, 04 Sep 2018 20:16:20 GMT):
there is some property in `core.yaml`
iramiller (Tue, 04 Sep 2018 20:16:37 GMT):
Ah. Will dig more then.
iramiller (Tue, 04 Sep 2018 20:16:40 GMT):
Thanks
yacovm (Tue, 04 Sep 2018 20:17:01 GMT):
https://github.com/hyperledger/fabric/blob/release-1.2/sampleconfig/core.yaml#L529
yacovm (Tue, 04 Sep 2018 20:17:20 GMT):
and this is for runtime https://github.com/hyperledger/fabric/blob/release-1.2/sampleconfig/core.yaml#L538
iramiller (Tue, 04 Sep 2018 20:18:02 GMT):
What about the specific chaincode itself?
iramiller (Tue, 04 Sep 2018 20:18:12 GMT):
I’m aware of the runtime and build images
iramiller (Tue, 04 Sep 2018 20:18:50 GMT):
ie instead of a chaincode version number perhaps it would be a container version that is prebuilt?
yacovm (Tue, 04 Sep 2018 20:20:01 GMT):
you can't do that
yacovm (Tue, 04 Sep 2018 20:20:13 GMT):
there is a limit to which you can customize anything in life
yacovm (Tue, 04 Sep 2018 20:20:15 GMT):
:)
iramiller (Tue, 04 Sep 2018 20:20:17 GMT):
If that is not present then I would think it is a design choice and I would like to understand further before I continue patching that out as part of our work so we can run natively in kubernetes
yacovm (Tue, 04 Sep 2018 20:20:43 GMT):
most things aren't design choices as they are "lack of time"
iramiller (Tue, 04 Sep 2018 20:21:08 GMT):
Excellent. I understand that one very well
iramiller (Tue, 04 Sep 2018 20:21:31 GMT):
Thank you for your time.
am (Tue, 04 Sep 2018 21:03:28 GMT):
Has joined the channel.
Rachit_gaur (Wed, 05 Sep 2018 09:07:51 GMT):
Getting the following error when i use InvokeChaincode() function inside a chaincode to call another chaincode function which uses getHistoryForKey() built in function,Can someone explain the issue?
[ERROR]20180905 08:47:56,521 org.hyperledger.fabric.sdk.Channel.sendQueryProposalToPeers(Channel.java:2913) Sending proposal to buyer12peer1 failed because of: gRPC failure=Status{code=UNKNOWN, description=error executing chaincode: transaction returned with failure: Failed to get policy manager for channel [main], cause=null}
java.lang.Exception: io.grpc.StatusRuntimeException: UNKNOWN: error executing chaincode: transaction returned with failure: Failed to get policy manager for channel [main]
at org.hyperledger.fabric.sdk.Channel.sendQueryProposalToPeers(Channel.java:2913)
... 25 more
[ERROR]20180905 08:47:56,523 com.oracle.bcs.gateway.Gateway.query(Gateway.java:1213) Failed query proposal from peer buyer12peer1 status: FAILURE. Messages: Sending proposal to buyer12peer1 failed because of: gRPC failure=Status{code=UNKNOWN, description=error executing chaincode: transaction returned with failure: Failed to get policy manager for channel [main], cause=null}. Was verified : false.
[INFO ]20180905 08:47:56,553 com.oracle.bcs.gateway.Gateway.query(Gateway.java:1221) Success query proposal from peer buyer11peer1.
[INFO ]20180905 08:47:56,554 com.oracle.bcs.gateway.BcsClientRestAPI.query(BcsClientRestAPI.java:79) /v1/transaction/query from abhishek.dabas@sofbang.com:REQ: sellers/chaincode/v1/invokecc/[chaincode, main, getHistory, 1]/transientMap:null/ :REP:Success/com.oracle.bcs.gateway.ResultInfo@159e771d/null.
Rachit_gaur (Wed, 05 Sep 2018 09:07:51 GMT):
Getting the following error when i use InvokeChaincode() function inside a chaincode to call another chaincode function which uses getHistoryForKey() built in function,Can someone explain the issue?
[ERROR]20180905 08:47:56,521 org.hyperledger.fabric.sdk.Channel.sendQueryProposalToPeers(Channel.java:2913) Sending proposal to buyer12peer1 failed because of: gRPC failure=Status{code=UNKNOWN, description=error executing chaincode: transaction returned with failure: Failed to get policy manager for channel [main], cause=null}
java.lang.Exception: io.grpc.StatusRuntimeException: UNKNOWN: error executing chaincode: transaction returned with failure: Failed to get policy manager for channel [main]
at org.hyperledger.fabric.sdk.Channel.sendQueryProposalToPeers(Channel.java:2913)
... 25 more
[ERROR]20180905 08:47:56,523 com.oracle.bcs.gateway.Gateway.query(Gateway.java:1213) Failed query proposal from peer buyer12peer1 status: FAILURE. Messages: Sending proposal to buyer12peer1 failed because of: gRPC failure=Status{code=UNKNOWN, description=error executing chaincode: transaction returned with failure: Failed to get policy manager for channel [main], cause=null}. Was verified : false.
[INFO ]20180905 08:47:56,553 com.oracle.bcs.gateway.Gateway.query(Gateway.java:1221) Success query proposal from peer buyer11peer1.
[INFO ]20180905 08:47:56,554 com.oracle.bcs.gateway.BcsClientRestAPI.query(BcsClientRestAPI.java:79) /v1/transaction/query from admin:REQ: sellers/chaincode/v1/invokecc/[chaincode, main, getHistory, 1]/transientMap:null/ :REP:Success/com.oracle.bcs.gateway.ResultInfo@159e771d/null.
Rachit_gaur (Wed, 05 Sep 2018 11:00:43 GMT):
getHistoryForKey() function when called from InvokeChaincode() works fine if both chaincodes are on same channel but returns empty result iterator if chaincode is on different channels .Can someone help?
Also not the issue of cross channel calling as query function works fine in all scenarios
gravity (Thu, 06 Sep 2018 11:45:02 GMT):
Hi all
I'm trying to perform to `PutState` in a single call:
```
func ccFunc() {
putState_1()
putState_2()
}
func putState_1() {
...
stub.PutState(key, value)
}
func putState_2() {
...
stub.PutState(key, value)
}
```
in this case, putState_1 will not change the ledger state (assume all endorsements and validations are fine)
Is there anything I should take into account? Because such a behavior look weird
akshay.sood (Thu, 06 Sep 2018 16:51:52 GMT):
How many orderer org and peer org are allowes? In short what is the limit for orderer and peee org??
ArianStef (Thu, 06 Sep 2018 18:46:58 GMT):
Has joined the channel.
ArianStef (Thu, 06 Sep 2018 18:48:39 GMT):
Hi! I'm trying to add a peer in the sample fabcar, but when I do the query by CLI I have this error:
```
Error: endorsement failure during query. response: status:500 message:"cannot retrieve package for chaincode fabcar/1.0, error open /var/hyperledger/production/chaincodes/fabcar.1.0: no such file or directory"
```
ArianStef (Thu, 06 Sep 2018 18:50:39 GMT):
Hi team! I'm trying to add a new peer to sample fabcar but when I invoke the chaincode with the follow CLI: docker exec -e "CORE_PEER_LOCALMSPID=Org1MSP" -e "CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp" -e "CORE_PEER_ADDRESS=peer1.org1.example.com:7051" cli peer chaincode query -o orderer.example.com:7050 -C mychannel -n fabcar -c '{"function":"queryAllCars","Args":[""]}' I have the follow
ArianStef (Thu, 06 Sep 2018 18:52:17 GMT):
Hi team! I'm trying to add a new peer to sample fabcar but when I invoke the chaincode with the follow CLI: docker exec -e "CORE_PEER_LOCALMSPID=Org1MSP" -e "CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp" -e "CORE_PEER_ADDRESS=peer1.org1.example.com:7051" cli peer chaincode query -o orderer.example.com:7050 -C mychannel -n fabcar -c '{"function":"queryAllCars","Args":[""]}'
I have the follow error:
Error: endorsement failure during query. response: status:500 message:"cannot retrieve package for chaincode fabcar/1.0, error open /var/hyperledger/production/chaincodes/fabcar.1.0: no such file or directory"
In the docker-compose.yml file I had add:
eer1.org1.example.com:
container_name: peer1.org1.example.com
image: hyperledger/fabric-peer
environment:
- CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
- CORE_PEER_ID=peer1.org1.example.com
- CORE_LOGGING_PEER=info
- CORE_CHAINCODE_LOGGING_LEVEL=info
- CORE_PEER_LOCALMSPID=Org1MSP
- CORE_PEER_MSPCONFIGPATH=/etc/hyperledger/msp/peer
- CORE_PEER_ADDRESS=peer1.org1.example.com:7051
- CORE_PEER_GOSSIP_USELEADERELECTION=true
- CORE_PEER_GOSSIP_ORGLEADER=false
- CORE_PEER_PROFILE_ENABLED=true
- CORE_PEER_GOSSIP_BOOTSTRAP=peer0.org1.example.com:7051
- CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer1.org1.example.com:7051
# # the following setting starts chaincode containers on the same
# # bridge network as the peers
# # https://docs.docker.com/compose/networking/
- CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE=${COMPOSE_PROJECT_NAME}_basic
- CORE_LEDGER_STATE_STATEDATABASE=CouchDB
- CORE_LEDGER_STATE_COUCHDBCONFIG_COUCHDBADDRESS=couchdb:5984
# The CORE_LEDGER_STATE_COUCHDBCONFIG_USERNAME and CORE_LEDGER_STATE_COUCHDBCONFIG_PASSWORD
# provide the credentials for ledger to connect to CouchDB. The username and password must
# match the username and password set for the associated CouchDB.
- CORE_LEDGER_STATE_COUCHDBCONFIG_USERNAME=
- CORE_LEDGER_STATE_COUCHDBCONFIG_PASSWORD=
working_dir: /opt/gopath/src/github.com/hyperledger/fabric/peer
command: peer node start
# command: peer node start --peer-chaincodedev=true
ports:
- 8051:7051
- 8053:7053
volumes:
- /var/run/:/host/var/run/
- ./crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp:/etc/hyperledger/msp/peer
- ./crypto-config/peerOrganizations/org1.example.com/users:/etc/hyperledger/msp/users
- ./config:/etc/hyperledger/configtx
depends_on:
- orderer.example.com
- couchdb
ArianStef (Thu, 06 Sep 2018 18:52:54 GMT):
Hi team! I'm trying to add a new peer to sample fabcar but when I invoke the chaincode with the follow CLI: docker exec -e "CORE_PEER_LOCALMSPID=Org1MSP" -e "CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp" -e "CORE_PEER_ADDRESS=peer1.org1.example.com:7051" cli peer chaincode query -o orderer.example.com:7050 -C mychannel -n fabcar -c '{"function":"queryAllCars","Args":[""]}'
I have the follow error:
Error: endorsement failure during query. response: status:500 message:"cannot retrieve package for chaincode fabcar/1.0, error open /var/hyperledger/production/chaincodes/fabcar.1.0: no such file or directory"
In the docker-compose.yml file I had add:
peer1.org1.example.com:
container_name: peer1.org1.example.com
image: hyperledger/fabric-peer
environment:
- CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
- CORE_PEER_ID=peer1.org1.example.com
- CORE_LOGGING_PEER=info
- CORE_CHAINCODE_LOGGING_LEVEL=info
- CORE_PEER_LOCALMSPID=Org1MSP
- CORE_PEER_MSPCONFIGPATH=/etc/hyperledger/msp/peer
- CORE_PEER_ADDRESS=peer1.org1.example.com:7051
- CORE_PEER_GOSSIP_USELEADERELECTION=true
- CORE_PEER_GOSSIP_ORGLEADER=false
- CORE_PEER_PROFILE_ENABLED=true
- CORE_PEER_GOSSIP_BOOTSTRAP=peer0.org1.example.com:7051
- CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer1.org1.example.com:7051
# # the following setting starts chaincode containers on the same
# # bridge network as the peers
# # https://docs.docker.com/compose/networking/
- CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE=${COMPOSE_PROJECT_NAME}_basic
- CORE_LEDGER_STATE_STATEDATABASE=CouchDB
- CORE_LEDGER_STATE_COUCHDBCONFIG_COUCHDBADDRESS=couchdb:5984
# The CORE_LEDGER_STATE_COUCHDBCONFIG_USERNAME and CORE_LEDGER_STATE_COUCHDBCONFIG_PASSWORD
# provide the credentials for ledger to connect to CouchDB. The username and password must
# match the username and password set for the associated CouchDB.
- CORE_LEDGER_STATE_COUCHDBCONFIG_USERNAME=
- CORE_LEDGER_STATE_COUCHDBCONFIG_PASSWORD=
working_dir: /opt/gopath/src/github.com/hyperledger/fabric/peer
command: peer node start
# command: peer node start --peer-chaincodedev=true
ports:
- 8051:7051
- 8053:7053
volumes:
- /var/run/:/host/var/run/
- ./crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp:/etc/hyperledger/msp/peer
- ./crypto-config/peerOrganizations/org1.example.com/users:/etc/hyperledger/msp/users
- ./config:/etc/hyperledger/configtx
depends_on:
- orderer.example.com
- couchdb
ArianStef (Thu, 06 Sep 2018 18:53:26 GMT):
Hi team! I'm trying to add a new peer to sample fabcar but when I invoke the chaincode with the follow CLI:
docker exec -e "CORE_PEER_LOCALMSPID=Org1MSP" -e "CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp" -e "CORE_PEER_ADDRESS=peer1.org1.example.com:7051" cli peer chaincode query -o orderer.example.com:7050 -C mychannel -n fabcar -c '{"function":"queryAllCars","Args":[""]}'
I have the follow error:
Error: endorsement failure during query. response: status:500 message:"cannot retrieve package for chaincode fabcar/1.0, error open /var/hyperledger/production/chaincodes/fabcar.1.0: no such file or directory"
In the docker-compose.yml file I had add:
peer1.org1.example.com:
container_name: peer1.org1.example.com
image: hyperledger/fabric-peer
environment:
- CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
- CORE_PEER_ID=peer1.org1.example.com
- CORE_LOGGING_PEER=info
- CORE_CHAINCODE_LOGGING_LEVEL=info
- CORE_PEER_LOCALMSPID=Org1MSP
- CORE_PEER_MSPCONFIGPATH=/etc/hyperledger/msp/peer
- CORE_PEER_ADDRESS=peer1.org1.example.com:7051
- CORE_PEER_GOSSIP_USELEADERELECTION=true
- CORE_PEER_GOSSIP_ORGLEADER=false
- CORE_PEER_PROFILE_ENABLED=true
- CORE_PEER_GOSSIP_BOOTSTRAP=peer0.org1.example.com:7051
- CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer1.org1.example.com:7051
# # the following setting starts chaincode containers on the same
# # bridge network as the peers
# # https://docs.docker.com/compose/networking/
- CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE=${COMPOSE_PROJECT_NAME}_basic
- CORE_LEDGER_STATE_STATEDATABASE=CouchDB
- CORE_LEDGER_STATE_COUCHDBCONFIG_COUCHDBADDRESS=couchdb:5984
# The CORE_LEDGER_STATE_COUCHDBCONFIG_USERNAME and CORE_LEDGER_STATE_COUCHDBCONFIG_PASSWORD
# provide the credentials for ledger to connect to CouchDB. The username and password must
# match the username and password set for the associated CouchDB.
- CORE_LEDGER_STATE_COUCHDBCONFIG_USERNAME=
- CORE_LEDGER_STATE_COUCHDBCONFIG_PASSWORD=
working_dir: /opt/gopath/src/github.com/hyperledger/fabric/peer
command: peer node start
# command: peer node start --peer-chaincodedev=true
ports:
- 8051:7051
- 8053:7053
volumes:
- /var/run/:/host/var/run/
- ./crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp:/etc/hyperledger/msp/peer
- ./crypto-config/peerOrganizations/org1.example.com/users:/etc/hyperledger/msp/users
- ./config:/etc/hyperledger/configtx
depends_on:
- orderer.example.com
- couchdb
ArianStef (Thu, 06 Sep 2018 18:57:04 GMT):
Hi team! I'm trying to add a new peer to sample fabcar but when I querry the chaincode with the follow CLI:
docker exec -e "CORE_PEER_LOCALMSPID=Org1MSP" -e "CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp" -e "CORE_PEER_ADDRESS=peer1.org1.example.com:7051" cli peer chaincode query -o orderer.example.com:7050 -C mychannel -n fabcar -c '{"function":"queryAllCars","Args":[""]}'
I have the follow error:
Error: endorsement failure during query. response: status:500 message:"cannot retrieve package for chaincode fabcar/1.0, error open /var/hyperledger/production/chaincodes/fabcar.1.0: no such file or directory"
In the docker-compose.yml file I had add:
peer1.org1.example.com:
container_name: peer1.org1.example.com
image: hyperledger/fabric-peer
environment:
- CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
- CORE_PEER_ID=peer1.org1.example.com
- CORE_LOGGING_PEER=info
- CORE_CHAINCODE_LOGGING_LEVEL=info
- CORE_PEER_LOCALMSPID=Org1MSP
- CORE_PEER_MSPCONFIGPATH=/etc/hyperledger/msp/peer
- CORE_PEER_ADDRESS=peer1.org1.example.com:7051
- CORE_PEER_GOSSIP_USELEADERELECTION=true
- CORE_PEER_GOSSIP_ORGLEADER=false
- CORE_PEER_PROFILE_ENABLED=true
- CORE_PEER_GOSSIP_BOOTSTRAP=peer0.org1.example.com:7051
- CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer1.org1.example.com:7051
# # the following setting starts chaincode containers on the same
# # bridge network as the peers
# # https://docs.docker.com/compose/networking/
- CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE=${COMPOSE_PROJECT_NAME}_basic
- CORE_LEDGER_STATE_STATEDATABASE=CouchDB
- CORE_LEDGER_STATE_COUCHDBCONFIG_COUCHDBADDRESS=couchdb:5984
# The CORE_LEDGER_STATE_COUCHDBCONFIG_USERNAME and CORE_LEDGER_STATE_COUCHDBCONFIG_PASSWORD
# provide the credentials for ledger to connect to CouchDB. The username and password must
# match the username and password set for the associated CouchDB.
- CORE_LEDGER_STATE_COUCHDBCONFIG_USERNAME=
- CORE_LEDGER_STATE_COUCHDBCONFIG_PASSWORD=
working_dir: /opt/gopath/src/github.com/hyperledger/fabric/peer
command: peer node start
# command: peer node start --peer-chaincodedev=true
ports:
- 8051:7051
- 8053:7053
volumes:
- /var/run/:/host/var/run/
- ./crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp:/etc/hyperledger/msp/peer
- ./crypto-config/peerOrganizations/org1.example.com/users:/etc/hyperledger/msp/users
- ./config:/etc/hyperledger/configtx
depends_on:
- orderer.example.com
- couchdb
ArianStef (Thu, 06 Sep 2018 18:57:20 GMT):
Hi team! I'm trying to add a new peer to sample fabcar but when I query the chaincode with the follow CLI:
docker exec -e "CORE_PEER_LOCALMSPID=Org1MSP" -e "CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp" -e "CORE_PEER_ADDRESS=peer1.org1.example.com:7051" cli peer chaincode query -o orderer.example.com:7050 -C mychannel -n fabcar -c '{"function":"queryAllCars","Args":[""]}'
I have the follow error:
Error: endorsement failure during query. response: status:500 message:"cannot retrieve package for chaincode fabcar/1.0, error open /var/hyperledger/production/chaincodes/fabcar.1.0: no such file or directory"
In the docker-compose.yml file I had add:
peer1.org1.example.com:
container_name: peer1.org1.example.com
image: hyperledger/fabric-peer
environment:
- CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
- CORE_PEER_ID=peer1.org1.example.com
- CORE_LOGGING_PEER=info
- CORE_CHAINCODE_LOGGING_LEVEL=info
- CORE_PEER_LOCALMSPID=Org1MSP
- CORE_PEER_MSPCONFIGPATH=/etc/hyperledger/msp/peer
- CORE_PEER_ADDRESS=peer1.org1.example.com:7051
- CORE_PEER_GOSSIP_USELEADERELECTION=true
- CORE_PEER_GOSSIP_ORGLEADER=false
- CORE_PEER_PROFILE_ENABLED=true
- CORE_PEER_GOSSIP_BOOTSTRAP=peer0.org1.example.com:7051
- CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer1.org1.example.com:7051
# # the following setting starts chaincode containers on the same
# # bridge network as the peers
# # https://docs.docker.com/compose/networking/
- CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE=${COMPOSE_PROJECT_NAME}_basic
- CORE_LEDGER_STATE_STATEDATABASE=CouchDB
- CORE_LEDGER_STATE_COUCHDBCONFIG_COUCHDBADDRESS=couchdb:5984
# The CORE_LEDGER_STATE_COUCHDBCONFIG_USERNAME and CORE_LEDGER_STATE_COUCHDBCONFIG_PASSWORD
# provide the credentials for ledger to connect to CouchDB. The username and password must
# match the username and password set for the associated CouchDB.
- CORE_LEDGER_STATE_COUCHDBCONFIG_USERNAME=
- CORE_LEDGER_STATE_COUCHDBCONFIG_PASSWORD=
working_dir: /opt/gopath/src/github.com/hyperledger/fabric/peer
command: peer node start
# command: peer node start --peer-chaincodedev=true
ports:
- 8051:7051
- 8053:7053
volumes:
- /var/run/:/host/var/run/
- ./crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp:/etc/hyperledger/msp/peer
- ./crypto-config/peerOrganizations/org1.example.com/users:/etc/hyperledger/msp/users
- ./config:/etc/hyperledger/configtx
depends_on:
- orderer.example.com
- couchdb
Baha-sk (Thu, 06 Sep 2018 20:21:58 GMT):
Has joined the channel.
rsherwood (Fri, 07 Sep 2018 08:15:49 GMT):
Hi team , in fabric 1.0.6 we are seeing transaction that create many key value pairs use more CPU in the CouchDB than we would like. Am I right in thinking that the work already done in Fabric 1.1 ( FAB-2725, FAB-6421, FAB-6422, FAB-6330) is likely to improve this ? I think my reading of the CR is Fabric now does a bulk write operation. Most of the FAB talk in terms of throughput time rather than resource usage.
dave.enyeart (Fri, 07 Sep 2018 10:50:24 GMT):
yes, the bulk updates for creates/updates and index support for queries in couchdb 1.1 will greatly improve performance and reduce cpu.
yousaf (Sat, 08 Sep 2018 14:31:57 GMT):
Has joined the channel.
auua (Sat, 08 Sep 2018 19:14:58 GMT):
Has joined the channel.
raviyelleni (Sun, 09 Sep 2018 04:44:09 GMT):
Has joined the channel.
issac.liu (Mon, 10 Sep 2018 03:52:29 GMT):
Has joined the channel.
Ryan2 (Wed, 12 Sep 2018 04:50:12 GMT):
Hi, can some help me with below concern:
in fabric v1.1.1, if peer is running on multiple cores server, do we need to enable parallel validation by setting `CORE_PEER_validatorPoolSize=XXX` (XXX will be no. of cores of peer server) or peer will default take number of cores of server as the go routines to parallel running validation?
Thanks!
kelvinzhong (Wed, 12 Sep 2018 08:08:25 GMT):
@dave.enyeart hi, rickr tell me to ask here, i found that i could get a peer event with a "filtered block" in java sdk, but i could not tell the differences, what exactly does the peer event filtered? should all the channel member could retrieve the whole blocks? then why filtered
kelvinzhong (Wed, 12 Sep 2018 08:09:52 GMT):
@yacovm saw you around here:grin: in case you know the answer
yacovm (Wed, 12 Sep 2018 08:11:25 GMT):
it's filtered because the client might not be authorized to see the entire block
yacovm (Wed, 12 Sep 2018 08:11:28 GMT):
only its own transactions
kelvinzhong (Wed, 12 Sep 2018 08:12:57 GMT):
how come...
kelvinzhong (Wed, 12 Sep 2018 08:13:17 GMT):
all members should have the right to get the whole ledger
kelvinzhong (Wed, 12 Sep 2018 08:14:57 GMT):
because of the private data involve?
kelvinzhong (Wed, 12 Sep 2018 08:17:40 GMT):
but if a client can not retrieve the whole block, how can the client verify the block is not been malevolent tampering
dave.enyeart (Wed, 12 Sep 2018 10:00:48 GMT):
@kelvinzhong The filtered block has the same structure as a normal block, however the transaction payload including read-write set is filtered out. A primary use case is that a client may simply want to know the validation/invalidation status of all transactions in the blocks, rather than wanting to know the data of each transaction.
dave.enyeart (Wed, 12 Sep 2018 10:01:05 GMT):
See doc here: https://hyperledger-fabric.readthedocs.io/en/latest/peer_event_services.html#available-services
dave.enyeart (Wed, 12 Sep 2018 10:01:19 GMT):
See the content of the filtered blocks here: https://github.com/hyperledger/fabric/blob/master/protos/peer/events.proto#L20-L47
dave.enyeart (Wed, 12 Sep 2018 10:05:39 GMT):
As yacovm mentions, you can also use it for access control... you can specify a different ACL for clients that can receive full block events vs filtered block events, see https://github.com/hyperledger/fabric/blob/master/sampleconfig/configtx.yaml#L184-L188
kelvinzhong (Thu, 13 Sep 2018 05:03:42 GMT):
got it, many thanks~
kelvinzhong (Thu, 13 Sep 2018 06:23:03 GMT):
well, i got confuse at the configtx.yaml, seems it's a channel level ACL, either you can retrieve the whole block of the ledger or can only retrieve the filtered block of the ledger. it seems not like what yacovm said block level ACL, client can get the transactions with authorized in the filtered block...
kelvinzhong (Thu, 13 Sep 2018 06:23:03 GMT):
well, i got confuse at the configtx.yaml, seems it's a channel level ACL, either you can retrieve the whole block of the ledger or can only retrieve the filtered block of the ledger. it seems not like what yacovm said as block level ACL, client can get the transactions with authorized in the filtered block...
kelvinzhong (Thu, 13 Sep 2018 06:23:03 GMT):
well, i got confuse at the configtx.yaml, seems it's a channel level ACL, either you can retrieve the whole block of the ledger or can only retrieve the filtered block of the ledger. it seems not like what yacovm said as block level ACL, client can get authorized transactions in the filtered block...
kelvinzhong (Thu, 13 Sep 2018 06:23:03 GMT):
well, i got confuse at the configtx.yaml, seems it's a channel level ACL, either you can retrieve the whole block of the ledger or can only retrieve the filtered block of the ledger. it seems not like what yacovm said as block level ACL that client can get authorized transactions in the filtered block...
kelvinzhong (Thu, 13 Sep 2018 07:08:07 GMT):
@dave.enyeart please correct me if i get it wrong:grin:
dave.enyeart (Thu, 13 Sep 2018 11:39:36 GMT):
correct, it is a channel-level acl only
JaydipMakadia (Thu, 13 Sep 2018 13:12:42 GMT):
Has joined the channel.
vdods (Thu, 13 Sep 2018 19:51:54 GMT):
Hi all, in trying to upgrade to Fabric 1.2, instantiating chaincode, I'm getting errors of the form
`[endorser] EndorseWithPlugin -> WARN 0ca Endorsement with plugin for {plugin: escc, channel: simple-channel, tx: 4364ca3903e068fccc6e1a25a91eac2c3d2280984092d778b72ee45409ea8326, chaincode: lscc} failed: plugin with name escc wasn't found`
`[endorser] ProcessProposal -> ERRO 0cb [simple-channel][8d8d524c] simulateProposal() resulted in chaincode name:"lscc" response status 500 for txid: 8d8d524c4bfa6d2f37668743020023cebcff754a257a639bddbfe5ebdd014cfb`
vdods (Thu, 13 Sep 2018 19:52:24 GMT):
which is blocking me from instantiating my chaincode. The chaincode install appears to have worked fine though.
yacovm (Thu, 13 Sep 2018 19:52:58 GMT):
@vdods change your core.yaml when you upgrade your peer....
yacovm (Thu, 13 Sep 2018 19:53:06 GMT):
it has changed ;)
vdods (Thu, 13 Sep 2018 19:55:54 GMT):
Hmm.. I thought I had, but I'll look more carefully.
vdods (Thu, 13 Sep 2018 19:57:45 GMT):
@yacovm Is fabric/sampleconfig/core.yaml up to date?
yacovm (Thu, 13 Sep 2018 19:57:54 GMT):
yeah of course
yacovm (Thu, 13 Sep 2018 19:59:07 GMT):
also kudos for upgrading to v1.2 @vdods , we're almost at 2019 now
yacovm (Thu, 13 Sep 2018 19:59:12 GMT):
about time...
vdods (Thu, 13 Sep 2018 20:00:36 GMT):
Haha
vdods (Thu, 13 Sep 2018 20:00:39 GMT):
Thanks ;)
anjalinaik (Fri, 14 Sep 2018 07:27:40 GMT):
Hi..can anybody please help me resolve this error from peer logs
```
2018-09-14 07:21:10.222 UTC [ConnProducer] NewConnection -> ERRO 95f Failed connecting to testf_orderer0:7050 , error: context deadline exceeded
2018-09-14 07:21:10.226 UTC [deliveryClient] connect -> DEBU 960 Connected to
2018-09-14 07:21:10.226 UTC [deliveryClient] connect -> ERRO 961 Failed obtaining connection: Could not connect to any of the endpoints: [testf_orderer0:7050]
```
githubcpc (Mon, 17 Sep 2018 03:07:23 GMT):
Has joined the channel.
githubcpc (Mon, 17 Sep 2018 03:15:57 GMT):
Hi, I had build fabric 1.1 environment and I used fabric-java-sdk to connect.I plan to monitor my peer states,but I hava no idea to do now.Thanks for any advice.
narendranathreddy (Tue, 18 Sep 2018 10:44:31 GMT):
Has joined the channel.
narendranathreddy (Tue, 18 Sep 2018 11:15:41 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=JjR8JDWSJRTRkc7Ji) orderer0 is down check
narendranathreddy (Tue, 18 Sep 2018 11:49:11 GMT):
still connecting to old port
aatkddny (Tue, 18 Sep 2018 14:18:23 GMT):
Has joined the channel.
aatkddny (Tue, 18 Sep 2018 14:20:29 GMT):
Have a problem with creating an index in couchdb and was referred here. Hopefully someone can tell me what I messed up...
Using the java SDK to create chaincode passing in an archive. Code works fine - been stable for months.
Tried to add an index using the instructions in the latest docs.
The archive looks like this:
aatkddny (Tue, 18 Sep 2018 14:20:49 GMT):
cut2.png
aatkddny (Tue, 18 Sep 2018 14:21:07 GMT):
CC is aacc. index1 looks like this
aatkddny (Tue, 18 Sep 2018 14:21:07 GMT):
CC is aacc. index1 looks like this:
```
{
"index":{
"fields":["id", "type"]
},
"ddoc":"index1Doc",
"name":"index1",
"type":"json"
}
```
aatkddny (Tue, 18 Sep 2018 14:23:55 GMT):
CC instantiates as expected
What did I miss?
aatkddny (Tue, 18 Sep 2018 14:23:55 GMT):
CC instantiates as expected. Nothing about the couch index though.
What did I miss?
yacovm (Tue, 18 Sep 2018 14:30:10 GMT):
@aatkddny ask in #fabric-ledger
aatkddny (Tue, 18 Sep 2018 14:34:25 GMT):
i'll copy it over. was referred here first so apologies for spamming multiple lists.
yacovm (Tue, 18 Sep 2018 15:09:21 GMT):
@aatkddny that's fine, though - I see you're redirected in a circle and that didn't help :/
aatkddny (Tue, 18 Sep 2018 15:12:14 GMT):
Well the last comment may. I'll try building the archive differently.
gravity (Tue, 18 Sep 2018 15:16:04 GMT):
Hello
after upgrade to fabric v1.2.0, some of peers getting stuck during transaction commit.
for example, if a channel has 3 peers, one out of three is stuckduring transaction. no errors in logs on peer or orderer.
if I restart a container for this peer, a transaction that stuck previously will proceed, but other peers tell this message in logs:
```
peer1-default-org | Failed obtaining connection for peer8-default-org:7051, PKIid:[13 148 83 230 154 35 173 0 16 141 110 78 210 23 72 254 254 177 143 36 136 23 72 84 31 6 16 18 221 34 107 223] reason: Authentication failure
peer1-default-org | 2018-09-18 14:48:02.284 UTC [gossip/comm] createConnection -> WARN 0b0 Remote endpoint claims to be a different peer, expected [13 148 83 230 154 35 173 0 16 141 110 78 210 23 72 254 254 177 143 36 136 23 72 84 31 6 16 18 221 34 107 223] but got [150 240 229 156 3 99 225 102 191 218 203 23 157 199 128 193 234 5 145 223 71 70 226 49 39 199 119 61 33 207 214 55]
```
and logs on peer that was restarted:
```
peer8-default-org | 2018-09-18 14:48:02.480 UTC [gossip/comm] authenticateRemotePeer -> WARN 081 Failed reading messge from 172.21.0.14:36126, reason: Timed out waiting for connection message from 172.21.0.14:36126
peer8-default-org | 2018-09-18 14:48:02.480 UTC [gossip/comm] GossipStream -> ERRO 082 Authentication failed: Timed out waiting for connection message from 172.21.0.14:36126
```
yacovm (Tue, 18 Sep 2018 15:18:15 GMT):
@gravity - are you using the deliver service for events?
yacovm (Tue, 18 Sep 2018 15:19:00 GMT):
`Remote endpoint claims to be a different peer` means the peer you re-connected to, changed its certificate.
yacovm (Tue, 18 Sep 2018 15:19:05 GMT):
and is unrelated to v1.2
yacovm (Tue, 18 Sep 2018 15:19:09 GMT):
it is that way since v1.0
yacovm (Tue, 18 Sep 2018 15:19:20 GMT):
(it's not a bug...)
gravity (Tue, 18 Sep 2018 15:19:22 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=FSuo4CjPniq8sQyzA) @yacovm actually, I'm not aware of it. how can I check this?
yacovm (Tue, 18 Sep 2018 15:19:40 GMT):
check if your application uses port 7051 for events, or 7053
yacovm (Tue, 18 Sep 2018 15:19:47 GMT):
if 7051 then yes
yacovm (Tue, 18 Sep 2018 15:19:52 GMT):
else, no.
gravity (Tue, 18 Sep 2018 15:21:14 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=EiiQxsjQ7t64YCLCu) @yacovm if you mean ports for peers, then yes, all peers run on 7051
yacovm (Tue, 18 Sep 2018 15:25:35 GMT):
i know that they run on 7051
yacovm (Tue, 18 Sep 2018 15:25:44 GMT):
i am asking whether you connect also to 7053 or not
gravity (Tue, 18 Sep 2018 15:28:03 GMT):
no, my client(sdk) application does not use 7053 port
yacovm (Tue, 18 Sep 2018 15:32:15 GMT):
ah so you use the deliver service
yacovm (Tue, 18 Sep 2018 15:32:23 GMT):
there is a bug that is going to be fixed in v1.2.1
yacovm (Tue, 18 Sep 2018 15:32:37 GMT):
this bug makes the commit sometimes stuck, if you connect to the event deliver service
yacovm (Tue, 18 Sep 2018 15:32:46 GMT):
so you need to upgrade to v1.2.1
yacovm (Tue, 18 Sep 2018 15:33:09 GMT):
@dave.enyeart any idea when v1.2.1 is cut?
gravity (Tue, 18 Sep 2018 15:33:35 GMT):
ok, got it
thanks
just wanted to ask if you know when 1.2.1 is going to be released :)
gravity (Tue, 18 Sep 2018 15:35:06 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=PGk4JpF4yDRHvF8HZ) @yacovm any advice what should be done in this case? what should I do to make all other peers know about a new certificate for a peer that was restarted?
yacovm (Tue, 18 Sep 2018 15:35:25 GMT):
you need to wait 30 minutes
gravity (Tue, 18 Sep 2018 15:37:15 GMT):
regardless of peer number?
could you explain please what this is implemented in this way?
yacovm (Tue, 18 Sep 2018 15:38:43 GMT):
hmmm, in v1.2.1 there is a fix where it happens only if the peer's organization has changed
yacovm (Tue, 18 Sep 2018 15:38:43 GMT):
hmmm, in v1.2.1 or in v1.3 there is a fix where it happens only if the peer's organization has changed
yacovm (Tue, 18 Sep 2018 15:39:43 GMT):
the idea in general was that if you change the peer's certificate - this is suspicious because it might mean your network is hijacked , but we didn't take into account if the peer was in the same organization :/
sstone1 (Tue, 18 Sep 2018 16:32:40 GMT):
Has joined the channel.
gravity (Wed, 19 Sep 2018 07:54:39 GMT):
thanks for the explanation
awaiting v1.2.1 and 1.3 :)
yacovm (Wed, 19 Sep 2018 10:27:28 GMT):
@gravity - we merged the fix into v1.2.1 this morning https://gerrit.hyperledger.org/r/#/c/26380/
yacovm (Wed, 19 Sep 2018 10:27:43 GMT):
when it'll be released, it won't happen anymore - unless the peer switches an MSP ID
yacovm (Wed, 19 Sep 2018 10:28:15 GMT):
(It was in v1.3 but I backported to v1.2.1)
gravity (Wed, 19 Sep 2018 10:29:59 GMT):
@yacovm many thanks
dave.enyeart (Wed, 19 Sep 2018 18:16:16 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=uCmJhzW9nN3JvCPWA) @yacovm I believe v1.2.1 has all the fixes merged that we were targeting, it's just a matter of freeing up a resource to do the final test and cut (prioritized behind v1.3.0 at the moment).
dave.enyeart (Wed, 19 Sep 2018 18:16:50 GMT):
in the meantime, people can pull latest binaries and images that will comprise v1.2.1 by using this script:
dave.enyeart (Wed, 19 Sep 2018 18:16:53 GMT):
https://github.com/hyperledger/fabric/blob/master/scripts/pull_build_artifacts.sh
dave.enyeart (Wed, 19 Sep 2018 18:17:01 GMT):
replace 1.3.0 with 1.2.1
yacovm (Wed, 19 Sep 2018 18:25:30 GMT):
@gravity ^
yacovm (Wed, 19 Sep 2018 18:25:36 GMT):
you can test my fix now
sean (Wed, 19 Sep 2018 18:58:51 GMT):
Has joined the channel.
gravity (Thu, 20 Sep 2018 07:24:13 GMT):
@yacovm thanks, will do
yousaf (Fri, 21 Sep 2018 11:47:08 GMT):
How to set environment variables to use orderer peer, just like we use orgs peers.?
yousaf (Sat, 22 Sep 2018 08:11:53 GMT):
I am using this command to set the mod_policy.... jq -s '.[0] * {"channel_group":{"groups":{"Consortiums":{"groups":{"mod_policy":"Admins"}}}}}' config.json > modified_config.json....................to set the mod policy in config.json file.
But getting this error............. Error decoding: error decoding input: *common.Config: error in PopulateFrom for field channel_group for message *common.Config: *common.DynamicChannelGroup: error in PopulateFrom for map field groups with key Consortiums for message *common.DynamicChannelGroup: *common.DynamicConsortiumsGroup: expected map field groups value for mod_policy for message *common.DynamicConsortiumsGroup to be assignable from map[string]interface {} but was not. Is string....................Any solution?
DerekC (Mon, 24 Sep 2018 09:16:26 GMT):
Has joined the channel.
reggiefelias (Mon, 24 Sep 2018 10:11:45 GMT):
Has joined the channel.
reggiefelias (Mon, 24 Sep 2018 10:12:31 GMT):
Hi All, good day! I'm having the following error in my peer: [blocksProvider] DeliverBlocks -> WARN 502 [someachannel] Got error &{SERVICE_UNAVAILABLE}
davidkel (Tue, 25 Sep 2018 16:51:25 GMT):
Can anyone answer what I hope is a simple question: Is a chaincode upgrade transaction subject to instantiation policy and endorsement policy ?
davidkel (Tue, 25 Sep 2018 16:51:25 GMT):
Can anyone answer what I hope is a simple question: Is a chaincode upgrade transaction subject to instantiation policy or endorsement policy ?
jrosmith (Tue, 25 Sep 2018 17:19:05 GMT):
@davidkel yes, a chaincode upgrade proposal is subject to the same requirements as a chaincode instantiation.
davidkel (Tue, 25 Sep 2018 17:39:47 GMT):
@jrosmith Thanks, that what I would have expected, it's just I have seen a log where a chaincode ugrade failed with what I thought was an ENDORSEMENT_POLICY message
Ryan2 (Wed, 26 Sep 2018 05:08:01 GMT):
Hi, can someone help to answer my concern:
I running fabric network with setting `Channel Capability ` V1_1; `Orderer Capability ` V1_1 and `Application Capability ` V1_1; my orderer, peer running on binary v1.1.1 and works fine.
however when I joined one peer, say org0-peer1, which build one `v1.2.0`) into channel successfully,
Does that correct that org0-peer1 could join the channel?
githubcpc (Wed, 26 Sep 2018 06:58:39 GMT):
Hi，I want to know what happens behind the peer when it starts?But I can't find a detailed description on the official website.
yacovm (Wed, 26 Sep 2018 07:02:43 GMT):
just look behind the peer...
yacovm (Wed, 26 Sep 2018 07:02:54 GMT):
after you start it
githubcpc (Wed, 26 Sep 2018 07:04:18 GMT):
I find the 'start.go' will start the peer node .
yacovm (Wed, 26 Sep 2018 07:04:28 GMT):
yes
githubcpc (Wed, 26 Sep 2018 07:05:46 GMT):
I just want to know what happened inside.Is there a work flow picture?
yacovm (Wed, 26 Sep 2018 07:19:52 GMT):
generally speaking... the peer opens all the ledgers for all the channels it participates in
yacovm (Wed, 26 Sep 2018 07:20:00 GMT):
and then establishes communication to orderers and peerrs
githubcpc (Wed, 26 Sep 2018 07:23:36 GMT):
Thanks for your reply.I find a picture in https://github.com/yeasy/hyperledger_code_fabric/blob/2e89749e16e9a5b35d02736aa44f7791df4fac22/peer/node/start_go.md
githubcpc (Wed, 26 Sep 2018 07:24:26 GMT):
This maybe solve my problem.
Ryan2 (Sat, 29 Sep 2018 10:46:51 GMT):
I tested below scenario:
1. recording variableA with value of 200 marbles, and this variable is committed into ledger inserted into couchdb
2. might someone logged into couchdb and modified variableA = 500 marbles (at this time, in couchdb version of document already change and not match with rest of peer's couchdb)
2.1 make a transfer transaction from 500 marble variableA to variableB , and this transaction was successfully.
this mean that fabric does not maintain the consistency of version of documents of peers' statedb.
And protection (or security) of statedb from modification any value of the key become critical important.
is my understand is correct?
vdods (Sun, 30 Sep 2018 04:37:09 GMT):
I've got a question regarding writing to a private collection. Say I have 2 orgs, each with their own private collection. Say I issue a transaction to peers in both orgs, and each org's peer stores something to its own private collection (this clearly depends on the peer knowing that it's a member of the org whose private collection it owns). Is that expected to work? Or is this prohibited?
vdods (Sun, 30 Sep 2018 04:37:09 GMT):
I've got a question regarding writing to a private collection. Say I have 2 orgs, each with their own private collection. Say I issue a transaction to peers in both orgs, and each org's peer stores something to its own private collection (this clearly depends on the peer knowing that it's a member of the org whose private collection it owns). Is that expected to work? Or is that prohibited?
yacovm (Sun, 30 Sep 2018 04:40:17 GMT):
yeah it's expected to work
yacovm (Sun, 30 Sep 2018 04:40:28 GMT):
there is even an upcoming feature that is called "local collections"
yacovm (Sun, 30 Sep 2018 04:40:37 GMT):
that does that....
vdods (Sun, 30 Sep 2018 04:40:42 GMT):
oh sweet!
vdods (Sun, 30 Sep 2018 04:40:53 GMT):
within chaincode, how does one figure out the identity of the executing peer?
yacovm (Sun, 30 Sep 2018 04:41:03 GMT):
search "local collections" in JIRA
vdods (Sun, 30 Sep 2018 04:41:03 GMT):
env vars perhaps?
yacovm (Sun, 30 Sep 2018 04:41:30 GMT):
> within chaincode, how does one figure out the identity of the executing peer?
hmmm you can have the peer have a decorator that passes the identity
yacovm (Sun, 30 Sep 2018 04:41:45 GMT):
decorators are plugins local to the peer, that annotate the input of the chaincode
vdods (Sun, 30 Sep 2018 04:41:53 GMT):
ah ok
yacovm (Sun, 30 Sep 2018 04:42:27 GMT):
https://github.com/hyperledger/fabric/blob/release-1.2/sampleconfig/core.yaml#L388
vdods (Sun, 30 Sep 2018 04:43:12 GMT):
just want to understand one point fully: when writing to a private collection, are hashes of the key and value written to the ledger? or perhaps somewhere else? if they're written to the ledger, are they part of the transaction's read-write set?
yacovm (Sun, 30 Sep 2018 04:45:11 GMT):
yes they are
yacovm (Sun, 30 Sep 2018 04:45:23 GMT):
that's exactly how it works actually
yacovm (Sun, 30 Sep 2018 04:45:31 GMT):
once a peer gets the block it has the hashes in it
yacovm (Sun, 30 Sep 2018 04:45:44 GMT):
and then it can ensure that the private data itself, the hash pre-image is correct
yacovm (Sun, 30 Sep 2018 04:45:49 GMT):
by hashing itself and comparing
vdods (Sun, 30 Sep 2018 04:46:45 GMT):
but if different peers produce different read-write sets because they're writing to different private collections, how can the different transaction proposals be accepted by the orderer?
vdods (Sun, 30 Sep 2018 04:50:42 GMT):
on a side note, the automatic storage of the hash of the private collection value is worrying; https://benlog.com/2008/06/19/dont-hash-secrets/
vdods (Sun, 30 Sep 2018 04:52:36 GMT):
presumably the hash of the private value is accessible by all committing peers. if the secret is something that occupies a relatively small space (such as passwords or similar) and an attacker knows that, then a dictionary attack or related could be used to infer the private value from the public hash
yacovm (Sun, 30 Sep 2018 05:07:09 GMT):
So? @vdods just add random salt to the key and value
vdods (Sun, 30 Sep 2018 05:10:22 GMT):
@yacovm I suppose, though that's rather annoying to have to do, rather than have the privacy abstraction take care of it. Realistically, no one will know to do that, so many Fabric apps will have this vulnerability
vdods (Sun, 30 Sep 2018 05:12:41 GMT):
But for now that's a side concern. I would like to know the answer to the question about a single transaction running on different peers being able to write to different private collections -- don't they produce different read-write sets?
vdods (Sun, 30 Sep 2018 05:12:51 GMT):
and therefore the transaction won't be accepted by the orderer?
vdods (Sun, 30 Sep 2018 05:13:22 GMT):
@yacovm BTW, I appreciate your always-insightful advice!
yacovm (Sun, 30 Sep 2018 05:30:13 GMT):
> I suppose, though that's rather annoying to have to do, rather than have the privacy abstraction take care of it. Realistically, no one will know to do that, so many Fabric apps will have this vulnerability
That's why I suggest everyone takes a crypto course if he/she uses Fabric :)
Jokes aside... you have a point, but - note that the peers themselves cannot generate the randomness, right? It has to come from the client.
So - if we ever do such a change we'd need to probably implement a wrapper stub that uses the existing stub API as a black box, and uses something like ASN1 or protobuf marshaling and includes salts.
> I would like to know the answer to the question about a single transaction running on different peers being able to write to different private collections -- don't they produce different read-write sets?
they do... you're supposed to do that in different transactions, if the RWSets are different.
A way to do that in the same RWSet is simply to pass the randomness of the salt via the transient map.
yacovm (Sun, 30 Sep 2018 05:30:56 GMT):
> BTW, I appreciate your always-insightful advice!
Why don't you implement a wrapper shim that uses salts and push that as a contribution to the project?
yacovm (Sun, 30 Sep 2018 05:35:41 GMT):
@vdods ^
vdods (Sun, 30 Sep 2018 05:42:13 GMT):
@yacovm Hehe, fair enough ;) Thanks for your answers. Could potentially allow random number generation on the peers by passing a seed to the transaction and then using a fixed PRNG. As for the separate transactions, I think I'm still coming to grips psychologically with not having atomic operations in certain cases :)
asaningmaxchain123 (Mon, 01 Oct 2018 04:59:55 GMT):
@mastersingh24 for the bccsp plugin,it support golang ? now i write the plugin bccsp and it generate a gm.a static lib,so how can i take it work?
krabradosty (Mon, 01 Oct 2018 13:10:13 GMT):
Has joined the channel.
krabradosty (Mon, 01 Oct 2018 13:49:30 GMT):
Hello!
When I changed the endorsement policy of my chaincode from `-P "OR ('Org1MSP.member','Org2MSP.member')"` to `-P "OR ('Org1MSP.peer','Org2MSP.peer')"`, I got an error from peer during block committing: ENDORSEMENT_POLICY_FAILURE.
I've set EnableNodeOUs to true in crypto-config.yaml, peer certificate contains `Subject: C=US, ST=California, L=San Francisco, OU=peer, CN=peer0.org1.example.com`. What is the problem?
asaningmaxchain123 (Tue, 02 Oct 2018 03:09:04 GMT):
@yacovm @mastersingh24 can you tell me what's the function of msp `OU`,and take an example
Thavarajajohn (Tue, 02 Oct 2018 07:39:22 GMT):
Has joined the channel.
vdods (Tue, 02 Oct 2018 08:17:11 GMT):
Hi there, I've already instantiated a chaincode on my 2 org network, and along with it is a private collection owned by a single org. This was sort of a mistake, and there was supposed to be a private collection owned by each org, but I issued the original instantiate transaction with only one of the private collections defined. Now i've issued another instantiate (upgrade) transaction, with both private collections defined, but there is no difference; only the single, already-existing private collection is present. Note that I'm issuing the instantiate transaction to one peer on one org only. Why isn't the definition of the private collections being updated to include the second one?
yacovm (Tue, 02 Oct 2018 08:32:42 GMT):
how do you know the 2nd one doesn't exist?
Thavarajajohn (Tue, 02 Oct 2018 08:37:33 GMT):
hi, I faced the issue while initializing channel on the peer like below (running peer cli command )
Thavarajajohn (Tue, 02 Oct 2018 08:37:41 GMT):
grpc: addrConn.resetTransport failed to create client transport: connection error: desc = "transport: Error while dialing dial tcp 69.172.201.153:7050: operation was canceled"; Reconnecting to {orderer.loyality.com:7050
Thavarajajohn (Tue, 02 Oct 2018 08:44:35 GMT):
using fabric-peer:x86_64-1.1.1
vdods (Tue, 02 Oct 2018 08:44:59 GMT):
@yacovm I'm doing a query of the instantiated chaincodes, and I only see one private collection
vdods (Tue, 02 Oct 2018 08:46:01 GMT):
And it doesn't matter if i do the query from org0 or org1, it's still just the same, single private collection (the one for org1)
yacovm (Tue, 02 Oct 2018 08:46:14 GMT):
try to do a transaction with that collection
yacovm (Tue, 02 Oct 2018 08:46:16 GMT):
and see what you get
vdods (Tue, 02 Oct 2018 08:46:30 GMT):
the one that exists, or the one that apparently doesn't?
yacovm (Tue, 02 Oct 2018 08:46:35 GMT):
latter
vdods (Tue, 02 Oct 2018 08:46:41 GMT):
ok
vdods (Tue, 02 Oct 2018 08:52:58 GMT):
```
2018-10-02 08:50:24.993 UTC [endorser] SimulateProposal -> ERRO 192a [simple-channel][41c8000e] failed to invoke chaincode name:"docuseal-chaincode" , error: getdepspec simple-channel/docuseal-chaincode responded with error: chaincode fingerprint mismatch: data mismatch
```
vdods (Tue, 02 Oct 2018 08:54:43 GMT):
Just for reference, what I get when I query the instantiated chaincodes is
```
ChainCodes: ([]*peer.ChaincodeInfo) (len=2 cap=2) {
(*peer.ChaincodeInfo)(0xc420146a80)(name:"docuseal-chaincode" version:"0.10.1-DEV.0.modified+g-08b36d360fb8223b.dh-SW5SDPVJRWHA3XHO" path:"github.com/LedgerDomain/docuseal-chaincode" input:"
Bartb0 (Tue, 02 Oct 2018 10:56:10 GMT):
Has joined the channel.
MaddaliPadmaja (Wed, 03 Oct 2018 07:15:20 GMT):
Has joined the channel.
IgorSim (Wed, 03 Oct 2018 18:54:18 GMT):
hi, i'm not sure if this is right channel to ask but here is my question: is it possible to apply 'label' (docker object label) to chaincode container , i.e. whenever chaincode container starts(chaincode is instantiated) i want that docker container to have specific label attached to it
mrjdomingus (Thu, 04 Oct 2018 08:11:14 GMT):
Has joined the channel.
silliman (Thu, 04 Oct 2018 17:33:08 GMT):
?ledger size
asaningmaxchain123 (Fri, 05 Oct 2018 07:17:07 GMT):
@yacovm @dave.enyeart i want to use the `service discovery` features, i must set the tls enable
yacovm (Fri, 05 Oct 2018 08:12:33 GMT):
@asaningmaxchain123 no
asaningmaxchain123 (Fri, 05 Oct 2018 09:35:50 GMT):
thx
qiangqinqq (Sat, 06 Oct 2018 07:37:14 GMT):
Has joined the channel.
dave.enyeart (Sun, 07 Oct 2018 22:29:38 GMT):
@sykesm I was talking to @muralisr and he mentioned he was going to start working on operational metrics soon in partnership with @grapebaba (Kai's framework). I know you are looking into this area as well. I'm just mentioning you all so that the efforts are coordinated. Thought this was a decent channel to use for now, although we could create another channel around serviceability and operations...
muralisr (Sun, 07 Oct 2018 22:31:57 GMT):
thanks @dave.enyeart ..this is a good opportunity to bring application level uses to topdown to meet monitoring support bottom up building on the work that's been started
muralisr (Sun, 07 Oct 2018 22:31:57 GMT):
thanks @dave.enyeart ..this is a good opportunity to bring topdon application level uses to meet bottomup monitoring support building on the work that's been started
muralisr (Sun, 07 Oct 2018 22:31:57 GMT):
thanks @dave.enyeart ..this is a good opportunity to bring topdown application level uses to meet bottomup monitoring support building on the work that's been started
rsherwood (Mon, 08 Oct 2018 10:53:11 GMT):
When instantiating chaincode what policy is a new chaincode instantiate checked against. Is it just any policy specified in the -i of the command , in which case any writer to a channel could install a new chaincode by specifying itself, or would it be checked against a default channel policy . The upgrade documentation makes it clear that any upgrade is checked against the previous upgrade or install policy, but I'm not 100% clear on the initial install.
gravity (Mon, 08 Oct 2018 13:13:43 GMT):
Hello
I'm trying to setup a network with apache kafka as a backend for an orderer, but I'm getting an error when attempting to create a channel:
```
[36m2018-10-08 13:09:57.094 UTC [grpc] Printf -> DEBU 04a[0m pickfirstBalancer: HandleSubConnStateChange: 0xc42028e780, CONNECTING
[36m2018-10-08 13:09:57.094 UTC [grpc] Printf -> DEBU 04b[0m pickfirstBalancer: HandleSubConnStateChange: 0xc42028e780, READY
Error: got unexpected status: SERVICE_UNAVAILABLE -- will not enqueue, consenter for this channel hasn't started yet
```
fabric v1.2.1
gravity (Mon, 08 Oct 2018 13:14:09 GMT):
any advice what should I do in this case?
rahulhegde (Mon, 08 Oct 2018 14:35:07 GMT):
hello, I have upgraded fabric setup from v1.0 to v1.2. I am using Peer CLI for sending ledger transaction. It looks like peer CLI is not sending the endorsed transaction having endorsement status code > 200 to orderer. It works for 200. This is working in v1.0. Is it case to open a JIRA?
rahulhegde (Mon, 08 Oct 2018 14:51:04 GMT):
Q2. In fabric v1.0 200 to 499 was considered as Endorsement Success and anything >= 500 is considered Endorsement Failure. This is how the range is been used in our chaincode . Is the range changed in Fabric v1.2?
muralisr (Mon, 08 Oct 2018 15:22:03 GMT):
@rahulhegde what status code do you actually see (thats not being sent to orderer) ?
rahulhegde (Mon, 08 Oct 2018 16:16:49 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=8dfYK3NF3emAaEYAG) @muralisr Endorsement status code: 235.
rahulhegde (Mon, 08 Oct 2018 16:18:43 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=h6iQS7JPSZdairBYJ) I have opened FAB-12340
rahulhegde (Mon, 08 Oct 2018 16:18:43 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=h6iQS7JPSZdairBYJ) I have opened https://jira.hyperledger.org/browse/FAB-12340
abhishek.s (Tue, 09 Oct 2018 05:34:12 GMT):
Hi Everyone! We have created a proposal for Deferred Transactions in Hyperledger Fabric. https://jira.hyperledger.org/browse/FAB-12161
asaningmaxchain123 (Tue, 09 Oct 2018 14:49:28 GMT):
@yacovm when the chaincode upgrade,the chaincode invoke should stop?
asaningmaxchain123 (Tue, 09 Oct 2018 14:49:28 GMT):
@yacovm when the chaincode is upgrading,the chaincode invoke should stop?
yacovm (Tue, 09 Oct 2018 14:50:27 GMT):
no
yacovm (Tue, 09 Oct 2018 14:50:31 GMT):
you need to stop it yourself
DeepakMP (Tue, 09 Oct 2018 16:03:00 GMT):
Has joined the channel.
DeepakMP (Tue, 09 Oct 2018 16:03:08 GMT):
Hey everyone!
DeepakMP (Tue, 09 Oct 2018 16:03:23 GMT):
Newly introduced to HL Fabric here!
DeepakMP (Tue, 09 Oct 2018 16:03:52 GMT):
going through the docs, and so far, I've been able to do the basic stuff, so thats good!
DeepakMP (Tue, 09 Oct 2018 16:05:18 GMT):
fyi, I'm new to docker and go, and basic proficiency in node, so some of those concepts might be holding me back, but as far as I can, I try to google for things and try to figure it out each time I'm stuck.
DeepakMP (Tue, 09 Oct 2018 16:05:40 GMT):
However, I'm stuck on two points, appreciate anyone who can help me out here:
DeepakMP (Tue, 09 Oct 2018 16:12:38 GMT):
1. I figured out that we can launch our custom configured network by modifying the crypto-config.yaml file and going through the launch network steps. (I'm using the documentation default resources- the /fabcar directory). The generate command works and creates 4 or more peers as per my entries in yaml, but thereafter, I get stuck, they dont get endorser nodes created for them, and then hence they're not part of my channel and so on. (This happens whenever, I create new Orgs, beyond the default Org1 and Org2). I think this is so because the .tx files that come with the documentation are placed for only Org1 and Org2. So I'm still trying to figure out if there's a way to dynamically create the .tx files or is there a healthier way to process new organisations and new peers for them.
gravity (Tue, 09 Oct 2018 16:14:58 GMT):
Hello @yacovm
I'm trying to setup a network with apache kafka as a backend for an orderer, but I'm getting an error when attempting to create a channel:
```
[36m2018-10-08 13:09:57.094 UTC [grpc] Printf -> DEBU 04a[0m pickfirstBalancer: HandleSubConnStateChange: 0xc42028e780, CONNECTING
[36m2018-10-08 13:09:57.094 UTC [grpc] Printf -> DEBU 04b[0m pickfirstBalancer: HandleSubConnStateChange: 0xc42028e780, READY
Error: got unexpected status: SERVICE_UNAVAILABLE -- will not enqueue, consenter for this channel hasn't started yet
```
fabric v1.2.1
DeepakMP (Tue, 09 Oct 2018 16:15:55 GMT):
2. In trying to create Private Data Collections, I pulled down existing network in /first-network by ./byfn.sh down and then ran ./byfn.sh up -c mychannel -s couchdb. This runs till the point of all channels getting created, but then my peers dont join my channel and the first peer tries to join, fails, retries a few times, fails and the whole thing stops. I'm wondering has anyone else run into similar/this issue before- how did you go about resolving this? What is the wrong thing I'm doing here/modification I need to do? Thanks!! The following is the last bit of output from my bash:
DeepakMP (Tue, 09 Oct 2018 16:16:01 GMT):
===================== Channel 'mychannel' created =====================
Having all peers join the channel...
+ peer channel join -b mychannel.block
+ res=1
+ set +x
Error: error getting endorser client for channel: endorser client failed to connect to peer0.org1.example.com:7051: failed to create new connection: context deadline exceeded
peer0.org1 failed to join the channel, Retry after 3 seconds
+ peer channel join -b mychannel.block
+ res=1
+ set +x
Error: error getting endorser client for channel: endorser client failed to connect to peer0.org1.example.com:7051: failed to create new connection: context deadline exceeded
peer0.org1 failed to join the channel, Retry after 3 seconds
+ peer channel join -b mychannel.block
+ res=1
+ set +x
Error: error getting endorser client for channel: endorser client failed to connect to peer0.org1.example.com:7051: failed to create new connection: context deadline exceeded
peer0.org1 failed to join the channel, Retry after 3 seconds
+ peer channel join -b mychannel.block
+ res=1
+ set +x
Error: error getting endorser client for channel: endorser client failed to connect to peer0.org1.example.com:7051: failed to create new connection: context deadline exceeded
peer0.org1 failed to join the channel, Retry after 3 seconds
+ peer channel join -b mychannel.block
+ res=1
+ set +x
Error: error getting endorser client for channel: endorser client failed to connect to peer0.org1.example.com:7051: failed to create new connection: context deadline exceeded
!!!!!!!!!!!!!!! After 5 attempts, peer0.org1 has failed to join channel 'mychannel' !!!!!!!!!!!!!!!!
========= ERROR !!! FAILED to execute End-2-End Scenario ===========
asaningmaxchain123 (Tue, 09 Oct 2018 16:20:18 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=XGtPEma4fWqoozr8A) @yacovm that means the invoke should stop?
asaningmaxchain123 (Tue, 09 Oct 2018 16:21:34 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=aC2vhYX7ikby6fpHj) @yacovm stop chaincode or stop invoke?
asaningmaxchain123 (Tue, 09 Oct 2018 16:32:56 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=XGtPEma4fWqoozr8A) @yacovm you give me two answer, i am confused,can you give me more simply answer?
asaningmaxchain123 (Tue, 09 Oct 2018 16:36:54 GMT):
@dave.enyeart @jyellick @mastersingh24 when the chaincode upgrading the invoke transaction should stop until all the peer has upgrade the chaincode successfully?
dave.enyeart (Tue, 09 Oct 2018 21:25:28 GMT):
@asaningmaxchain123 once the chaincode upgrade transaction is committed on the channel, any already inflight transactions from the prior chaincode version will get invalidated upon their commit. any new invoke will utilize the new chaincode version. if some peers do not yet have the new version installed, invoke on those peers will return an error.
dave.enyeart (Tue, 09 Oct 2018 21:25:36 GMT):
takeaways:
dave.enyeart (Tue, 09 Oct 2018 21:25:44 GMT):
1) peers should install the next chaincode version before it is instantiated on the channel (having multiple chaincode versions installed is not a problem, the latest instantiated chaincode will always be used)
dave.enyeart (Tue, 09 Oct 2018 21:25:47 GMT):
2) clients need to handle potential transaction invalidations with retries.
asaningmaxchain123 (Tue, 09 Oct 2018 23:31:47 GMT):
@dave.enyeart which validate code indicate the transaction is invalid due to chaincode upgrade?
Barry_CPF (Wed, 10 Oct 2018 03:42:54 GMT):
Has joined the channel.
ArianStef (Wed, 10 Oct 2018 10:47:20 GMT):
Hi! I am testing a simple network, 1 peer, solo orderer and sending 30 parallel transactions. (I know that this network has no real meaning, but I have to do this trial). Varing batch timeout and batch size I have always this problem: the transactions have all the same commit time (circa 5s) except two/three transactions which commit time is circa 5/10s higher. Those transactions are the first one to send the proposal transaction to the endorsment peer. Logging the timestamp, I notice that is due to the endorsment peer who responds slow for this transactions (the first one), as if it needs a time to wake up from a sleep. Anyone knows why? thank you
ArianStef (Wed, 10 Oct 2018 10:47:50 GMT):
Clipboard - October 10, 2018 12:47 PM
ArianStef (Wed, 10 Oct 2018 10:48:26 GMT):
on the left the commit time for each transaction
ArianStef (Wed, 10 Oct 2018 10:48:53 GMT):
on the right the timestamp for the first 7 transaction
ArianStef (Wed, 10 Oct 2018 10:49:27 GMT):
timestamp:
-send proposal transactio to the end. peer
-
ArianStef (Wed, 10 Oct 2018 10:50:33 GMT):
timestamp:
-invoke code start
-send proposal transaction to the end. peer
-send proposal transaction the orderer
-commit
muralisr (Wed, 10 Oct 2018 21:46:28 GMT):
@ArianStef several things contribute to latency (couple of things you have pointed out - batch timeout and batch size). The initial tx delay could be due to bringing up chaincode (this may include creating the image if not present). My suggestion would be to go through the usual "warm up" with some TXs and then begin measurement
vdods (Thu, 11 Oct 2018 06:08:18 GMT):
Here's a question: I realize the following feature could be abused easily, but is there a way to obtain a lock on a set of specified ledger keys on a specified set of peers, such that others who try to obtain the lock and execute a transaction will have their transaction simulation delayed until the lock is released? Basically as a bit of preventative care to avoid the situation of the orderer rejecting transactions because their RW sets conflict.
yacovm (Thu, 11 Oct 2018 07:06:10 GMT):
you can use state based endorsement @vdods
yacovm (Thu, 11 Oct 2018 07:06:21 GMT):
if you set an endorsement policy of a key
yacovm (Thu, 11 Oct 2018 07:06:31 GMT):
no one can change it but the orgs in the policy....
vdods (Thu, 11 Oct 2018 07:41:46 GMT):
@yacovm Hmm.. that's a pretty heavy-handed thing, right? It would require a configuration update to change?
yacovm (Thu, 11 Oct 2018 07:44:44 GMT):
not a config update
yacovm (Thu, 11 Oct 2018 07:44:56 GMT):
state based endorsement is all chaincode methods
yacovm (Thu, 11 Oct 2018 07:45:02 GMT):
you use chaincode to change the key policy
vdods (Thu, 11 Oct 2018 07:56:14 GMT):
where is the interface defined? This can be called from chaincode?
yacovm (Thu, 11 Oct 2018 07:58:17 GMT):
טקשי
yacovm (Thu, 11 Oct 2018 07:58:19 GMT):
yeah
ShobhitSrivastava (Thu, 11 Oct 2018 11:19:40 GMT):
Has joined the channel.
ShobhitSrivastava (Thu, 11 Oct 2018 11:20:53 GMT):
Hi @yacovm ..I am stuck in one of the issue. It is I have to get endorsement from two peers. These 2 peers are in different org. In java sdk i add two peer in one channel and invoke a code. But in "consistencyGroups" it is more then 1 and hence I am getting exception. How should i get endorsement form two peers.
yacovm (Thu, 11 Oct 2018 11:22:10 GMT):
consistency groups...?
yacovm (Thu, 11 Oct 2018 11:22:18 GMT):
i only know of this term from storage domain
yacovm (Thu, 11 Oct 2018 11:22:26 GMT):
in RAID groups :/
yacovm (Thu, 11 Oct 2018 11:22:43 GMT):
also - java sdk is this way: #fabric-sdk-java ;)
ShobhitSrivastava (Thu, 11 Oct 2018 11:25:01 GMT):
in fabric-java sdk..there is something in code
ShobhitSrivastava (Thu, 11 Oct 2018 11:25:01 GMT):
but it would be good if you can tell me, how can I get endorsement form two peers?
ShobhitSrivastava (Thu, 11 Oct 2018 11:25:28 GMT):
i asked in java-sdk channel
ShobhitSrivastava (Thu, 11 Oct 2018 11:25:46 GMT):
anyway thanks :-)
yacovm (Thu, 11 Oct 2018 11:27:44 GMT):
never used java SDK sorry
ShobhitSrivastava (Thu, 11 Oct 2018 11:30:28 GMT):
no problem thanks
gravity (Thu, 11 Oct 2018 13:18:03 GMT):
hello
trying to setup kafka for an orderer but getting this error:
`2018-10-11 10:31:08.346 UTC [orderer/consensus/kafka] try -> DEBU 0f3 [channel: testchainid] Need to retry because process failed = kafka server: Replication-factor is invalid.`
overall behavior is weird. sometime orderer with kafka cluster starts OK, sometime fails with the error above.
have I missed something?
thanks in advance
atirekg (Thu, 11 Oct 2018 13:36:49 GMT):
Has joined the channel.
atirekg (Thu, 11 Oct 2018 13:37:24 GMT):
Hello Guys,
atirekg (Thu, 11 Oct 2018 13:37:24 GMT):
Hello Guys,
I am using https://github.com/hyperledger/education example
atirekg (Thu, 11 Oct 2018 13:37:24 GMT):
Hello Guys,
I am using https://github.com/hyperledger/education example it is currently working on basis of org1 peer0, want to introduce new peer but getting error when event_hub is trying to registerTxEvent any idea?
atirekg (Thu, 11 Oct 2018 13:37:24 GMT):
Hello Guys,
I am using https://github.com/hyperledger/education example it is currently working on basis of org1 peer0, want to introduce new peer but getting error when event_hub is trying to registerTxEvent.
any idea how can I solve it?
ArianStef (Thu, 11 Oct 2018 14:40:41 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=JhgdBrS5JMpKzyCog) @muralisr thank you!
ArianStef (Thu, 11 Oct 2018 14:44:29 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=XbubB6ttoqsRezFBY) @atirekg this may help https://github.com/hyperledger/fabric-samples/tree/release/balance-transfer
asaningmaxchain123 (Thu, 11 Oct 2018 17:52:23 GMT):
@yacovm @jyellick @dave.enyeart can you provide an exmaple for me about `Setting key-level endorsement policies`
dave.enyeart (Thu, 11 Oct 2018 18:40:07 GMT):
@asaningmaxchain123 please dont mention me for the same question in multiple channels. i've replied in #fabric-ledger
asaningmaxchain123 (Thu, 11 Oct 2018 18:44:38 GMT):
ok
yacovm (Thu, 11 Oct 2018 20:01:32 GMT):
@asaningmaxchain123 I believe there is a (sample chaincode in review)[https://gerrit.hyperledger.org/r/#/c/26232/12/interest_rate_swaps/chaincode/chaincode.go]
yacovm (Thu, 11 Oct 2018 20:01:32 GMT):
@asaningmaxchain123 I believe there is a [sample chaincode in review](https://gerrit.hyperledger.org/r/#/c/26232/12/interest_rate_swaps/chaincode/chaincode.go)
atirekg (Fri, 12 Oct 2018 06:49:36 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=QDsztGGuSWwifEo84) @ArianStef I have tried to implement the multi organization and multiple peer from this example but no success
waxer (Fri, 12 Oct 2018 12:30:38 GMT):
Has joined the channel.
atirekg (Fri, 12 Oct 2018 16:56:35 GMT):
Guys, trying to upgrade my chaincode
current version is app-1.0
running following command to upgrade
`docker exec -e "CORE_PEER_LOCALMSPID=Org1MSP" -e "CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp" cli peer chaincode upgrade -C mychannel -n app -v 1.1 -p github.com/app -c '{"Args":[""]}' -P "OR ('Org1MSP.member','Org2MSP.member')"`
error I am getting
2018-10-12 16:43:03.267 UTC [endorser] callChaincode -> INFO 0c8 [][f208804e] Entry chaincode: name:"cscc"
2018-10-12 16:43:03.271 UTC [endorser] callChaincode -> INFO 0c9 [][f208804e] Exit chaincode: name:"cscc" (5ms)
2018-10-12 16:43:03.296 UTC [endorser] callChaincode -> INFO 0ca [mychannel][d19e1b99] Entry chaincode: name:"lscc"
2018-10-12 16:43:03.298 UTC [lscc] executeDeployOrUpgrade -> ERRO 0cb cannot get package for chaincode (app:1.1)-err:open /var/hyperledger/production/chaincodes/app.1.1: no such file or directory
2018-10-12 16:43:03.304 UTC [endorser] callChaincode -> INFO 0cc [mychannel][d19e1b99] Exit chaincode: name:"lscc" (8ms)
2018-10-12 16:43:03.305 UTC [endorser] ProcessProposal -> ERRO 0cd [mychannel][d19e1b99] simulateProposal() resulted in chaincode name:"lscc" response status 500 for txid: d19e1b99b9370fc9635bd97afee2a62ce835749184a7eec1eee65d73ae289fcb
ubuntu@ip-172-31-16-152:~/example/app$ docker exec -e "CORE_PEER_LOCALMSPID=Org1MSP" -e "CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp" cli
muralisr (Fri, 12 Oct 2018 17:47:36 GMT):
@atirekg `cannot get package for chaincode (app:1.1)-err:open /var/hyperledger/production/chaincodes/app.1.1: no such file or directory` - did you install the to-be-upgraded chaincode (using `peer chaincode install -n app -v 1.1 ...`) ?
atirekg (Sun, 14 Oct 2018 08:39:26 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=foKvX4hnQNrCWCgTj) @muralisr No I haven't installed it
atirekg (Sun, 14 Oct 2018 08:39:26 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=foKvX4hnQNrCWCgTj) @muralisr No I haven't installed it, as there was no isntruction about it, let me do it then will ask again, Thanks :)
ASell (Sun, 14 Oct 2018 21:21:04 GMT):
Has joined the channel.
atirekg (Mon, 15 Oct 2018 09:08:09 GMT):
Guys, I am getting `undefined` for `event_hub.setPeerAddr('grpc://localhost:7053');`
atirekg (Mon, 15 Oct 2018 09:08:09 GMT):
Guys, I am getting `undefined` for `event_hub.setPeerAddr('grpc://localhost:7053');` anyidea?
atirekg (Mon, 15 Oct 2018 09:08:09 GMT):
Guys, I am getting `undefined` for `event_hub.setPeerAddr('grpc://localhost:7053');` anyidea?
atirekg (Mon, 15 Oct 2018 09:08:09 GMT):
Guys, I am getting `undefined` for `event_hub.setPeerAddr('grpc://localhost:7053');` any idea?
leusgrif (Mon, 15 Oct 2018 09:12:51 GMT):
Has joined the channel.
sheetal-hlf (Tue, 16 Oct 2018 05:07:26 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=3CE4rn6tWLZtBYiwB) @atirekg I think the event port is 7051; since the channel-based events were introduced
atirekg (Tue, 16 Oct 2018 06:02:34 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=ZNYLokv3Es4ki8S3n) @sheetal-hlf thanks, but it looks like something else to me port 7051 is also not working
sheetal-hlf (Tue, 16 Oct 2018 07:41:28 GMT):
does the peer hostname and grpc address match?
huikang (Wed, 17 Oct 2018 02:56:54 GMT):
Has joined the channel.
atirekg (Wed, 17 Oct 2018 09:25:43 GMT):
no it was fine, I have upgraded the version of fabric client sdk to 1.3.0 and changed the way of event_hub, it's gone now
atirekg (Wed, 17 Oct 2018 13:01:59 GMT):
Guys, I am generating new and trying to make them live
I have used command `cryptogen extend --config=./crypto-config.yaml` to generate the peer files
but getting following error
`2018-10-17 12:57:37.625 UTC [main] main -> ERRO 001 Cannot run peer because error when setting up MSP of type bccsp from directory /etc/hyperledger/msp/peer/: the supplied identity is not valid: x509: certificate signed by unknown authority`
atirekg (Wed, 17 Oct 2018 13:01:59 GMT):
Guys, I am generating new peer and trying to make them live
I have used command `cryptogen extend --config=./crypto-config.yaml` to generate the peer files
but getting following error
`2018-10-17 12:57:37.625 UTC [main] main -> ERRO 001 Cannot run peer because error when setting up MSP of type bccsp from directory /etc/hyperledger/msp/peer/: the supplied identity is not valid: x509: certificate signed by unknown authority`
atirekg (Thu, 18 Oct 2018 09:34:38 GMT):
`2018-10-18 09:31:37.379 UTC [main] main -> ERRO 001 Cannot run peer because cannot init crypto, missing /etc/hyperledger/msp/users/Admin@org2.apple.com/msp folder`
atirekg (Thu, 18 Oct 2018 09:35:27 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=NngiQ94R2Ey4ofqGs) I have regenerated new certificates and this is solved now
atirekg (Thu, 18 Oct 2018 09:35:43 GMT):
`2018-10-18 09:31:37.379 UTC [main] main -> ERRO 001 Cannot run peer because cannot init crypto, missing /etc/hyperledger/msp/users/Admin@org2.apple.com/msp folder`
Anyone about this?
atirekg (Thu, 18 Oct 2018 11:03:58 GMT):
Guys, anyone know anything about this error `Error: failed to create deliver client: failed to load config for OrdererClient: unable to load orderer.tls.rootcert.file: open /etc/hyperledger/fabric/tlsca.apple.com-cert.pem: no such file or directory`
ArianStef (Thu, 18 Oct 2018 12:35:56 GMT):
Hi! I have a doubt regarding the command `peer chaincode invoke`. Do this command check if the endorsement policy is fulfilled before sending the transaction to the ordering service?
tchataigner (Thu, 18 Oct 2018 15:32:08 GMT):
Has joined the channel.
gravity (Thu, 18 Oct 2018 15:55:30 GMT):
Hi all
I'm trying to upgrade a chaincode after joining a new org to a channel, but getting this error:
```
root@b88c1a11958a:/opt/gopath/src/github.com/hyperledger/fabric/peer# CORE_PEER_MSPCONFIGPATH=/data/orgs/partners-org/admin/msp peer chaincode upgrade -o partners-orderer-1:7050 -C tmpchannel -n common -v 2.0 -P "OR ('main-orgMSP.member','partners-orgMSP.member')" -c '{"Args":["init", ""]}'
2018-10-18 15:00:13.799 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 001 Using default escc
2018-10-18 15:00:13.799 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 002 Using default vscc
Error: got unexpected status: NOT_FOUND -- channel does not exist
```
but the peer is a member of this channel
Does anyone know how to fix it?
gravity (Thu, 18 Oct 2018 16:06:48 GMT):
and another one:
Given the situation:
I've a single org network. Later, I've added one more and joined peer1 from that org to a channel named tmpchannel.
Next, I can enroll as a user1 on ica server related to org1 and call a chaincode and everything is ok.
Next, I login to peer1 in org2, enrolled user1 using ica server related to org1 and attempting to call a chaincode, but getting the error:
```
2018-10-18 16:00:30.997 UTC [protoutils] ValidateProposalMessage -> WARN 04d channel [tmpchannel]: MSP error: the supplied identity is not valid: x509: certificate signed by unknown authority
```
Is it a correct behavior?
atirekg (Thu, 18 Oct 2018 16:13:00 GMT):
@gravity can you please help me to join a new org to a channel, I have created the new org but not able to get how to join the channel
gravity (Thu, 18 Oct 2018 16:18:28 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=nAwzStY5Hs33J2qr4) @atirekg Have you check the documentation on how to join org to a channel?
atirekg (Thu, 18 Oct 2018 16:35:27 GMT):
yes
atirekg (Thu, 18 Oct 2018 16:35:27 GMT):
@gravity yes
atirekg (Thu, 18 Oct 2018 16:37:02 GMT):
I am getting this error
`Error: got unexpected status: BAD_REQUEST -- error authorizing update: Update not for correct channel: for mychannel`
for command `peer channel update -f org2_update_in_envelope.pb -c mychannel -o orderer.apple.com:7050 --cafile tlsca.apple.com-cert.pem`
atirekg (Thu, 18 Oct 2018 16:37:29 GMT):
running this command on cli
atirekg (Thu, 18 Oct 2018 16:37:29 GMT):
running this command on cli docker
yousaf (Thu, 18 Oct 2018 17:09:16 GMT):
@jyellick If a peer has installed multiple same named multiple chaincodes for multiple channels(which the peer have joined.) then is it necessary that their versions should be different?
ibmamnt (Fri, 19 Oct 2018 00:50:54 GMT):
Has joined the channel.
gravity (Fri, 19 Oct 2018 09:42:28 GMT):
Hello
is there any recommendations on how many peers should be serving a channel for a better throughput?
yousaf (Fri, 19 Oct 2018 19:22:34 GMT):
@jyellick Are the anchor peers specified for an organization, per channel separately? Or they are fixed while developing the network, independent of the channel?
PCP 1 (Mon, 22 Oct 2018 16:27:35 GMT):
Has joined the channel.
PCP 1 (Mon, 22 Oct 2018 16:28:12 GMT):
Hello everyone. I have an issue, both peers (peer 0 and peer 1) stopped with this error: func1 -> ERRO 002 Received error from server: rpc error: code = Unknown desc = Error handling message, ending stream: transition canceled with error: peer will not accepting external chaincode connection name:"mycc:1.0" (except in dev mode), ending chaincode stream
PCP 1 (Mon, 22 Oct 2018 16:28:23 GMT):
Could anyone help decipher this? It used to work fine until not long ago.
PCP 1 (Mon, 22 Oct 2018 16:37:33 GMT):
Sorry, I found the issue. Ran out of disk space :-|
PCP 1 (Mon, 22 Oct 2018 16:37:36 GMT):
I solved it
atirekg (Mon, 22 Oct 2018 18:45:54 GMT):
I am getting this error
`Error: got unexpected status: BAD_REQUEST -- error authorizing update: Update not for correct channel: for mychannel`
for command `peer channel update -f org2_update_in_envelope.pb -c mychannel -o orderer.apple.com:7050 --cafile tlsca.apple.com-cert.pem`
running this command on cli docker
atirekg (Mon, 22 Oct 2018 18:45:54 GMT):
I am getting this error
`Error: got unexpected status: BAD_REQUEST -- error authorizing update: Update not for correct channel: for mychannel`
for command `peer channel update -f org2_update_in_envelope.pb -c mychannel -o orderer.apple.com:7050 --cafile tlsca.apple.com-cert.pem`
running this command on cli docker
anyone?
atirekg (Mon, 22 Oct 2018 18:45:54 GMT):
I am getting this error
`Error: got unexpected status: BAD_REQUEST -- error authorizing update: Update not for correct channel: for mychannel`
for command `peer channel update -f org2_update_in_envelope.pb -c mychannel -o orderer.apple.com:7050 --cafile tlsca.apple.com-cert.pem`
running this command on cli docker, trying to add new org into the channel
anyone?
atirekg (Mon, 22 Oct 2018 18:45:54 GMT):
I am getting this error
`Error: got unexpected status: BAD_REQUEST -- error authorizing update: Update not for correct channel: for mychannel`
for command `peer channel update -f org2_update_in_envelope.pb -c mychannel -o orderer.apple.com:7050 --cafile tlsca.apple.com-cert.pem`
running this command on cli docker, trying to add new org into the channel
atirekg (Mon, 22 Oct 2018 18:45:54 GMT):
I am getting this error
`Error: got unexpected status: BAD_REQUEST -- error authorizing update: Update not for correct channel: for mychannel`
for command `peer channel update -f org2_update_in_envelope.pb -c mychannel -o orderer.apple.com:7050 --cafile tlsca.apple.com-cert.pem`
running this command on cli docker, trying to add new org into the channel
atirekg (Mon, 22 Oct 2018 18:45:54 GMT):
I am getting this error
`Error: got unexpected status: BAD_REQUEST -- error authorizing update: Update not for correct channel: for mychannel`
for command `peer channel update -f org2_update_in_envelope.pb -c mychannel -o orderer.apple.com:7050 --cafile tlsca.apple.com-cert.pem`
running this command on cli docker, trying to add new org into the channel
and `Error: failed to create deliver client: failed to load config for OrdererClient: unable to load orderer.tls.rootcert.file: open /etc/hyperledger/fabric/tlsca.apple.com-cert.pem: no such file or directory` for
`peer channel update -f org2_update_in_envelope.pb -c mychannel -o orderer.apple.com:7050 --tls --cafile tlsca.apple.com-cert.pem` command
please help
atirekg (Mon, 22 Oct 2018 18:47:19 GMT):
and `Error: failed to create deliver client: failed to load config for OrdererClient: unable to load orderer.tls.rootcert.file: open /etc/hyperledger/fabric/tlsca.apple.com-cert.pem: no such file or directory` for
`peer channel update -f org2_update_in_envelope.pb -c mychannel -o orderer.apple.com:7050 --tls --cafile tlsca.apple.com-cert.pem` command
atirekg (Mon, 22 Oct 2018 18:47:23 GMT):
please help
atirekg (Tue, 23 Oct 2018 06:50:30 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=e2gR4uM9KC4YF5yYW) Anyone?
jrosmith (Tue, 23 Oct 2018 12:54:45 GMT):
hey all, i have a question regarding batch timeouts and block validation. i successfully updated my channel configuration to have a BatchTimeout of 100ms, but am still getting MVCC errors. specifically in the following scenario:
txnA updates key1 => val1. ~300 ms later txnB updates key1 => val2. txnB fails with an MVCC error.
i'm assuming that since they occur 300ms apart they would be in separate blocks based on the configured BatchTimeout. is it the vscc that is rejecting with the MVCC error? if so why would the transaction be rejected if my assumption is correct and they are in separate blocks?
atirekg (Tue, 23 Oct 2018 13:15:09 GMT):
Hello guys getting following error while trying to add new Org into the network
`2018-10-23 13:09:05.825 UTC [msp] setupSigningIdentity -> DEBU 035 Signing identity expires at 2028-10-14 14:54:22 +0000 UTC
2018-10-23 13:09:05.825 UTC [msp] Validate -> DEBU 036 MSP Org1MSP validating identity
2018-10-23 13:09:05.825 UTC [msp] GetDefaultSigningIdentity -> DEBU 037 Obtaining default signing identity
2018-10-23 13:09:05.825 UTC [grpc] DialContext -> DEBU 038 parsed scheme: ""
2018-10-23 13:09:05.825 UTC [grpc] DialContext -> DEBU 039 scheme "" not registered, fallback to default scheme
2018-10-23 13:09:05.825 UTC [grpc] watcher -> DEBU 03a ccResolverWrapper: sending new addresses to cc: [{orderer.apple.com:7050 0
jrosmith (Tue, 23 Oct 2018 13:16:40 GMT):
@atirekg all of your errors seem to be related to cert issues. the error logs explicitly state `transport: authentication handshake failed: tls: first record does not look like a TLS handshake`
jrosmith (Tue, 23 Oct 2018 13:17:11 GMT):
check your certs and make sure your applications are looking for them in the right place
atirekg (Tue, 23 Oct 2018 13:17:35 GMT):
yes tried all mentioned ways but always getting this error
jrosmith (Tue, 23 Oct 2018 13:18:15 GMT):
do you have secure ssl set up on both ends?
atirekg (Tue, 23 Oct 2018 13:18:35 GMT):
I am trying on local
atirekg (Tue, 23 Oct 2018 13:18:45 GMT):
first org is running
atirekg (Tue, 23 Oct 2018 13:19:01 GMT):
and able to join multiple peer in first org
atirekg (Tue, 23 Oct 2018 13:19:24 GMT):
but when I am trying to add new org then getting the problem
jrosmith (Tue, 23 Oct 2018 13:19:30 GMT):
right when i say both ends i mean services. even if you are running things locally you cant designate only one service to use secure ssl
jrosmith (Tue, 23 Oct 2018 13:20:04 GMT):
have you properly set up the new orgs crypto material and added it to the channel configuration?
atirekg (Tue, 23 Oct 2018 13:21:15 GMT):
yes, generated by same method `cryptogen generate --config=./crypto-config-org2.yaml`
atirekg (Tue, 23 Oct 2018 13:21:48 GMT):
then I am fetching the channel config block from orderer on org2 cli
atirekg (Tue, 23 Oct 2018 13:21:55 GMT):
and getting this error
jrosmith (Tue, 23 Oct 2018 13:22:32 GMT):
have you updated your network configuration to allow org2 to be a member?
jrosmith (Tue, 23 Oct 2018 13:23:08 GMT):
just generating the crypto material then attempting to fetch the block isnt enough, all of that crypto material needs to be added to the network config
atirekg (Tue, 23 Oct 2018 13:23:44 GMT):
I am following instructions from eyfn.sh (first-network)
atirekg (Tue, 23 Oct 2018 13:24:38 GMT):
is there any standard guide or step how to do it?
atirekg (Tue, 23 Oct 2018 13:24:59 GMT):
https://hyperledger-fabric.readthedocs.io/en/latest/channel_update_tutorial.html
atirekg (Tue, 23 Oct 2018 13:25:13 GMT):
this tutorial I am following
jrosmith (Tue, 23 Oct 2018 13:26:24 GMT):
that is the standard guide. from your earlier posts it looks like the channel update was not configured properly and was rejected
atirekg (Tue, 23 Oct 2018 13:27:02 GMT):
yes I got this error when I follow the tutorial
I am getting this error
`Error: got unexpected status: BAD_REQUEST -- error authorizing update: Update not for correct channel: for mychannel`
for command `peer channel update -f org2_update_in_envelope.pb -c mychannel -o orderer.apple.com:7050 --cafile tlsca.apple.com-cert.pem`
running this command on cli docker, trying to add new org into the channel
and `Error: failed to create deliver client: failed to load config for OrdererClient: unable to load orderer.tls.rootcert.file: open /etc/hyperledger/fabric/tlsca.apple.com-cert.pem: no such file or directory` for
`peer channel update -f org2_update_in_envelope.pb -c mychannel -o orderer.apple.com:7050 --tls --cafile tlsca.apple.com-cert.pem` command
atirekg (Tue, 23 Oct 2018 13:27:27 GMT):
then I started doing it manually from eyfn.sh (first-network) then get different error
atirekg (Tue, 23 Oct 2018 13:28:06 GMT):
I am not sure where I am making the mistake
atirekg (Tue, 23 Oct 2018 13:28:17 GMT):
but tried many time from start
jrosmith (Tue, 23 Oct 2018 13:29:48 GMT):
i think the reason you are struggling to get help is because you are posting multiple error logs from different examples without any context.
jrosmith (Tue, 23 Oct 2018 13:30:10 GMT):
in order to help we will need to see what you have attempted to insert as an update to the network config
jrosmith (Tue, 23 Oct 2018 13:30:27 GMT):
please use a service like hastebin.com to post what youre attempting to change
atirekg (Tue, 23 Oct 2018 13:34:16 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=55gc2vYD2zmDMHN9h) @jrosmith the above error I was getting from 18oct and didn't get any help, then I tried different way and get different error.
ok, I will prepare the full attempt then will post it here for old error
jrosmith (Tue, 23 Oct 2018 13:41:08 GMT):
@atirekg i understand your frustration when questions are not replied to, but please bear in mind that everyone here has a day job and is difficult to set aside time to pick through logs without context in an effort to assist. the more specific you can be about what you were attempting to do, what example you were following, and at what step there was an error, the easier it will be for channel members to help
atirekg (Tue, 23 Oct 2018 13:47:10 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=qS82ZnYS35Fi6YGfr) @jrosmith yes, and technology is new so possibly everyone don't know the answers, I was not frustrated but tried :)
githubcpc (Wed, 24 Oct 2018 07:08:18 GMT):
Hi.Could specify dynamic endorsement policy？The endorsement policy specified only when instantiate the chaincode ?Is there another way to specify it?
yacovm (Wed, 24 Oct 2018 08:15:14 GMT):
you can't have a dynamic EP
yacovm (Wed, 24 Oct 2018 08:15:24 GMT):
you can only upgrade the EP via chaincode upgrade
githubcpc (Wed, 24 Oct 2018 08:16:11 GMT):
Thanks.
ShobhitSrivastava (Wed, 24 Oct 2018 08:57:57 GMT):
hey @yacovm ```
I have a ques in hyperledger fabric. I am using Couch DB as state DB and using two peers in channel. However I am able to delete the keys and update value in Json. How is this replicated? If I am able to change value in Json key and value.
```
yacovm (Wed, 24 Oct 2018 09:25:16 GMT):
You change keys manually via the database?
ShobhitSrivastava (Wed, 24 Oct 2018 09:53:03 GMT):
yes
ShobhitSrivastava (Wed, 24 Oct 2018 09:53:48 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=d453b341-97e3-4af8-8e98-5653cbcb9bc4) @yacovm correct. I wanted to check if further transaction will get affected due to it.
dave.enyeart (Wed, 24 Oct 2018 09:57:39 GMT):
If you 'tamper' with state db data directly, then the peer will not match other peers and cause proposal responses to not match other peers, this will result in clients throwing away the 'bad' proposals sent to that peer or if submitted to ordering regardless, will cause transaction to get invalidated. In short, don't tamper with state database, as it will be found out and that peer will be not trusted and isolated
ShobhitSrivastava (Wed, 24 Oct 2018 10:02:29 GMT):
hey @dave.enyeart . I need to give business guys as how this peer will be isolated. But in fabric, It does not happen automatically. Also once I delete one key from statedb I am still able to create new transactions. Ideally block of chain should get corrupted and block should not get created.
ShobhitSrivastava (Wed, 24 Oct 2018 10:03:03 GMT):
hey @dave.enyeart . I need to give business guys an explanation as how this peer will be isolated. But in fabric, It does not happen automatically. Also once I delete one key from statedb I am still able to create new transactions. Ideally block of chain should get corrupted and block should not get created.
dave.enyeart (Wed, 24 Oct 2018 10:08:58 GMT):
Clients send proposals to multiple peers and check consistency of results. If one peer doesn't match, clients won't trust that peer anymore and will not go to it anymore. Doing a verification of entire chain for each transaction is prohibitively expensive. You can do a verification of peer's blockchain using external tools instead. Think of statedb as a cache. If it's data is in doubt you can drop statedb and it will be rebuilt from the blockchain automatically upon peer restart. But I'd recommend lock down couchdb by not exposing couchdb port beyond the peer's docker network and have peer use username/password to ensure it cannot be tampered by external users in the first place.
ShobhitSrivastava (Wed, 24 Oct 2018 10:16:33 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=fz6chQmjWMTZy4jXY) @dave.enyeart Sounds logical. I thought of locking couchdb in some manner. Thanks for giving confirmation on my thoughts.
ShobhitSrivastava (Wed, 24 Oct 2018 10:59:53 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=fz6chQmjWMTZy4jXY) @dave.enyeart Sorry for posting again. I stopped my peer and couch db instance and started them both. But I still got same old ledger having fews keys deleted by me. Any thought on that?
dave.enyeart (Wed, 24 Oct 2018 11:04:16 GMT):
You have to drop statedb (delete) if you want peer to rebuild it
ShobhitSrivastava (Wed, 24 Oct 2018 11:11:52 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=r2W4ZFu69y4Cfh3FL) @dave.enyeart can you suggest any reading to delete statedb. I deleted from CouchDb frontend. But after restart it does not work
dave.enyeart (Wed, 24 Oct 2018 11:13:03 GMT):
If you are using couchdb, deleting the /opt/couchdb/data directory would do the trick
ShobhitSrivastava (Wed, 24 Oct 2018 11:13:30 GMT):
okay. Checking
ShobhitSrivastava (Wed, 24 Oct 2018 11:21:09 GMT):
hey thanks alot @dave.enyeart
ShobhitSrivastava (Wed, 24 Oct 2018 11:21:15 GMT):
appreciate a lot
ShobhitSrivastava (Wed, 24 Oct 2018 11:21:37 GMT):
cheers man:smile:
jrosmith (Wed, 24 Oct 2018 13:22:53 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=gNQcRKeBsWFQEfdqa) bumping for visibility
jrosmith (Wed, 24 Oct 2018 15:18:36 GMT):
please ignore the above, it has been answered in #fabric-orderer
cagdast (Thu, 25 Oct 2018 07:53:40 GMT):
Has joined the channel.
MohammadObaid (Thu, 25 Oct 2018 16:27:05 GMT):
Has joined the channel.
MohammadObaid (Thu, 25 Oct 2018 16:28:42 GMT):
Question . Since chaincode only simulate by endorsing peers , so how does committer who is not an endorser validate read write set as writeset is generated after executing chaincode . What exactly does committer check except signature validations
MohammadObaid (Thu, 25 Oct 2018 16:28:42 GMT):
Question . Since chaincode only simulate by endorsing peers , so how does committer who is not an endorser validate read write set as writeset is generated after executing chaincode . What exactly does committer check except signature validations ?
albert.lacambra (Thu, 25 Oct 2018 19:54:11 GMT):
Hi
while trying to instantiate a chaincode I am having this error
2018-10-25 19:45:14.055 UTC [gossip/state] commitBlock -> ERRO 0b3 Got error while committing(unexpected Previous block hash. Expected PreviousHash = [2e2048fcf6bcc4d99c210d7cdd99e135e0de419e35d6ccc7f5a1d58e25bc6ad0], PreviousHash referred in the latest block= [19ee18412db71ea5ddbc52a9e6fd4d8a56c8de695e15f7755e2dd3db7b675370]
the peer is immediatly killed
I have no idea what can be :s
here whole stacktzrace in case it helps: https://gist.github.com/alacambra/4f7d3e2c488bf4282c22d9910e3bb54d
albert.lacambra (Thu, 25 Oct 2018 19:54:11 GMT):
Hi
while trying to instantiate a chaincode I am having this error
2018-10-25 19:45:14.055 UTC [gossip/state] commitBlock -> ERRO 0b3 Got error while committing(unexpected Previous block hash. Expected PreviousHash = [2e2048fcf6bcc4d99c210d7cdd99e135e0de419e35d6ccc7f5a1d58e25bc6ad0], PreviousHash referred in the latest block= [19ee18412db71ea5ddbc52a9e6fd4d8a56c8de695e15f7755e2dd3db7b675370]
*the peer is immediatly killed*
I have no idea what can be :s
here whole stacktzrace in case it helps: https://gist.github.com/alacambra/4f7d3e2c488bf4282c22d9910e3bb54d
albert.lacambra (Thu, 25 Oct 2018 19:54:11 GMT):
Hi
while trying to instantiate a chaincode I am having this error
2018-10-25 19:45:14.055 UTC [gossip/state] commitBlock -> ERRO 0b3 Got error while committing(unexpected Previous block hash. Expected PreviousHash = [2e2048fcf6bcc4d99c210d7cdd99e135e0de419e35d6ccc7f5a1d58e25bc6ad0], PreviousHash referred in the latest block= [19ee18412db71ea5ddbc52a9e6fd4d8a56c8de695e15f7755e2dd3db7b675370]
## *the peer is immediatly killed*
I have no idea what can be :s
here whole stacktzrace in case it helps: https://gist.github.com/alacambra/4f7d3e2c488bf4282c22d9910e3bb54d
albert.lacambra (Thu, 25 Oct 2018 19:54:11 GMT):
Hi
while trying to instantiate a chaincode I am having this error
2018-10-25 19:45:14.055 UTC [gossip/state] commitBlock -> ERRO 0b3 Got error while committing(unexpected Previous block hash. Expected PreviousHash = [2e2048fcf6bcc4d99c210d7cdd99e135e0de419e35d6ccc7f5a1d58e25bc6ad0], PreviousHash referred in the latest block= [19ee18412db71ea5ddbc52a9e6fd4d8a56c8de695e15f7755e2dd3db7b675370] *the peer is immediatly killed*
I have no idea what can be :s
here whole stacktzrace in case it helps: https://gist.github.com/alacambra/4f7d3e2c488bf4282c22d9910e3bb54d
albert.lacambra (Thu, 25 Oct 2018 19:54:11 GMT):
Hi
while trying to instantiate a chaincode I am having this error
2018-10-25 19:45:14.055 UTC [gossip/state] commitBlock -> ERRO 0b3 Got error while committing(unexpected Previous block hash. Expected PreviousHash = [2e2048fcf6bcc4d99c210d7cdd99e135e0de419e35d6ccc7f5a1d58e25bc6ad0], PreviousHash referred in the latest block= [19ee18412db71ea5ddbc52a9e6fd4d8a56c8de695e15f7755e2dd3db7b675370] *the peer is immediatly killed*
I have no idea what can be :s
here whole stacktzrace in case it helps: https://gist.github.com/alacambra/4f7d3e2c488bf4282c22d9910e3bb54d
albert.lacambra (Thu, 25 Oct 2018 19:54:11 GMT):
Hi
while trying to instantiate a chaincode I am having this error
2018-10-25 19:45:14.055 UTC [gossip/state] commitBlock -> ERRO 0b3 Got error while committing(unexpected Previous block hash. Expected PreviousHash = [2e2048fcf6bcc4d99c210d7cdd99e135e0de419e35d6ccc7f5a1d58e25bc6ad0], PreviousHash referred in the latest block= [19ee18412db71ea5ddbc52a9e6fd4d8a56c8de695e15f7755e2dd3db7b675370]
*the peer is immediatly killed*
I have no idea what can be :s
here whole stacktzrace in case it helps: https://gist.github.com/alacambra/4f7d3e2c488bf4282c22d9910e3bb54d
aso (Mon, 29 Oct 2018 08:36:00 GMT):
> Question . Since chaincode only simulate by endorsing peers , so how does committer who is not an endorser validate read write set as writeset is generated after executing chaincode . What exactly does committer check except signature validations ?
the mostly validator checks 2 things:
1) compliance of the transaction with the endorsement policy: that basically entails signature checks and policy checks
2) concurrency control checks: the writes in the read-write set are applied only if all variables that were read at simulation time haven't changed since - this is a check over versions. (this description is a simplification but it should give you the big picture).
Mostly: there is no semantic check on the correctness of any value - that's implied in the trust assusmptions over the endorsement policy
mko (Mon, 29 Oct 2018 11:58:58 GMT):
Has joined the channel.
aatkddny (Mon, 29 Oct 2018 13:54:08 GMT):
I *think* this is the right venue for this question. If not pls point me elsewhere - this pertains to performing chaincode instantiation.
Is it (now) normal to get different length proposal responses from different peers? Running 1.3.0 - have never seen this problem until an inadvertent upgrade from 1.2.0.
1.0 and 1.1 never exhibited this behavior either.
qizhang (Mon, 29 Oct 2018 20:15:19 GMT):
Question: since the transaction proposals on a peer are simulated in parallel (each in a different goroutine), is there any limitation on how many such goroutines can exist in parallel?
nhrishi (Tue, 30 Oct 2018 10:35:47 GMT):
Hi, I am using v1.3 version and seeing below error in the peer log. Any idea what does this mean and how to resolve. Error -- ```{"log":"\u001b[36m2018-10-30 10:01:21.476 UTC [deliveryClient] connect -\u003e DEBU 372\u001b[0m Connected to orderer0.example.com:7050\n","stream":"stderr","time":"2018-10-30T10:01:21.476432032Z"}
{"log":"\u001b[36m2018-10-30 10:01:21.476 UTC [deliveryClient] connect -\u003e DEBU 373\u001b[0m Establishing gRPC stream with orderer0.example.com:7050 ...\n","stream":"stderr","time":"2018-10-30T10:01:21.476453531Z"}
{"log":"\u001b[36m2018-10-30 10:01:21.476 UTC [deliveryClient] afterConnect -\u003e DEBU 374\u001b[0m Entering\n","stream":"stderr","time":"2018-10-30T10:01:21.476547581Z"}
{"log":"\u001b[36m2018-10-30 10:01:21.476 UTC [deliveryClient] RequestBlocks -\u003e DEBU 375\u001b[0m Starting deliver with block [1] for channel globalchannel\n","stream":"stderr","time":"2018-10-30T10:01:21.476560941Z"}
{"log":"\u001b[36m2018-10-30 10:01:21.476 UTC [deliveryClient] afterConnect -\u003e DEBU 376\u001b[0m Exiting\n","stream":"stderr","time":"2018-10-30T10:01:21.476818024Z"}
{"log":"\u001b[31m2018-10-30 10:01:21.481 UTC [blocksProvider] DeliverBlocks -\u003e ERRO 377\u001b[0m [globalchannel] Got error \u0026{FORBIDDEN}\n","stream":"stderr","time":"2018-10-30T10:01:21.482197137Z"}
```.
ArianStef (Wed, 31 Oct 2018 15:50:47 GMT):
Clipboard - October 31, 2018 12_54 PM.png
ArianStef (Wed, 31 Oct 2018 15:52:26 GMT):
Clipboard - October 31, 2018 4_28 PM.png
ArianStef (Wed, 31 Oct 2018 15:53:03 GMT):
Clipboard - October 31, 2018 4_28 PM.png
bh4rtp (Thu, 01 Nov 2018 00:15:08 GMT):
hi, install chaincode succeeded but instantiate chaincode failed. i could not find any message on chaincode instantiate from peer logs. and there was a message about chaincode install:
```
2018-10-31 08:40:33.603 CST [cceventmgmt] HandleChaincodeInstall -> DEBU 4d51 Channel [mychannel]: Chaincode [Name=register, Version=v1, Hash=[]byte{0xc4, 0xb0, 0xd, 0xc, 0xaf, 0xdc, 0xda, 0xb1, 0x5, 0xc6, 0x7c, 0x2d, 0xc3, 0xe2, 0xc, 0x17, 0xd1, 0xfc, 0xf0, 0x1f, 0x53, 0xb5, 0x7f, 0x63, 0x54, 0x5e, 0xc2, 0xd, 0x6d, 0x8, 0x4b, 0xa5}] is not deployed on channel hence not creating chaincode artifacts.
```
what does `not deployed on channel hence not creating chaincode artifacts` mean? and is it the reason?
waxer (Thu, 01 Nov 2018 00:24:39 GMT):
@bh4rtp , What is the output of the instantiation request?
bh4rtp (Thu, 01 Nov 2018 00:27:56 GMT):
@waxer it prints bad instantiate proposal.
bh4rtp (Thu, 01 Nov 2018 00:28:17 GMT):
i am using `balance-transfer` as an example.
bh4rtp (Thu, 01 Nov 2018 02:20:09 GMT):
hi, i filtered the messages from peer logs and the following lines may relate to instantiate chaincode.
```2018-11-01 09:46:58.183 CST [chaincode] handleMessage -> DEBU 6078 [805147b5] Fabric side handling ChaincodeMessage of type: COMPLETED in state ready
2018-11-01 09:46:58.183 CST [chaincode] Notify -> DEBU 6079 [805147b5] notifying Txid:805147b529315755b05890db4e5aabe8b86a17f652e4613ae45d05ced73b2b19, channelID:registerch
2018-11-01 09:46:58.183 CST [chaincode] Execute -> DEBU 607a Exit
2018-11-01 09:46:58.183 CST [endorser] callChaincode -> INFO 607b [registerch][805147b5] Exit chaincode: name:"lscc" (53ms)
2018-11-01 09:46:58.183 CST [lockbasedtxmgr] GetTxSimulationResults -> DEBU 607c Simulation completed, getting simulation results
2018-11-01 09:46:58.183 CST [lockbasedtxmgr] Done -> DEBU 607d Done with transaction simulation / query execution [805147b529315755b05890db4e5aabe8b86a17f652e4613ae45d05ced73b2b19]
2018-11-01 09:46:58.183 CST [endorser] SimulateProposal -> DEBU 607e [registerch][805147b5] Exit
2018-11-01 09:46:58.183 CST [endorser] ProcessProposal -> ERRO 607f [registerch][805147b5] simulateProposal() resulted in chaincode name:"lscc" response status 500 for txid: 805147b529315755b05890db4e5aabe8b86a17f652e4613ae45d05ced73b2b19```
the last line shows an error. is this the reason for instantiation failure?
mrlinjun (Thu, 01 Nov 2018 03:00:33 GMT):
Has joined the channel.
mrlinjun (Thu, 01 Nov 2018 03:00:41 GMT):
https://chat.hyperledger.org/channel/fabric-gossip?msg=3FjTMu87Zo3K9KEJs
mrlinjun (Thu, 01 Nov 2018 03:00:41 GMT):
https://chat.hyperledger.org/channel/fabric-gossip?msg=3FjTMu87Zo3K9KEJs
mrlinjun (Thu, 01 Nov 2018 03:00:41 GMT):
@dave.enyeart @yacovm https://chat.hyperledger.org/channel/fabric-gossip?msg=3FjTMu87Zo3K9KEJs
rsherwood (Thu, 01 Nov 2018 09:40:07 GMT):
Hi I've a question about how much data can be deduced by non-members of private data collections.
If I take and example if there are peers P1, P2 and P3 , where there is a private collection C1 between P1 and P2 but not P3, and a single channel between all three. If a transactions is submitted by C1 and endorsed by P1 and P2, creating date private data in C1.
How much can P3 see ?
I assume P3 will see the submitter certs, the endorsers certs.
Will P3 also see that C1 has been used. I assume yes but would like confirmation.
So given a trading network with a single channel but private collection between pairs or participants any participant could deduce who is trading (or at least have a very good guess) with who and when, but no details of the trades assuming all details of the trade is in the private data collection. Is this correct ? I'm assuming fixing the above would need some aspect of the identify mixing that the Fabric team are exploring.
dave.enyeart (Thu, 01 Nov 2018 10:34:41 GMT):
@rsherwood right, currently P3 will know that there is some private data in C1 that P1 and P2 are members of. there is work ongoing to make that information secret as well, using identity mixer, zero knowledge proof, and 'local collections' rather than static collections (where clients choose who should see the data, rather than it being defined in static collections).
albert.lacambra (Thu, 01 Nov 2018 10:42:21 GMT):
One question about scaling peers
albert.lacambra (Thu, 01 Nov 2018 10:42:59 GMT):
would it be possible to have several peers behind a load balancer? They will share the same identity and for other components the endpoint would reference the loadbalancer
albert.lacambra (Thu, 01 Nov 2018 10:43:24 GMT):
I am not sure if tha copuld have issues when updating the chain and issues with the gossip protocol
albert.lacambra (Thu, 01 Nov 2018 10:43:24 GMT):
I am not sure if that could have issues when updating the chain and issues with the gossip protocol
MohammadObaid (Thu, 01 Nov 2018 11:08:07 GMT):
@dave.enyeart Question: Let suppose we have four peers out of which only one is endorsing peer . So I installed and instantiated chaincode and invoke query using that peer terminal and successfully able to change state of asset . But when I query about value of that asset sing other peer terminal , I get an error `Error: endorsement failure during query. response: status:500 message:"cannot retrieve package for chaincode mycc/v0, error open /var/hyperledger/production/chaincodes/mycc.v0: no such file or directory" ` . My question is do I need to install chaincode in each peer including non endorsing peers ? I have read in documentation that only endorsing peer need chaincode !
dave.enyeart (Thu, 01 Nov 2018 11:15:41 GMT):
@MohammadObaid you need to install chaincode on each peer where you want to invoke chaincode. A peer that executes chaincode is an endorser, regardless of what that chaincode call does reads or writes.
dave.enyeart (Thu, 01 Nov 2018 11:15:41 GMT):
@MohammadObaid you need to install chaincode on each peer where you want to invoke chaincode. A peer that executes chaincode is an endorser, regardless of whether that chaincode call does reads or writes.
dave.enyeart (Thu, 01 Nov 2018 11:17:05 GMT):
From peer perspective, there is no difference between invokes and queries... they are all chaincode calls that get endorsed
MohammadObaid (Thu, 01 Nov 2018 11:19:50 GMT):
so if comitting peers want to find out value of asset for example value of `a` they cant do it ?
MohammadObaid (Thu, 01 Nov 2018 11:20:23 GMT):
Does block deliver to comitting peers only contain hashes and signatures ?
yacovm (Thu, 01 Nov 2018 11:21:19 GMT):
of course it contains more than hashes and signatures... it also contains the key and value pairs
yacovm (Thu, 01 Nov 2018 11:21:38 GMT):
otherwise you couldn't have extracted them from the block
yacovm (Thu, 01 Nov 2018 11:21:45 GMT):
but - to read a key you need a chaincode
yacovm (Thu, 01 Nov 2018 11:21:58 GMT):
a chaincode, for that key.
yacovm (Thu, 01 Nov 2018 11:21:58 GMT):
a chaincode, for that namespace where the key resides
bh4rtp (Thu, 01 Nov 2018 11:34:16 GMT):
@dave.enyeart could you please help me about this issue `ERRO 607f [registerch][805147b5] simulateProposal() resulted in chaincode name:"lscc" response status 500 for txid: 805147b529315755b05890db4e5aabe8b86a17f652e4613ae45d05ced73b2b19`. it was printed from peer logs when instantiating chaincode.
dave.enyeart (Thu, 01 Nov 2018 11:39:53 GMT):
@bh4rtp the root cause error message is not printed in peer logs for security reasons. you'll need to get the root error message from client side.
bh4rtp (Thu, 01 Nov 2018 11:41:47 GMT):
@dave.enyeart my chaincode has private data. and the node sdk client just prints proposal is bad. the response message is null.
dave.enyeart (Thu, 01 Nov 2018 11:43:47 GMT):
@bh4rtp well that stinks, will have to get fixed. can you open a jira issue and include peer debug log?
bh4rtp (Thu, 01 Nov 2018 11:44:14 GMT):
ok. thanks!
dave.enyeart (Thu, 01 Nov 2018 11:44:38 GMT):
at-mention me in the jira or ping me the number
bh4rtp (Thu, 01 Nov 2018 12:27:01 GMT):
@dave.enyeart i opened a jira issue, please view FAB-12676.
dave.enyeart (Thu, 01 Nov 2018 14:00:08 GMT):
@bh4rtp to mention it here as well... looks like the app client code is not printing the "message" that is returned by the chaincode. That should provide the root cause of the error. We will also look into improving the samples to demonstrate this.
muralisr (Thu, 01 Nov 2018 14:35:57 GMT):
@sykesm can you note down the metric namespace components (perhaps with some examples) for https://jira.hyperledger.org/browse/FAB-3389 please ( @grapebaba @dave.enyeart )
muralisr (Thu, 01 Nov 2018 14:36:32 GMT):
we can iterate on various metrics
muralisr (Thu, 01 Nov 2018 14:36:32 GMT):
we can then iterate on various metrics
MohammadObaid (Thu, 01 Nov 2018 19:05:53 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=2yfYvwWiro9As5xB8) @yacovm @yacovm Thanks for clarification . That means peer can't access world ledger if it doesnt install chaincode because query process involves calling getState function from chaincode which lookup in world ledger and return value right ?
MohammadObaid (Thu, 01 Nov 2018 19:05:59 GMT):
Just one more thing is this mechanism is due to some security reasons like why cant comitting peers just simply fetch key value pair from world ledger without chaincode since world ledger stores all key value pair with its latest state/version if all of the peers storing the same thing?
yacovm (Thu, 01 Nov 2018 19:13:08 GMT):
I agree that it would make sense to have an API that just reads the ledger's key-value store
yacovm (Thu, 01 Nov 2018 19:13:19 GMT):
maybe a system chaincode that does that
MohammadObaid (Fri, 02 Nov 2018 08:37:47 GMT):
Yes that will be better solution . If any client-sdk/node sdk integrate with comitting peer ledger then it wont be able to fetch keyvalue pairs so in current scenario every peer have to be endorsing !
bh4rtp (Fri, 02 Nov 2018 11:54:38 GMT):
@dave.enyeart i found the reason. the `chaincodeType` argument was passed as `init`, i.e. fcn. however the error message is not returned to client. that is the problem.
i added a logging line in the source file `core/endorser/endorser.go`, and finally got the error message. so i just did a negative test to endorser.go :grinning:.
bh4rtp (Fri, 02 Nov 2018 11:59:00 GMT):
the message from fabric after added the logging line:
`2018-11-02 19:33:38.843 CST [endorser] ProcessProposal -> DEBU 5e2d [registerch][0bdb6251] simulateProposal() - cd :
bh4rtp (Fri, 02 Nov 2018 12:01:06 GMT):
i feel very happy to get this issue solved. thank you.
bh4rtp (Fri, 02 Nov 2018 16:36:53 GMT):
hi, now instantiate chaincode actually succeeds, but client wait timeout for event.
```[2018-11-03 00:30:54.261] [ERROR] instantiate-chaincode - REQUEST_TIMEOUT:localhost:7051
[2018-11-03 00:30:54.262] [ERROR] instantiate-chaincode - Error: ChannelEventHub has been shutdown```
i have changed timeout to be 300000. it still doesn't work.
```let event_timeout = setTimeout(() => {
let message = 'REQUEST_TIMEOUT:' + eh.getPeerAddr();
logger.error(message);
eh.disconnect();
}, 60000);```
bh4rtp (Fri, 02 Nov 2018 16:36:53 GMT):
hi, now instantiate chaincode actually succeeds, but client will wait timeout for event.
```[2018-11-03 00:30:54.261] [ERROR] instantiate-chaincode - REQUEST_TIMEOUT:localhost:7051
[2018-11-03 00:30:54.262] [ERROR] instantiate-chaincode - Error: ChannelEventHub has been shutdown```
i have changed timeout to be 300000. it still doesn't work.
```let event_timeout = setTimeout(() => {
let message = 'REQUEST_TIMEOUT:' + eh.getPeerAddr();
logger.error(message);
eh.disconnect();
}, 300000);```
ShobhitSrivastava (Mon, 05 Nov 2018 11:03:13 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=9pnWNkm2ZmipsmAng) @nhrishi hey!! Can you tell me, which SDK are you using? If java, where have you got its build library from?
nhrishi (Mon, 05 Nov 2018 11:53:38 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=uJXfzX8pDEHXRYnBa) @ShobhitSrivastava We are using nodejs SDK. But i have seen this error after we brought up the network before doing any invoke transactions.
ShobhitSrivastava (Mon, 05 Nov 2018 12:07:43 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=7WZpHWQo3qtp4xTLu) @nhrishi oh okay. Thanks for confirmation!!
awes0menessInc (Tue, 06 Nov 2018 03:39:33 GMT):
Has joined the channel.
MohammadObaid (Tue, 06 Nov 2018 16:17:40 GMT):
Hey . I have a question . If a peer is non admin why can't they join channels despite fetching all blocks ? When I try to join block from non admin peer terminal I got 500 status code with error `peer is not admin identity `
toddinpal (Tue, 06 Nov 2018 17:04:21 GMT):
Has any thought been given to including the block height of the peer endorsing a transaction in the endorsement reply? My thinking is that with that information, a client could reasonably infer if a node is corrupt or not. If the client receives endorsements from multiple peers at the same block height and their RWsets differ, then either the chaincode is non-deterministic (which is already a disaster) or one or more of the peers has been corrupted.
gravity (Tue, 06 Nov 2018 17:12:56 GMT):
hello
I'm running a network v1.3.0 and right after network start, I'm getting this warning:
```
peer9.test.com | 2018-11-06 17:11:07.895 UTC [gossip/gossip] handleMessage -> WARN 020 Message GossipMessage: tag:EMPTY alive_msg:
yacovm (Tue, 06 Nov 2018 19:33:26 GMT):
@gravity as long as it doesn't show up more - ignore it
enriquebusti (Wed, 07 Nov 2018 12:01:41 GMT):
Has joined the channel.
antoniovassell (Thu, 08 Nov 2018 10:09:30 GMT):
Has joined the channel.
gravity (Fri, 09 Nov 2018 10:34:52 GMT):
Hi all
I'm getting messages on peers when the network is running with TLS enabled:
`2018/11/09 09:44:42 [DEBUG] Client TLS certificate and/or key file not provided`
but I've provided TLS client certificates:
```
- CORE_PEER_TLS_CLIENTCERT_FILE=/data/tls/peer3.org1.com-client.crt
- CORE_PEER_TLS_CLIENTKEY_FILE=/data/tls/peer3.org1.com-client.key
```
am I missing something?
aatkddny (Fri, 09 Nov 2018 16:29:37 GMT):
Repeat of the question I asked on october 29. I'm unable to move to 1.3.0 because of this issue.
```
I *think* this is the right venue for this question. If not pls point me elsewhere - this pertains to performing chaincode instantiation.
Is it (now) normal to get different length proposal responses from different peers? Running 1.3.0 - have never seen this problem until an inadvertent upgrade from 1.2.0.
1.0 and 1.1 never exhibited this behavior either.```
aatkddny (Fri, 09 Nov 2018 16:29:37 GMT):
Repeat of the question I asked on october 29. I'm unable to move to 1.3.0 because of this issue, so if anyone else has seen it or has an answer for it that would be great...
```
I *think* this is the right venue for this question. If not pls point me elsewhere - this pertains to performing chaincode instantiation.
Is it (now) normal to get different length proposal responses from different peers? Running 1.3.0 - have never seen this problem until an inadvertent upgrade from 1.2.0.
1.0 and 1.1 never exhibited this behavior either.```
yacovm (Fri, 09 Nov 2018 18:22:41 GMT):
what is the difference, @aatkddny ?
aatkddny (Fri, 09 Nov 2018 18:34:28 GMT):
@yacom - the length of the response differs between peers. one is 4 bytes longer than the other.
aatkddny (Fri, 09 Nov 2018 18:34:28 GMT):
@yacovm - the length of the response differs between peers. one is 4 bytes longer than the other.
aatkddny (Fri, 09 Nov 2018 18:34:28 GMT):
@yacovm - the length of the response differs between peers. one is 4 bytes longer than the other. There's a post in the fabric-sdk-java channel about it back i October.
aatkddny (Fri, 09 Nov 2018 18:34:28 GMT):
@yacovm - the length of the response differs between peers. one is 4 bytes longer than the other. There's a post I made in the fabric-sdk-java channel about it back on October 29.
yacovm (Fri, 09 Nov 2018 19:21:11 GMT):
ok but what is the difference....? @aatkddny
yacovm (Fri, 09 Nov 2018 19:21:16 GMT):
what field is different
aatkddny (Sun, 11 Nov 2018 23:33:20 GMT):
The instantiate proposal response differs between peer0 and peer1.
The one from peer1 is a different length to the one from peer0.
The java SDK does a consistency check - it expects them to be identical. When they differ it fails.
This difference is new to 1.3 - or at least if it isn't I never saw it before.
Hence my question. Is this a known or previously unseen thing? It happened to me
aatkddny (Sun, 11 Nov 2018 23:33:20 GMT):
The instantiate proposal response differs between peer0 and peer1 while I'm instantiating chaincode.
The one from peer1 is a different length - longer by 4 bytes - than the one from peer0.
The java SDK does a consistency check - it expects them to be identical. When they differ it fails.
This difference is new to 1.3 - or at least if it isn't I never saw it before.
Hence my question. Is this a known or previously unseen thing?
It happened to me multiple times when I ran 1.3. It never occurred running 1.2.
aatkddny (Sun, 11 Nov 2018 23:33:20 GMT):
The instantiate proposal response differs between peer0 and peer1 while I'm instantiating chaincode on the first of a list of channels I need to shove a piece of cc into.
The one from peer1 is a different length - longer by 4 bytes - than the one from peer0.
The java SDK does a consistency check - it expects them to be identical. When they differ it fails.
This difference is new to 1.3 - or at least if it isn't I never saw it before.
Hence my question. Is this a known or previously unseen thing?
It happened to me multiple times when I ran 1.3. It never occurred running 1.2.
yacovm (Sun, 11 Nov 2018 23:37:08 GMT):
@aatkddny I beg your pardon... instantiate proposal differs?
yacovm (Sun, 11 Nov 2018 23:37:20 GMT):
instantiate is always on a single node....
yacovm (Sun, 11 Nov 2018 23:38:34 GMT):
@aatkddny it seems to me perhaps 1 peer is in a different version than another?
aatkddny (Sun, 11 Nov 2018 23:56:05 GMT):
no they are both 1.3 - deployed in same kubernetes cluster at same time both using :latest, which resolved to 1.3
aatkddny (Sun, 11 Nov 2018 23:56:59 GMT):
I wish it was that simple. I redeployed the entire network from scratch 3 times thinking I'd messed something up.
aatkddny (Sun, 11 Nov 2018 23:56:59 GMT):
I wish it was that simple. I redeployed the entire network from scratch 3 times thinking I'd messed something up. When I went back to 1.2 it worked (and works) just fine
yacovm (Mon, 12 Nov 2018 11:12:01 GMT):
@aatkddny can you perhaps send me the files?
yacovm (Mon, 12 Nov 2018 11:12:18 GMT):
I'll investigate what is different (what field)
yacovm (Mon, 12 Nov 2018 11:12:24 GMT):
or you can do it yourself if you want....
yacovm (Mon, 12 Nov 2018 11:12:41 GMT):
(I can show you how)
aatkddny (Mon, 12 Nov 2018 15:55:35 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=c6AsrMnGEutiqyX4x) @yacovm You want the TP responses?
yacovm (Mon, 12 Nov 2018 16:00:27 GMT):
yeah
githubcpc (Tue, 13 Nov 2018 07:29:48 GMT):
I want to adding an org3 to an lanuched fabric-network based this tutorials: https://hyperledger-fabric.readthedocs.io/en/release-1.2/channel_update_tutorial.html
but when I execute this command finally
peer channel join -b mychannel.block
it appears this error:
Error: error getting endorser client for channel: endorser client failed to connect to peer0.org3.example.com:7051: failed to create new connection: context deadline exceeded
githubcpc (Tue, 13 Nov 2018 07:30:39 GMT):
so I want to ask why appears this question and how can I solve this problm?Thanks.
tballast (Tue, 13 Nov 2018 14:50:44 GMT):
Has joined the channel.
tballast (Tue, 13 Nov 2018 14:55:21 GMT):
For the past few days I have been trying to get a network running with several peers (ie. more than one) and I am struggling like crazy to overcome this error:
```
$ docker logs dev-peer0.org1.example.com-example_cc_go-1 [0s038]
2018-11-13 10:51:07.714 UTC [example_cc0] Info -> INFO 001 Calling into main of chaincode.
2018-11-13 10:51:10.715 UTC [shim] userChaincodeStreamGetter -> ERRO 002 context deadline exceeded
error trying to connect to local peer
github.com/hyperledger/fabric/core/chaincode/shim.userChaincodeStreamGetter
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/shim/chaincode.go:112
github.com/hyperledger/fabric/core/chaincode/shim.Start
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/shim/chaincode.go:151
main.main
/chaincode/input/src/github.com/example_cc/example_cc.go:220
runtime.main
/opt/go/src/runtime/proc.go:198
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:2361
2018-11-13 10:51:10.715 UTC [example_cc0] Errorf -> ERRO 003 Error starting Simple chaincode: error trying to connect to local peer: context deadline exceeded
```
I cannot seem to find the root of this. I will upload whatever logs or documents are necessary.
I experience the same issue if I start a cli container and attempt to create/join the channel and install/instantiate the chaincode manually, without any java client.
githubcpc (Wed, 14 Nov 2018 06:55:21 GMT):
I follow the demo from https://hyperledger-fabric.readthedocs.io/en/release-1.2/channel_update_tutorial.html but I get "Error: received bad response, status 500" when I execute the "peer channel join -b mychannel.block" .Before this step ,everything execute successfully.
My orderer logs show that,
2018-11-14 02:23:13.043 UTC [orderer/consensus/kafka/sarama] RefreshMetadata -> DEBU 693 client/metadata fetching metadata for all topics from broker kafka2.example.com:9092
2018-11-14 02:24:16.866 UTC [grpc] Printf -> DEBU 694 grpc: Server.Serve failed to complete security handshake from "192.168.21.146:46804": remote error: tls: bad certificate
However, I don't know how to solve this error ,"tls: bad certificate".Could anyone help me? Thanks.
githubcpc (Wed, 14 Nov 2018 07:07:43 GMT):
I want to add an org to my HLF v1.2.[root@chain11 e2e_cli]# ll crypto-config/ordererOrganizations/example.com/ca
total 8
-rw-r--r-- 1 root root 818 Nov 14 01:20 ca.example.com-cert.pem
-rw------- 1 root root 241 Nov 14 01:20 d45b9a220e81e53e8b69f5bf7d43543ef2fc0cbd29403405f7e98e11b750c387_sk
githubcpc (Wed, 14 Nov 2018 07:08:47 GMT):
I want to add an org to my HLF v1.2.
[root@chain11 e2e_cli]# ll crypto-config/ordererOrganizations/example.com/ca
-rw-r--r-- 1 root root 818 Nov 14 01:20 ca.example.com-cert.pem
-rw------- 1 root root 241 Nov 14 01:20 d45b9a220e81e53e8b69f5bf7d43543ef2fc0cbd29403405f7e98e11b750c387_sk
My New Peer ordererOrganizations TLS is the same to the old.
nainiubaba (Thu, 15 Nov 2018 09:03:29 GMT):
Has joined the channel.
ArianStef (Thu, 15 Nov 2018 16:03:56 GMT):
Clipboard - November 15, 2018 5:02 PM
ArianStef (Thu, 15 Nov 2018 16:05:30 GMT):
Clipboard - November 15, 2018 5:04 PM
ArianStef (Thu, 15 Nov 2018 16:05:57 GMT):
Clipboard - November 15, 2018 5:05 PM
ArianStef (Thu, 15 Nov 2018 16:07:10 GMT):
and the query response is empty. How can I do? Can I modify some timeout setup? Thank you very much and sorry for the messy question
h4995974 (Thu, 15 Nov 2018 22:09:09 GMT):
Has joined the channel.
h4995974 (Thu, 15 Nov 2018 22:09:11 GMT):
Hello everyone.
We're receiving the following error when trying to spin up peers inside a kubernetes pods. `2018-11-15 21:52:25.172 UTC [gossip/gossip] handleMessage -> WARN 01f Message GossipMessage: tag:EMPTY alive_msg:
yacovm (Thu, 15 Nov 2018 22:58:50 GMT):
@h4995974 do you receive it over and over again?
qizhang (Fri, 16 Nov 2018 02:12:55 GMT):
if I want to measure how long does it take to simulate and endorse a tx, shall I just measure how long does this `ProcessProposal` function run? https://github.com/hyperledger/fabric/blob/release-1.3/core/endorser/endorser.go#L402
chuda (Fri, 16 Nov 2018 05:12:09 GMT):
Has joined the channel.
akshay.sood (Fri, 16 Nov 2018 11:46:35 GMT):
Hi experts,
I am facing issue in adding a new peer into existing organization.
Issue description can be found here
https://stackoverflow.com/questions/53325360/adding-new-peer-in-existing-organization-in-hyperledger-fabric-v1-3-causing-new
BellaAdams (Sat, 17 Nov 2018 00:46:09 GMT):
Has joined the channel.
huxiangdong (Tue, 20 Nov 2018 00:34:05 GMT):
Has joined the channel.
anjalinaik (Tue, 20 Nov 2018 11:28:40 GMT):
can anybody please guide me to resolve below error
anjalinaik (Tue, 20 Nov 2018 11:28:51 GMT):
```
`2018-11-08 09:52:25.082 UTC [shim] userChaincodeStreamGetter -> ERRO 001 context deadline exceeded
error trying to connect to local peer
github.com/hyperledger/fabric/core/chaincode/shim.userChaincodeStreamGetter
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/shim/chaincode.go:111
github.com/hyperledger/fabric/core/chaincode/shim.Start
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/shim/chaincode.go:150
main.main
/chaincode/input/src/github.com/fabcar/fabcar.go:200
runtime.main
/opt/go/src/runtime/proc.go:198
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:2361
Error creating new Smart Contract: error trying to connect to local peer: context deadline exceeded`
```
muralisr (Fri, 23 Nov 2018 14:49:45 GMT):
@anjalinaik chaincode is unable to connect to the peer. You would need to look at various connection specific properties such as https://github.com/hyperledger/fabric/blob/master/sampleconfig/core.yaml#L26 and make sure the address chaincode is trying to connect to is reachable
tballast (Mon, 26 Nov 2018 09:24:14 GMT):
@anjalinaik make sure that all of your docker networks are also configured properly. For instance, make sure your network name (ie mynetworkname):
```
networks:
mynetworkname:
```
matches the network mode for your peers: ` - CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE=${COMPOSE_PROJECT_NAME}_mynetworkname`
giacomo.minighin (Tue, 27 Nov 2018 16:02:30 GMT):
Has joined the channel.
igor-egorov (Wed, 28 Nov 2018 15:35:08 GMT):
Has joined the channel.
AishwaryaKudalkar (Thu, 29 Nov 2018 05:56:12 GMT):
Has joined the channel.
huikang (Thu, 29 Nov 2018 14:51:30 GMT):
Hi, I have a question about concurrent requests being sent to an endorser. If two requests (for indepenent data sets) are being sent to the same endorser, how does the endorser handle them? Will the endorser create two chaincode containers or execute them sequentially on one chaincode container? Thanks.
muralisr (Thu, 29 Nov 2018 15:38:46 GMT):
@huikang there is one container per chaincode. All requests to a chaincode are sent to tha container
gravity (Thu, 29 Nov 2018 19:44:22 GMT):
Hi all
I'm trying to call a chaincode with the transient parameter passed to call
```
peer chaincode invoke -C tmpchannel -n cc_example -c '{"Args": ["doStuff", ""]}' --transient '{"key": "someValue"}'
```
but getting the error:
```
Error: error parsing transient string: illegal base64 data at input byte 8 - proposal response:
Ryan2 (Mon, 03 Dec 2018 02:23:40 GMT):
Hi, I read over the document https://hyperledger-fabric.readthedocs.io/en/release-1.3/membership/membership.html
`KeyStore for Private Key: This folder is defined for the local MSP of a peer or orderer node (or in an client’s local MSP), and contains the node’s signing key. This key matches cryptographically the node’s identity included in Node Identity folder and is used to sign data — for example to sign a transaction proposal response, as part of the endorsement phase.
This folder is mandatory for local MSPs, and must contain exactly one private key. Obviously, access to this folder must be limited only to the identities of users who have administrative responsibility on the peer.`
I tested by delete msp folder (crypto-config/peerOrganizations/org0/msp/) on local peer, then submit transaction, it succeeded.
However, it seem transaction is not signed by local peer private key, but signed by peer certificate?
Can someone explain?
Ryan2 (Mon, 03 Dec 2018 02:23:40 GMT):
Hi, I read over the document https://hyperledger-fabric.readthedocs.io/en/release-1.3/membership/membership.html
`KeyStore for Private Key: This folder is defined for the local MSP of a peer or orderer node (or in an client’s local MSP), and contains the node’s signing key. This key matches cryptographically the node’s identity included in Node Identity folder and is used to sign data — for example to sign a transaction proposal response, as part of the endorsement phase.
This folder is mandatory for local MSPs, and must contain exactly one private key. Obviously, access to this folder must be limited only to the identities of users who have administrative responsibility on the peer.`
I tested by deleting msp folder (crypto-config/peerOrganizations/org0/msp/) on local peer, then submit transaction by application, it succeeded.
it seem endorsement transaction response is not signed by local peer private key,
Can someone explain?
giacomo.minighin (Mon, 03 Dec 2018 15:18:06 GMT):
Has left the channel.
arjitkhullar (Wed, 05 Dec 2018 00:04:03 GMT):
Has joined the channel.
anjalinaik (Wed, 05 Dec 2018 04:44:01 GMT):
Hi Experts,can anyone please guide me on, how do I need to modify the transaction proposal request in fabric-java-SDK so that it gets signed by both Org1 and Org2.[AND Endorsment policy]
asaningmaxchain123 (Wed, 05 Dec 2018 13:22:44 GMT):
@yacovm when i want to instantiate chaincode i got the following error
asaningmaxchain123 (Wed, 05 Dec 2018 13:22:44 GMT):
@yacovm @muralisr when i want to instantiate chaincode i got the following error
asaningmaxchain123 (Wed, 05 Dec 2018 13:22:46 GMT):
`failed to invoke chaincode name:"lscc" , error: timeout expired while executing transaction`
yacovm (Wed, 05 Dec 2018 13:29:03 GMT):
it might be because the chaincode instantiate timed out
yacovm (Wed, 05 Dec 2018 13:29:11 GMT):
for example if you instantiate a node.js chaincode
yacovm (Wed, 05 Dec 2018 13:29:19 GMT):
and it failed to download the binaries before the time expires
asaningmaxchain123 (Wed, 05 Dec 2018 13:29:47 GMT):
i use golang chaincode
yacovm (Wed, 05 Dec 2018 13:29:58 GMT):
so maybe it didn't compile at all
asaningmaxchain123 (Wed, 05 Dec 2018 13:30:07 GMT):
so how can i resolve it, by increment timeout
asaningmaxchain123 (Wed, 05 Dec 2018 13:30:07 GMT):
so how can i resolve it, by add timeout
asaningmaxchain123 (Wed, 05 Dec 2018 13:31:07 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=xKEXCQ4AC4DhywaT5) @yacovm however the chaincode has started
yacovm (Wed, 05 Dec 2018 13:37:06 GMT):
look at the logs of the peer/container
yacovm (Wed, 05 Dec 2018 13:37:12 GMT):
see if there are any clues
asaningmaxchain123 (Wed, 05 Dec 2018 13:37:36 GMT):
Clipboard - December 5, 2018 9:37 PM
asaningmaxchain123 (Wed, 05 Dec 2018 13:38:15 GMT):
just tell me it's fail
asaningmaxchain123 (Wed, 05 Dec 2018 13:38:15 GMT):
just tell me it's fail due to timeout
yacovm (Wed, 05 Dec 2018 13:41:02 GMT):
so you need to turn on some variable
yacovm (Wed, 05 Dec 2018 13:41:14 GMT):
https://github.com/hyperledger/fabric/blob/release-1.2/sampleconfig/core.yaml#L484
yacovm (Wed, 05 Dec 2018 13:41:40 GMT):
it's vm.attachstdout=true
yacovm (Wed, 05 Dec 2018 13:41:48 GMT):
it makes the peer print the output of the compilation to the log
yacovm (Wed, 05 Dec 2018 13:41:50 GMT):
and then try again
asaningmaxchain123 (Wed, 05 Dec 2018 13:42:26 GMT):
ok，i set the env var to try again
asaningmaxchain123 (Wed, 05 Dec 2018 13:47:32 GMT):
Clipboard - December 5, 2018 9:47 PM
asaningmaxchain123 (Wed, 05 Dec 2018 13:47:32 GMT):
Clipboard - December 5, 2018 9:47 PM
asaningmaxchain123 (Wed, 05 Dec 2018 13:48:00 GMT):
Clipboard - December 5, 2018 9:47 PM
asaningmaxchain123 (Wed, 05 Dec 2018 13:48:55 GMT):
it seem doesn't work
yacovm (Wed, 05 Dec 2018 13:49:52 GMT):
did you restart the peer?
asaningmaxchain123 (Wed, 05 Dec 2018 13:50:10 GMT):
yes
asaningmaxchain123 (Wed, 05 Dec 2018 13:50:46 GMT):
Clipboard - December 5, 2018 9:50 PM
yacovm (Wed, 05 Dec 2018 13:52:07 GMT):
what version are you using?
yacovm (Wed, 05 Dec 2018 13:52:09 GMT):
fabric version
asaningmaxchain123 (Wed, 05 Dec 2018 13:52:32 GMT):
Clipboard - December 5, 2018 9:52 PM
asaningmaxchain123 (Wed, 05 Dec 2018 13:52:38 GMT):
1.2.1
yacovm (Wed, 05 Dec 2018 13:52:45 GMT):
odd... it worked for me in the past
asaningmaxchain123 (Wed, 05 Dec 2018 13:53:56 GMT):
so，i shoule add the chaincode execute time
asaningmaxchain123 (Wed, 05 Dec 2018 13:54:08 GMT):
`const (
defaultExecutionTimeout = 30 * time.Second
minimumStartupTimeout = 5 * time.Second
)`
asaningmaxchain123 (Wed, 05 Dec 2018 13:54:08 GMT):
```const (
defaultExecutionTimeout = 30 * time.Second
minimumStartupTimeout = 5 * time.Second
)```
asaningmaxchain123 (Wed, 05 Dec 2018 13:55:03 GMT):
but the chaincode is running
asaningmaxchain123 (Wed, 05 Dec 2018 14:03:57 GMT):
@muralisr can you take a look?
asaningmaxchain123 (Wed, 05 Dec 2018 14:04:27 GMT):
i think the peer doesn't receive chaincode response
asaningmaxchain123 (Wed, 05 Dec 2018 14:55:27 GMT):
@yacovm i got the following info
asaningmaxchain123 (Wed, 05 Dec 2018 14:55:30 GMT):
`2018-12-05 14:53:03.673 UTC [shim] handlePutState -> ERRO 001 [ae0b4692]Received ERROR. Payload: PUT_STATE failed: transaction ID: ae0b46925db239fe8d39c276534e8e3356d48e0f16ea5c2ccbcfa8acc6bb6297: no ledger context
2018-12-05 14:53:03.673 UTC [shim] 2 -> ERRO 002 [[ae0b4692 ERROR]]Init get error response [%!s(MISSING)]. Sending %!s(MISSING)`
asaningmaxchain123 (Wed, 05 Dec 2018 14:55:30 GMT):
```2018-12-05 14:53:03.673 UTC [shim] handlePutState -> ERRO 001 [ae0b4692]Received ERROR. Payload: PUT_STATE failed: transaction ID: ae0b46925db239fe8d39c276534e8e3356d48e0f16ea5c2ccbcfa8acc6bb6297: no ledger context
2018-12-05 14:53:03.673 UTC [shim] 2 -> ERRO 002 [[ae0b4692 ERROR]]Init get error response [%!s(MISSING)]. Sending %!s(MISSING)```
asaningmaxchain123 (Wed, 05 Dec 2018 14:59:12 GMT):
@jyellick please take a look
asaningmaxchain123 (Wed, 05 Dec 2018 15:10:15 GMT):
@Muralidharan do you resolve the FAB-2767
jrosmith (Wed, 05 Dec 2018 20:27:05 GMT):
@anjalinaik are you asking about modifying the policy or constructing a proposal request that gets sent to both orgs?
gravity (Thu, 06 Dec 2018 15:46:40 GMT):
hi all
are there any recommendations on how many peers(of each role: discovery, endorser, commiter) should be assigned to a channel? (if we speak about performance)
or maybe these peers should be separated like, peer0, peer1, peer2 are assigned to a channel1, peer3, peer4, peer5 - to a channel2?
is it a good practice for peers to be members of several channels with the same/different chaincodes installed?
thanks in advance
ApurvTandon (Thu, 06 Dec 2018 16:34:25 GMT):
Has joined the channel.
muralisr (Thu, 06 Dec 2018 17:13:12 GMT):
https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=NYQphWBGuDkrijYCc
muralisr (Thu, 06 Dec 2018 17:18:44 GMT):
@asaningmaxchain123 I'm guessing
1. the original request timed out
2. the chaincode execution got aborted after the time out when it tried to do a PUT (the ledger context was taken away after the timeout)
3. bumping up CORE_LOGGING_LEVEL from info to debug in the docker-compose file might give you more info.
4. u might also want to consider bumping up the startup time out (given we see `lscc` in the stack this faiuklure might be during instantiation... possible longer time due to image creation or something)
tongli (Thu, 06 Dec 2018 19:53:19 GMT):
@muralisr got an error instantiate chaincode. here is the error.
tongli (Thu, 06 Dec 2018 19:53:41 GMT):
```chaincode instantiate: Policy str is OutOf (2, 'org1.member','org2.member','org3.member','org4.member', 'org5.member','org6.member','org7.member','org8.member')
chaincode instantiate: ccPolicy is rule:
tongli (Thu, 06 Dec 2018 19:54:46 GMT):
how can i specify endorsement policy so that it won't ask for discovery service/
tongli (Thu, 06 Dec 2018 19:54:49 GMT):
?
tongli (Thu, 06 Dec 2018 19:54:59 GMT):
what I have now is this.
tongli (Thu, 06 Dec 2018 19:55:13 GMT):
```OutOf (2, 'org1.member','org2.member','org3.member','org4.member',
'org5.member','org6.member','org7.member','org8.member')```
tongli (Thu, 06 Dec 2018 19:55:36 GMT):
with that policy, it asks for discovery service.
tongli (Thu, 06 Dec 2018 19:55:41 GMT):
eventually failed.
tongli (Thu, 06 Dec 2018 20:15:53 GMT):
can any one help please ?
muralisr (Thu, 06 Dec 2018 21:29:23 GMT):
@tongli where do you see this error ? nodejs SDK ?
muralisr (Thu, 06 Dec 2018 21:31:50 GMT):
trying to understand `with that policy, it asks for discovery service.` ... are you saying there are other policies where you don't get that error ?
muralisr (Thu, 06 Dec 2018 21:32:20 GMT):
in any case if this error is seen in an SDK, suggest try the question - if u haven't done so already - there
tongli (Thu, 06 Dec 2018 21:52:12 GMT):
@muralisr sorry, i was in a meeting.
tongli (Thu, 06 Dec 2018 21:52:41 GMT):
here is what i am trying to do. i have installed chaincode, now try to instantiate the chaincode using a policy like this
tongli (Thu, 06 Dec 2018 21:52:53 GMT):
```OutOf (2, 'org1.member','org2.member','org3.member','org4.member',
'org5.member','org6.member','org7.member','org8.member')```
tongli (Thu, 06 Dec 2018 21:53:03 GMT):
The error happened during the chaincode instantiation
tongli (Thu, 06 Dec 2018 21:53:33 GMT):
it seems to me it is trying to use the discovery service to find peers. but it failed.
tongli (Thu, 06 Dec 2018 21:53:39 GMT):
we are uinsg gosdk.
tongli (Thu, 06 Dec 2018 21:53:42 GMT):
using
tongli (Thu, 06 Dec 2018 22:04:03 GMT):
Then I found a doc about doing something like this to specify the peers in each org.
tongli (Thu, 06 Dec 2018 22:04:07 GMT):
```Layouts: [
QuantitiesByGroup: {
“Org1”: 1,
“Org2”: 1,
}
],
EndorsersByGroups: {
“Org1”: [peer0.org1, peer1.org1],
“Org2”: [peer0.org2, peer1.org2]
}```
tongli (Thu, 06 Dec 2018 22:04:36 GMT):
but I do not know how to word the EndorsersByGroups using the syntax above.
tongli (Thu, 06 Dec 2018 22:04:43 GMT):
any help will be very much appreciated.
ApurvTandon (Fri, 07 Dec 2018 02:58:31 GMT):
Hi can anyone tell me where on the peer/system are the transaction stored, so that i can see the kind of information they hold
pankajcheema (Fri, 07 Dec 2018 06:30:48 GMT):
Hi I am getting this error ```Error during CouchDB CreateDatabaseIfNotExist() for system dbName: _users error: json: cannot unmarshal string into Go struct field DBInfo.purge_seq of type int
```
pankajcheema (Fri, 07 Dec 2018 06:31:06 GMT):
in peer startup process any idea ?
pankajcheema (Fri, 07 Dec 2018 06:31:54 GMT):
these are the complete logs ```2018-12-07 06:12:35.191 UTC [couchdb] CreateSystemDatabasesIfNotExist -> ERRO 005 Error during CouchDB CreateDatabaseIfNotExist() for system dbName: _users error: json: cannot unmarshal string into Go struct field DBInfo.purge_seq of type int
2018-12-07 06:12:35.191 UTC [couchdb] VerifyCouchConfig -> ERRO 006 Unable to connect to CouchDB, error: json: cannot unmarshal string into Go struct field DBInfo.purge_seq of type int Check the admin username and password.
panic: Error in instantiating ledger provider: Unable to connect to CouchDB, error: json: cannot unmarshal string into Go struct field DBInfo.purge_seq of type int Check the admin username and password.
```
pankajcheema (Fri, 07 Dec 2018 06:32:37 GMT):
This error is coming only AWS cloud .not on any other machine
pankajcheema (Fri, 07 Dec 2018 06:34:01 GMT):
I am providing right username and password for couchdb .I verified multiple time
pankajcheema (Fri, 07 Dec 2018 09:19:58 GMT):
https://stackoverflow.com/questions/53666330/hyperledger-fabric-native-peer-binary-not-able-to-communicate-with-couchdb
asaningmaxchain123 (Fri, 07 Dec 2018 11:09:41 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=7L76otPQxH2LDjraE) @muralisr i will try it
krabradosty (Fri, 07 Dec 2018 12:58:19 GMT):
Hello. I have a strange issue with peers. Sometimes one of channels on one of the peers just like "freeze" and do not respond. The behavior that I noticed:
1. When I send new transaction to orderer, a new block is not committed to the "frozen" channel on the "problem" peer.
2. On "good" peers I see that new blocks are committed.
3. I can't get channel info from "problem" peer container (`peer channel getinfo -c fronzen_channel`). I see just:
```
2018-12-07 11:30:37.169 UTC [msp] getMspConfig -> INFO 001 Loading NodeOUs
2018-12-07 11:30:37.192 UTC [channelCmd] InitCmdFactory -> INFO 002 Endorser and orderer connections initialized
```
In peer logs I this: hastebin.com/educifufef.md
Other channels on "problem" peer respond to this command.
4. There are no other error logs for "problem" peer
krabradosty (Fri, 07 Dec 2018 12:58:19 GMT):
Hello. I have a strange issue with peers. Sometimes one of channels on one of the peers just like "freeze" and do not respond. The behavior that I noticed:
1. When I send new transaction to orderer, a new block is not committed to the "frozen" channel on the "problem" peer.
2. On "good" peers I see that new blocks are committed.
3. I can't get channel info from "problem" peer container (`peer channel getinfo -c fronzen_channel`). I see just:
```
2018-12-07 11:30:37.169 UTC [msp] getMspConfig -> INFO 001 Loading NodeOUs
2018-12-07 11:30:37.192 UTC [channelCmd] InitCmdFactory -> INFO 002 Endorser and orderer connections initialized
```
In peer logs I this: hastebin.com/educifufef.md
Other channels on "problem" peer respond to this command.
4. There are no other error logs for "problem" peer
krabradosty (Fri, 07 Dec 2018 12:58:19 GMT):
Hello. I have a strange issue with peers. Sometimes one of channels on one of the peers just like "freeze" and do not respond. The behavior that I noticed:
1. When I send new transaction to orderer, a new block is not committed to the "frozen" channel on the "problem" peer.
2. On "good" peers I see that new blocks are committed.
3. I can't get channel info from "problem" peer container (`peer channel getinfo -c fronzen_channel`). I see just:
```
2018-12-07 11:30:37.169 UTC [msp] getMspConfig -> INFO 001 Loading NodeOUs
2018-12-07 11:30:37.192 UTC [channelCmd] InitCmdFactory -> INFO 002 Endorser and orderer connections initialized
```
In peer logs I this: hastebin.com/educifufef.md
Other channels on "problem" peer respond to this command.
4. There are no other error logs for "problem" peer
5. ChannelEventHub can't connect to this channel
6. Only a restart of the peer can help
krabradosty (Fri, 07 Dec 2018 12:58:19 GMT):
Hello. I have a strange issue with peers. Sometimes one of channels on one of the peers just like "freeze" and do not respond. The behavior that I noticed:
1. When I send new transaction to orderer, a new block is not committed to the "frozen" channel on the "problem" peer.
2. On "good" peers I see that new blocks are committed.
3. I can't get channel info from "problem" peer container (`peer channel getinfo -c fronzen_channel`). I see just:
```
2018-12-07 11:30:37.169 UTC [msp] getMspConfig -> INFO 001 Loading NodeOUs
2018-12-07 11:30:37.192 UTC [channelCmd] InitCmdFactory -> INFO 002 Endorser and orderer connections initialized
```
In peer logs I this: hastebin.com/educifufef.md
Other channels on "problem" peer respond to this command.
4. There are no other error logs for "problem" peer
5. ChannelEventHub can't connect to this channel via "problem" peer
6. Only a restart of the peer can help
krabradosty (Fri, 07 Dec 2018 12:58:19 GMT):
Hello. I have a strange issue with peers (v 1.3.0). Sometimes one of channels on one of the peers just like "freeze" and do not respond. The behavior that I noticed:
1. When I send new transaction to orderer, a new block is not committed to the "frozen" channel on the "problem" peer.
2. On "good" peers I see that new blocks are committed.
3. I can't get channel info from "problem" peer container (`peer channel getinfo -c fronzen_channel`). I see just:
```
2018-12-07 11:30:37.169 UTC [msp] getMspConfig -> INFO 001 Loading NodeOUs
2018-12-07 11:30:37.192 UTC [channelCmd] InitCmdFactory -> INFO 002 Endorser and orderer connections initialized
```
In peer logs I this: hastebin.com/educifufef.md
Other channels on "problem" peer respond to this command.
4. There are no other error logs for "problem" peer
5. ChannelEventHub can't connect to this channel via "problem" peer
6. Only a restart of the peer can help
muralisr (Fri, 07 Dec 2018 13:57:38 GMT):
https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=EdBJnYq42cgxgTwCg
muralisr (Fri, 07 Dec 2018 13:59:44 GMT):
https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=5JAp7pFGmaxHyyuq2 @tongli did you try in the #fabric-sdk-go channel ? They are quite responsive..
dave.enyeart (Fri, 07 Dec 2018 23:12:42 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=jYPnsyz8z3kBjJtTN) @pankajcheema @chris.elder Any ideas on this error? See above for the full error...
ApurvTandon (Sat, 08 Dec 2018 06:02:59 GMT):
@tongli Hi can you tell me where on the peer/system are the transaction stored, so that i can see the kind of information they hold
pankajcheema (Sat, 08 Dec 2018 09:01:45 GMT):
@dave.enyeart I found the issue
pankajcheema (Sat, 08 Dec 2018 09:02:09 GMT):
issue is with couchdb 2.3
pankajcheema (Sat, 08 Dec 2018 09:04:43 GMT):
couchdb has changed the data type in response for `CreateDBIfExist` check
pankajcheema (Sat, 08 Dec 2018 09:04:43 GMT):
couchdb has changed the data type in response for `CreateDatabaseIfNotExist()` check
pankajcheema (Sat, 08 Dec 2018 09:05:04 GMT):
in couchdb version 2.3
tkg (Sun, 09 Dec 2018 14:13:30 GMT):
Has joined the channel.
javapriyan (Sun, 09 Dec 2018 17:12:47 GMT):
Has joined the channel.
anjalinaik (Mon, 10 Dec 2018 09:48:33 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=YmFYuszdMzP6m8WwG) @jrosmith hi..i am asking about constructing a proposal request..changing policy is done with the help of chaincodeendorsement.yaml file right? the user context should contain both the orgs identity signatures for "AND" policy, so i am asking, how do we create such a proposal request.
anjalinaik (Mon, 10 Dec 2018 09:56:23 GMT):
Hi experts.can anyone please help me solve the this error: `Error handling message: event message validation failed for 10.255.0.3:33388: failed deserializing event creator: expected MSP ID legal, received org1
`
anjalinaik (Mon, 10 Dec 2018 09:56:23 GMT):
Hi experts.can anyone please help me solve the this error: ````
``` Error handling message: event message validation failed for 10.255.0.3:33388: failed deserializing event creator: expected MSP ID legal, received org1
`
anjalinaik (Mon, 10 Dec 2018 09:56:23 GMT):
Hi experts.can anyone please help me solve the this error:
`Error handling message: event message validation failed for 10.255.0.3:33388: failed deserializing event creator: expected MSP ID legal, received org1`
anjalinaik (Mon, 10 Dec 2018 09:56:23 GMT):
Hi experts. can anyone please help me solve this error:
`Error handling message: event message validation failed for 10.255.0.3:33388: failed deserializing event creator: expected MSP ID legal, received org1`
suryalanka (Mon, 10 Dec 2018 15:37:41 GMT):
@yacovm Hi. I am trying to use service discovery and found discovery related parameters in sampleconfig/core.yaml file ``` discovery:
enabled: true
# Whether the authentication cache is enabled or not.
authCacheEnabled: true
# The maximum size of the cache, after which a purge takes place
authCacheMaxSize: 1000
# The proportion (0 to 1) of entries that remain in the cache after the cache is purged due to overpopulation
authCachePurgeRetentionRatio: 0.75
# Whether to allow non-admins to perform non channel scoped queries.
# When this is false, it means that only peer admins can perform non channel scoped queries.
orgMembersAllowedAccess: false ```
suryalanka (Mon, 10 Dec 2018 15:42:08 GMT):
@yacovm Hi. I am trying to use service discovery and found discovery related parameters in sampleconfig/core.yaml file ``` discovery:
enabled: true
# Whether the authentication cache is enabled or not.
authCacheEnabled: true
# The maximum size of the cache, after which a purge takes place
authCacheMaxSize: 1000
# The proportion (0 to 1) of entries that remain in the cache after the cache is purged due to overpopulation
authCachePurgeRetentionRatio: 0.75
# Whether to allow non-admins to perform non channel scoped queries.
# When this is false, it means that only peer admins can perform non channel scoped queries.
orgMembersAllowedAccess: false ``` If I dont define these parameters in core.yaml, does discovery enabled default to true?
yacovm (Mon, 10 Dec 2018 15:44:50 GMT):
yes
scottz (Mon, 10 Dec 2018 16:02:24 GMT):
Does the nodesdk request the first layout automatically when cc instantiation happens? That seems to be true. We do not see a need to send additional service discovery requests for new layouts if the nodes in our test network do not change. Just restarting the nodes would simply use the service discovery to use whatever peers are available.
yacovm (Mon, 10 Dec 2018 16:05:26 GMT):
> Does the nodesdk request the first layout automatically when cc instantiation happens?
I don't know...
> We do not see a need to send additional service discovery requests for new layouts if the nodes in our test network do not change.
It depends on what you want to test, but - if you change the endorsement policy then you might need to do a re-query.
> Just restarting the nodes would simply use the service discovery to use whatever peers are available.
This is a decision that is yours to make
rickr (Mon, 10 Dec 2018 21:05:21 GMT):
https://gerrit.hyperledger.org/r/#/c/26609/ like to see this running locally. Have some questions .. What if any capabilities are needed to enable this new lifecycle in my confitx.yaml ? Example please ! Any idea how soon it will be rebased ? I'm guessing even without the rebasing it should support the new lifecycle deployment. @jyellick @wlahti
rickr (Mon, 10 Dec 2018 21:05:21 GMT):
https://gerrit.hyperledger.org/r/#/c/26609/ like to see this running locally. Have some questions .. What if any capabilities are needed to enable this new lifecycle in my confitx.yaml ? Example please ! Any idea how soon the stack will be rebased ? I'm guessing even without the rebasing it should support the new lifecycle deployment. @jyellick @wlahti
wlahti (Tue, 11 Dec 2018 15:08:49 GMT):
@rickr +lifecycle will be enabled/disabled via core.yaml using `chaincode.system.+lifecycle: enable`. FYI, just noticed that the configuration parameter was left around from when development started even though the server code was pulled from v1.3 and v1.4.
rickr (Tue, 11 Dec 2018 17:01:40 GMT):
@wlahti Thx seems I already had that there as you indicated. I would have thought this enablement would be in the configtx.yaml Should this work if I've not regenerated the channel config block and peer join transaction since v1.3 release ?
rickr (Tue, 11 Dec 2018 17:04:56 GMT):
is enabled the default ?
rickr (Tue, 11 Dec 2018 17:07:04 GMT):
Would this be the equivalent in a docker compose ? CORE_PEER_CHAINCODE_SYSTEM_+LIFECYCLE_ENABLE=true
anjalinaik (Wed, 12 Dec 2018 04:04:58 GMT):
what parameter defines the number of peers in an organization?
SuperSeiyan (Wed, 12 Dec 2018 04:50:22 GMT):
Has joined the channel.
NeerajKumar (Wed, 12 Dec 2018 05:56:44 GMT):
Hi Experts,
I have been using hyperledger fabric with nodejs SDK from past many months now and i haven't faced any big issues but from last week some containers of my network infrastructure kept shutting down which some how i recovered but but i am not able to start the chaincode containers which were automatically generated after installing and instantiating the chaincode. it keep on shuttiing down. and now it says
"x509: certificate signed by unknown authority (possibly because of "x509: ECDSA verification failure" while trying to verify candidate authority certificate "serial:71333524560576167915191865139975345404"
in every containers log
can some body please explain why when ever i run
docker restart dev-peer1.org2.example.com-bel_adhaar-v1
command
containers exites immediately after trying to restart with the above error
anjalinaik (Wed, 12 Dec 2018 08:07:47 GMT):
If there is an AND endorsment policy for a 2 org[2 peer/org] , and if one of the peer couchdb is compromised, will the blockchain allow any further transactions?
FlorianStoica (Wed, 12 Dec 2018 16:41:18 GMT):
Has joined the channel.
dave.enyeart (Thu, 13 Dec 2018 05:03:22 GMT):
@anjalinaik Your endorsement policy of two or more peers will protect the network from a compromised state database... see details in this post: https://lists.hyperledger.org/g/fabric/message/4896
dave.enyeart (Thu, 13 Dec 2018 05:05:33 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=x9R4btzvGphqHcRNH) @rickr @jyellick @wlahti I don't think environment variables can have plus sign, right?
rickr (Thu, 13 Dec 2018 13:46:35 GMT):
yup -- That's what I figured so why I asked how that would translate .. also what's the default ... @wlahti ??
wlahti (Thu, 13 Dec 2018 13:49:39 GMT):
I imagine the default will be disabled. As mentioned, the +lifecycle code is not enabled now. There hasn't been any work on this in a number of months so I'll need to re-familiarize myself with the details and also check with @jyellick on the plan going forward.
wlahti (Thu, 13 Dec 2018 13:49:39 GMT):
I imagine the default will be disabled. The current plan, as I understand it, is to support both +lifecycle as well as the old lifecycle for a period of time before removing the old lifecycle. As mentioned, the +lifecycle code has either been removed from the codebase or has been explicitly disabled for now. There hasn't been any work on this in a number of months so I'll need to re-familiarize myself with the details and also check with @jyellick on the plan going forward.
wlahti (Thu, 13 Dec 2018 13:49:39 GMT):
@rickr I imagine the default will be disabled. The current plan, as I understand it, is to support both +lifecycle as well as the old lifecycle for a period of time before removing the old lifecycle. As mentioned, the +lifecycle code has either been removed from the codebase or has been explicitly disabled for now. There hasn't been any work on this in a number of months so I'll need to re-familiarize myself with the details and also check with @jyellick on the plan going forward.
wlahti (Thu, 13 Dec 2018 13:49:39 GMT):
@rickr I imagine the default will be disabled but don't quote me on that. @jyellick, thoughts? The current plan, as I understand it, is to support both +lifecycle as well as the old lifecycle for a period of time before removing the old lifecycle. As mentioned, the +lifecycle code has either been removed from the codebase or has been explicitly disabled for now. There hasn't been any work on this in a number of months so I'll need to re-familiarize myself with the details and also check with @jyellick on the plan going forward.
rickr (Thu, 13 Dec 2018 14:47:48 GMT):
Oh -- am I reading this wrong ... I was understanding _+lifecycle_ was the *new* lifecycle ? BTW IMO + in a setting name variable is not ideal
wlahti (Thu, 13 Dec 2018 15:55:48 GMT):
Correct, +lifecycle is the current name of the new lifecycle.
wlahti (Thu, 13 Dec 2018 15:55:48 GMT):
Correct, +lifecycle is how we'll continue to refer to the new lifecycle. However, the setting name isn't set in stone.
nickgaski (Thu, 13 Dec 2018 16:41:27 GMT):
hey guys, grown a little rusty on my Fabric knowledge so here's an elementary question. If I instantiate a cc with an `AND` endorsement policy, wouldn't the proposal need to target all of the relevant peers specified in the policy. And wouldn't this result in a container starting for each of the targeted peers? Or is `invoke` the only time when the call needs to go to all of the peers in the EP?
nickgaski (Thu, 13 Dec 2018 16:45:06 GMT):
The origin of the question is from when I ran through BYFN for the first time in six months or so yesterday. I did all the manual steps and everything worked until invoke, because the endorsement policy is `"AND ('Org1MSP.peer','Org2MSP.peer')"` and the documentation doesn't explicitly tell you to install the cc on the second org's peer. Makes sense that invoke doesn't work until the cc is installed, but it appears that instantiate still works without the cc installed.
nickgaski (Thu, 13 Dec 2018 16:46:02 GMT):
I was under the impression that instantiate operated like a normal transaction and that the enumerated endorsement policy would still need to be fulfilled on that operation
wlahti (Thu, 13 Dec 2018 17:06:07 GMT):
@nickgaski I haven't looked into it much lately so my knowledge may be outdated on this but I'd guess it's because in Fabric there's an instantiation policy in addition to an endorsement policy. So the instantiation policy could be set to something different from the endorsement policy (or likely not set at all, and I can't remember what the default is), which would allow instantiation to complete successful while invokes would fail.
wlahti (Thu, 13 Dec 2018 17:06:07 GMT):
@nickgaski I haven't looked into it much lately so my knowledge may be outdated on this but I'd guess it's because in Fabric there's an instantiation policy in addition to an endorsement policy. So the instantiation policy could be set to something different from the endorsement policy (or likely not set at all, and I can't remember what the default is), which would allow instantiation to complete successfully while invokes would fail.
nickgaski (Thu, 13 Dec 2018 18:49:25 GMT):
aha, thanks Will. I need to do a deep dive on the new features. That makes sense though
JaccobSmith (Fri, 14 Dec 2018 01:43:08 GMT):
Has joined the channel.
JaccobSmith (Fri, 14 Dec 2018 01:43:44 GMT):
Hello，all How could I use the Prometheus with Peer
anjalinaik (Fri, 14 Dec 2018 06:04:10 GMT):
Hi everyone.. i want to reset my network, so i deleted all the volumes,images created by chaincode container, crypto-config files ,pruned the network. Still my new network throws MSP not found error for the previous configuration. May i please know what am i missing here?
anjalinaik (Fri, 14 Dec 2018 06:04:10 GMT):
Hi everyone.. i want to reset my network, so i deleted all the volumes,images created by chaincode container, crypto-config files ,pruned the network. Still my new network throws MSP not found error for the previous configuration. May i please know what am i missing here?```
2018-12-14 06:17:53.722 UTC [cauthdsl] deduplicate -> ERRO 54a Principal deserialization failure (the supplied identity is not valid: x509: certificate signed by unknown authority (possibly because of "x509: ECDSA verification failure" while trying to verify candidate authority certificate "ca.org1.org1.com"))
``` my new network doesn't even define org1
JaccobSmith (Mon, 17 Dec 2018 03:26:37 GMT):
Hello，all，Dose the results returned by function “GetHistoryForKey” include the current state ？
Thomas-tuo (Mon, 17 Dec 2018 06:53:25 GMT):
Has joined the channel.
gordon1987 (Mon, 17 Dec 2018 08:39:52 GMT):
Has joined the channel.
rickr (Mon, 17 Dec 2018 16:01:35 GMT):
Back to the new +lifecycle ...
tar -tvf ../simplecc.tar.gz
---------- 0/0 89 1969-12-31 19:00 Chaincode-Package-Metadata.json
---------- 0/0 2193215 1969-12-31 19:00 GOLANG-Code-Package.tar.gz
```
was it really by design that files were to have no permision at all it the package ?
```
GOLANG-Code-Package.tar.gz
```
why the need for language type in the file name for the package ? It's in the `Chaincode-Package-Metadata.json ?
@wlahti @jyellick ^^^^
```
rickr (Mon, 17 Dec 2018 16:01:35 GMT):
Back to the new +lifecycle ...
tar -tvf ../simplecc.tar.gz
---------- 0/0 89 1969-12-31 19:00 Chaincode-Package-Metadata.json
---------- 0/0 2193215 1969-12-31 19:00 GOLANG-Code-Package.tar.gz
```
was it really by design that files were to have no permision at all it the package ?
```
GOLANG-Code-Package.tar.gz
```
why the need for language type in the file name for the package ? It's in the `Chaincode-Package-Metadata.json ?
```
rickr (Mon, 17 Dec 2018 16:01:35 GMT):
Back to the new +lifecycle ...
tar -tvf ../simplecc.tar.gz
---------- 0/0 89 1969-12-31 19:00 Chaincode-Package-Metadata.json
---------- 0/0 2193215 1969-12-31 19:00 GOLANG-Code-Package.tar.gz
```
Was it really by design that files were to have no permissions at all in the package ?
```
GOLANG-Code-Package.tar.gz
```
why the need for language type in the file name for the package ? It's in the `Chaincode-Package-Metadata.json ?
```
rickr (Mon, 17 Dec 2018 16:02:11 GMT):
@wlahti @jyellick ^^^^
wlahti (Mon, 17 Dec 2018 16:15:36 GMT):
I'll have to look into the permissions aspect. As for the naming of the chaincode package, I believe we just did that for easy human readability.
rickr (Mon, 17 Dec 2018 16:18:12 GMT):
Means we'll need to do that for each different language .. just having it as some package name for all languages would be easier for tooling find the actually code package .. the language is in the meta data already.
wlahti (Mon, 17 Dec 2018 16:19:20 GMT):
I see. We'll take that into consideration as we rebase/refactor.
wlahti (Mon, 17 Dec 2018 16:20:04 GMT):
Jason plans to push a rebased series of CRs for +lifecycle soon and I'll look into that when I rework the packaging CRs on top of that.
rickr (Mon, 17 Dec 2018 16:26:11 GMT):
thx
wlahti (Mon, 17 Dec 2018 18:52:59 GMT):
The pattern `
wlahti (Mon, 17 Dec 2018 18:52:59 GMT):
The pattern `
wlahti (Mon, 17 Dec 2018 18:52:59 GMT):
The pattern `
wlahti (Mon, 17 Dec 2018 18:52:59 GMT):
The pattern `
MikeEmery (Mon, 17 Dec 2018 23:36:33 GMT):
Trying to debug an lscc invoke timeout:
```2018-12-17 23:33:17.096 UTC [endorser] SimulateProposal -> ERRO 1f99 [][71f722f8] failed to invoke chaincode name:"lscc" , error: timeout expired while executing transaction
...
error sending
failed to execute transaction 71f722f8be014543e6ec58d5f7b7fa2b8bf89013efa8d5296aaf1f28c869fe2a```
I'm seeing this across the board while attempting to install any chaincode, regardless of peer or channel
ex: `peer chaincode install -n hashcc -v 2.0 -p /content/admin/cc-staging/hashcc --lang node`
MikeEmery (Mon, 17 Dec 2018 23:37:06 GMT):
existing chaincodes continue to run and function normally
yacovm (Mon, 17 Dec 2018 23:37:13 GMT):
put this https://github.com/hyperledger/fabric/blob/master/sampleconfig/core.yaml#L420 to `true`
yacovm (Mon, 17 Dec 2018 23:37:16 GMT):
and try again... @MikeEmery
yacovm (Mon, 17 Dec 2018 23:37:45 GMT):
oh, this is during install?
yacovm (Mon, 17 Dec 2018 23:37:48 GMT):
not instantiate?
yacovm (Mon, 17 Dec 2018 23:37:51 GMT):
are you sure?
MikeEmery (Mon, 17 Dec 2018 23:37:56 GMT):
correct, install
yacovm (Mon, 17 Dec 2018 23:38:15 GMT):
what is the error?
MikeEmery (Mon, 17 Dec 2018 23:38:49 GMT):
full log looks like:
```2018-12-17 23:32:47.096 UTC [endorser] callChaincode -> INFO 1f97 [][71f722f8] Entry chaincode: name:"lscc"
2018-12-17 23:33:17.096 UTC [endorser] callChaincode -> INFO 1f98 [][71f722f8] Exit chaincode: name:"lscc" (30000ms)
2018-12-17 23:33:17.096 UTC [endorser] SimulateProposal -> ERRO 1f99 [][71f722f8] failed to invoke chaincode name:"lscc" , error: timeout expired while executing transaction
github.com/hyperledger/fabric/core/chaincode.(*Handler).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:1225
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:312
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Invoke
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:301
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:238
github.com/hyperledger/fabric/core/endorser.(*SupportImpl).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/support.go:147
github.com/hyperledger/fabric/core/endorser.(*Endorser).callChaincode
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:142
github.com/hyperledger/fabric/core/endorser.(*Endorser).SimulateProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:237
github.com/hyperledger/fabric/core/endorser.(*Endorser).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:456
github.com/hyperledger/fabric/core/handlers/auth/filter.(*expirationCheckFilter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/expiration.go:61
github.com/hyperledger/fabric/core/handlers/auth/filter.(*filter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/filter.go:32
github.com/hyperledger/fabric/protos/peer._Endorser_ProcessProposal_Handler.func1
/opt/gopath/src/github.com/hyperledger/fabric/protos/peer/peer.pb.go:169
github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware.ChainUnaryServer.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware/chain.go:31
github.com/hyperledger/fabric/common/grpclogging.UnaryServerInterceptor.func1
/opt/gopath/src/github.com/hyperledger/fabric/common/grpclogging/server.go:91
github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware.ChainUnaryServer.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware/chain.go:34
github.com/hyperledger/fabric/common/grpcmetrics.UnaryServerInterceptor.func1
/opt/gopath/src/github.com/hyperledger/fabric/common/grpcmetrics/interceptor.go:30
github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware.ChainUnaryServer.func1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware/chain.go:39
github.com/hyperledger/fabric/protos/peer._Endorser_ProcessProposal_Handler
/opt/gopath/src/github.com/hyperledger/fabric/protos/peer/peer.pb.go:171
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).processUnaryRPC
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:982
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).handleStream
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:1208
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:686
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:1333
```
MikeEmery (Mon, 17 Dec 2018 23:38:56 GMT):
```error sending
failed to execute transaction 71f722f8be014543e6ec58d5f7b7fa2b8bf89013efa8d5296aaf1f28c869fe2a
github.com/hyperledger/fabric/core/chaincode.processChaincodeExecutionResult
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:244
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:239
github.com/hyperledger/fabric/core/endorser.(*SupportImpl).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/support.go:147
github.com/hyperledger/fabric/core/endorser.(*Endorser).callChaincode
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:142
github.com/hyperledger/fabric/core/endorser.(*Endorser).SimulateProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:237
github.com/hyperledger/fabric/core/endorser.(*Endorser).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:456
github.com/hyperledger/fabric/core/handlers/auth/filter.(*expirationCheckFilter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/expiration.go:61
github.com/hyperledger/fabric/core/handlers/auth/filter.(*filter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/filter.go:32
github.com/hyperledger/fabric/protos/peer._Endorser_ProcessProposal_Handler.func1
/opt/gopath/src/github.com/hyperledger/fabric/protos/peer/peer.pb.go:169
github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware.ChainUnaryServer.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware/chain.go:31
github.com/hyperledger/fabric/common/grpclogging.UnaryServerInterceptor.func1
/opt/gopath/src/github.com/hyperledger/fabric/common/grpclogging/server.go:91
github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware.ChainUnaryServer.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware/chain.go:34
github.com/hyperledger/fabric/common/grpcmetrics.UnaryServerInterceptor.func1
/opt/gopath/src/github.com/hyperledger/fabric/common/grpcmetrics/interceptor.go:30
github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware.ChainUnaryServer.func1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware/chain.go:39
github.com/hyperledger/fabric/protos/peer._Endorser_ProcessProposal_Handler
/opt/gopath/src/github.com/hyperledger/fabric/protos/peer/peer.pb.go:171
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).processUnaryRPC
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:982
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).handleStream
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:1208
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:686
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:1333```
yacovm (Mon, 17 Dec 2018 23:39:47 GMT):
doesn't ring a bell, sorry
MikeEmery (Mon, 17 Dec 2018 23:42:25 GMT):
it feels like it doesn't even really get started. I can point this as already instantiated chaincodes (expecting an error) but those time out also
MikeEmery (Mon, 17 Dec 2018 23:42:25 GMT):
it feels like it doesn't even really get started. I can point this at already instantiated chaincodes (expecting an error) but those time out also
yacovm (Mon, 17 Dec 2018 23:43:01 GMT):
try to install a golang chaincode @MikeEmery
yacovm (Mon, 17 Dec 2018 23:43:03 GMT):
and tell if that works
MikeEmery (Mon, 17 Dec 2018 23:47:20 GMT):
:thumbsup: will try shortly
MikeEmery (Tue, 18 Dec 2018 01:14:01 GMT):
no joy with golang cc, however deleting all of the peer files and letting it catch back up from the orderer appears to be working (still catching up, however lscc calls on the hashcc example immediately return now)
MikeEmery (Tue, 18 Dec 2018 01:14:01 GMT):
no joy with golang cc, however deleting all of the peer files and letting it catch back up from the orderer/other peers appears to be working (still catching up, however lscc calls on the hashcc example immediately return now)
rickr (Tue, 18 Dec 2018 17:56:19 GMT):
In the `Chaincode-Package-Metadata.json` does `Path` need to be present for languages other than GOLANG ?
rickr (Tue, 18 Dec 2018 18:02:21 GMT):
Also the type will be Type will be the same as ChaincodeSpec proto but all lower case; however, the code payload filename is ChaincodeSpec all upper case with suffix '-Code-Package.tar.gz' ?
rickr (Tue, 18 Dec 2018 18:02:21 GMT):
Also Type will be the same as ChaincodeSpec proto but all lower case; however, the code payload filename is ChaincodeSpec Type all upper case with suffix '-Code-Package.tar.gz' ?
rickr (Tue, 18 Dec 2018 18:02:41 GMT):
@wlahti @jyellick ^^^
MikeEmery (Tue, 18 Dec 2018 18:12:13 GMT):
Running peers on version v1.4.0-rc1 it appears that only the anchor peer is sending events back to the java SDK? is this a configuration setting or a change or am I way off base here?
wlahti (Tue, 18 Dec 2018 18:15:01 GMT):
@rickr As mentioned before, the naming of the code package tar.gz does not matter, and I can update the peer CLI to simply package it without the chaincode type in the file.
wlahti (Tue, 18 Dec 2018 18:15:01 GMT):
@rickr As mentioned before, the naming of the code package tar.gz does not matter, and I can update the peer CLI to simply package it without the chaincode type in the file name.
wlahti (Tue, 18 Dec 2018 18:15:01 GMT):
@rickr As mentioned before, the naming of the code package tar.gz does not matter, and I can update the peer CLI to simply package it without the chaincode type in the file name. Let me look into the specifics for your path question.
wlahti (Tue, 18 Dec 2018 18:15:01 GMT):
@rickr As mentioned before, the naming of the code package tar.gz does not matter, and I can update the peer CLI to simply package it without the chaincode type in the file name. Let me look into the specifics for your path question. I know it's required at the moment, just not familiar with what it should be set to for other languages.
wlahti (Tue, 18 Dec 2018 18:25:36 GMT):
Let me look into the specifics for your path question.
rickr (Tue, 18 Dec 2018 18:56:13 GMT):
Maybe I misunderstood ... so basically anything other than the Chaincode-Package-Metadata.json file is considered to be the codepackage payload ?
wlahti (Tue, 18 Dec 2018 19:01:27 GMT):
Correct, and if it is not a code package payload, the server will return an error.
wlahti (Tue, 18 Dec 2018 19:26:27 GMT):
Regarding the path, on the server side, it needs to be there for each language other than CAR.
chuda (Thu, 20 Dec 2018 13:07:10 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=AL4Ah9TMe6Cw4PJpv) @wlahti hi can u help here,,details are...in fabcar example i have inserted 20 cars ..iam retriving using query.js ,function queryall cars here calling query allcarsbyrange(startkey,endkey), iam passing these values explicitly,,when i have given startkey as 1 and endkey as 16 ..output is like this this..car1,car2,car11,car12,car1,car14,...which is unexpected output..if its not clear i will explain it further
rahulhegde (Thu, 20 Dec 2018 13:39:02 GMT):
In fabric on using couch database as state ledger, how does PEER ensure the complete operation at a ledger transaction is atomic?
Couch database does provide atomic operation at document level however a single endorsement response could have multiple write operation. How does peer recover in case if not all documents are written to couch database?
dave.enyeart (Thu, 20 Dec 2018 13:42:18 GMT):
@rahulhegde updates are committed to couchdb and then a savepoint is written to couchdb. in crash scenario, peer restart will look for the savepoint, and if not there, re-write the last block (writes are idempotent). for full details see https://github.com/hyperledger/fabric/blob/release-1.4/core/ledger/kvledger/txmgmt/statedb/statecouchdb/statecouchdb.go#L568-L574
rahulhegde (Thu, 20 Dec 2018 13:51:39 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=o4p93xfi9pctiKFY4) @dave.enyeart thank you.
anjalinaik (Mon, 24 Dec 2018 11:29:44 GMT):
Hi experts.. if we need to create a invoke request, do we need to redirect the request to only endorsing peers?
anjalinaik (Thu, 27 Dec 2018 06:30:39 GMT):
Hi experts..if the endorsment policy is not satisfied then the block shouldnt be added to the chain, correct?
`org1peer2.1.t5ttto5ct9bp@CPU92 | 2018-12-27 06:13:57.935 UTC [committer/txvalidator] validateTx -> ERRO 019 VSCCValidateTx for transaction txId = 52e73a5c8f2d75062b6fe06e877559138a285aba5204466ca2dd40489c0088cb returned error: validation of endorsement policy for chaincode fabcarand in tx 48:0 failed: signature set did not satisfy policy
org1peer2.1.t5ttto5ct9bp@CPU92 | 2018-12-27 06:14:05.253 UTC [gossip/privdata] StoreBlock -> INFO 01a [mychannel] Received block [49] from buffer`
anjalinaik (Thu, 27 Dec 2018 06:30:39 GMT):
Hi experts..if the endorsment policy is not satisfied then the block shouldnt be added to the chain, correct?
```
`org1peer2.1.t5ttto5ct9bp@CPU92 | 2018-12-27 06:13:57.935 UTC [committer/txvalidator] validateTx -> ERRO 019 VSCCValidateTx for transaction txId = 52e73a5c8f2d75062b6fe06e877559138a285aba5204466ca2dd40489c0088cb returned error: validation of endorsement policy for chaincode fabcarand in tx 48:0 failed: signature set did not satisfy policy
org1peer2.1.t5ttto5ct9bp@CPU92 | 2018-12-27 06:14:05.253 UTC [gossip/privdata] StoreBlock -> INFO 01a [mychannel] Received block [49] from buffer`
```
anjalinaik (Thu, 27 Dec 2018 06:30:39 GMT):
Hi experts..if the endorsment policy is not satisfied then the block shouldnt be added to the chain, correct?However from below peer logs i see that the blocks are being added inspite of endorsement policy failure.Any explanation would be helpful.
```
org1peer2.1.t5ttto5ct9bp@CPU92 | 2018-12-27 06:13:57.935 UTC [committer/txvalidator] validateTx -> ERRO 019 VSCCValidateTx for transaction txId = 52e73a5c8f2d75062b6fe06e877559138a285aba5204466ca2dd40489c0088cb returned error: validation of endorsement policy for chaincode fabcarand in tx 48:0 failed: signature set did not satisfy policy
org1peer2.1.t5ttto5ct9bp@CPU92 | 2018-12-27 06:14:05.253 UTC [gossip/privdata] StoreBlock -> INFO 01a [mychannel] Received block [49] from buffer
```
ShobhitSrivastava (Thu, 27 Dec 2018 12:11:08 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=5h5ssaZEuGiMSZGWg) @anjalinaik It goes in transaction log. Refer to it https://hyperledger-fabric.readthedocs.io/en/release-1.3/ledger/ledger.html
akshay.sood (Fri, 28 Dec 2018 09:00:13 GMT):
Hi Alll
akshay.sood (Fri, 28 Dec 2018 09:00:26 GMT):
anyone knows this error ```$ peer node start
2018-12-28 14:23:57.663 IST [main] InitCmd -> ERRO 001 Cannot run peer because error when setting up MSP of type bccsp from directory /home/akshay/dev/fabric-ca/fabric-ca-client/peerOrg/msp: could not initialize BCCSP Factories: %!s(
akshay.sood (Fri, 28 Dec 2018 09:00:32 GMT):
in `core.yaml` file
akshay.sood (Fri, 28 Dec 2018 09:00:48 GMT):
```BCCSP:
Default: pkcs11
pkcs11:
Library: /usr/local/lib/softhsm/libsofthsm2.so
Pin: 98765432
Label: ForFabric
hash: SHA2
security: 256
# Location of Key Store
FileKeyStore:
# If "", defaults to 'mspConfigPath'/keystore
# TODO: Ensure this is read with fabric/core/config.GetPath() once ready
KeyStore:```
StefanKosc (Thu, 03 Jan 2019 15:31:24 GMT):
Has joined the channel.
asaningmaxchain123 (Fri, 04 Jan 2019 01:08:25 GMT):
@wlahti the `CORE_PEER_TLS_SERVERHOSTOVERRIDE=false` doesn't support?
asaningmaxchain123 (Fri, 04 Jan 2019 01:08:55 GMT):
when i set the `CORE_PEER_TLS_SERVERHOSTOVERRIDE=false` but it doesn't work for me, can you help me?
x4e-salvi (Fri, 04 Jan 2019 18:54:39 GMT):
Has joined the channel.
asaningmaxchain123 (Sun, 06 Jan 2019 10:16:01 GMT):
@jyellick when i want to update the config value,it's policy which need majority policy,so these policy shoud sign in orderer?
asaningmaxchain123 (Sun, 06 Jan 2019 10:16:01 GMT):
@jyellick when i want to update the config value,it's policy which need majority policy,so shoud i sign in orderer?
asaningmaxchain123 (Sun, 06 Jan 2019 15:45:22 GMT):
@dave.enyeart can you tell me what's the `Organizational Units` in MSP
asaningmaxchain123 (Sun, 06 Jan 2019 15:45:22 GMT):
can you tell me what's the `Organizational Units` in MSP
asaningmaxchain123 (Sun, 06 Jan 2019 15:45:57 GMT):
and what's the function of the it
dave.enyeart (Sun, 06 Jan 2019 15:50:38 GMT):
@asaningmaxchain123 see https://hyperledger-fabric.readthedocs.io/en/latest/msp.html#identity-classification and how it can be used for endorser roles at https://hyperledger-fabric.readthedocs.io/en/latest/endorsement-policies.html#setting-chaincode-level-endorsement-policie
dave.enyeart (Sun, 06 Jan 2019 15:50:38 GMT):
@asaningmaxchain123 see https://hyperledger-fabric.readthedocs.io/en/latest/msp.html#identity-classification and how it can be used for endorser roles at https://hyperledger-fabric.readthedocs.io/en/latest/endorsement-policies.html#setting-chaincode-level-endorsement-policies
igor-egorov (Wed, 09 Jan 2019 10:19:09 GMT):
Has left the channel.
akshay.lawange (Fri, 11 Jan 2019 13:17:15 GMT):
Hi, I am getting an connection error to peer0 of org when i am trying to invoke even if the proposal is correct. Can anyone help why it is unable to connect?
Error `error: [Remote.js]: Error: Failed to connect before the deadline URL:grpcs://10.10.6.16:7051`
sstone1 (Fri, 11 Jan 2019 13:26:14 GMT):
@akshay.lawange are you 100% sure that the machine you're running the SDK on can access port 7051 on that IP address? you can test this using `ping 10.10.6.16` and `nc 10.10.6.16 7051`. if you're using some kind of cloud hosting, then you may need to open up the ports.
akshay.lawange (Fri, 11 Jan 2019 13:33:35 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=BAXP9xx9nApFebmJh) @sstone1 yes i am sure, cause it registers and enrolls user succesfully. that means it is able to get affiliations from orderer
akshay.lawange (Fri, 11 Jan 2019 13:33:35 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=BAXP9xx9nApFebmJh) @sstone1 yes i am sure, cause it registers and enrolls user succesfully. that means it is able to get affiliations from same server
sstone1 (Fri, 11 Jan 2019 13:34:32 GMT):
no, that means it can access the CA port on the server (7054?) - can it access port 7051?
akshay.lawange (Fri, 11 Jan 2019 13:36:25 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=zBPx2uoWDiKJyqyJj) @sstone1 ohh yes..so when i tried nc command i did not get any response its blank
akshay.lawange (Fri, 11 Jan 2019 13:38:02 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=sPL6pqxwvqhmW2nHz) but till yesterday it was able to connect..when i tried today it did not
sstone1 (Fri, 11 Jan 2019 13:42:57 GMT):
```
$ nc -v -G 5 10.10.6.16 7051
nc: connectx to 10.10.6.16 port 7051 (tcp) failed: Operation timed out
```
sstone1 (Fri, 11 Jan 2019 13:43:16 GMT):
are you sure the peer is even running then? is the docker container still running on that system? are there any errors in the docker container logs?
akshay.lawange (Fri, 11 Jan 2019 13:46:29 GMT):
yeah, container is running and there is no error in the log
akshay.lawange (Fri, 11 Jan 2019 13:48:19 GMT):
nc -v 10.10.6.16 7051
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connected to 10.10.6.16:7051.
akshay.lawange (Fri, 11 Jan 2019 13:48:23 GMT):
got this
akshay.lawange (Fri, 11 Jan 2019 13:59:14 GMT):
any clue?
chinmsay213211 (Fri, 11 Jan 2019 22:20:34 GMT):
Has joined the channel.
dan13 (Mon, 14 Jan 2019 17:43:54 GMT):
Has joined the channel.
MikeEmery (Mon, 14 Jan 2019 21:49:06 GMT):
Could someone please verify that the peer chaincode config `deploytimeout` is now defunct (1.4)? Is it fully replaced by `requesttimeout` or is there a different approach I should be taking?
iramiller (Mon, 14 Jan 2019 21:57:13 GMT):
Addendum to @MikeEmery's question above ... the config files in the cluster example folder and the sampleconfig folder of the 1.4 release branch are not in sync. Would be nice if the peer config file had a little more structure like the `orderer.yaml` file does.
yacovm (Mon, 14 Jan 2019 22:14:06 GMT):
what do you mean? they are both yaml files
iramiller (Mon, 14 Jan 2019 22:21:06 GMT):
@yacovm ... I am referring to minor stuff like
```
# timeout in millisecs for starting up a container and waiting for Register
# to come through. 1sec should be plenty for chaincode unit tests
startuptimeout: 300000
# timeout in millisecs for invokes and initialize commands
# this timeout is used by all chaincodes in all the channels including
# system chaincodes. Default is 30000ms (30 seconds)
executetimeout: 30000
#timeout in millisecs for deploying chaincode from a remote repository.
deploytimeout: 30000
```
in the cluster config core.yaml file which is quite out of date. The sampleconfig/core.yaml seems to be the most current.
iramiller (Mon, 14 Jan 2019 22:21:55 GMT):
deploytimeout was removed sometime in early 2017 based on this commit : https://github.com/FigureTechnologies/fabric/commit/dff87f934df4e67b20fbe61b038c2b24b218380c
yacovm (Mon, 14 Jan 2019 22:22:32 GMT):
I understand, but what do you mean by structure?
iramiller (Mon, 14 Jan 2019 22:22:35 GMT):
These files would probably stay cleaner and more current if they were validated like the orderer.yaml file is... but I certainly understand that there is no shortage of clean up work to do
yacovm (Mon, 14 Jan 2019 22:22:47 GMT):
you mean having defaults, etc. ?
iramiller (Mon, 14 Jan 2019 22:22:49 GMT):
(that validation comment is what I mean about structure)
iramiller (Mon, 14 Jan 2019 22:23:15 GMT):
If I add sections to orderer.yaml file that are not supported it faults
yacovm (Mon, 14 Jan 2019 22:23:19 GMT):
right
yacovm (Mon, 14 Jan 2019 22:23:25 GMT):
oh... i see now
yacovm (Mon, 14 Jan 2019 22:23:35 GMT):
you want the peer parsing to be fail-fast like the orderer?
iramiller (Mon, 14 Jan 2019 22:23:55 GMT):
That is what I was getting at
yacovm (Mon, 14 Jan 2019 22:23:59 GMT):
it doesn't work the other direction though
iramiller (Mon, 14 Jan 2019 22:24:03 GMT):
(and a pony too since I am so needy)
yacovm (Mon, 14 Jan 2019 22:24:07 GMT):
if we *add* a value it doesn't fail
yacovm (Mon, 14 Jan 2019 22:24:31 GMT):
what size do you want the pony?
iramiller (Mon, 14 Jan 2019 22:24:44 GMT):
I encountered the orderer.yaml validation in the middle of the testing of the new metrics stuff
iramiller (Mon, 14 Jan 2019 22:25:02 GMT):
I had an old config with the new code base ... was bad ...
iramiller (Mon, 14 Jan 2019 22:25:19 GMT):
very helpful at the time once I figured out what was up
yacovm (Mon, 14 Jan 2019 22:25:29 GMT):
you can open a JIRA
yacovm (Mon, 14 Jan 2019 22:25:42 GMT):
to ignite a discussion about it
iramiller (Mon, 14 Jan 2019 22:25:43 GMT):
I could ...
iramiller (Mon, 14 Jan 2019 22:25:50 GMT):
if you think it is worth while
yacovm (Mon, 14 Jan 2019 22:26:06 GMT):
I think anything that makes the user's life easier or more productive or safe is worthwhile
yacovm (Mon, 14 Jan 2019 22:26:22 GMT):
you are a user, are you not?
yacovm (Mon, 14 Jan 2019 22:26:27 GMT):
so yes :)
iramiller (Mon, 14 Jan 2019 22:26:52 GMT):
eh ... my solution to much of this is to have my fork open and review the code base when I have questions ...
iramiller (Mon, 14 Jan 2019 22:26:59 GMT):
I wouldn't expect that to be normal
iramiller (Mon, 14 Jan 2019 22:27:13 GMT):
even if effective
yacovm (Mon, 14 Jan 2019 22:27:28 GMT):
wouldn't expect what to be normal? reviewing the code?
iramiller (Mon, 14 Jan 2019 22:28:08 GMT):
yes ... tracing out usage of config file parameters in the code base when there are differences between the examples and the sample config file to determine which is the current correct approach
iramiller (Mon, 14 Jan 2019 22:28:24 GMT):
that is probably a step farther than most users go
yacovm (Mon, 14 Jan 2019 22:28:32 GMT):
why did you use the cluster file in the 1st place?
iramiller (Mon, 14 Jan 2019 22:28:33 GMT):
given the many questions that appear here
yacovm (Mon, 14 Jan 2019 22:29:03 GMT):
@dave.enyeart what are we going to do about the cluster sample? it's outdated....
iramiller (Mon, 14 Jan 2019 22:29:10 GMT):
I didn't use it ... I saw a reference to a config parameter in our old stuff that wasn't in the current sample ... searched and found it only occurred in a unit test and the example cluster
yacovm (Mon, 14 Jan 2019 22:30:39 GMT):
anyway I am sorry for your inconvenience and loss of time debugging fabric :)
you are right that it shouldn't be that way... are you using though v1.4 or master branch?
iramiller (Mon, 14 Jan 2019 22:31:33 GMT):
minor points overall ... I am working on a 1.4 release branch based update to our environments
iramiller (Mon, 14 Jan 2019 22:32:45 GMT):
looking forward to statsd and updated logging improvements ... I'm expecting a much nicer experience in production with those updates.
yacovm (Mon, 14 Jan 2019 22:36:02 GMT):
all right. anyway - you can always (apart from debugging the code yourself, which is actually not a bad solution)- ask in rocket chat , open a JIRA, or send an email to the mailing list
iramiller (Mon, 14 Jan 2019 22:36:29 GMT):
:thumbsup:
yacovm (Mon, 14 Jan 2019 22:37:34 GMT):
and, just as an "action item" - @dave.enyeart I think we should either remove or update the cluster examples as people use it and get burned...
yacovm (Mon, 14 Jan 2019 22:37:44 GMT):
@sykesm ^
dave.enyeart (Mon, 14 Jan 2019 22:51:32 GMT):
@yacovm I don't have background with the cluster example, but it seems it could be completely removed in favor of BYFN
dave.enyeart (Mon, 14 Jan 2019 22:52:55 GMT):
@lehors has volunteered to clean up /examples, I think the cluster example is an easy delete
QwertyJack (Tue, 15 Jan 2019 00:57:22 GMT):
Has joined the channel.
QwertyJack (Tue, 15 Jan 2019 00:58:59 GMT):
Hi there. I want to debug peer but my Goland says 'could not launch process: could not get .debug_frame section: could not find .debug_frame section'.
I m using Goland with release 1.3.0 . Both golang 1.10 & 1.11 tried.
Thanks for help.
QwertyJack (Tue, 15 Jan 2019 00:58:59 GMT):
Hi there. I want to debug peer but my Goland says 'could not launch process: could not get .debug_frame section: could not find .debug_frame section'.
I m using Goland with release 1.3.0 . Both golang 1.10 & 1.11 tried with failure, while sdk-go works like a charm.
Thanks for help.
jrosmith (Tue, 15 Jan 2019 15:41:13 GMT):
hey all, looking for some help reconfiguring the peer docker contain in the byfn example. i'm using a custom chaincode which i have successfully deployed on fabric 1.1 and 1.2. i've skipped 1.3 and am now integrating 1.4. when i go to install the chaincode, i receive the following error in my client: `Error: 8 RESOURCE_EXHAUSTED: grpc: received message larger than max (133963831 vs. 104857600)`
i've looked through the docs and i've seen i can update env vars for the peer in `peer-base.yml` and I'm assuming I can just set a var of `GRPC_MAX_RECEIVE_SIZE=-1`?
jrosmith (Tue, 15 Jan 2019 15:41:13 GMT):
hey all, looking for some help reconfiguring the peer docker container in the byfn example. i'm using a custom chaincode which i have successfully deployed on fabric 1.1 and 1.2. i've skipped 1.3 and am now upgrading my applications to work against 1.4. when i go to install the chaincode, i receive the following error in my client: `Error: 8 RESOURCE_EXHAUSTED: grpc: received message larger than max (133963831 vs. 104857600)`
i've looked through the docs and i've seen i can update env vars for the peer in `peer-base.yml` and I'm assuming I can just set a var of `GRPC_MAX_RECEIVE_SIZE=-1`? also curious as to why there is a limit where im assuming previously one did not exist
jrosmith (Tue, 15 Jan 2019 15:41:13 GMT):
hey all, looking for some help reconfiguring the peer docker container in the byfn example. i'm using a custom chaincode which i have successfully deployed on fabric 1.1 and 1.2. i've skipped 1.3 and am now upgrading my applications to work against 1.4. when i go to install the chaincode, i receive the following error in my client: `Error: 8 RESOURCE_EXHAUSTED: grpc: received message larger than max (133963831 vs. 104857600)`
i've looked through the docs and i've seen i can update env vars for the peer in `peer-base.yml` and I'm assuming I can just set a var of `GRPC_MAX_RECEIVE_SIZE=-1`? also curious as to why there is a limit where im assuming previously one did not exist
update: i tried setting the env var as above, it did not resolve my issue. how can i increase the max message size for the peer?
toddinpal (Tue, 15 Jan 2019 19:36:14 GMT):
@aso I just listed to your state based endorsement talk and it seems that this completely conflates consensus and authorization. What is the use case that chaincode and the existing endorsement policy doesn't handle?
toddinpal (Tue, 15 Jan 2019 19:36:14 GMT):
@aso I just listened to your state based endorsement talk and it seems that this completely conflates consensus and authorization. What is the use case that chaincode and the existing endorsement policy doesn't handle?
aso (Tue, 15 Jan 2019 20:50:35 GMT):
@toddinpal : state-based endorsement is just a way to express an endorsement policy at the level of an individual ledger key. Without this feature, it is far more complicated to handle a ledger namespace with a more diverse security model that can't be expressed by a single, global policy
aso (Tue, 15 Jan 2019 20:50:35 GMT):
@toddinpal : state-based endorsement is just a way to express an endorsement policy at the level of an individual ledger key. Without this feature, it is far more complicated to handle a ledger namespace with a more diverse security model that can't be captured by a single, global policy
jrosmith (Wed, 16 Jan 2019 14:33:21 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=X9zvoo5JErDgo2JCG) so i've found where the limit of 104857600 comes from. fabric/core/comm/config.go line 23 has a default config var set: `MaxRecvMsgSize = 100 * 1024 * 1024`. still trying to figure out how to override the config for both the binary and docker container.
toddinpal (Wed, 16 Jan 2019 15:19:32 GMT):
@aso I understand the change in granularity. What I don't understand is when might this be useful and how it relates to security? I've always viewed endorsement policies as a matter of trust and not security. As well, now chaincode has to have specific knowledge about these trust arrangements whereas with the normal endorsement policy mechanism the chaincode is (or at least can be) completely ignorant of the trust issues as they are handled outside the chaincode in a declarative manner.
aso (Wed, 16 Jan 2019 15:26:17 GMT):
this (https://github.com/hyperledger/fabric-samples/tree/release-1.4/interest_rate_swaps) is an example in which state-based endorsement is useful. In general, state-based endorsement is applicable whenever a chaincode-wide endorsement policy cannot assure the integrity and correctness of the entirety of the chaincode state.
aso (Wed, 16 Jan 2019 15:26:57 GMT):
(...and breaking down the state into multiple chaincodes is undesirable/not applicable)
gaijinviki (Thu, 17 Jan 2019 04:46:58 GMT):
Has joined the channel.
WouterVanHecke (Thu, 17 Jan 2019 14:02:47 GMT):
Has joined the channel.
amendafernando (Fri, 18 Jan 2019 05:26:32 GMT):
Has joined the channel.
amendafernando (Fri, 18 Jan 2019 05:34:15 GMT):
I'm trying to connect to an existing channel from newly created peer. But I'm getting exception as
```
root@56ef49d1347f:/etc/hyperledger/configtx# peer channel join -o orderer.example.com:7050 --blockpath composerchannel_config.block
2019-01-17 14:27:49.893 UTC [msp] GetLocalMSP -> DEBU 001 Returning existing local MSP
2019-01-17 14:27:49.893 UTC [msp] GetDefaultSigningIdentity -> DEBU 002 Obtaining default signing identity
2019-01-17 14:27:49.896 UTC [channelCmd] InitCmdFactory -> INFO 003 Endorser and orderer connections initialized
2019-01-17 14:27:49.897 UTC [msp/identity] Sign -> DEBU 004 Sign: plaintext: 0A9C070A5C08011A0C08E5A182E20510...48DE8AA89E1E1A080A000A000A000A00
2019-01-17 14:27:49.897 UTC [msp/identity] Sign -> DEBU 005 Sign: digest: E4BB7028F4F6483A94DCD0BF992F73F41D7A48EB5C496E5C5E4F2A29B56425BD
Error: proposal failed (err: rpc error: code = Unknown desc = chaincode error (status: 500, message: "JoinChain" request failed authorization check for channel [composerchannel]: [Failed verifying that proposal's creator satisfies local MSP principal during channelless check policy with policy [Admins]: [This identity is not an admin]]))
```
someone please help me with this.
sanket1211 (Sat, 19 Jan 2019 10:02:18 GMT):
Has joined the channel.
sanket1211 (Sat, 19 Jan 2019 10:03:34 GMT):
2019-01-19 07:06:56.818 UTC [main] InitCmd -> ERRO 001 Cannot run peer because cannot init crypto, folder "/etc/hyperledger/crypto/peer/msp" does not exist
2019-01-19 07:06:56.818 UTC [main] InitCmd -> ERRO 001 Cannot run peer because cannot init crypto, folder "/etc/hyperledger/crypto/peer/msp" does not exist
2019-01-19 07:06:56.818 UTC [main] InitCmd -> ERRO 001 Cannot run peer because cannot init crypto, folder "/etc/hyperledger/crypto/peer/msp" does not exist
2019-01-19 07:06:56.818 UTC [main] InitCmd -> ERRO 001 Cannot run peer because cannot init crypto, folder "/etc/hyperledger/crypto/peer/msp" does not exist
2019-01-19 07:06:56.818 UTC [main] InitCmd -> ERRO 001 Cannot run peer because cannot init crypto, folder "/etc/hyperledger/crypto/peer/msp" does not exist2019-01-19 07:06:56.818 UTC [main] InitCmd -> ERRO 001 Cannot run peer because cannot init crypto, folder "/etc/hyperledger/crypto/peer/msp" does not exist
2019-01-19 07:06:56.818 UTC [main] InitCmd -> ERRO 001 Cannot run peer because cannot init crypto, folder "/etc/hyperledger/crypto/peer/msp" does not exist
2019-01-19 07:06:56.818 UTC [main] InitCmd -> ERRO 001 Cannot run peer because cannot init crypto, folder "/etc/hyperledger/crypto/peer/msp" does not exist
2019-01-19 07:06:56.818 UTC [main] InitCmd -> ERRO 001 Cannot run peer because cannot init crypto, folder "/etc/hyperledger/crypto/peer/msp" does not exist
2019-01-19 07:06:56.818 UTC [main] InitCmd -> ERRO 001 Cannot run peer because cannot init crypto, folder "/etc/hyperledger/crypto/peer/msp" does not exist
2019-01-19 07:06:56.818 UTC [main] InitCmd -> ERRO 001 Cannot run peer because cannot init crypto, folder "/etc/hyperledger/crypto/peer/msp" does not exist
2019-01-19 07:06:56.818 UTC [main] InitCmd -> ERRO 001 Cannot run peer because cannot init crypto, folder "/etc/hyperledger/crypto/peer/msp" does not exist
peer2.org1.example.com | 2019-01-19 07:06:56.818 UTC [main] InitCmd -> ERRO 001 Cannot run peer because cannot init crypto, folder "/etc/hyperledger/crypto/peer/msp" does not exist
peer2.org1.example.com | 2019-01-19 07:06:56.818 UTC [main] InitCmd -> ERRO 001 Cannot run peer because cannot init crypto, folder "/etc/hyperledger/crypto/peer/msp" does not exist
sanket1211 (Sat, 19 Jan 2019 10:04:09 GMT):
peer2.org1.example.com | 2019-01-19 07:06:56.818 UTC [main] InitCmd -> ERRO 001 Cannot run peer because cannot init crypto, folder "/etc/hyperledger/crypto/peer/msp" does not exist
....this error shows up when i try to add new peer...
sanket1211 (Sat, 19 Jan 2019 10:04:53 GMT):
plz revert back for solution...thank you
WouterVanHecke (Mon, 21 Jan 2019 10:25:46 GMT):
The fabric network is running correctly, but when I try to restart to peer, the chaincode doesn't work anymore. I know that the dev containers gets put down and then restarted together with the peer container. But it doesn't work anymore. When I try to invoke a function. That function is not found anymore, so I'm getting a time-out every time. Can someone help me with this problem?
WouterVanHecke (Mon, 21 Jan 2019 10:26:15 GMT):
Log of the peer after restarting:
```
...
2019-01-21 10:09:28.360 UTC [gossip/service] func1 -> INFO 012 Initialize gossip with endpoint 172.22.0.5:7051 and bootstrap set [127.0.0.1:7051]
2019-01-21 10:09:28.362 UTC [gossip/gossip] NewGossipService -> INFO 013 Creating gossip service with self membership of {peer0.org1.example.com:7051 [] [7 28 82 74 12 2 191 205 247 212 85 142 28 4 220 110 7 37 159 95 164 241 229 238 15 213 151 178 253 175 214 101] 172.22.0.5:7051
WouterVanHecke (Mon, 21 Jan 2019 10:26:18 GMT):
Log of the dev container:
```
(node:19) UnhandledPromiseRejectionWarning: Error: function not found: publishResource
at Chaincode._callee$ (/usr/local/src/dist/MyChainCode.js:90:23)
at tryCatch (/usr/local/src/node_modules/regenerator-runtime/runtime.js:62:40)
at Generator.invoke [as _invoke] (/usr/local/src/node_modules/regenerator-runtime/runtime.js:296:22)
at Generator.prototype.(anonymous function) [as next] (/usr/local/src/node_modules/regenerator-runtime/runtime.js:114:21)
at asyncGeneratorStep (/usr/local/src/dist/MyChainCode.js:35:103)
at _next (/usr/local/src/dist/MyChainCode.js:37:194)
at /usr/local/src/dist/MyChainCode.js:37:364
at new Promise (
WouterVanHecke (Mon, 21 Jan 2019 10:27:10 GMT):
Cut out some logs of the peer that had no benefit to the question because the message was to long
JaccobSmith (Mon, 21 Jan 2019 11:45:58 GMT):
Hello all，How could I invoke the lscc/GetDeploymentSpec?
ycarmel (Tue, 22 Jan 2019 08:47:12 GMT):
Has joined the channel.
SahithiDyavarashetti (Tue, 22 Jan 2019 11:17:45 GMT):
Has joined the channel.
SahithiDyavarashetti (Tue, 22 Jan 2019 11:17:49 GMT):
can anyone help me with this?
Starting business network definition. This may take a minute...
Error: Error trying to start business network. Error: Peer localhost:7051 has rejected transaction '8d53f47f01efa13c5124a019ca7bfaa83622f0ba7e043bafdded1bf388c8ffe6' with code ENDORSEMENT_POLICY_FAILURE
Command failed
Jamie (Tue, 22 Jan 2019 17:08:30 GMT):
Has joined the channel.
incarose (Wed, 23 Jan 2019 00:23:59 GMT):
Has joined the channel.
SahithiDyavarashetti (Wed, 23 Jan 2019 07:06:00 GMT):
```
Starting business network definition. This may take a minute...
Error: Error trying to start business network. Error: Failed to receive commit notification from 192.168.1.164:9051 for transaction 'da77cb6ecd57396622d318005d78f5b6805a5545ed6c7ea75bd116fa8531cf86' within the timeout period
Command failed
```
AkhilKura (Wed, 23 Jan 2019 09:26:00 GMT):
Has joined the channel.
unlimited (Wed, 23 Jan 2019 17:42:32 GMT):
Has joined the channel.
unlimited (Wed, 23 Jan 2019 17:44:32 GMT):
Hey Gurus! I understand that the Kafka mechanism ensures transactions are stored in logical order. However is there a way to reference the transactions in chronological order, since transactions may not arrive in order due to network latency?
unlimited (Wed, 23 Jan 2019 17:44:46 GMT):
(arrive in order of submission)
kelvinzhong (Fri, 25 Jan 2019 02:04:44 GMT):
@dave.enyeart @yacovm hi, i'm confusing that seems fabric try to implement a raft-based ordering service then move on to BFT-based ordering service, but as i know, the consensus of fabric is based on a transaction flow and the ordering service can't altered any transaction on it's own, why fabric care the consensus between the orderer nodes?
even the BFT-based ordering service is delivered, i can't tell what's the different between Kaffka-based ordering service, even worse the BFT-based ordering service might slower in ordering.
adamhardie (Fri, 25 Jan 2019 09:34:00 GMT):
Has joined the channel.
adamhardie (Fri, 25 Jan 2019 09:34:21 GMT):
hey! have been installing chaincode happily for a while now,. but have just setup a new network...
When i try to instantiate a chaincode from the cli container, with the command:
peer chaincode instantiate -o orderer0.company:7050 -C messagebus -n nodecode -l "golang" -v 4.0 -c '{"Args":[""]}' -P "OR ('Org1MSP.member','Org2MSP.member')"
i get this error:
API error (500): Could not attach to network company-new_net: rpc error: code = NotFound desc = network company-new_net not found
My question is where is company-new_net coming from? The peer is connected to a network called node_node.
I have run a network called company_new_net previously; but have since changed all instances within the configuration files. So i am wondering how the chaincode script is picking that name up. Hope you can help!
adamhardie (Fri, 25 Jan 2019 09:34:49 GMT):
i have tried removing all volumes, images, networks and services and starting from scratch, but no luck
dave.enyeart (Fri, 25 Jan 2019 10:12:57 GMT):
@kelvinzhong The benefit of going to Raft is that it removes the Kafka dependency. The benefit of eventual BFT is that ordering can be run by a group of non-trusting organizations. See some discussion of this at https://lists.hyperledger.org/g/fabric/message/5295. If you want to drill deep I'll refer you to #fabric-orderer where the ordering service experts hang out.
yacovm (Fri, 25 Jan 2019 10:19:58 GMT):
Right, and to add to what Dave said - Raft work actually entails 2 independent parts:
- The Raft consensus core itself, which uses the etcd/raft library and translates its input/output to Fabric language
- Communication and replication support for orderers that have leader based consensus, that is independent of consensus type and can be re-used for BFT as well
yacovm (Fri, 25 Jan 2019 10:20:41 GMT):
So in a way - a considerable of work put into Raft orderer is going to be reused
adamhardie (Fri, 25 Jan 2019 16:28:21 GMT):
i have also restarted docker completely and i still get this strange network name! only when instantiating the chaincode do i see that name!
adamhardie (Fri, 25 Jan 2019 16:34:10 GMT):
and regenerated all crypto, everything
Error: could not assemble transaction, err proposal response was not successful, error code 500, msg error starting container: error starting container: API error (500): Could not attach to network company-new_net: rpc error: code = NotFound desc = network company-new_net not found
adamhardie (Fri, 25 Jan 2019 16:34:21 GMT):
can someone tell me where i can find the cause of the above error?
adamhardie (Fri, 25 Jan 2019 16:34:51 GMT):
i cant see it in logs anywhere, im trying to find where the instantiate command is getting a random network name from
lip-inagora (Mon, 28 Jan 2019 00:22:39 GMT):
Has joined the channel.
kelvinzhong (Mon, 28 Jan 2019 04:49:17 GMT):
@yacovm @dave.enyeart thx for the reply, i can see the benefit of raft / BFT, but somehow the idea of consensus between the orderers might have misleading many people that make them believed the consensus of orderer is equal to the consensus of the fabric, even worse they believe the Crash Fault Tolerence(CFT) offered by kaffa is the consensus of fabric. I think it's better to point out kaffka/raft/BFT have nothing to do with the consensus of fabric in the introduction of fabric :joy:
kelvinzhong (Mon, 28 Jan 2019 04:57:43 GMT):
my point is, as I know fabric v0.6 is using orderer to achieve the consensus, and indeed using BFT as the consensus method, but v1.X or v2.X is not, which is using a transaction flow the achieve the consensus, but still many people(as I know in china) believe the consensus of v1.X or v2.X is also based on orderer to achieve the consensus, even the first time when i found the raft/bft orderer service is going to provide in 2.X, I was quite confused about the definition of the consensus of fabric.
kelvinzhong (Mon, 28 Jan 2019 04:57:43 GMT):
my point is, as I know fabric v0.6 is using orderer to achieve the consensus, and indeed using BFT as the consensus method, but v1.X or v2.X is not, which is using a transaction flow to achieve the consensus, but still many people(as I know in china) believe the consensus of v1.X or v2.X is also based on orderer to achieve the consensus, even the first time when i found the raft/bft orderer service is going to provide in 2.X, I was quite confused about the definition of the consensus of fabric.
kelvinzhong (Mon, 28 Jan 2019 04:57:43 GMT):
my point is, as I know fabric v0.6 is using orderer to achieve the consensus, and indeed using BFT as the consensus method, but v1.X or v2.X is not, which is using a transaction flow to achieve the consensus, but still many people(as I know in china) believe the consensus of v1.X or v2.X is also based on orderer to achieve the consensus, even the first time when i found the raft/bft orderer service is going to provide in 2.X, I was quite confused about the definition of the consensus.
knagware9 (Mon, 28 Jan 2019 13:11:58 GMT):
Hi ,, anybody face this issue , when transaction send for proposal to endorser peer , chaincode conatiner get exited with error
panic: runtime error: index out of range
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0x94e086]
goroutine 60 [running]:
github.com/hyperledger/fabric/core/chaincode/shim.(*Handler).triggerNextState(0xc00007db00, 0x0, 0xc0000872c0)
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/shim/handler.go:35 +0x26
github.com/hyperledger/fabric/core/chaincode/shim.(*Handler).handleTransaction.func1.1(0xc00007db00, 0xc0001e7eb0, 0xc0000872c0)
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/shim/handler.go:247 +0x42
panic(0xadf180, 0x12fbc80)
/opt/go/src/runtime/panic.go:513 +0x1b9
main.(*SimpleChaincode).addProduct(0x136d380, 0xc5cd80, 0xc0001ce000, 0xc0001e0010, 0x7, 0x7, 0x0, 0x0, 0x0, 0x0, ...)
/chaincode/input/src/github.com/example_cc/go/rolex.go:131 +0x707
main.(*SimpleChaincode).Invoke(0x136d380, 0xc5cd80, 0xc0001ce000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
/chaincode/input/src/github.com/example_cc/go/rolex.go:84 +0x5fe
github.com/hyperledger/fabric/core/chaincode/shim.(*Handler).handleTransaction.func1(0xc00007db00, 0xc0000872c0, 0xc000464480)
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/shim/handler.go:273 +0x4eb
created by github.com/hyperledger/fabric/core/chaincode/shim.(*Handler).handleTransaction
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/shim/handler.go:242 +0x53
and all the peer which are given in endrosment policy get exited
and strange is that when I use curl this invoke transaction successful , I am getting this only when I use any web UI to invoke the same transact
yacovm (Mon, 28 Jan 2019 13:13:38 GMT):
@sykesm
edisinovcic (Mon, 28 Jan 2019 13:15:50 GMT):
Has joined the channel.
gravity (Mon, 28 Jan 2019 13:23:37 GMT):
hi all
what is the recommended expiration time for the certificates for peers and orderers? is it a good practice to leave expiry time 1 year and re-enroll them before they expire?
knagware9 (Mon, 28 Jan 2019 13:40:48 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=f6w7f62hSFWwwuDBJ) please check someone , I am getting this issue and not able to find out why this strange behavious
knagware9 (Mon, 28 Jan 2019 13:40:48 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=f6w7f62hSFWwwuDBJ) please check someone , I am getting this issue and not able to find out why this strange behaviour
adamhardie (Mon, 28 Jan 2019 14:11:52 GMT):
hey all, when I try to instantiate chaincode, i see this printed:
Error: could not assemble transaction, err proposal response was not successful, error code 500, msg timeout expired while starting chaincode ccode:1.0 for transaction
seems some error when creating the peer container . in peer logs i can see the chaincode container being created, then..
"stopping due to error while launching: timeout expired while starting chaincode ccode:1.0 for transaction" logged here too, with a stack trace
adamhardie (Mon, 28 Jan 2019 14:13:03 GMT):
the stacktrace shows
2019-01-25 16:49:06.180 UTC [endorser] SimulateProposal -> ERRO 7a4 [messagebus][b5e77bba] failed to invoke chaincode name:"lscc" , error: timeout expired while starting chaincode ccode:1.0 for transaction
github.com/hyperledger/fabric/core/chaincode.(*RuntimeLauncher).Launch
pankajcheema (Mon, 28 Jan 2019 16:47:22 GMT):
@knagware9 it seems you are trying to access null pointer in your chaincode
pankajcheema (Mon, 28 Jan 2019 16:48:43 GMT):
This is not related to Hyperledger this is totally related to your chaincode
pankajcheema (Mon, 28 Jan 2019 16:48:50 GMT):
Code
pankajcheema (Mon, 28 Jan 2019 16:53:06 GMT):
@adamhardie it’s coming from the base directory of you sample if using fabric sample
pankajcheema (Mon, 28 Jan 2019 16:53:27 GMT):
If using your own then let me know
knagware9 (Tue, 29 Jan 2019 04:52:10 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=ayuBsvfh7jP6zFJ6z7) @pankajcheema but how the same chaincode function invoked successfully using CURL
knagware9 (Tue, 29 Jan 2019 08:13:02 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=wok6rHrEwmKQZK3mW) @yacovm @sykesm ..Its strange to me same chaincode invoke function fine but when i use any UI API call , chaincode container get exited when propsoal request send out to endorser peer , and chaincode container get exited.. some one please help me out
knagware9 (Tue, 29 Jan 2019 08:13:02 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=wok6rHrEwmKQZK3mW) @yacovm @sykesm ..Its strange to me same chaincode invoke function works fine using CURL but when i use any UI API call(AJAX REST CALL) even my GET request running fine , chaincode container get exited when propsoal request send out to endorser peer , and chaincode container get exited.. some one please help me out
SahithiDyavarashetti (Tue, 29 Jan 2019 08:59:06 GMT):
Can anyone help me with this error ?
```
Error: Error trying to ping. Error: 2 UNKNOWN: access denied: channel [composerchannel] creator org [Org1MSP] Command failed
```
adamhardie (Tue, 29 Jan 2019 11:20:34 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=7MCihwzOaXSbHlPCfG) @pankajcheema Hey @pankajcheema thanks for the reply.
On my first question, i solved the problem (about the unknown network name) . It was a mistake on my part that was in one of the docker files.
my current issue however seems to be peer-container related. - when instantiating chaincode..
2019-01-25 16:49:06.180 UTC [endorser] SimulateProposal -> ERRO 7a4 [messagebus][b5e77bba] failed to invoke chaincode name:"lscc" , error: timeout expired while starting chaincode ccode:1.0 for transaction
i am not based on fabric-samples anymore
adamhardie (Tue, 29 Jan 2019 11:21:10 GMT):
i have the whole network running on docker swarm with kafka, chaincode deployment is the final piece to complete!
khudeja (Tue, 29 Jan 2019 11:29:52 GMT):
Has joined the channel.
knagware9 (Wed, 30 Jan 2019 10:35:24 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=FRaWg3LpxijrmYXdZ) My fault ,Issue is resolved now. Invoke function was missing one chaincode variable And that is the reason chaincode container were failing but there should be proper error message instead of exit the container.
adamhardie (Thu, 31 Jan 2019 10:45:53 GMT):
what is the purpose of CORE_PEER_NETWORKID on the peer environment?
jeffgarratt (Thu, 31 Jan 2019 14:12:15 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=PkJvBig2TnyDiovwf) @adamhardie It is used to create a naming context (scope) for the peer for its subsequent container control (i.e. naming the containers for chaincode isolation).
adamhardie (Thu, 31 Jan 2019 16:11:56 GMT):
awesome, thanks for the info!
gravity (Sun, 03 Feb 2019 08:25:38 GMT):
Hi @yacovm
There is a case: I have a running network with one channel, three peers joined this channel. No one of them is an anchor peer. Is it possible to turn one of them into an anchor peer?
yacovm (Sun, 03 Feb 2019 08:27:15 GMT):
yes
gravity (Sun, 03 Feb 2019 21:33:38 GMT):
To do so, an update channel configuration transaction should be issued, shouldn't it?
yacovm (Sun, 03 Feb 2019 23:38:39 GMT):
yes
gravity (Mon, 04 Feb 2019 09:43:40 GMT):
thanks
gaijinviki (Wed, 06 Feb 2019 09:09:05 GMT):
Hello, I have a Fabric Org with *3 Peer* connected to *mychannel*. Each peer is connected to it's own Couchdb instance. Peer0 has the chaincode installed, and when I execute a query, the state is updated in *CouchDB0*. I can see a gossip message to the other peer like so `2019-02-06 08:53:57.457 UTC [blocksProvider] DeliverBlocks -> DEBU 4f2b4 [mychannel] Gossiping block [3], peers number [2]`, but *CouchDB1 and CouchDB2* do *not* have any information about the state. Is this normal behaviour or have I configured something wrong ?
gaijinviki (Wed, 06 Feb 2019 09:09:05 GMT):
Hello, I have a Fabric Org with *3 Peer* connected to *mychannel*. Each peer is connected to it's own Couchdb instance. Peer0 has the chaincode installed, and when I execute a query, the state is updated in CouchDB0. I can see a gossip message to the other peer like so `2019-02-06 08:53:57.457 UTC [blocksProvider] DeliverBlocks -> DEBU 4f2b4 [mychannel] Gossiping block [3], peers number [2]`, but CouchDB1 and CouchDB2 do not have any information about the state. Is this normal behaviour or have I configured something wrong ?
gaijinviki (Wed, 06 Feb 2019 09:21:19 GMT):
In the logs of Peer1, I can see that it is updating CouchDB1. But in the CouchDB UI, I cannot see the Database or the records.
dave.enyeart (Wed, 06 Feb 2019 18:42:30 GMT):
@gaijinviki peer ensures commit in couchdb before moving on to next block, the committed data will be visible in UI. Capture peer debug and look at the `couchdb` debug statements to see exactly what is going on.
gaijinviki (Thu, 07 Feb 2019 03:59:57 GMT):
@dave.enyeart
gaijinviki (Thu, 07 Feb 2019 03:59:57 GMT):
@dave.enyeart I do see in the logs that the commit is made, but still nothing in the UI of `couchdb1`. I can see the data in the UI of `couchdb0` only. Here is the log for `couchdb1` ```
2019-02-06 08:53:57.367 UTC [statecouchdb] executeBatches -> DEBU 1772 Executing batches = [%!s(*statecouchdb.nsCommittersBuilder=&{map[1_1_1:0xc002d569c0] 0xc003d47000 map[] []})]
2019-02-06 08:53:57.367 UTC [statecouchdb] addRevisionsForMissingKeys -> DEBU 1773 Pulling revisions for the [1] keys for namsespace [mychannel_pta$demo] that were not part of the readset
2019-02-06 08:53:57.367 UTC [statecouchdb] executeBatches -> DEBU 1774 Executing batches = [subNsMetadataRetriever:ns=, num keys=1]
2019-02-06 08:53:57.367 UTC [couchdb] BatchRetrieveDocumentMetadata -> DEBU 1775 [mychannel_pta$demo] Entering BatchRetrieveDocumentMetadata() keys=[1_1_1]
2019-02-06 08:53:57.367 UTC [couchdb] handleRequest -> DEBU 1776 Entering handleRequest() method=POST url=http://couchdb1_org1:5984 dbName=mychannel_pta$demo
2019-02-06 08:53:57.367 UTC [couchdb] handleRequest -> DEBU 1777 Request URL: http://couchdb1_org1:5984/mychannel_pta$demo/_all_docs?include_docs=true
2019-02-06 08:53:57.367 UTC [couchdb] handleRequest -> DEBU 1778 HTTP Request: POST /mychannel_pta$demo/_all_docs?include_docs=true HTTP/1.1 | Host: couchdb1_org1:5984 | User-Agent: Go-http-client/1.1 | Content-Length: 18 | Accept: application/json | Content-Type: application/json | Accept-Encoding: gzip | |
2019-02-06 08:53:57.370 UTC [couchdb] handleRequest -> DEBU 1779 Exiting handleRequest()
2019-02-06 08:53:57.370 UTC [couchdb] BatchRetrieveDocumentMetadata -> DEBU 177a [mychannel_pta$demo] HTTP Response: HTTP/1.1 200 OK | Transfer-Encoding: chunked | Cache-Control: must-revalidate | Content-Type: application/json | Date: Wed, 06 Feb 2019 08:53:56 GMT | Server: CouchDB/2.2.0 (Erlang OTP/18) | X-Couch-Request-Id: c33d00b2bd | X-Couchdb-Body-Time: 0 | |
2019-02-06 08:53:57.370 UTC [couchdb] BatchRetrieveDocumentMetadata -> DEBU 177b [mychannel_pta$demo] Exiting BatchRetrieveDocumentMetadata()
2019-02-06 08:53:57.370 UTC [statecouchdb] executeBatches -> DEBU 177c Executing batches = [%!s(*statecouchdb.subNsCommitter=&{0xc003d47000 map[1_1_1:0xc002d56d80]})]
2019-02-06 08:53:57.370 UTC [couchdb] BatchUpdateDocuments -> DEBU 177d [mychannel_pta$demo] Entering BatchUpdateDocuments() document ids=[1_1_1]
2019-02-06 08:53:57.370 UTC [couchdb] handleRequest -> DEBU 177e Entering handleRequest() method=POST url=http://couchdb1_org1:5984 dbName=mychannel_pta$demo
2019-02-06 08:53:57.371 UTC [couchdb] handleRequest -> DEBU 177f Request URL: http://couchdb1_org1:5984/mychannel_pta$demo/_bulk_docs
2019-02-06 08:53:57.371 UTC [couchdb] handleRequest -> DEBU 1780 HTTP Request: POST /mychannel_pta$demo/_bulk_docs HTTP/1.1 | Host: couchdb1_org1:5984 | User-Agent: Go-http-client/1.1 | Content-Length: 312 | Accept: application/json | Content-Type: application/json | Accept-Encoding: gzip | |
2019-02-06 08:53:57.375 UTC [couchdb] handleRequest -> DEBU 1781 Exiting handleRequest()
2019-02-06 08:53:57.375 UTC [couchdb] BatchUpdateDocuments -> DEBU 1782 [mychannel_pta$demo] HTTP Response: HTTP/1.1 201 Created | Content-Length: 70 | Cache-Control: must-revalidate | Content-Type: application/json | Date: Wed, 06 Feb 2019 08:53:56 GMT | Server: CouchDB/2.2.0 (Erlang OTP/18) | X-Couch-Request-Id: fff767e735 | X-Couchdb-Body-Time: 0 | |
2019-02-06 08:53:57.375 UTC [couchdb] BatchUpdateDocuments -> DEBU 1783 [mychannel_pta$demo] Exiting BatchUpdateDocuments() _bulk_docs response=[[{"ok":true,"id":"1_1_1","rev":"2-c7a1977afbaab2cb062e03cbb7ea18ed"}]
2019-02-06 08:53:57.375 UTC [statecouchdb] executeBatches -> DEBU 1784 Executing batches = [%!s(*statecouchdb.nsFlusher=&{0xc003d47000})]
2019-02-06 08:53:57.375 UTC [couchdb] EnsureFullCommit -> DEBU 1785 [mychannel_pta$demo] Entering EnsureFullCommit()
2019-02-06 08:53:57.375 UTC [couchdb] handleRequest -> DEBU 1786 Entering handleRequest() method=POST url=http://couchdb1_org1:5984 dbName=mychannel_pta$demo
2019-02-06 08:53:57.375 UTC [couchdb] handleRequest -> DEBU 1787 Request URL: http://couchdb1_org1:5984/mychannel_pta$demo/_ensure_full_commit
2019-02-06 08:53:57.375 UTC [couchdb] handleRequest -> DEBU 1788 HTTP Request: POST /mychannel_pta$demo/_ensure_full_commit HTTP/1.1 | Host: couchdb1_org1:5984 | User-Agent: Go-http-client/1.1 | Content-Length: 0 | Accept: application/json | Content-Type: application/json | Accept-Encoding: gzip | |
2019-02-06 08:53:57.376 UTC [couchdb] handleRequest -> DEBU 1789 Exiting handleRequest()
2019-02-06 08:53:57.376 UTC [couchdb] EnsureFullCommit -> DEBU 178a [mychannel_pta$demo] Exiting EnsureFullCommit()
```
gaijinviki (Thu, 07 Feb 2019 03:59:57 GMT):
@dave.enyeart I do see in the logs that the commit is made, but still nothing in the UI of couchdb1. I can see the data in the UI of couchdb0 only. Here is the log```
2019-02-06 08:53:57.367 UTC [statecouchdb] executeBatches -> DEBU 1772 Executing batches = [%!s(*statecouchdb.nsCommittersBuilder=&{map[1_1_1:0xc002d569c0] 0xc003d47000 map[] []})]
2019-02-06 08:53:57.367 UTC [statecouchdb] addRevisionsForMissingKeys -> DEBU 1773 Pulling revisions for the [1] keys for namsespace [mychannel_pta$demo] that were not part of the readset
2019-02-06 08:53:57.367 UTC [statecouchdb] executeBatches -> DEBU 1774 Executing batches = [subNsMetadataRetriever:ns=, num keys=1]
2019-02-06 08:53:57.367 UTC [couchdb] BatchRetrieveDocumentMetadata -> DEBU 1775 [mychannel_pta$demo] Entering BatchRetrieveDocumentMetadata() keys=[1_1_1]
2019-02-06 08:53:57.367 UTC [couchdb] handleRequest -> DEBU 1776 Entering handleRequest() method=POST url=http://couchdb1_org1:5984 dbName=mychannel_pta$demo
2019-02-06 08:53:57.367 UTC [couchdb] handleRequest -> DEBU 1777 Request URL: http://couchdb1_org1:5984/mychannel_pta$demo/_all_docs?include_docs=true
2019-02-06 08:53:57.367 UTC [couchdb] handleRequest -> DEBU 1778 HTTP Request: POST /mychannel_pta$demo/_all_docs?include_docs=true HTTP/1.1 | Host: couchdb1_org1:5984 | User-Agent: Go-http-client/1.1 | Content-Length: 18 | Accept: application/json | Content-Type: application/json | Accept-Encoding: gzip | |
2019-02-06 08:53:57.370 UTC [couchdb] handleRequest -> DEBU 1779 Exiting handleRequest()
2019-02-06 08:53:57.370 UTC [couchdb] BatchRetrieveDocumentMetadata -> DEBU 177a [mychannel_pta$demo] HTTP Response: HTTP/1.1 200 OK | Transfer-Encoding: chunked | Cache-Control: must-revalidate | Content-Type: application/json | Date: Wed, 06 Feb 2019 08:53:56 GMT | Server: CouchDB/2.2.0 (Erlang OTP/18) | X-Couch-Request-Id: c33d00b2bd | X-Couchdb-Body-Time: 0 | |
2019-02-06 08:53:57.370 UTC [couchdb] BatchRetrieveDocumentMetadata -> DEBU 177b [mychannel_pta$demo] Exiting BatchRetrieveDocumentMetadata()
2019-02-06 08:53:57.370 UTC [statecouchdb] executeBatches -> DEBU 177c Executing batches = [%!s(*statecouchdb.subNsCommitter=&{0xc003d47000 map[1_1_1:0xc002d56d80]})]
2019-02-06 08:53:57.370 UTC [couchdb] BatchUpdateDocuments -> DEBU 177d [mychannel_pta$demo] Entering BatchUpdateDocuments() document ids=[1_1_1]
2019-02-06 08:53:57.370 UTC [couchdb] handleRequest -> DEBU 177e Entering handleRequest() method=POST url=http://couchdb1_org1:5984 dbName=mychannel_pta$demo
2019-02-06 08:53:57.371 UTC [couchdb] handleRequest -> DEBU 177f Request URL: http://couchdb1_org1:5984/mychannel_pta$demo/_bulk_docs
2019-02-06 08:53:57.371 UTC [couchdb] handleRequest -> DEBU 1780 HTTP Request: POST /mychannel_pta$demo/_bulk_docs HTTP/1.1 | Host: couchdb1_org1:5984 | User-Agent: Go-http-client/1.1 | Content-Length: 312 | Accept: application/json | Content-Type: application/json | Accept-Encoding: gzip | |
2019-02-06 08:53:57.375 UTC [couchdb] handleRequest -> DEBU 1781 Exiting handleRequest()
2019-02-06 08:53:57.375 UTC [couchdb] BatchUpdateDocuments -> DEBU 1782 [mychannel_pta$demo] HTTP Response: HTTP/1.1 201 Created | Content-Length: 70 | Cache-Control: must-revalidate | Content-Type: application/json | Date: Wed, 06 Feb 2019 08:53:56 GMT | Server: CouchDB/2.2.0 (Erlang OTP/18) | X-Couch-Request-Id: fff767e735 | X-Couchdb-Body-Time: 0 | |
2019-02-06 08:53:57.375 UTC [couchdb] BatchUpdateDocuments -> DEBU 1783 [mychannel_pta$demo] Exiting BatchUpdateDocuments() _bulk_docs response=[[{"ok":true,"id":"1_1_1","rev":"2-c7a1977afbaab2cb062e03cbb7ea18ed"}]
2019-02-06 08:53:57.375 UTC [statecouchdb] executeBatches -> DEBU 1784 Executing batches = [%!s(*statecouchdb.nsFlusher=&{0xc003d47000})]
2019-02-06 08:53:57.375 UTC [couchdb] EnsureFullCommit -> DEBU 1785 [mychannel_pta$demo] Entering EnsureFullCommit()
2019-02-06 08:53:57.375 UTC [couchdb] handleRequest -> DEBU 1786 Entering handleRequest() method=POST url=http://couchdb1_org1:5984 dbName=mychannel_pta$demo
2019-02-06 08:53:57.375 UTC [couchdb] handleRequest -> DEBU 1787 Request URL: http://couchdb1_org1:5984/mychannel_pta$demo/_ensure_full_commit
2019-02-06 08:53:57.375 UTC [couchdb] handleRequest -> DEBU 1788 HTTP Request: POST /mychannel_pta$demo/_ensure_full_commit HTTP/1.1 | Host: couchdb1_org1:5984 | User-Agent: Go-http-client/1.1 | Content-Length: 0 | Accept: application/json | Content-Type: application/json | Accept-Encoding: gzip | |
2019-02-06 08:53:57.376 UTC [couchdb] handleRequest -> DEBU 1789 Exiting handleRequest()
2019-02-06 08:53:57.376 UTC [couchdb] EnsureFullCommit -> DEBU 178a [mychannel_pta$demo] Exiting EnsureFullCommit()
```
gaijinviki (Thu, 07 Feb 2019 03:59:57 GMT):
@dave.enyeart I do see in the logs that the commit is made, but still nothing in the UI of couchdb1. I can see the data in the UI of couchdb0 only. Here is the log for couchdb1```
2019-02-06 08:53:57.367 UTC [statecouchdb] executeBatches -> DEBU 1772 Executing batches = [%!s(*statecouchdb.nsCommittersBuilder=&{map[1_1_1:0xc002d569c0] 0xc003d47000 map[] []})]
2019-02-06 08:53:57.367 UTC [statecouchdb] addRevisionsForMissingKeys -> DEBU 1773 Pulling revisions for the [1] keys for namsespace [mychannel_pta$demo] that were not part of the readset
2019-02-06 08:53:57.367 UTC [statecouchdb] executeBatches -> DEBU 1774 Executing batches = [subNsMetadataRetriever:ns=, num keys=1]
2019-02-06 08:53:57.367 UTC [couchdb] BatchRetrieveDocumentMetadata -> DEBU 1775 [mychannel_pta$demo] Entering BatchRetrieveDocumentMetadata() keys=[1_1_1]
2019-02-06 08:53:57.367 UTC [couchdb] handleRequest -> DEBU 1776 Entering handleRequest() method=POST url=http://couchdb1_org1:5984 dbName=mychannel_pta$demo
2019-02-06 08:53:57.367 UTC [couchdb] handleRequest -> DEBU 1777 Request URL: http://couchdb1_org1:5984/mychannel_pta$demo/_all_docs?include_docs=true
2019-02-06 08:53:57.367 UTC [couchdb] handleRequest -> DEBU 1778 HTTP Request: POST /mychannel_pta$demo/_all_docs?include_docs=true HTTP/1.1 | Host: couchdb1_org1:5984 | User-Agent: Go-http-client/1.1 | Content-Length: 18 | Accept: application/json | Content-Type: application/json | Accept-Encoding: gzip | |
2019-02-06 08:53:57.370 UTC [couchdb] handleRequest -> DEBU 1779 Exiting handleRequest()
2019-02-06 08:53:57.370 UTC [couchdb] BatchRetrieveDocumentMetadata -> DEBU 177a [mychannel_pta$demo] HTTP Response: HTTP/1.1 200 OK | Transfer-Encoding: chunked | Cache-Control: must-revalidate | Content-Type: application/json | Date: Wed, 06 Feb 2019 08:53:56 GMT | Server: CouchDB/2.2.0 (Erlang OTP/18) | X-Couch-Request-Id: c33d00b2bd | X-Couchdb-Body-Time: 0 | |
2019-02-06 08:53:57.370 UTC [couchdb] BatchRetrieveDocumentMetadata -> DEBU 177b [mychannel_pta$demo] Exiting BatchRetrieveDocumentMetadata()
2019-02-06 08:53:57.370 UTC [statecouchdb] executeBatches -> DEBU 177c Executing batches = [%!s(*statecouchdb.subNsCommitter=&{0xc003d47000 map[1_1_1:0xc002d56d80]})]
2019-02-06 08:53:57.370 UTC [couchdb] BatchUpdateDocuments -> DEBU 177d [mychannel_pta$demo] Entering BatchUpdateDocuments() document ids=[1_1_1]
2019-02-06 08:53:57.370 UTC [couchdb] handleRequest -> DEBU 177e Entering handleRequest() method=POST url=http://couchdb1_org1:5984 dbName=mychannel_pta$demo
2019-02-06 08:53:57.371 UTC [couchdb] handleRequest -> DEBU 177f Request URL: http://couchdb1_org1:5984/mychannel_pta$demo/_bulk_docs
2019-02-06 08:53:57.371 UTC [couchdb] handleRequest -> DEBU 1780 HTTP Request: POST /mychannel_pta$demo/_bulk_docs HTTP/1.1 | Host: couchdb1_org1:5984 | User-Agent: Go-http-client/1.1 | Content-Length: 312 | Accept: application/json | Content-Type: application/json | Accept-Encoding: gzip | |
2019-02-06 08:53:57.375 UTC [couchdb] handleRequest -> DEBU 1781 Exiting handleRequest()
2019-02-06 08:53:57.375 UTC [couchdb] BatchUpdateDocuments -> DEBU 1782 [mychannel_pta$demo] HTTP Response: HTTP/1.1 201 Created | Content-Length: 70 | Cache-Control: must-revalidate | Content-Type: application/json | Date: Wed, 06 Feb 2019 08:53:56 GMT | Server: CouchDB/2.2.0 (Erlang OTP/18) | X-Couch-Request-Id: fff767e735 | X-Couchdb-Body-Time: 0 | |
2019-02-06 08:53:57.375 UTC [couchdb] BatchUpdateDocuments -> DEBU 1783 [mychannel_pta$demo] Exiting BatchUpdateDocuments() _bulk_docs response=[[{"ok":true,"id":"1_1_1","rev":"2-c7a1977afbaab2cb062e03cbb7ea18ed"}]
2019-02-06 08:53:57.375 UTC [statecouchdb] executeBatches -> DEBU 1784 Executing batches = [%!s(*statecouchdb.nsFlusher=&{0xc003d47000})]
2019-02-06 08:53:57.375 UTC [couchdb] EnsureFullCommit -> DEBU 1785 [mychannel_pta$demo] Entering EnsureFullCommit()
2019-02-06 08:53:57.375 UTC [couchdb] handleRequest -> DEBU 1786 Entering handleRequest() method=POST url=http://couchdb1_org1:5984 dbName=mychannel_pta$demo
2019-02-06 08:53:57.375 UTC [couchdb] handleRequest -> DEBU 1787 Request URL: http://couchdb1_org1:5984/mychannel_pta$demo/_ensure_full_commit
2019-02-06 08:53:57.375 UTC [couchdb] handleRequest -> DEBU 1788 HTTP Request: POST /mychannel_pta$demo/_ensure_full_commit HTTP/1.1 | Host: couchdb1_org1:5984 | User-Agent: Go-http-client/1.1 | Content-Length: 0 | Accept: application/json | Content-Type: application/json | Accept-Encoding: gzip | |
2019-02-06 08:53:57.376 UTC [couchdb] handleRequest -> DEBU 1789 Exiting handleRequest()
2019-02-06 08:53:57.376 UTC [couchdb] EnsureFullCommit -> DEBU 178a [mychannel_pta$demo] Exiting EnsureFullCommit()
```
dave.enyeart (Thu, 07 Feb 2019 07:20:53 GMT):
@gaijinviki The debug says document 1_1_1 got committed to CouchDB. It will be there. Maybe the UI is not pointing to the db that you think it is. Or perhaps there is some glitch in the CouchDB UI...try using curl.
knagware9 (Thu, 07 Feb 2019 10:38:06 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=aAXaA7XqgLf3pJxpY) @dave.enyeart http://localhost:
knagware9 (Thu, 07 Feb 2019 10:38:43 GMT):
@gaijinviki http://localhost:
gaijinviki (Thu, 07 Feb 2019 13:56:12 GMT):
@knagware9 there isn't one. Not in `couchdb1` atleast. That is what I am trying to figure out why. `couchdb0` has the database and the records.
gaijinviki (Thu, 07 Feb 2019 13:56:45 GMT):
CouchDB0
gaijinviki (Thu, 07 Feb 2019 13:56:52 GMT):
Couchdb1
plato (Thu, 07 Feb 2019 18:11:02 GMT):
Has joined the channel.
plato (Thu, 07 Feb 2019 18:19:47 GMT):
@dave.enyeart I have 6 orgs and 12 peers and the endorsement policy is to get the signature of each member of each orgs. I'm sending 12 proposal thru all peers and receiving the signature of each and then Ithe sending the transaction and it happen successfully but once I'm checking the state db ( couchdb for all 12 peers there is the db name like my chaincode name but there is not data in any collection but once the endorsmnet policy is for only one org I can see the stat on the specific state db )
plato (Thu, 07 Feb 2019 18:19:47 GMT):
@dave.enyeart I have 6 orgs and 12 peers and the endorsement policy is to get the signature of each member of each orgs. I'm sending 12 proposal thru all peers and receiving the signature of each peers and then I'm sending the transaction thru orderer, result coming back successfully but once I'm checking the state db ( couchdb for all 12 peers there is the db name like my chaincode name but there is not data in any of collection which I expect once the gossip protocol update everybody! in another scenario once I'm changing the endorsement policy to get only one signature for only one org I can see the state updating on the specific state db for that org ) any idea where and what i'm doing wrong ?
dave.enyeart (Thu, 07 Feb 2019 19:08:25 GMT):
@plato First check if peer log has any errors or warnings. If not, then you must enable debug to see what is going on during block commit timeframe:
dave.enyeart (Thu, 07 Feb 2019 19:08:29 GMT):
v1.0 to v1.3: `CORE_LOGGING_GOSSIP=debug CORE_LOGGING_LEVEL=info:transientstore,kvledger,ledgerstorage,pvtdatastorage,gossip/privdata,statecouchdb=debug peer node start`
v1.4: `FABRIC_LOGGING_SPEC=info:transientstore,kvledger,ledgerstorage,pvtdatastorage,gossip.privdata,gossip.discovery,statecouchdb=debug peer node start`
dave.enyeart (Thu, 07 Feb 2019 19:08:29 GMT):
v1.0 to v1.3: `CORE_LOGGING_GOSSIP=debug CORE_LOGGING_LEVEL=info:transientstore,kvledger,ledgerstorage,pvtdatastorage,gossip/privdata,statecouchdb=debug peer node start`
v1.4: `FABRIC_LOGGING_SPEC=info:transientstore,kvledger,ledgerstorage,pvtdatastorage,gossip.privdata,statecouchdb=debug peer node start`
dave.enyeart (Thu, 07 Feb 2019 19:08:29 GMT):
v1.0 to v1.3: `CORE_LOGGING_GOSSIP=debug CORE_LOGGING_LEVEL=info:transientstore,kvledger,ledgerstorage,pvtdatastorage,gossip/privdata,statecouchdb,couchdb=debug peer node start`
v1.4: `FABRIC_LOGGING_SPEC=info:transientstore,kvledger,ledgerstorage,pvtdatastorage,gossip.privdata,statecouchdb,couchdb=debug peer node start`
plato (Thu, 07 Feb 2019 23:16:02 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=H7ZoGjB6A7s5Rbk9Z) @dave.enyeart thanks Dave, I found this issue which some how one org has some and the other one can not reach this, the eeror was this issue and the TLS handshake failed with error remote error: tls: bad certificate {"server": "PeerServer", "remote address":
gaijinviki (Fri, 08 Feb 2019 06:19:12 GMT):
Hello,
One of my peers keep crashing with `panic` after a few minutes. When I start it, it runs normally for a while, and then it panics without me doing anything. Here is the stacktrace:
```
^[[36m2019-02-08 06:11:43.528 UTC [grpc] watcher -> DEBU 105b^[[0m ccResolverWrapper: sending new addresses to cc: [{peer0:8051 0
gaijinviki (Fri, 08 Feb 2019 06:19:12 GMT):
Hello,
One of my peers keep crashing with `panic` after a few minutes. When I start it, it runs normally for a while, and then it panics without me doing anything. Here is the stacktrace:
```
^[[36m2019-02-08 06:11:43.528 UTC [grpc] watcher -> DEBU 105b^[[0m ccResolverWrapper: sending new addresses to cc: [{stg-apaymol401z.stg.jp.local:8051 0
gaijinviki (Fri, 08 Feb 2019 06:19:12 GMT):
Hello,
One of my peers keep crashing with `panic` after a few minutes. When I start it, it runs normally for a while, and then it panics without me doing anything. Here is the stacktrace:
```
^[[36m2019-02-08 06:11:43.528 UTC [grpc] watcher -> DEBU 105b^[[0m ccResolverWrapper: sending new addresses to cc: [{stg-apaymol401z.stg.jp.local:8051 0
gaijinviki (Fri, 08 Feb 2019 06:19:12 GMT):
Hello,
One of my peers keep crashing with `panic` after a few minutes. When I start it, it runs normally for a while, and then it panics without me doing anything. Here is the stacktrace:
```
^[[36m2019-02-08 06:11:43.528 UTC [grpc] watcher -> DEBU 105b^[[0m ccResolverWrapper: sending new addresses to cc: [{stg-apaymol401z.stg.jp.local:8051 0
gaijinviki (Fri, 08 Feb 2019 06:19:12 GMT):
Hello,
One of my peers keep crashing with `panic` after a few minutes. When I start it, it runs normally for a while, and then it panics without me doing anything. Here is the stacktrace:
```
^[[36m2019-02-08 06:11:43.528 UTC [grpc] watcher -> DEBU 105b^[[0m ccResolverWrapper: sending new addresses to cc: [{peer0:8051 0
yacovm (Fri, 08 Feb 2019 07:27:29 GMT):
@gaijinviki set the following environment variable: ` GODEBUG=netdns=go`
chill37 (Tue, 12 Feb 2019 04:44:33 GMT):
ENDORSEMENT policy loading without service discovery.
Is it possible to load the endorsement policy layout without the service discovery in fabric JAVA Sdk?
I can't seem to find it....if anyone could give me a hint on this, I would greatly appreciate it.
gaijinviki (Tue, 12 Feb 2019 05:19:29 GMT):
Hello,
Does anyone know the limit for the maximum number of `transaction proposal requests` that a single endorsing peer can handle `simultaneously`?
gaijinviki (Tue, 12 Feb 2019 05:19:29 GMT):
Hello,
Does anyone know the limit for the maximum number of `proposal requests` that a single endorsing peer can handle `simultaneously`?
gaijinviki (Wed, 13 Feb 2019 01:37:36 GMT):
Hello, can someone guide on how can I make my committing peer emit a `Transaction Committed Event` ?
gaijinviki (Wed, 13 Feb 2019 01:37:36 GMT):
Hello, can someone guide on how can I make my committing peer emit a `Transaction Committed Event` ?
In my current peer logs, I do not see any `commit event`
```
2019-02-13 01:08:45.035 UTC [couchdb] handleRequest -> DEBU b73c50 Exiting handleRequest()
2019-02-13 01:08:45.036 UTC [couchdb] ReadDoc -> DEBU b73c51 [mychannel2_] Exiting ReadDoc()
2019-02-13 01:08:45.036 UTC [couchdb] handleRequest -> DEBU b73c52 Entering handleRequest() method=PUT url=http://couchdb0_org1:5984 dbName=mychannel2_
2019-02-13 01:08:45.036 UTC [couchdb] handleRequest -> DEBU b73c53 Request URL: http://couchdb0_org1:5984/mychannel2_/statedb_savepoint
2019-02-13 01:08:45.036 UTC [couchdb] handleRequest -> DEBU b73c54 HTTP Request: PUT /mychannel2_/statedb_savepoint HTTP/1.1 | Host: couchdb0_org1:5984 | User-Agent: Go-http-client/1.1 | Content-Length: 27 | Accept: application/json | Content-Type: application/json | If-Match: 5590-17e8dfbe42ff7392117c2a1918e9ec57 | Accept-Encoding: gzip | |
2019-02-13 01:08:45.051 UTC [couchdb] handleRequest -> DEBU b73c55 Exiting handleRequest()
2019-02-13 01:08:45.051 UTC [couchdb] WarmIndexAllIndexes -> DEBU b73c56 [mychannel2_pta$demo2] Exiting WarmIndexAllIndexes()
2019-02-13 01:08:45.059 UTC [couchdb] handleRequest -> DEBU b73c57 Exiting handleRequest()
2019-02-13 01:08:45.060 UTC [couchdb] SaveDoc -> DEBU b73c58 [mychannel2_] Exiting SaveDoc()
2019-02-13 01:08:45.060 UTC [statecouchdb] ClearCachedVersions -> DEBU b73c59 Clear Cache
2019-02-13 01:08:45.060 UTC [lockbasedtxmgr] Commit -> DEBU b73c5a Updates committed to state database and the write lock is released
2019-02-13 01:08:45.060 UTC [pvtstatepurgemgmt] prepareWorkingsetFor -> DEBU b73c5b Preparing potential purge list working-set for expiringAtBlk [5591]
2019-02-13 01:08:45.060 UTC [leveldbhelper] GetIterator -> DEBU b73c5c Getting iterator for range [[]byte{0x6d, 0x79, 0x63, 0x68, 0x61, 0x6e, 0x6e, 0x65, 0x6c, 0x32, 0x2f, 0x30, 0x0, 0x31, 0x2, 0x15, 0xd7, 0x0}] - [[]byte{0x6d, 0x79, 0x63, 0x68, 0x61, 0x6e, 0x6e, 0x65, 0x6c, 0x32, 0x2f, 0x30, 0x0, 0x31, 0x2, 0x15, 0xd8, 0x0}]
2019-02-13 01:08:45.060 UTC [lockbasedtxmgr] func1 -> DEBU b73c5d launched the background routine for preparing keys to purge with the next block
2019-02-13 01:08:45.060 UTC [statecouchdb] executeBatches -> DEBU b73c5e Executing batches = []
2019-02-13 01:08:45.060 UTC [statecouchdb] LoadCommittedVersions -> DEBU b73c5f nsKeysMap=map[]
2019-02-13 01:08:45.060 UTC [statecouchdb] LoadCommittedVersions -> DEBU b73c60 nsMetadataMap=map[]
2019-02-13 01:08:45.060 UTC [kvledger] CommitWithPvtData -> DEBU b73c61 [mychannel2] Committing block [5590] transactions to history database
2019-02-13 01:08:45.060 UTC [pvtstatepurgemgmt] prepareWorkingsetFor -> DEBU b73c62 No expiry entry found for expiringAtBlk [5591]
2019-02-13 01:08:45.060 UTC [historyleveldb] Commit -> DEBU b73c63 Channel [mychannel2]: Updating history database for blockNo [5590] with [7] transactions
2019-02-13 01:08:45.062 UTC [historyleveldb] Commit -> DEBU b73c64 Channel [mychannel2]: Updates committed to history database for blockNo [5590]
2019-02-13 01:08:45.062 UTC [kvledger] CommitWithPvtData -> INFO b73c65 [mychannel2] Committed block [5590] with 7 transaction(s) in 131ms (state_validation=29ms block_commit=9ms state_commit=90ms)
2019-02-13 01:08:45.180 UTC [peer.gossip.mcs] VerifyByChannel -> DEBU b73c66 Got policy manager for channel [mychannel2] with flag [true]
2019-02-13 01:08:45.180 UTC [peer.gossip.mcs] VerifyByChannel -> DEBU b73c67 Got reader policy for channel [mychannel2] with flag [true]
2019-02-13 01:08:45.180 UTC [policies] Evaluate -> DEBU b73c68 == Evaluating *policies.implicitMetaPolicy Policy /Channel/Application/Readers ==
2019-02-13 01:08:45.180 UTC [policies] Evaluate -> DEBU b73c69 This is an implicit meta policy, it will trigger other policy evaluations, whose failures may be benign
```
vtech (Wed, 13 Feb 2019 04:41:56 GMT):
Has joined the channel.
JayJong (Wed, 13 Feb 2019 11:05:56 GMT):
Has joined the channel.
chuda (Wed, 13 Feb 2019 11:50:24 GMT):
while using ./startFabric.sh script peer container exited at the time of channel creation,any one check this
gravity (Tue, 19 Feb 2019 21:29:39 GMT):
Hello. How to handle the situation when the enrollment certificates for peers are expired? can I issue the reenroll request for peers from an application and expect that peer's enrollment cert will be renewed? are there any recommended practices how to handle this?
thanks in advance
aleksandar.nasuovski (Tue, 26 Feb 2019 14:54:26 GMT):
Has joined the channel.
bibek54 (Wed, 27 Feb 2019 04:09:03 GMT):
Has joined the channel.
aatkddny (Wed, 27 Feb 2019 16:52:20 GMT):
This may not be the right place, but it at least says peer...
Is there a way to tell what's causing this?
`2019-02-27 14:23:51.231 UTC [eventhub_producer] Chat -> ERRO 136 error during Chat, stopping handler: rpc error: code = Canceled desc = context canceled
`
aatkddny (Wed, 27 Feb 2019 16:52:20 GMT):
This may not be the right place, but it at least says peer...
Is there a way to tell what's causing this?
`2019-02-27 14:23:51.231 UTC [eventhub_producer] Chat -> ERRO 136 error during Chat, stopping handler: rpc error: code = Canceled desc = context canceled`
jeffgarratt (Fri, 01 Mar 2019 01:11:14 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=7z22XnEMSJKjxHPa8) @aatkddny that is an eventHub client disconnecting, and the peer is denoting this process.
jeffgarratt (Fri, 01 Mar 2019 01:11:14 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=7z22XnEMSJKjxHPa8) @aatkddny that is an eventHub client disconnecting without properly closing the channel (or at least not waiting long enough for this process to complete), and the peer is denoting this process.
jeffgarratt (Fri, 01 Mar 2019 01:11:14 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=7z22XnEMSJKjxHPa8) @aatkddny that is an eventHub client disconnecting without properly closing the stream (or at least not waiting long enough for this process to complete), and the peer is denoting this process
duwenhui (Fri, 01 Mar 2019 08:55:31 GMT):
Has joined the channel.
duwenhui (Fri, 01 Mar 2019 08:59:05 GMT):
At present, there is a need to design an Org, and specify the Org peer to implement a special endorsement function, such as the deduction in the billing function in the process of endorsement, and the deduction information need to be on the chain. I know that the fabric supports the plugin way to modify the endorsement smart contract. Can fabric support and achieve such a function?
qizhang (Mon, 04 Mar 2019 23:05:47 GMT):
I am trying to build a fabric-peer that uses Golang1.11.1, by the following two approaches:
1. replace the Go in `hyperledger/fabric-baseimage:s390x-0.4.14` with Go 1.11.1, commit such change to a new fabric-baseimage, then build the fabric-peer using the updated fabric-baseimage
2. change the command in fabric-baseimage/scripts/common/setup.sh to use Go 1.11.1, rebuild the fabric-baseimage, and then build the fabric-peer using the updated fabric-baseimage.
However, when running the experiments, both approaches ended up with the same same error:
From the chaincode container:
```2019-03-04 22:32:32.451 UTC [ccperf] Info -> INFO 001 CCPerf chaincode started
2019-03-04 22:32:32.635 UTC [shim] chatWithPeer -> ERRO 002 Received error from server, ending chaincode stream: rpc error: code = Unavailable desc = transport is closing
receive failed
github.com/hyperledger/fabric/core/chaincode/shim.chatWithPeer
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/shim/chaincode.go:364
github.com/hyperledger/fabric/core/chaincode/shim.Start
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/shim/chaincode.go:158
main.main
/chaincode/input/src/ccperf/ccperf.go:399
runtime.main
/opt/go/src/runtime/proc.go:201
runtime.goexit
/opt/go/src/runtime/asm_s390x.s:782
2019-03-04 22:32:32.635 UTC [ccperf] Errorf -> ERRO 003 Failed to start chaincode: receive failed: rpc error: code = Unavailable desc = transport is closing
2019-03-04 22:32:32.636 UTC [ccperf] Info -> INFO 004 CCPerf chaincode finished```
from the peer container:
```^[[34m2019-03-04 22:32:20.669 UTC [endorser] callChaincode -> INFO 414^[[0m [mychannel1][76476fb5] Exit chaincode: name:"ccperf" (30000ms)
^[[31m2019-03-04 22:32:20.669 UTC [endorser] SimulateProposal -> ERRO 415^[[0m [mychannel1][76476fb5] failed to invoke chaincode name:"ccperf" , error: timeout expired while executing transaction```
braduf (Tue, 05 Mar 2019 00:06:49 GMT):
Has joined the channel.
qizhang (Wed, 06 Mar 2019 21:00:19 GMT):
can peers from the same organization join different channels?
yacovm (Wed, 06 Mar 2019 21:01:44 GMT):
yes
qizhang (Wed, 06 Mar 2019 21:04:07 GMT):
@yacovm thanks! I got the following error when invoking a chaincode, what could be the cause?
`Error: error endorsing chaincode: rpc error: code = Unknown desc = access denied: channel [mychannel2] creator org [PeerOrg1]`
yacovm (Wed, 06 Mar 2019 21:06:17 GMT):
look at the peer log
braduf (Thu, 07 Mar 2019 15:18:54 GMT):
Hi all, I am using the fabric-cli to create a channel. I have the create channel transaction, and in the CORE_PEER_MSPCONFIGPATH variable on the cli host I point to the msp of a network admin (included in the admincerts of an organization included in the system channel). The error that I get is
```
Error: got unexpected status: BAD_REQUEST -- error authorizing update: error validating DeltaSet: policy for [Group] /Channel/Application not satisfied: Failed to reach implicit threshold of 1 sub-policies, required 1 remaining
```
braduf (Thu, 07 Mar 2019 15:18:54 GMT):
Hi all, I am using the fabric-cli to create a channel. I have the create channel transaction, and in the CORE_PEER_MSPCONFIGPATH variable on the cli host I point to the msp of a network admin (included in the admincerts of an organization included in the system channel). The error that I get is
```
Error: got unexpected status: BAD_REQUEST -- error authorizing update: error validating DeltaSet: policy for [Group] /Channel/Application not satisfied: Failed to reach implicit threshold of 1 sub-policies, required 1 remaining
```
Should I point to the msp of an admin of the peer the cli is pointing to instead of a network admin? Or what is the exact policy that I am not satisfying? Thanks in advance!
braduf (Thu, 07 Mar 2019 15:39:49 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=paGAsmiXphSBsQ359) @jyellick , I read an answer from you on a similar problem:
"This error indicates that the certificate you are signing with was not appropriately issued by any of the CAs that the orderer is aware of. Did you set the CORE_PEER_MSPCONFIGPATH to point to an orderer certificate before executing the fetch command? For example, in the first-network example, you can see it is set to:
CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/users/Admin@.../msp"
What exactly do you mean with an orderer certificate? The signcert of an orderer node, or one of the admincerts of the orderer's msp, or one of the admincerts from the organization's MSPs in the system channel genesis block?
braduf (Thu, 07 Mar 2019 19:05:55 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=GzrSEhC8hM6xqsahY) Could it be because in the profile for the system channel genesis block, we included an application section? Should we remove this?
jyellick (Thu, 07 Mar 2019 20:06:21 GMT):
@braduf We discourage including an application section in the orderer system channel. It sounds like your config update is attempting to modify that section without the appropriate signatures.
braduf (Thu, 07 Mar 2019 20:15:11 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=ZE3uSF8TWmNjNkX7A) @jyellick Thanks @jyellick , we removed the application section in the orderer system now and it still gave the same error. Are we using the wrong msp on the CLI? We are using the msp of an identity that is included in the admincerts of our org and so that is known in the genesisblock...
braduf (Thu, 07 Mar 2019 20:15:11 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=ZE3uSF8TWmNjNkX7A) @jyellick Thanks @jyellick , we removed the application section in the orderer system now and it still gave the same error. Are we using the wrong msp on the CLI? We are using the msp of an identity that is included in the admincerts of our org and so that is known in the genesisblock...
In the byfn sample they use one and the same Admin identity for all admincerts and also as the CORE_PEER_MSPCONFIGPATH on the CLI. We have different identities as admincerts on the localMSPs of the orderer and peer, is that a problem? (so we have 3 identities in the admincerts for our MSP of the system channel, and then we have another peeradmin and ordereradmin in the admincerts of the localMSPs of the peer and orderer respectively).
Another possible reason I am thinking about is if it has something to do with MAJORITY Admins policies, while we are just trying to create the channel with one admin...could it be that?
braduf (Thu, 07 Mar 2019 20:49:23 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=ACJaQfqQpARLEf54r) We changed MAJORITY Admins to ANY Admins in all the policies just to check if the problem was there, but still gives the same error about sub-policies that were not satisfied. So removing application section and changing MAJORITY for ANY didn't work
stephenman (Fri, 08 Mar 2019 11:19:58 GMT):
Has joined the channel.
stephenman (Fri, 08 Mar 2019 11:31:32 GMT):
Hi all, I'm starting up my fabric blockchain network components for the example "first-network" one by one, I can startup orderer, however, my peer0-org1-example-com cannot start and have errors as below. is there anyone got the idea? Thanks!
2019-03-08 11:24:03.274 UTC [nodeCmd] computeChaincodeEndpoint -> INFO 00b Exit with ccEndpoint: peer0-org1-example-com:7052
2019-03-08 11:24:03.274 UTC [nodeCmd] createChaincodeServer -> WARN 00c peer.chaincodeListenAddress is not set, using peer0-org1-example-com:7052
2019-03-08 11:24:03.282 UTC [nodeCmd] createChaincodeServer -> ERRO 00d Error creating GRPC server: listen tcp: lookup peer0-org1-example-com on 172.30.0.2:53: server misbehaving
2019-03-08 11:24:03.282 UTC [nodeCmd] startChaincodeServer -> PANI 00e Failed to create chaincode server: listen tcp: lookup peer0-org1-example-com on 172.30.0.2:53: server misbehaving
panic: Failed to create chaincode server: listen tcp: lookup peer0-org1-example-com on 172.30.0.2:53: server misbehaving
chill37 (Mon, 11 Mar 2019 11:49:17 GMT):
When instantiating with POLICY, what's the difference between Org1.Member, Org1.Client, Org1.Peer? I've read the document, but it doesn't say much other than the name itself?
Could anyone clarify? Thx!
chill37 (Mon, 11 Mar 2019 12:02:57 GMT):
I just tried example of First-Network with OR(Org1.Member, Org2.Member) and it said invalid policy. same with Org1.Client
jyellick (Mon, 11 Mar 2019 15:56:30 GMT):
@chill37 Try lower case, like `Org1.member`
jyellick (Mon, 11 Mar 2019 15:56:30 GMT):
@chill37 Try lower case, like `Org1.member` (an example would be `"OR('SampleOrg.member')"`
jyellick (Mon, 11 Mar 2019 15:56:30 GMT):
@chill37 Try lower case, like `Org1.member` (an example would be `"OR('SampleOrg.member')"` )
chill37 (Tue, 12 Mar 2019 01:15:49 GMT):
@jyellick Thanks Jason. It worked! I don't even know why I tried it with Uppercase in first place. lol
KyunghoKim (Tue, 12 Mar 2019 03:10:16 GMT):
Has joined the channel.
Pradeep_Pentakota (Tue, 12 Mar 2019 12:42:47 GMT):
Has joined the channel.
gravity (Tue, 12 Mar 2019 13:05:41 GMT):
hi all
is it possible to tamper peer's state db if state db is a LevelDB?
thanks in advance
gaijinviki (Wed, 13 Mar 2019 00:35:06 GMT):
Hello all, I am running a hyperledger network with 3 peer nodes and 2 kafka based orderers. All components are running on separate VMs, connected by a docker swarm network.
I am doing a test to put data into the hyperledger network via `Hyperledger Java SDK`. The test is putting about `10 million records` at `500TPS`, so it is a long running test (about 5-6 hours).
After a few hours of the test running, my `anchor peer` panics and crashes.
Here is the error log:
```
panic: error during commit to txmgr: error reading response body: invalid byte in chunk length
goroutine 13188777 [running]:
github.com/hyperledger/fabric/core/ledger/kvledger.(*kvLedger).CommitWithPvtData(0xc003502ba0, 0xc00e534980, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/kvledger/kv_ledger.go:320 +0xac7
github.com/hyperledger/fabric/core/committer.(*LedgerCommitter).CommitWithPvtData(0xc0039e1060, 0xc00e534980, 0xc01287bd78, 0x2ad)
/opt/gopath/src/github.com/hyperledger/fabric/core/committer/committer_impl.go:93 +0x6b
github.com/hyperledger/fabric/gossip/privdata.(*coordinator).StoreBlock(0xc001d818c0, 0xc00661ac00, 0x0, 0x0, 0x0, 0xc01287beb0, 0x793230)
/opt/gopath/src/github.com/hyperledger/fabric/gossip/privdata/coordinator.go:233 +0x114a
github.com/hyperledger/fabric/gossip/state.(*GossipStateProviderImpl).commitBlock(0xc003ada400, 0xc00661ac00, 0x0, 0x0, 0x0, 0x3, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/gossip/state/state.go:771 +0x6c
github.com/hyperledger/fabric/gossip/state.(*GossipStateProviderImpl).deliverPayloads(0xc003ada400)
/opt/gopath/src/github.com/hyperledger/fabric/gossip/state/state.go:558 +0x3d5
created by github.com/hyperledger/fabric/gossip/state.NewGossipStateProvider
/opt/gopath/src/github.com/hyperledger/fabric/gossip/state/state.go:239 +0x62e
```
Can someone please help to determine what could be the issue?
P.S. - I am running v1.4.0.
gaijinviki (Wed, 13 Mar 2019 00:35:06 GMT):
Hello all, I am running a hyperledger network with 3 peer nodes and 2 kafka based orderers. All components are running on separate VMs, connected by a docker swarm network.
I am doing a test to put data into the hyperledger network via `Hyperledger Java SDK`. The test is putting about `10 million records` at `500TPS`, so it is a long running test (about 5-6 hours).
After a few hours of the test running, my `anchor peer` panics and crashes.
Here is the error log:
```
panic: error during commit to txmgr: error reading response body: invalid byte in chunk length
goroutine 13188777 [running]:
github.com/hyperledger/fabric/core/ledger/kvledger.(*kvLedger).CommitWithPvtData(0xc003502ba0, 0xc00e534980, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/kvledger/kv_ledger.go:320 +0xac7
github.com/hyperledger/fabric/core/committer.(*LedgerCommitter).CommitWithPvtData(0xc0039e1060, 0xc00e534980, 0xc01287bd78, 0x2ad)
/opt/gopath/src/github.com/hyperledger/fabric/core/committer/committer_impl.go:93 +0x6b
github.com/hyperledger/fabric/gossip/privdata.(*coordinator).StoreBlock(0xc001d818c0, 0xc00661ac00, 0x0, 0x0, 0x0, 0xc01287beb0, 0x793230)
/opt/gopath/src/github.com/hyperledger/fabric/gossip/privdata/coordinator.go:233 +0x114a
github.com/hyperledger/fabric/gossip/state.(*GossipStateProviderImpl).commitBlock(0xc003ada400, 0xc00661ac00, 0x0, 0x0, 0x0, 0x3, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/gossip/state/state.go:771 +0x6c
github.com/hyperledger/fabric/gossip/state.(*GossipStateProviderImpl).deliverPayloads(0xc003ada400)
/opt/gopath/src/github.com/hyperledger/fabric/gossip/state/state.go:558 +0x3d5
created by github.com/hyperledger/fabric/gossip/state.NewGossipStateProvider
/opt/gopath/src/github.com/hyperledger/fabric/gossip/state/state.go:239 +0x62e
```
Can someone please help to determine what could be the issue?
yacovm (Wed, 13 Mar 2019 00:37:04 GMT):
@dave.enyeart @manish-sethi ^
manish-sethi (Wed, 13 Mar 2019 02:01:58 GMT):
@gaijinviki - this appears to be caused by a commiunication problem during commit between peer and couchdb
dave.enyeart (Wed, 13 Mar 2019 02:10:46 GMT):
@gaijinviki If peer can't commit to the database it can't proceed with block processing and has no choice but to panic and hope an administrator or a restart can fix it. Is there anything in the couchdb log around that time?
gaijinviki (Wed, 13 Mar 2019 02:12:00 GMT):
@dave.enyeart Thanks for the info, let me check the couchdb log
gaijinviki (Wed, 13 Mar 2019 03:46:18 GMT):
@dave.enyeart , I found some error logs in couchdb
```
{"log":"[info] 2019-03-12T18:25:19.926585Z nonode@nohost \u003c0.3329.5260\u003e -------- Starting index update for db: shards/20000000-3fffffff/mychannel2_pta$demo2.1551854584 idx: _design/indexCompkeyDoc\n","stream":"stderr","time":"2019-03-12T18:25:19.927619212Z"}
{"log":"[error] 2019-03-12T18:25:29.889194Z nonode@nohost \u003c0.2895.7310\u003e b1380371dd req_err(1114665363) badmatch : timeout\n","stream":"stderr","time":"2019-03-12T18:25:57.297092859Z"}
{"log":" [\u003c\u003c\"fabric_view_all_docs:go/5 L107\"\u003e\u003e,\u003c\u003c\"chttpd_db:all_docs_view/4 L690\"\u003e\u003e,\u003c\u003c\"chttpd:handle_req_after_auth/2 L317\"\u003e\u003e,\u003c\u003c\"chttpd:process_request/1 L300\"\u003e\u003e,\u003c\u003c\"chttpd:handle_request_int/1 L240\"\u003e\u003e,\u003c\u003c\"mochiweb_http:headers/6 L124\"\u003e\u003e,\u003c\u003c\"proc_lib:init_p_do_apply/3 L240\"\u003e\u003e]\n","stream":"stderr","time":"2019-03-12T18:25:57.297136914Z"}
{"log":"[notice] 2019-03-12T18:25:29.889626Z nonode@nohost \u003c0.2895.7310\u003e b1380371dd couchdb0_org1:5984 10.0.0.11 undefined POST /mychannel_pta$demo/_all_docs?include_docs=true 500 ok 10041\n","stream":"stderr","time":"2019-03-12T18:25:57.297156819Z"}
{"log":"[notice] 2019-03-12T18:25:57.416695Z nonode@nohost \u003c0.31100.7311\u003e a1331dd791 couchdb0_org1:5984 10.0.0.11 undefined PUT /mychannel2_/statedb_savepoint 201 ok 37490\n","stream":"stderr","time":"2019-03-12T18:25:57.418367552Z"}
{"log":"[info] 2019-03-12T18:25:57.447407Z nonode@nohost \u003c0.7328.5260\u003e -------- Index update finished for db: shards/60000000-7fffffff/mychannel2_pta$demo2.1551854584 idx: _design/indexCompkeyDoc\n","stream":"stderr","time":"2019-03-12T18:25:57.447874185Z"}
```
chill37 (Wed, 13 Mar 2019 05:43:04 GMT):
Hi, In Endorsement Policy, I see that there are more classification than the basic MSP Role.
is there an example where it uses ORGANIZATION UNIT or IDENTITY/ANONYMITY instead of MSPROLE for MSP Classification? I would like to know how to approach the data
iamdm (Wed, 13 Mar 2019 10:25:52 GMT):
Hi, is it possible to start peer without tls, but it must communicate with orderer with tls?
gravity (Fri, 15 Mar 2019 09:51:16 GMT):
Hi all
I have a question regarding endorsement policies
for example, if a chaincode has a policy like `AND("Org1.peer", "Org2.peer")`, but Org2 has no endorser peers (all peers from Org2 in this channel have no installed chaincodes). would this policy work?
thanks in advance
knagware9 (Fri, 15 Mar 2019 13:10:25 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=PrYpAbepvMscu5xgn) @gravity no , It wont work, chaincode should be installed on endorser peer
ChaviArora (Mon, 18 Mar 2019 10:14:15 GMT):
Has joined the channel.
adamhardie (Wed, 20 Mar 2019 10:32:38 GMT):
hey,
I have a stable network running ontop of kafka. We have 2 orderers, 1 channel, 1 anchor peer and 1 chaincode deployed
adamhardie (Wed, 20 Mar 2019 10:33:03 GMT):
Before switching to kafka and multiple orderers, we had barely any latency
adamhardie (Wed, 20 Mar 2019 10:33:39 GMT):
However, now the same transactions can take up to 1 hour for some applications to receive a newly created block from the channel
adamhardie (Wed, 20 Mar 2019 10:34:16 GMT):
I cant really see much in the way of logging, but have confirmed there is 1 hour wait in some cases between the SDK commit and the receipt of the block on the channel
adamhardie (Wed, 20 Mar 2019 10:34:40 GMT):
can you suggest the best way to debug this? the orderer logs do not give much information..
adamhardie (Wed, 20 Mar 2019 13:56:37 GMT):
it appears that one application on the channel receives the block, and the others dont
adamhardie (Wed, 20 Mar 2019 13:56:49 GMT):
receives the block immediately *
aatkddny (Wed, 20 Mar 2019 15:39:14 GMT):
So I'm trying to install chaincode. Not something new - but the error is.
```
2019-03-20 15:22:54.435 UTC [endorser] SimulateProposal -> ERRO 3bf [][6d64d4ab] failed to invoke chaincode name:"lscc" , error: timeout expired while executing transaction
github.com/hyperledger/fabric/core/chaincode.(*Handler).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:919
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:253
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Invoke
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:239
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:179
github.com/hyperledger/fabric/core/endorser.(*SupportImpl).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/support.go:141
github.com/hyperledger/fabric/core/endorser.(*Endorser).callChaincode
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:136
github.com/hyperledger/fabric/core/endorser.(*Endorser).SimulateProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:287
github.com/hyperledger/fabric/core/endorser.(*Endorser).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:501
github.com/hyperledger/fabric/core/handlers/auth/filter.(*expirationCheckFilter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/expiration.go:61
github.com/hyperledger/fabric/core/handlers/auth/filter.(*filter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/filter.go:31
github.com/hyperledger/fabric/protos/peer._Endorser_ProcessProposal_Handler
/opt/gopath/src/github.com/hyperledger/fabric/protos/peer/peer.pb.go:112
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).processUnaryRPC
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:923
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).handleStream
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:1148
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:637
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:2361
error sending
failed to execute transaction 6d64d4ab82809dc6afe5d9932de2e15b59762e47d971dd52a1bb7e6786a26278
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:181
github.com/hyperledger/fabric/core/endorser.(*SupportImpl).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/support.go:141
github.com/hyperledger/fabric/core/endorser.(*Endorser).callChaincode
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:136
github.com/hyperledger/fabric/core/endorser.(*Endorser).SimulateProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:287
github.com/hyperledger/fabric/core/endorser.(*Endorser).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:501
github.com/hyperledger/fabric/core/handlers/auth/filter.(*expirationCheckFilter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/expiration.go:61
github.com/hyperledger/fabric/core/handlers/auth/filter.(*filter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/filter.go:31
github.com/hyperledger/fabric/protos/peer._Endorser_ProcessProposal_Handler
/opt/gopath/src/github.com/hyperledger/fabric/protos/peer/peer.pb.go:112
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).processUnaryRPC
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:923
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).handleStream
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:1148
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:637
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:2361
```
It looks like it's working on 3 of 6 peers but failing on the other 3. Logs give the above from the peer, orderers and kafkas don't show anything.
Anyone know why it's started doing this off the top of their head?
aatkddny (Wed, 20 Mar 2019 15:39:14 GMT):
So I'm trying to install chaincode. Not something new - but the error is.
```
2019-03-20 15:22:54.435 UTC [endorser] SimulateProposal -> ERRO 3bf [][6d64d4ab] failed to invoke chaincode name:"lscc" , error: timeout expired while executing transaction
github.com/hyperledger/fabric/core/chaincode.(*Handler).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:919
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:253
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Invoke
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:239
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:179
github.com/hyperledger/fabric/core/endorser.(*SupportImpl).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/support.go:141
github.com/hyperledger/fabric/core/endorser.(*Endorser).callChaincode
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:136
github.com/hyperledger/fabric/core/endorser.(*Endorser).SimulateProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:287
github.com/hyperledger/fabric/core/endorser.(*Endorser).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:501
github.com/hyperledger/fabric/core/handlers/auth/filter.(*expirationCheckFilter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/expiration.go:61
github.com/hyperledger/fabric/core/handlers/auth/filter.(*filter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/filter.go:31
github.com/hyperledger/fabric/protos/peer._Endorser_ProcessProposal_Handler
/opt/gopath/src/github.com/hyperledger/fabric/protos/peer/peer.pb.go:112
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).processUnaryRPC
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:923
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).handleStream
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:1148
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:637
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:2361
error sending
failed to execute transaction 6d64d4ab82809dc6afe5d9932de2e15b59762e47d971dd52a1bb7e6786a26278
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:181
github.com/hyperledger/fabric/core/endorser.(*SupportImpl).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/support.go:141
github.com/hyperledger/fabric/core/endorser.(*Endorser).callChaincode
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:136
github.com/hyperledger/fabric/core/endorser.(*Endorser).SimulateProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:287
github.com/hyperledger/fabric/core/endorser.(*Endorser).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:501
github.com/hyperledger/fabric/core/handlers/auth/filter.(*expirationCheckFilter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/expiration.go:61
github.com/hyperledger/fabric/core/handlers/auth/filter.(*filter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/filter.go:31
github.com/hyperledger/fabric/protos/peer._Endorser_ProcessProposal_Handler
/opt/gopath/src/github.com/hyperledger/fabric/protos/peer/peer.pb.go:112
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).processUnaryRPC
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:923
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).handleStream
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:1148
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:637
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:2361
```
It looks like it's working on 3 of 6 peers but failing on the other 3. Logs give the above from the peer, orderers and kafkas don't show anything.
Anyone know why it's started doing this off the top of their head?
aatkddny (Wed, 20 Mar 2019 15:39:14 GMT):
So I'm trying to install chaincode. Not something new - but the error is.
```
2019-03-20 15:22:54.435 UTC [endorser] SimulateProposal -> ERRO 3bf [][6d64d4ab] failed to invoke chaincode name:"lscc" , error: timeout expired while executing transaction
github.com/hyperledger/fabric/core/chaincode.(*Handler).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:919
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:253
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Invoke
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:239
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:179
github.com/hyperledger/fabric/core/endorser.(*SupportImpl).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/support.go:141
github.com/hyperledger/fabric/core/endorser.(*Endorser).callChaincode
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:136
github.com/hyperledger/fabric/core/endorser.(*Endorser).SimulateProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:287
github.com/hyperledger/fabric/core/endorser.(*Endorser).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:501
github.com/hyperledger/fabric/core/handlers/auth/filter.(*expirationCheckFilter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/expiration.go:61
github.com/hyperledger/fabric/core/handlers/auth/filter.(*filter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/filter.go:31
github.com/hyperledger/fabric/protos/peer._Endorser_ProcessProposal_Handler
/opt/gopath/src/github.com/hyperledger/fabric/protos/peer/peer.pb.go:112
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).processUnaryRPC
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:923
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).handleStream
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:1148
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:637
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:2361
error sending
failed to execute transaction 6d64d4ab82809dc6afe5d9932de2e15b59762e47d971dd52a1bb7e6786a26278
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:181
github.com/hyperledger/fabric/core/endorser.(*SupportImpl).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/support.go:141
github.com/hyperledger/fabric/core/endorser.(*Endorser).callChaincode
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:136
github.com/hyperledger/fabric/core/endorser.(*Endorser).SimulateProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:287
github.com/hyperledger/fabric/core/endorser.(*Endorser).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:501
github.com/hyperledger/fabric/core/handlers/auth/filter.(*expirationCheckFilter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/expiration.go:61
github.com/hyperledger/fabric/core/handlers/auth/filter.(*filter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/filter.go:31
github.com/hyperledger/fabric/protos/peer._Endorser_ProcessProposal_Handler
/opt/gopath/src/github.com/hyperledger/fabric/protos/peer/peer.pb.go:112
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).processUnaryRPC
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:923
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).handleStream
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:1148
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:637
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:2361
```
It looks like it's working on 3 of 6 peers but failing on the other 3. Logs give the above from the peer, orderers and kafkas don't show anything.
Anyone know why it's started doing this off the top of their head?
aatkddny (Wed, 20 Mar 2019 15:41:56 GMT):
My logs look like this:
```
2019-03-20 11:37:09.084 INFO 28904 --- [nio-8095-exec-5] c.m.f.e.p.chaincode.ChaincodeProcessor : Chaincode will be installed from /opt/blockchain/chaincode-install/sacc
2019-03-20 11:37:09.084 INFO 28904 --- [nio-8095-exec-5] com.mo.fabric.utils.Util : sacc
2019-03-20 11:37:09.084 INFO 28904 --- [nio-8095-exec-5] com.mo.fabric.utils.Util : Copying /opt/blockchain/chaincode-install/sacc to src/sacc
2019-03-20 11:37:09.084 INFO 28904 --- [nio-8095-exec-5] com.mo.fabric.utils.Util : sacc/sacc.go
2019-03-20 11:37:09.085 INFO 28904 --- [nio-8095-exec-5] com.mo.fabric.utils.Util : Copying /opt/blockchain/chaincode-install/sacc/sacc.go to src/sacc/sacc.go
2019-03-20 11:37:09.089 INFO 28904 --- [nio-8095-exec-5] com.mo.fabric.utils.Util : 84374 bytes copied
2019-03-20 11:37:09.090 INFO 28904 --- [nio-8095-exec-5] c.m.f.e.p.chaincode.ChaincodeProcessor : Checking installed chaincode: sacc, at version: 3.1, on peer: peer1-org1
2019-03-20 11:37:09.110 INFO 28904 --- [nio-8095-exec-5] c.m.f.e.p.chaincode.ChaincodeProcessor : Checking installed chaincode: sacc, at version: 3.1, on peer: peer0-org1
2019-03-20 11:37:09.130 INFO 28904 --- [nio-8095-exec-5] o.h.f.s.t.InstallProposalBuilder : Installing 'sacc::sacc::3.1' Go chaincode chaincodePath:'sacc' from input stream
2019-03-20 11:37:09.221 ERROR 28904 --- [nio-8095-exec-5] c.m.f.e.p.chaincode.ChaincodeProcessor : Failed install proposal response 4031aa55740c7067965823ba769c33e64d40fdf5b4d21d2cb5e198ea6f7ed536 from peer peer0-org2
2019-03-20 11:37:09.221 ERROR 28904 --- [nio-8095-exec-5] c.m.f.e.p.chaincode.ChaincodeProcessor : Failed install proposal response 4031aa55740c7067965823ba769c33e64d40fdf5b4d21d2cb5e198ea6f7ed536 from peer peer1-org2
2019-03-20 11:37:09.221 INFO 28904 --- [nio-8095-exec-5] c.m.f.e.p.chaincode.ChaincodeProcessor : Successful install proposal response 16bb8d90f44607a9209b6a4a06a54940c11840dd6bff015d00fad284f1a578a1 from peer peer0-org3
2019-03-20 11:37:09.221 ERROR 28904 --- [nio-8095-exec-5] c.m.f.e.p.chaincode.ChaincodeProcessor : Failed install proposal response 16bb8d90f44607a9209b6a4a06a54940c11840dd6bff015d00fad284f1a578a1 from peer peer1-org3
2019-03-20 11:37:09.221 INFO 28904 --- [nio-8095-exec-5] c.m.f.e.p.chaincode.ChaincodeProcessor : Successful install proposal response a387afbd685a0a8fd747ba689d687717a29643ac48e4be71235e326370b2e07e from peer peer1-org1
2019-03-20 11:37:09.221 INFO 28904 --- [nio-8095-exec-5] c.m.f.e.p.chaincode.ChaincodeProcessor : Successful install proposal response a387afbd685a0a8fd747ba689d687717a29643ac48e4be71235e326370b2e07e from peer peer0-org1
2019-03-20 11:37:09.221 INFO 28904 --- [nio-8095-exec-5] c.m.f.e.p.chaincode.ChaincodeProcessor : Transmitted 6 install proposals. Received 6 responses. Successful+verified: 3 . Failed: 3
2019-03-20 11:37:09.221 ERROR 28904 --- [nio-8095-exec-5] c.m.f.e.p.chaincode.ChaincodeProcessor : Failed chaincode install: failed to execute transaction 4031aa55740c7067965823ba769c33e64d40fdf5b4d21d2cb5e198ea6f7ed536: error sending: timeout expired while executing transaction
2019-03-20 11:37:12.530 DEBUG 28904 --- [nio-8095-exec-5] o.s.b.w.s.f.OrderedRequestContextFilter : Cleared thread-bound request context: org.apache.catalina.connector.RequestFacade@fa1641a
```
aatkddny (Wed, 20 Mar 2019 15:41:56 GMT):
My logs look like this:
```
2019-03-20 11:37:09.084 INFO 28904 --- [nio-8095-exec-5] c.m.f.e.p.chaincode.ChaincodeProcessor : Chaincode will be installed from /opt/blockchain/chaincode-install/sacc
2019-03-20 11:37:09.084 INFO 28904 --- [nio-8095-exec-5] com.mo.fabric.utils.Util : sacc
2019-03-20 11:37:09.084 INFO 28904 --- [nio-8095-exec-5] com.mo.fabric.utils.Util : Copying /opt/blockchain/chaincode-install/sacc to src/sacc
2019-03-20 11:37:09.084 INFO 28904 --- [nio-8095-exec-5] com.mo.fabric.utils.Util : sacc/sacc.go
2019-03-20 11:37:09.085 INFO 28904 --- [nio-8095-exec-5] com.mo.fabric.utils.Util : Copying /opt/blockchain/chaincode-install/sacc/sacc.go to src/sacc/sacc.go
2019-03-20 11:37:09.089 INFO 28904 --- [nio-8095-exec-5] com.mo.fabric.utils.Util : 84374 bytes copied
2019-03-20 11:37:09.090 INFO 28904 --- [nio-8095-exec-5] c.m.f.e.p.chaincode.ChaincodeProcessor : Checking installed chaincode: sacc, at version: 3.1, on peer: peer1-org1
2019-03-20 11:37:09.110 INFO 28904 --- [nio-8095-exec-5] c.m.f.e.p.chaincode.ChaincodeProcessor : Checking installed chaincode: sacc, at version: 3.1, on peer: peer0-org1
2019-03-20 11:37:09.130 INFO 28904 --- [nio-8095-exec-5] o.h.f.s.t.InstallProposalBuilder : Installing 'sacc::sacc::3.1' Go chaincode chaincodePath:'sacc' from input stream
2019-03-20 11:37:09.221 ERROR 28904 --- [nio-8095-exec-5] c.m.f.e.p.chaincode.ChaincodeProcessor : Failed install proposal response 4031aa55740c7067965823ba769c33e64d40fdf5b4d21d2cb5e198ea6f7ed536 from peer peer0-org2
2019-03-20 11:37:09.221 ERROR 28904 --- [nio-8095-exec-5] c.m.f.e.p.chaincode.ChaincodeProcessor : Failed install proposal response 4031aa55740c7067965823ba769c33e64d40fdf5b4d21d2cb5e198ea6f7ed536 from peer peer1-org2
2019-03-20 11:37:09.221 INFO 28904 --- [nio-8095-exec-5] c.m.f.e.p.chaincode.ChaincodeProcessor : Successful install proposal response 16bb8d90f44607a9209b6a4a06a54940c11840dd6bff015d00fad284f1a578a1 from peer peer0-org3
2019-03-20 11:37:09.221 ERROR 28904 --- [nio-8095-exec-5] c.m.f.e.p.chaincode.ChaincodeProcessor : Failed install proposal response 16bb8d90f44607a9209b6a4a06a54940c11840dd6bff015d00fad284f1a578a1 from peer peer1-org3
2019-03-20 11:37:09.221 INFO 28904 --- [nio-8095-exec-5] c.m.f.e.p.chaincode.ChaincodeProcessor : Successful install proposal response a387afbd685a0a8fd747ba689d687717a29643ac48e4be71235e326370b2e07e from peer peer1-org1
2019-03-20 11:37:09.221 INFO 28904 --- [nio-8095-exec-5] c.m.f.e.p.chaincode.ChaincodeProcessor : Successful install proposal response a387afbd685a0a8fd747ba689d687717a29643ac48e4be71235e326370b2e07e from peer peer0-org1
2019-03-20 11:37:09.221 INFO 28904 --- [nio-8095-exec-5] c.m.f.e.p.chaincode.ChaincodeProcessor : Transmitted 6 install proposals. Received 6 responses. Successful+verified: 3 . Failed: 3
2019-03-20 11:37:09.221 ERROR 28904 --- [nio-8095-exec-5] c.m.f.e.p.chaincode.ChaincodeProcessor : Failed chaincode install: failed to execute transaction 4031aa55740c7067965823ba769c33e64d40fdf5b4d21d2cb5e198ea6f7ed536: error sending: timeout expired while executing transaction
2019-03-20 11:37:12.530 DEBUG 28904 --- [nio-8095-exec-5] o.s.b.w.s.f.OrderedRequestContextFilter : Cleared thread-bound request context: org.apache.catalina.connector.RequestFacade@fa1641a
```
aatkddny (Wed, 20 Mar 2019 15:41:56 GMT):
Timeouts in the SDK are set crazy high so I don't think it's that, but my logs look like this:
```
2019-03-20 11:37:09.084 INFO 28904 --- [nio-8095-exec-5] c.m.f.e.p.chaincode.ChaincodeProcessor : Chaincode will be installed from /opt/blockchain/chaincode-install/sacc
2019-03-20 11:37:09.084 INFO 28904 --- [nio-8095-exec-5] com.mo.fabric.utils.Util : sacc
2019-03-20 11:37:09.084 INFO 28904 --- [nio-8095-exec-5] com.mo.fabric.utils.Util : Copying /opt/blockchain/chaincode-install/sacc to src/sacc
2019-03-20 11:37:09.084 INFO 28904 --- [nio-8095-exec-5] com.mo.fabric.utils.Util : sacc/sacc.go
2019-03-20 11:37:09.085 INFO 28904 --- [nio-8095-exec-5] com.mo.fabric.utils.Util : Copying /opt/blockchain/chaincode-install/sacc/sacc.go to src/sacc/sacc.go
2019-03-20 11:37:09.089 INFO 28904 --- [nio-8095-exec-5] com.mo.fabric.utils.Util : 84374 bytes copied
2019-03-20 11:37:09.090 INFO 28904 --- [nio-8095-exec-5] c.m.f.e.p.chaincode.ChaincodeProcessor : Checking installed chaincode: sacc, at version: 3.1, on peer: peer1-org1
2019-03-20 11:37:09.110 INFO 28904 --- [nio-8095-exec-5] c.m.f.e.p.chaincode.ChaincodeProcessor : Checking installed chaincode: sacc, at version: 3.1, on peer: peer0-org1
2019-03-20 11:37:09.130 INFO 28904 --- [nio-8095-exec-5] o.h.f.s.t.InstallProposalBuilder : Installing 'sacc::sacc::3.1' Go chaincode chaincodePath:'sacc' from input stream
2019-03-20 11:37:09.221 ERROR 28904 --- [nio-8095-exec-5] c.m.f.e.p.chaincode.ChaincodeProcessor : Failed install proposal response 4031aa55740c7067965823ba769c33e64d40fdf5b4d21d2cb5e198ea6f7ed536 from peer peer0-org2
2019-03-20 11:37:09.221 ERROR 28904 --- [nio-8095-exec-5] c.m.f.e.p.chaincode.ChaincodeProcessor : Failed install proposal response 4031aa55740c7067965823ba769c33e64d40fdf5b4d21d2cb5e198ea6f7ed536 from peer peer1-org2
2019-03-20 11:37:09.221 INFO 28904 --- [nio-8095-exec-5] c.m.f.e.p.chaincode.ChaincodeProcessor : Successful install proposal response 16bb8d90f44607a9209b6a4a06a54940c11840dd6bff015d00fad284f1a578a1 from peer peer0-org3
2019-03-20 11:37:09.221 ERROR 28904 --- [nio-8095-exec-5] c.m.f.e.p.chaincode.ChaincodeProcessor : Failed install proposal response 16bb8d90f44607a9209b6a4a06a54940c11840dd6bff015d00fad284f1a578a1 from peer peer1-org3
2019-03-20 11:37:09.221 INFO 28904 --- [nio-8095-exec-5] c.m.f.e.p.chaincode.ChaincodeProcessor : Successful install proposal response a387afbd685a0a8fd747ba689d687717a29643ac48e4be71235e326370b2e07e from peer peer1-org1
2019-03-20 11:37:09.221 INFO 28904 --- [nio-8095-exec-5] c.m.f.e.p.chaincode.ChaincodeProcessor : Successful install proposal response a387afbd685a0a8fd747ba689d687717a29643ac48e4be71235e326370b2e07e from peer peer0-org1
2019-03-20 11:37:09.221 INFO 28904 --- [nio-8095-exec-5] c.m.f.e.p.chaincode.ChaincodeProcessor : Transmitted 6 install proposals. Received 6 responses. Successful+verified: 3 . Failed: 3
2019-03-20 11:37:09.221 ERROR 28904 --- [nio-8095-exec-5] c.m.f.e.p.chaincode.ChaincodeProcessor : Failed chaincode install: failed to execute transaction 4031aa55740c7067965823ba769c33e64d40fdf5b4d21d2cb5e198ea6f7ed536: error sending: timeout expired while executing transaction
2019-03-20 11:37:12.530 DEBUG 28904 --- [nio-8095-exec-5] o.s.b.w.s.f.OrderedRequestContextFilter : Cleared thread-bound request context: org.apache.catalina.connector.RequestFacade@fa1641a
```
aatkddny (Thu, 21 Mar 2019 13:15:59 GMT):
Is there a way to up this timeout?
```
2019-03-21 13:13:19.188 UTC [endorser] callChaincode -> DEBU ff0 [][c53bf5bdbd7827c0923c952f6491d4b9d2c18d9ead197640b80b1a110170d891] Exit
2019-03-21 13:13:19.188 UTC [endorser] SimulateProposal -> ERRO ff1 [][c53bf5bd] failed to invoke chaincode name:"lscc" , error: timeout expired while executing transaction
github.com/hyperledger/fabric/core/chaincode.(*Handler).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:919
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:253
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Invoke
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:239
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:179
github.com/hyperledger/fabric/core/endorser.(*SupportImpl).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/support.go:141
github.com/hyperledger/fabric/core/endorser.(*Endorser).callChaincode
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:136
github.com/hyperledger/fabric/core/endorser.(*Endorser).SimulateProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:287
github.com/hyperledger/fabric/core/endorser.(*Endorser).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:501
github.com/hyperledger/fabric/core/handlers/auth/filter.(*expirationCheckFilter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/expiration.go:61
github.com/hyperledger/fabric/core/handlers/auth/filter.(*filter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/filter.go:31
github.com/hyperledger/fabric/protos/peer._Endorser_ProcessProposal_Handler
/opt/gopath/src/github.com/hyperledger/fabric/protos/peer/peer.pb.go:112
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).processUnaryRPC
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:923
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).handleStream
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:1148
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:637
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:2361
error sending
failed to execute transaction c53bf5bdbd7827c0923c952f6491d4b9d2c18d9ead197640b80b1a110170d891
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:181
github.com/hyperledger/fabric/core/endorser.(*SupportImpl).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/support.go:141
github.com/hyperledger/fabric/core/endorser.(*Endorser).callChaincode
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:136
github.com/hyperledger/fabric/core/endorser.(*Endorser).SimulateProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:287
github.com/hyperledger/fabric/core/endorser.(*Endorser).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:501
github.com/hyperledger/fabric/core/handlers/auth/filter.(*expirationCheckFilter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/expiration.go:61
github.com/hyperledger/fabric/core/handlers/auth/filter.(*filter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/filter.go:31
github.com/hyperledger/fabric/protos/peer._Endorser_ProcessProposal_Handler
/opt/gopath/src/github.com/hyperledger/fabric/protos/peer/peer.pb.go:112
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).processUnaryRPC
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:923
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).handleStream
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:1148
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:637
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:2361
2019-03-21 13:13:19.189 UTC [endorser] SimulateProposal -> DEBU ff2 [][c53bf5bd] Exit
```
aatkddny (Thu, 21 Mar 2019 13:15:59 GMT):
Is there a way to up this timeout? Every time it happens my peers go TU and I have to restart them. It's proving troublesome...
```
2019-03-21 13:13:19.188 UTC [endorser] callChaincode -> DEBU ff0 [][c53bf5bdbd7827c0923c952f6491d4b9d2c18d9ead197640b80b1a110170d891] Exit
2019-03-21 13:13:19.188 UTC [endorser] SimulateProposal -> ERRO ff1 [][c53bf5bd] failed to invoke chaincode name:"lscc" , error: timeout expired while executing transaction
github.com/hyperledger/fabric/core/chaincode.(*Handler).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:919
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:253
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Invoke
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:239
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:179
github.com/hyperledger/fabric/core/endorser.(*SupportImpl).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/support.go:141
github.com/hyperledger/fabric/core/endorser.(*Endorser).callChaincode
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:136
github.com/hyperledger/fabric/core/endorser.(*Endorser).SimulateProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:287
github.com/hyperledger/fabric/core/endorser.(*Endorser).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:501
github.com/hyperledger/fabric/core/handlers/auth/filter.(*expirationCheckFilter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/expiration.go:61
github.com/hyperledger/fabric/core/handlers/auth/filter.(*filter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/filter.go:31
github.com/hyperledger/fabric/protos/peer._Endorser_ProcessProposal_Handler
/opt/gopath/src/github.com/hyperledger/fabric/protos/peer/peer.pb.go:112
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).processUnaryRPC
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:923
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).handleStream
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:1148
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:637
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:2361
error sending
failed to execute transaction c53bf5bdbd7827c0923c952f6491d4b9d2c18d9ead197640b80b1a110170d891
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:181
github.com/hyperledger/fabric/core/endorser.(*SupportImpl).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/support.go:141
github.com/hyperledger/fabric/core/endorser.(*Endorser).callChaincode
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:136
github.com/hyperledger/fabric/core/endorser.(*Endorser).SimulateProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:287
github.com/hyperledger/fabric/core/endorser.(*Endorser).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:501
github.com/hyperledger/fabric/core/handlers/auth/filter.(*expirationCheckFilter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/expiration.go:61
github.com/hyperledger/fabric/core/handlers/auth/filter.(*filter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/filter.go:31
github.com/hyperledger/fabric/protos/peer._Endorser_ProcessProposal_Handler
/opt/gopath/src/github.com/hyperledger/fabric/protos/peer/peer.pb.go:112
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).processUnaryRPC
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:923
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).handleStream
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:1148
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:637
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:2361
2019-03-21 13:13:19.189 UTC [endorser] SimulateProposal -> DEBU ff2 [][c53bf5bd] Exit
```
aatkddny (Thu, 21 Mar 2019 13:15:59 GMT):
Is there a way to up this timeout? Or better - have this code fixed to retry.
Every time it happens my peers go TU and I have to restart them. It's proving troublesome...
```
2019-03-21 13:13:19.188 UTC [endorser] SimulateProposal -> ERRO ff1 [][c53bf5bd] failed to invoke chaincode name:"lscc" , error: timeout expired while executing transaction
github.com/hyperledger/fabric/core/chaincode.(*Handler).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:919
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:253
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Invoke
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:239
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:179
github.com/hyperledger/fabric/core/endorser.(*SupportImpl).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/support.go:141
github.com/hyperledger/fabric/core/endorser.(*Endorser).callChaincode
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:136
github.com/hyperledger/fabric/core/endorser.(*Endorser).SimulateProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:287
github.com/hyperledger/fabric/core/endorser.(*Endorser).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:501
github.com/hyperledger/fabric/core/handlers/auth/filter.(*expirationCheckFilter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/expiration.go:61
github.com/hyperledger/fabric/core/handlers/auth/filter.(*filter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/filter.go:31
github.com/hyperledger/fabric/protos/peer._Endorser_ProcessProposal_Handler
/opt/gopath/src/github.com/hyperledger/fabric/protos/peer/peer.pb.go:112
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).processUnaryRPC
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:923
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).handleStream
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:1148
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:637
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:2361
error sending
failed to execute transaction c53bf5bdbd7827c0923c952f6491d4b9d2c18d9ead197640b80b1a110170d891
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:181
github.com/hyperledger/fabric/core/endorser.(*SupportImpl).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/support.go:141
github.com/hyperledger/fabric/core/endorser.(*Endorser).callChaincode
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:136
github.com/hyperledger/fabric/core/endorser.(*Endorser).SimulateProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:287
github.com/hyperledger/fabric/core/endorser.(*Endorser).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:501
github.com/hyperledger/fabric/core/handlers/auth/filter.(*expirationCheckFilter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/expiration.go:61
github.com/hyperledger/fabric/core/handlers/auth/filter.(*filter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/filter.go:31
github.com/hyperledger/fabric/protos/peer._Endorser_ProcessProposal_Handler
/opt/gopath/src/github.com/hyperledger/fabric/protos/peer/peer.pb.go:112
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).processUnaryRPC
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:923
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).handleStream
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:1148
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:637
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:2361
2019-03-21 13:13:19.189 UTC [endorser] SimulateProposal -> DEBU ff2 [][c53bf5bd] Exit
```
aatkddny (Thu, 21 Mar 2019 13:15:59 GMT):
Is there a way to up this timeout? Or better - have this code fixed to retry.
Every time it happens my peers go TU and I have to restart them. It's proving troublesome...
```
2019-03-21 13:13:19.188 UTC [endorser] SimulateProposal -> ERRO ff1 [][c53bf5bd] failed to invoke chaincode name:"lscc" , error: timeout expired while executing transaction
github.com/hyperledger/fabric/core/chaincode.(*Handler).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:919
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:253
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Invoke
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:239
*blah blah blah*
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:637
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:2361
error sending
failed to execute transaction c53bf5bdbd7827c0923c952f6491d4b9d2c18d9ead197640b80b1a110170d891
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:181
github.com/hyperledger/fabric/core/endorser.(*SupportImpl).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/support.go:141
github.com/hyperledger/fabric/core/endorser.(*Endorser).callChaincode
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:136
*blah blah blah*
/opt/gopath/src/github.com/hyperledger/fabric/protos/peer/peer.pb.go:112
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).processUnaryRPC
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:923
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).handleStream
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:1148
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:637
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:2361
2019-03-21 13:13:19.189 UTC [endorser] SimulateProposal -> DEBU ff2 [][c53bf5bd] Exit
```
Happens when installing chaincode if that helps.
muralisr (Fri, 22 Mar 2019 14:22:19 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=wpRRsyMqBAXHWTKq8) I found in the docs, and was told about `FABRIC_LOGGING_SPEC` which I used as `export FABRIC_LOGGING_SPEC=FATAL` to get some peace and quiet.
muralisr (Fri, 22 Mar 2019 14:22:19 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=wpRRsyMqBAXHWTKq8) from @MHBauer -> I found in the docs, and was told about `FABRIC_LOGGING_SPEC` which I used as `export FABRIC_LOGGING_SPEC=FATAL` to get some peace and quiet.
muralisr (Fri, 22 Mar 2019 14:23:02 GMT):
@MHBauer redirected your question to here ...( @wlahti may be able to help ?)
MHBauer (Fri, 22 Mar 2019 14:23:02 GMT):
Has joined the channel.
wlahti (Fri, 22 Mar 2019 15:46:25 GMT):
@MHBauer Which tests are you referring to? And yes, for the peer and orderer, you can use `FABRIC_LOGGING_SPEC` to control the log level for all loggers or just for certain loggers. Let me know if you still have any questions and I'll be glad to help!
MHBauer (Fri, 22 Mar 2019 18:08:06 GMT):
what's this channel for?
MHBauer (Fri, 22 Mar 2019 18:32:05 GMT):
I was looking at txvalidator tests
MHBauer (Fri, 22 Mar 2019 18:32:20 GMT):
seems to be an imprettyportant part of the lifeciycle
wlahti (Fri, 22 Mar 2019 18:38:39 GMT):
so you're looking to mute logging while running unit tests via `go test ./... -v`?
MHBauer (Fri, 22 Mar 2019 18:43:05 GMT):
yup, problem already solved.
MHBauer (Fri, 22 Mar 2019 18:43:07 GMT):
mostly.
MHBauer (Fri, 22 Mar 2019 18:43:13 GMT):
there's some rando print statements
MHBauer (Fri, 22 Mar 2019 18:43:39 GMT):
I had a different question about the feelings about some tests, but I can't remember which ones.
aatkddny (Fri, 22 Mar 2019 19:15:01 GMT):
So we are having an issue with chaincode and peer endorsement. Lets keep it simple - 2 orgs, 2 peers each. Or endorsement policy Org1 or Org 2. Channel between orgs.
It goes something like this:
We try to install and instantiate new chaincode at a specific version - say 1.0 not he mutual channel.
It fails due to the timeout issue i listed about 7 posts up.
We restart the peer that it fails on and reinstall same chaincode at a different version - say 1.01 or something. No changes, just a restart. All storage is outside of the containers in NFS.
This reports that it went in just fine.
But there's a problem.
Now the proposal responses from the two peers are coming back inconsistent. They both come back with an OK return code, but the payload differs slightly. Which means the Tx won't commit.
1. Why?
2. Nothing - and I mean nothing, from installing chaincode again to bouncing the whole network to deleting the ledger and couched storage for this peer fixes it. Is there something we can do that we missed?
We've hit this twice now. Twice we had to reconstitute the entire network.
aatkddny (Fri, 22 Mar 2019 19:15:01 GMT):
So we are having an issue with chaincode and peer endorsement. Lets keep it simple - 2 orgs, 2 peers each. Or endorsement policy - Org1 or Org 2. Channel between orgs, all peers endorse.
It goes something like this:
We try to install and instantiate new chaincode at a specific version - say 1.0 not he mutual channel.
It fails due to the timeout issue i listed about 7 posts up.
We restart the peer that it fails on and reinstall same chaincode at a different version - say 1.01 or something. No changes, just a restart. All storage is outside of the containers in NFS.
This reports that it went in just fine.
But there's a problem.
Now the proposal responses from the two peers in the org - org1 say - are coming back inconsistent. They both come back with an OK return code, but the payload differs slightly. Which means the Tx won't commit.
1. Why?
2. Nothing - and I mean nothing, from installing chaincode again to bouncing the whole network to deleting the ledger and couched storage for this peer fixes it. Is there something we can do that we missed?
We've hit this twice now. Twice we had to reconstitute the entire network.
aatkddny (Fri, 22 Mar 2019 19:15:01 GMT):
So we are having an issue with chaincode and peer endorsement. Lets keep it simple - 2 orgs, 2 peers each. Or endorsement policy - Org1 or Org 2. Channel between orgs, all peers endorse.
It goes something like this:
We try to install and instantiate new chaincode at a specific version - say 1.0 on the mutual channel.
It fails due to the timeout issue i listed about 7 posts up.
We restart the peer that it fails on and reinstall same chaincode at a different version - say 1.01 or something. No changes, just a restart. All storage is outside of the containers in NFS.
This reports that it went in just fine.
But there's a problem.
Now the proposal responses from the two peers in the org - org1 say - are coming back inconsistent. They both come back with an OK return code, but the payload differs slightly. Which means the Tx won't commit.
1. Why?
2. Nothing - and I mean nothing, from installing chaincode again to bouncing the whole network to deleting the ledger and couched storage for this peer fixes it. Is there something we can do that we missed?
We've hit this twice now. Twice we had to reconstitute the entire network.
yacovm (Fri, 22 Mar 2019 19:15:56 GMT):
you are missing the most important information part... what fabric version?
aatkddny (Fri, 22 Mar 2019 19:16:01 GMT):
1.2.0
aatkddny (Fri, 22 Mar 2019 19:16:16 GMT):
Can't move to 1.4 until BMX does same.
yacovm (Fri, 22 Mar 2019 19:17:24 GMT):
so about the chaincode not instantiating
yacovm (Fri, 22 Mar 2019 19:17:43 GMT):
https://github.com/hyperledger/fabric/blob/release-1.4/sampleconfig/core.yaml#L420
yacovm (Fri, 22 Mar 2019 19:17:47 GMT):
put this to true and try again
aatkddny (Fri, 22 Mar 2019 19:20:08 GMT):
I guess that'll resolve to `CORE_PEER_VM_ATTACHSTDOUT`?
I just spent two hours reconstituting this thing so I'm not doing it now. I'll do it if it fails again - right now we have someone replaying Tx through it to reconstitute.
yacovm (Fri, 22 Mar 2019 19:20:16 GMT):
yes. and - and you can't install a chaincode with different version
yacovm (Fri, 22 Mar 2019 19:20:19 GMT):
it should not work
yacovm (Fri, 22 Mar 2019 19:20:32 GMT):
the chaincode version has to match the one instantiated
aatkddny (Fri, 22 Mar 2019 19:20:40 GMT):
I can do an upgrade, no?
yacovm (Fri, 22 Mar 2019 19:20:50 GMT):
but did you?
aatkddny (Fri, 22 Mar 2019 19:21:01 GMT):
Yes. You have to.
yacovm (Fri, 22 Mar 2019 19:21:17 GMT):
i know, i thought you perhaps did not
aatkddny (Fri, 22 Mar 2019 19:21:21 GMT):
As you said it doesn't allow you to install over the top.
yacovm (Fri, 22 Mar 2019 19:21:28 GMT):
ok
yacovm (Fri, 22 Mar 2019 19:21:54 GMT):
so after the upgrade do both peers have the 1.0.1 version?
aatkddny (Fri, 22 Mar 2019 19:22:09 GMT):
Yes.
yacovm (Fri, 22 Mar 2019 19:22:23 GMT):
hmm and they are inconsistent... weird, but you can look what is different no?
yacovm (Fri, 22 Mar 2019 19:22:26 GMT):
compare the results
aatkddny (Fri, 22 Mar 2019 19:23:00 GMT):
4 extra bytes of 0x0 on the end
aatkddny (Fri, 22 Mar 2019 19:23:08 GMT):
Otherwise identical.
yacovm (Fri, 22 Mar 2019 19:23:16 GMT):
oh... hmmm... interesting. do you know in what field?
aatkddny (Fri, 22 Mar 2019 19:23:32 GMT):
No it's a byte array at that point.
yacovm (Fri, 22 Mar 2019 19:23:52 GMT):
it's a proposal response protobuf message no?
yacovm (Fri, 22 Mar 2019 19:24:02 GMT):
so you can unmarshal it recursively
aatkddny (Fri, 22 Mar 2019 19:26:23 GMT):
By time I get to it it's where it fails in the SDK. I could intercept when I get the proposal response, but I don't have a sample right now.
yacovm (Fri, 22 Mar 2019 19:26:46 GMT):
yeah you can also do that too
aatkddny (Fri, 22 Mar 2019 19:28:27 GMT):
What exactly should I be looking for - assuming this repeats?
yacovm (Fri, 22 Mar 2019 19:35:07 GMT):
name of the field that adds these zeros
aatkddny (Sun, 24 Mar 2019 03:01:57 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=ythiZF4dvSiHih2wu) @yacovm So as I said, I'm restricted as to where I get access to these things.
aatkddny (Sun, 24 Mar 2019 03:01:57 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=ythiZF4dvSiHih2wu) @yacovm So as I said, I'm restricted as to where I get access to these things.
My best intercept point gives me something like this when I get the responses back, before I submit them to the SDK to go to the orderer:
```
2019-03-23 22:53:36.082 INFO 18890 --- [nio-8095-exec-2] c.m.fabric.processor.ChaincodeProcessor : ProposalResponseField: protos.ProposalResponse.version Value: 1
2019-03-23 22:53:36.082 INFO 18890 --- [nio-8095-exec-2] c.m.fabric.processor.ChaincodeProcessor : ProposalResponseField: protos.ProposalResponse.response Value: status: 200
payload: "\n\005asset\022\0041.01\032\004escc\"\004vscc*<\022\022\022\020\b\001\022\f\022\n\b\001\022\002\b\000\022\002\b\001\032\021\022\017\n\rMyChangedOrgsMSP\032\023\022\021\n\rMyChangedOrgsMSP\020\0012D\n \332\315\265\277\270\214?\253\226;R\335\n\346I\360iKosR\213\201\313\217\210\225\214\275\034\311\233\022 X@\t\"\354E\344\256\242\250\375y\372J\373G\332\221\321\351\361\021\216\275r\350f\312\310\251\320.: \335\017\377\254\216\241\r\324S\366\353k\340\215\231\310\323\324o\344\240d\302l\333Gu\031\212S\310\nB\037\022\b\022\006\b\001\022\002\b\000\032\023\022\021\n\rMyChangedOrgsMSP\020\001"
```
Is that sufficient to tell what's messing it up or is there a way - which I can't readily see in the SDK code - to further break down the payload?
This one is on my local instance and it worked, I'm asking to make sure if this happens again I capture enough detail to figure out what's going wrong.
yacovm (Sun, 24 Mar 2019 08:01:08 GMT):
@aatkddny no it's not enough... if you want you can just capture both outputs to files and send them to me and i can look whenever i have time
yanli133 (Mon, 25 Mar 2019 06:56:12 GMT):
Has joined the channel.
gravity (Tue, 26 Mar 2019 20:10:09 GMT):
Hi all. I have a question regarding the `validatorPoolSize` property for peers: should I override this property? if yes, what is a recommended value for it?
gravity (Wed, 27 Mar 2019 09:18:26 GMT):
hello @yacovm
is there any guide on how to enable parallel `vscc` for a single channel? does parallel `vscc` depend on the value of `validatorPoolSize`?
in my case, every peer has single vCPU and according to the documentation, `validatorPoolSize` will be `1`, right?
thanks in advance
yacovm (Wed, 27 Mar 2019 09:40:01 GMT):
it's always parallel
yacovm (Wed, 27 Mar 2019 09:40:29 GMT):
why do you only have a single CPU in a peer?
yacovm (Wed, 27 Mar 2019 09:40:33 GMT):
that's very low
gravity (Wed, 27 Mar 2019 10:03:55 GMT):
@yacovm we have low resources on a dev environment and currently I'm updating the environment for peers and adding more resources for them
and there is one more question: according to this report https://arxiv.org/pdf/1805.11390.pdf peers serve requests for several channels. is it recommended to have shared peers (for example 6 peers that are joined to 4 channels and serve requests for 4 channels) or have isolated peers (for example we have 8 peers, two peers per channel)?
adamhardie (Thu, 28 Mar 2019 11:26:39 GMT):
hi channel, I have attempted to deploy an updated config to a channel but received an failed response back from the orderer 2 days ago.
Now when I try to connect a new peer i see the following -:
peer channel fetch config config_block.pb -o orderer0.group:7050 -c channelone
2019-03-28 11:23:01.360 UTC [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized
2019-03-28 11:23:01.364 UTC [cli.common] readBlock -> INFO 002 Received block: 8929
2019-03-28 11:23:01.365 UTC [cli.common] readBlock -> INFO 003 Got status: &{NOT_FOUND}
Error: can't read the block: &{NOT_FOUND}
adamhardie (Thu, 28 Mar 2019 11:26:52 GMT):
do i need to remove the channel from the orderer (as it is corrupted) ?
stone-ch (Fri, 29 Mar 2019 03:10:48 GMT):
Has left the channel.
stephenman (Fri, 29 Mar 2019 04:18:40 GMT):
Hi, I have tried to run ./byfn.sh of first-network, it went well, however, right after it finished the right, I go to the cli (Fabric-tools) container, and like to execute "peer chaincode query -C mychannel -n mycc -c '{"Args":["query","a"]}'" again with CORE_PEER_LOCALMSPID, CORE_PEER_TLS_ROOTCERT_FILE, CORE_PEER_ADDRESS, CORE_PEER_MSPCONFIGPATH have been set.
The result has error:
Error: endorsement failure during query. response: status:500 message:"cannot retrieve package for chaincode mycc/1.0, error open /var/hyperledger/production/chaincodes/mycc.1.0: no such file or directory"
Could anyone help? thanks!
jeffgarratt (Fri, 29 Mar 2019 15:05:58 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=8nwYccKpdhDxJLygW) @stephenman looks like the "install" needs to be performed and verified, or you need to verify you are supplying the correct name and version for chaincode.
smallant (Fri, 29 Mar 2019 15:18:13 GMT):
Hi to everyone
smallant (Fri, 29 Mar 2019 15:18:21 GMT):
Currently have a small network in one machine. We were doing some tests and got this error:
GET_STATE failed: transaction ID: 6d7fac50d4c921a98e604b0c1fe2b7b964b91d00471fe67bf81464de86be99ad: Get http://peer2-org1-CouchDB:5984/BC_lscc/BC?attachments=true: dial tcp: lookup peer2-org1-CouchDB on 127.0.0.11:53: dial udp 127.0.0.11:53: socket: too many open files.
We are making the calls trough java sdk and the network is 1.4
dave.enyeart (Sun, 31 Mar 2019 02:39:02 GMT):
Sounds like you need to increase the ulimit on your host
dave.enyeart (Sun, 31 Mar 2019 02:39:02 GMT):
@smallant Sounds like you need to increase the ulimit on your host
smallant (Sun, 31 Mar 2019 17:40:06 GMT):
@dave.enyeart I have the unlimited on the AWS VM when i do ulimit
stephenman (Mon, 01 Apr 2019 06:17:03 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=3uKELuZKssonWfhSc) @jeffgarratt Thank you Jeff! Will have a check on it, thanks for the advice!
klkumar369 (Tue, 02 Apr 2019 18:39:01 GMT):
Has joined the channel.
luckforzhang (Wed, 03 Apr 2019 01:04:14 GMT):
Has joined the channel.
luckforzhang (Wed, 03 Apr 2019 01:09:11 GMT):
Hi team, when I am using node SDK to updateChannel, I have got error like this : ` result: { status: 'BAD_REQUEST',
info: 'error authorizing update: unexpected EOF' } `
is there anything I can refer to? I have followed the test in `fabric-samples/fabric-sdk-node/test/integration/configtxlator.js` , nearlly the same, but it won't work at the last step 'client.updateChannel(request)', I have got the data used to update, and the signatures of OrdererAdmin, Org1Admin. I am using the `fabric-samples/basic-network` to test and no TLS
```
2019-04-02 08:48:25.787 UTC [grpc] infof -> DEBU 4cf transport: loopyWriter.run returning. connection error: desc = "transport is closing"
2019-04-02 08:50:53.282 UTC [orderer.common.server] Broadcast -> DEBU 4d0 Starting new Broadcast handler
2019-04-02 08:50:53.282 UTC [orderer.common.broadcast] Handle -> DEBU 4d1 Starting new broadcast loop for 172.18.0.1:48646
2019-04-02 08:50:53.282 UTC [orderer.common.broadcast] ProcessMessage -> DEBU 4d2 [channel: mychannel] Broadcast is processing config update message from 172.18.0.1:48646
2019-04-02 08:50:53.282 UTC [orderer.common.msgprocessor] ProcessConfigUpdateMsg -> DEBU 4d3 Processing config update message for channel mychannel
2019-04-02 08:50:53.282 UTC [policies] Evaluate -> DEBU 4d4 == Evaluating *policies.implicitMetaPolicy Policy /Channel/Writers ==
2019-04-02 08:50:53.282 UTC [policies] Evaluate -> DEBU 4d5 This is an implicit meta policy, it will trigger other policy evaluations, whose failures may be benign
2019-04-02 08:50:53.282 UTC [policies] Evaluate -> DEBU 4d6 == Evaluating *policies.implicitMetaPolicy Policy /Channel/Orderer/Writers ==
2019-04-02 08:50:53.282 UTC [policies] Evaluate -> DEBU 4d7 This is an implicit meta policy, it will trigger other policy evaluations, whose failures may be benign
2019-04-02 08:50:53.282 UTC [policies] Evaluate -> DEBU 4d8 == Evaluating *cauthdsl.policy Policy /Channel/Orderer/OrdererOrg/Writers ==
2019-04-02 08:50:53.283 UTC [cauthdsl] func1 -> DEBU 4d9 0xc000b2e5a0 gate 1554195053283007832 evaluation starts
2019-04-02 08:50:53.283 UTC [cauthdsl] func2 -> DEBU 4da 0xc000b2e5a0 signed by 0 principal evaluation starts (used [false])
2019-04-02 08:50:53.283 UTC [cauthdsl] func2 -> DEBU 4db 0xc000b2e5a0 processing identity 0 with bytes of a0af20
2019-04-02 08:50:53.283 UTC [cauthdsl] func2 -> DEBU 4dc 0xc000b2e5a0 principal matched by identity 0
2019-04-02 08:50:53.283 UTC [msp.identity] Verify -> DEBU 4dd Verify: digest = 00000000 55 4a 07 82 b4 63 54 ac b5 ae 1e a9 ac 3b cb 00 |UJ...cT......;..|
00000010 ca 0d cc b1 06 3c aa 8f d9 d7 f0 8f 2b 17 5e 0b |.....<......+.^.|
2019-04-02 08:50:53.283 UTC [msp.identity] Verify -> DEBU 4de Verify: sig = 00000000 30 44 02 20 70 83 ee 46 ac 0e 83 13 ef 4d bd d7 |0D. p..F.....M..|
00000010 14 5f 33 c6 52 55 39 e5 78 b7 c1 af 75 fb df a6 |._3.RU9.x...u...|
00000020 c5 72 36 06 02 20 0c 51 73 fa 9b 6c c0 5a 29 32 |.r6.. .Qs..l.Z)2|
00000030 29 ac fb ac 9d 6a 70 b7 0e 22 86 60 d1 2b 0e 3c |)....jp..".`.+.<|
00000040 50 66 ce c1 a3 78 |Pf...x|
2019-04-02 08:50:53.283 UTC [cauthdsl] func2 -> DEBU 4df 0xc000b2e5a0 principal evaluation succeeds for identity 0
2019-04-02 08:50:53.283 UTC [cauthdsl] func1 -> DEBU 4e0 0xc000b2e5a0 gate 1554195053283007832 evaluation succeeds
2019-04-02 08:50:53.283 UTC [policies] Evaluate -> DEBU 4e1 Signature set satisfies policy /Channel/Orderer/OrdererOrg/Writers
2019-04-02 08:50:53.283 UTC [policies] Evaluate -> DEBU 4e2 == Done Evaluating *cauthdsl.policy Policy /Channel/Orderer/OrdererOrg/Writers
2019-04-02 08:50:53.283 UTC [policies] Evaluate -> DEBU 4e3 Signature set satisfies policy /Channel/Orderer/Writers
2019-04-02 08:50:53.283 UTC [policies] Evaluate -> DEBU 4e4 == Done Evaluating *policies.implicitMetaPolicy Policy /Channel/Orderer/Writers
2019-04-02 08:50:53.283 UTC [policies] Evaluate -> DEBU 4e5 Signature set satisfies policy /Channel/Writers
2019-04-02 08:50:53.283 UTC [policies] Evaluate -> DEBU 4e6 == Done Evaluating *policies.implicitMetaPolicy Policy /Channel/Writers
2019-04-02 08:50:53.283 UTC [orderer.common.broadcast] ProcessMessage -> WARN 4e7 [channel: mychannel] Rejecting broadcast of config message from 172.18.0.1:48646 because of error: error authorizing update: unexpected EOF
```
And here is the debug infos from orderer
Not so sure if this infomation is too much, sorry...
gravity (Wed, 03 Apr 2019 10:40:27 GMT):
Hi all
what resources should be allocated for kafka and orderer nodes for not being a bottleneck if we speak about performance?
Because in our app we've run 4 peers (every node has 16 GB RAM, 8 vCPU). commit time and validateTx time take from 5 to 20 ms in average so that means that peers are doing well, but performance is poor
if I set (in JMeter) constant throughput timer to 300 TPS and 100 threads, the actual TPS is ~50-60. and after 3-5 minutes, transactions start failing
gravity (Wed, 03 Apr 2019 10:41:26 GMT):
Block timeout in this case is 1s and max-message-count had different values (5, 10, 30, 50, 100). the best performance was when the max-message-count was 5
adamhardie (Thu, 04 Apr 2019 14:19:09 GMT):
getting a weird issue when loading a chaincode in one environment
`2019-04-04 14:17:07.879 UTC [container] lockContainer -> DEBU 43f waiting for container(ccode-1.0) lock
2019-04-04 14:17:07.880 UTC [container] lockContainer -> DEBU 440 got container (ccode-1.0) lock
2019-04-04 14:17:07.880 UTC [dockercontroller] stopInternal -> DEBU 441 stopping container id=dev-peer0.testing-ccode-1.0
2019-04-04 14:17:07.881 UTC [dockercontroller] stopInternal -> DEBU 442 stop container result error="Container not running: dev-peer0.testing-ccode-1.0"
2019-04-04 14:17:07.882 UTC [dockercontroller] stopInternal -> DEBU 443 killing container id=dev-peer0.testing-ccode-1.0
2019-04-04 14:17:07.883 UTC [dockercontroller] stopInternal -> DEBU 444 kill container result id=dev-peer0.testing-ccode-1.0 error="Container not running: dev-peer0.testing-ccode-1.0"
2019-04-04 14:17:07.883 UTC [dockercontroller] stopInternal -> DEBU 445 removing container id=dev-peer0.testing-ccode-1.0
2019-04-04 14:17:07.891 UTC [dockercontroller] stopInternal -> DEBU 446 remove container result id=dev-peer0.testing-ccode-1.0 error=null
2019-04-04 14:17:07.891 UTC [container] unlockContainer -> DEBU 447 container lock deleted(ccode-1.0)
2019-04-04 14:17:07.892 UTC [chaincode] Launch -> DEBU 448 launch complete
2019-04-04 14:17:07.892 UTC [chaincode] Deregister -> DEBU 449 deregister handler: ccode:1.0
2019-04-04 14:17:07.892 UTC [endorser] callChaincode -> INFO 44a [messagebus][586adf37] Exit chaincode: name:"lscc" (31286ms)
2019-04-04 14:17:07.892 UTC [endorser] SimulateProposal -> ERRO 44b [messagebus][586adf37] failed to invoke chaincode name:"lscc" , error: container exited with 0
github.com/hyperledger/fabric/core/chaincode.(*RuntimeLauncher).Launch.func1
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/runtime_launcher.go:63
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:1333
chaincode registration failed`
gravity (Mon, 08 Apr 2019 12:43:00 GMT):
hi @yacovm
could you please explain how to set kafka version for orderer correctly?
because it is not very clear from the documentation.
in our case fabric version is 1.4.0. is this `ORDERER_KAFKA_VERSION: 1.0.0` property correct?
thanks in advance
yacovm (Mon, 08 Apr 2019 12:54:39 GMT):
you can put any kafka version you want....
yacovm (Mon, 08 Apr 2019 12:54:43 GMT):
doesn't depend on the fabric version
yacovm (Mon, 08 Apr 2019 12:55:11 GMT):
what the kafka version in the `orderer.yaml` does is simply pass it to the kafka client library
gravity (Mon, 08 Apr 2019 12:57:02 GMT):
I see
thanks
gravity (Mon, 08 Apr 2019 12:58:24 GMT):
@yacovm
initially I thought that this version might be somehow connected to these warning that orderers spam after the network restart
```
2019-04-08 12:29:54.487 UTC [common.deliver] deliverBlocks -> WARN 627 [channel: channel01554211419025] Rejecting deliver request for 10.150.101.64:52322 because of consenter error
```
yacovm (Mon, 08 Apr 2019 13:10:33 GMT):
no no
yacovm (Mon, 08 Apr 2019 13:10:53 GMT):
it is only related because you probably can't connect to kafka
yacovm (Mon, 08 Apr 2019 13:10:57 GMT):
because of a wrong version
gravity (Mon, 08 Apr 2019 13:18:32 GMT):
@yacovm wrong version of kafka passed to the client library? how to know which version should be passed?
yacovm (Mon, 08 Apr 2019 13:20:18 GMT):
you check the kafka version....
yacovm (Mon, 08 Apr 2019 13:20:28 GMT):
you do know the version of kafka you use, right?
yacovm (Mon, 08 Apr 2019 13:20:39 GMT):
but honestly Raft is out... why not use it instead of Kafka? :)
yacovm (Mon, 08 Apr 2019 13:20:43 GMT):
give it a try ;)
gravity (Mon, 08 Apr 2019 15:36:08 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=NQ4RDfWR58Z4CaWAo) @yacovm as I can see 1.4.1 is not released yet, the latest version is v1.4.1-rc1
gravity (Mon, 08 Apr 2019 15:36:08 GMT):
@yacovm as I can see 1.4.1 is not released yet, the latest version is v1.4.1-rc1
gravity (Mon, 08 Apr 2019 15:36:08 GMT):
@yacovm as I can see 1.4.1 is not released yet, the latest version is v1.4.1-rc1
gravity (Mon, 08 Apr 2019 15:36:08 GMT):
@yacovm as I can see 1.4.1 is not released yet, the latest version is v1.4.1-rc1
gravity (Mon, 08 Apr 2019 19:26:06 GMT):
@yacovm we cannot try raft right now because we are going to production in a few days. and there is a question: will ut be possible to migrate all the data from kafka to raft?
yacovm (Mon, 08 Apr 2019 20:58:19 GMT):
@gravity eventually yes, but it will take downtime
yacovm (Mon, 08 Apr 2019 20:58:29 GMT):
i really suggest to you to just start use Raft
yacovm (Mon, 08 Apr 2019 20:58:36 GMT):
and not Kafka
yacovm (Mon, 08 Apr 2019 20:58:52 GMT):
i think it's very stable :)
gravity (Tue, 09 Apr 2019 08:05:33 GMT):
@yacovm does raft have better performance compared to kafka?
also, as I see in the documentation, it works only when TLS is enabled, doesn't it?
stephenman (Tue, 09 Apr 2019 09:28:49 GMT):
Hi all, I have replaced my certs for admin and peer, and then tried to create channel, however, it throws error as below:
** Error: got unexpected status: BAD_REQUEST -- error authorizing update: error validating DeltaSet: policy for [Group] /Channel/Application not satisfied: Failed to reach implicit threshold of 1 sub-policies, required 1 remaining **
can anyone give a hand? Thanks!
stephenman (Tue, 09 Apr 2019 09:28:49 GMT):
Hi all, I have replaced my certs for admin and peer, while creating channel, it throws error in orderer as below:
2019-04-12 02:46:06.798 UTC [orderer.common.broadcast] ProcessMessage -> WARN 011 [channel: mychannel] Rejecting broadcast of config message from 10.0.0.196:38572 because of error: Failed to reach implicit threshold of 1 sub-policies, required 1 remaining: permission denied
2019-04-12 02:46:06.798 UTC [comm.grpc.server] 1 -> INFO 012 streaming call completed {"grpc.start_time": "2019-04-12T02:46:06.796Z", "grpc.service": "orderer.AtomicBroadcast", "grpc.method": "Broadcast", "grpc.peer_address": "10.0.0.196:38572", "grpc.code": "OK", "grpc.call_duration": "2.107804ms"}
2019-04-12 02:46:06.801 UTC [common.deliver] Handle -> WARN 013 Error reading from 10.0.0.196:38570: rpc error: code = Canceled desc = context canceled
2019-04-12 02:46:06.801 UTC [comm.grpc.server] 1 -> INFO 014 streaming call completed {"grpc.start_time": "2019-04-12T02:46:06.794Z", "grpc.service": "orderer.AtomicBroadcast", "grpc.method": "Deliver", "grpc.peer_address": "10.0.0.196:38570", "error": "rpc error: code = Canceled desc = context canceled", "grpc.code": "Canceled", "grpc.call_duration": "7.115516ms"}
can anyone help? Thanks!
yacovm (Tue, 09 Apr 2019 10:04:33 GMT):
@gravity I am not sure about the performance, we are currently evaluating that
yacovm (Tue, 09 Apr 2019 10:04:41 GMT):
and yeah it only works wit TLS
gravity (Tue, 09 Apr 2019 13:22:13 GMT):
@yacovm understood, thanks
adamhardie (Tue, 09 Apr 2019 13:25:17 GMT):
my java program is currently experiencing timeouts for some transactions. the process is this...
1) send transaction proposal to 1 peer
2) receive valid response
3) send signed response to orderer
4) receive acknowledgement of send
5) await 5 seconds for Deliver Response
6) timeout
adamhardie (Tue, 09 Apr 2019 13:25:39 GMT):
what may cause the failure of a deliver response. I can see the block is created successfully
kariyappal (Wed, 10 Apr 2019 12:27:47 GMT):
Has joined the channel.
kariyappal (Wed, 10 Apr 2019 12:27:58 GMT):
Does anyone know why fabric-ca-peer image is discontinued from 1.4 version
braduf (Wed, 10 Apr 2019 20:46:26 GMT):
I am not able to instantiate chaincode and I think the problem is not with the chaincode itself, but with the peer.
The error I get from the chaincode container before it is stopped and removed is:
```
Error creating new Smart Contract: error trying to connect to local peer
```runs on a AWS EC-2 machine in
braduf (Wed, 10 Apr 2019 20:46:26 GMT):
I am not able to instantiate chaincode and I think the problem is not with the chaincode itself, but with the peer.
The error I get from the chaincode container before it is stopped and removed is:
```
Error creating new Smart Contract: error trying to connect to local peer
```
My peer is a container running a fabric-peer image on an AWS EC2 machine with TLS enabled. The CouchDB for the world state is running on the same EC2 machine and there seems to be no problems between the peer and the CouchDB. But it seems between the chaincode containers and the peer there is a connection problem, but I can't figure out what it is...
stephenman (Fri, 12 Apr 2019 02:52:42 GMT):
Hi all, I have replaced my certs for admin and a peer, and now while creating channel, it throws error as below, could anyone help? Thanks!
2019-04-12 02:46:06.798 UTC [orderer.common.broadcast] ProcessMessage -> WARN 011 [channel: mychannel] Rejecting broadcast of config message from 10.0.0.196:38572 because of error: Failed to reach implicit threshold of 1 sub-policies, required 1 remaining: permission denied
2019-04-12 02:46:06.798 UTC [comm.grpc.server] 1 -> INFO 012 streaming call completed {"grpc.start_time": "2019-04-12T02:46:06.796Z", "grpc.service": "orderer.AtomicBroadcast", "grpc.method": "Broadcast", "grpc.peer_address": "10.0.0.196:38572", "grpc.code": "OK", "grpc.call_duration": "2.107804ms"}
2019-04-12 02:46:06.801 UTC [common.deliver] Handle -> WARN 013 Error reading from 10.0.0.196:38570: rpc error: code = Canceled desc = context canceled
2019-04-12 02:46:06.801 UTC [comm.grpc.server] 1 -> INFO 014 streaming call completed {"grpc.start_time": "2019-04-12T02:46:06.794Z", "grpc.service": "orderer.AtomicBroadcast", "grpc.method": "Deliver", "grpc.peer_address": "10.0.0.196:38570", "error": "rpc error: code = Canceled desc = context canceled", "grpc.code": "Canceled", "grpc.call_duration": "7.115516ms"}
gravity (Fri, 12 Apr 2019 13:25:31 GMT):
hi all
is it correct to assume that only endorser peers will have `/var/hyperledger/production/ledgersData/stateLeveldb` growing only if peer is an endorser peer?
qsmen (Fri, 19 Apr 2019 05:47:19 GMT):
experts here, Would you please tell me how to obtain an org's root certificate in application chaincde? I know if it is possible because system chaincodes need root certificate to verify the correctness of certificates. Thank you
rahulhegde (Sun, 21 Apr 2019 22:03:43 GMT):
hello, Q: During a single endorsement request processing by chaincode, if there is sequence of Shim GetState -> PutState -> GetState, will the 3rd GetState call have the data as 1st GetState (original) or 2nd PutState (modified)?
yacovm (Sun, 21 Apr 2019 22:20:07 GMT):
@rahulhegde you don't read your own writes
rahulhegde (Mon, 22 Apr 2019 00:35:13 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=pq7QXHti9uut3BQrr) @yacovm Thanks - so it is the 1st GetState (original) value stored in the ledger irrespective of PutState or DeleteState called on the same key in the same endorsement request.
KartikChauhan (Mon, 22 Apr 2019 08:59:43 GMT):
Has joined the channel.
KartikChauhan (Mon, 22 Apr 2019 08:59:58 GMT):
When a transaction's r/w set is sent to committing peers, how do peers perform MVCC verification? Do they check if the values from read set and current values in state db are equal or not or do they verify by any unique id? If they check from the read set, what happens when a transaction's read set is very large?
stephenman (Tue, 23 Apr 2019 07:07:03 GMT):
Hi all, I'm trying to use node SDK to query chaincode, however, it throws the error: *[Remote.js]: Error: Failed to connect before the deadline URL:grpcs://localhost:7051*
But I execute a script to query chaincode successfully, could anyone help? Thanks!!
stephenman (Thu, 25 Apr 2019 09:43:51 GMT):
Hi all, could you advise what the below error is?
* instantiate proposal resulted in an error :: Error: 2 UNKNOWN: access denied: channel [mychannel] creator org [Org1MSP] *
stephenman (Thu, 25 Apr 2019 09:44:17 GMT):
I'm trying to instantiate chaincode by SDK
KartikChauhan (Thu, 25 Apr 2019 12:52:53 GMT):
I'm trying to get status of a transaction by using node.js sdk. I know about `queryTransaction` method which returns the transaction data and in it, I can find transaction response. But its limitation is that it only returns response `200` if the transaction gets succeeded or _Failed to get transaction_ message if the transaction is invalid or hasn't mined yet.
`queryTransaction` method queries ledger data present on the peers and then gives a binary response. But what if I want to know a transaction is in process or not? How can I get the response _pending_ if a transaction id is valid but hasn't mined yet?
I found this stackoverflow question https://stackoverflow.com/questions/51163023/hyperledger-transaction-mempool which is somewhat related to my question. Is it even possible to do that in Hyperledger Fabric or not?
sejalpawar (Sun, 28 Apr 2019 10:24:04 GMT):
Has joined the channel.
sejalpawar (Sun, 28 Apr 2019 10:24:36 GMT):
Hey there, chaincode dev peers show exited status after trying to invoke the very first transaction:
sejalpawar (Sun, 28 Apr 2019 10:25:03 GMT):
UTC [chaincode] ProcessStream -> ERRO 172 handling chaincode support stream: rpc error: code = Canceled desc = context canceled
receive failed
github.com/hyperledger/fabric/core/chaincode.(*Handler).ProcessStream
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:427
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).HandleChaincodeStream
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:190
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Register
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:195
github.com/hyperledger/fabric/core/chaincode/accesscontrol.(*interceptor).Register
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/accesscontrol/interceptor.go:57
github.com/hyperledger/fabric/protos/peer._ChaincodeSupport_Register_Handler
/opt/gopath/src/github.com/hyperledger/fabric/protos/peer/chaincode_shim.pb.go:1066
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).processStreamingRPC
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:1124
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).handleStream
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:1212
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:686
runtime.goexit
sejalpawar (Sun, 28 Apr 2019 10:25:18 GMT):
Any solution for this issue?
AshishMishra 1 (Tue, 30 Apr 2019 06:10:25 GMT):
Hi experts, I have setup a fabric cluster on kubernetes using helm charts. I could join the peers to a channel and install chaincode on it. However when I 'm instantiating the chaincode, I am not getting any error the chaincode container also starts successfully on the peer node but it's not registering himself with the peer container somehow. So when I do peer chaincode list --instantiated -C mychannel... I don't see anything. Am I missing some env here?
Shivi (Thu, 02 May 2019 12:05:56 GMT):
Has joined the channel.
tongli (Wed, 08 May 2019 16:05:42 GMT):
@AshishMishra 1 seems that the chaincode container can not find way back.
tongli (Wed, 08 May 2019 16:05:42 GMT):
@AshishMishra 1 seems that the chaincode container can not find way back to the peer.
tongli (Wed, 08 May 2019 16:06:28 GMT):
not sure how you set things up, but you have to make sure that peer and chaincode containers can reach each other,
tongli (Wed, 08 May 2019 16:07:09 GMT):
check your dns entries and see if you can ping from one to another.
AshishMishra 1 (Tue, 14 May 2019 09:39:42 GMT):
@tongli thanks. The DNS and networking was fine between the containers. It was a configtx issue with incorrect orderer endpoint.
andkononykhin (Wed, 15 May 2019 08:44:22 GMT):
Has left the channel.
sejalpawar (Fri, 17 May 2019 09:27:59 GMT):
Has left the channel.
hfr1994 (Mon, 20 May 2019 01:38:15 GMT):
Has joined the channel.
hfr1994 (Mon, 20 May 2019 01:38:17 GMT):
Hi experts, we have two identical peers mounted on a Kubernets env. The only thing that differ between both peers are certificates. When we try to invoke a transaction on peer1 we get the following errror: Error: endorsement failure during invoke. chaincode result:
smallant (Tue, 21 May 2019 12:23:31 GMT):
hi to all,
I'm using the java sdk to connect to my network and i received a peculiar error:
May 20, 2019 @ 15:34:01.216 peer1 [33m2019-05-20 13:34:01.216 UTC [valimpl] preprocessProtoBlock -> WARN 0ed[0m Channel [mychannel]: Block [13] Transaction index [0] TxId [6adad972827e6296f14a6bcca79855ada25f2ccd0403980383155bf9dac7c95] marked as invalid by committer. Reason code [DUPLICATE_TXID]
How can this happen??
PS: I'm using the txID as a key when I store my data
SashaPESIC (Wed, 22 May 2019 14:43:26 GMT):
Has joined the channel.
risc (Mon, 03 Jun 2019 13:36:54 GMT):
Has joined the channel.
risc (Mon, 03 Jun 2019 13:36:55 GMT):
Guys l have a little issue with CC endorsement. Every time that we add a new organisation to the network we need to reinstall and reinstantiate the CC, in order to accept new transactions .
We are instantiating with NO endorsement policy . As far as documentation says it should by Any Org can endorse. But looks that it just is true for Orgs already in the network and not new ones. So anyone knows what policy should we use? Can use meta policy’s? Such a Any Members?
knagware9 (Thu, 06 Jun 2019 07:38:12 GMT):
you can try service discovery , it will help to find endorsment policy of the network and send the transanctions to the endorser
smallant (Thu, 06 Jun 2019 09:07:29 GMT):
Any ideias on why this happens?
root10 (Thu, 06 Jun 2019 14:12:01 GMT):
Has joined the channel.
root10 (Thu, 06 Jun 2019 14:12:02 GMT):
Hi guys. I have a problem invoking chaincode. I'm running a lot of insert using goroutine. I've tried with 10.000 without problem, but if I try 25.000, some requests are lost giving me back this error:
[fabsdk/fab] 2019/06/06 13:29:47 UTC - peer.(*peerEndorser).sendProposal -> ERRO process proposal failed [rpc error: code = DeadlineExceeded desc = context deadline exceeded]
[fabsdk/util] 2019/06/06 13:29:47 UTC - lazyref.(*Reference).refreshValue -> WARN Error - initializer returned error: QueryBlockConfig failed: queryChaincode failed: Transaction processing for endorser [localhost:7051]: gRPC Transport Status Code: (4) DeadlineExceeded. Description: context deadline exceeded. Will retry again later
This is block configuration:
```yaml
Orderer: &OrdererDefaults
OrdererType: solo
BatchTimeout: 2s
BatchSize:
MaxMessageCount: 100
AbsoluteMaxBytes: 99 MB
PreferredMaxBytes: 512 KB
```
Have I to configure the network in a different way? Thanks
root10 (Thu, 06 Jun 2019 14:16:22 GMT):
This are some errors in peer log:
```bash
2019-06-06 13:27:52.711 UTC [chaincode] HandleTransaction -> ERRO 28e8e [5803343e] Failed to handle PUT_STATE. error: no ledger context
github.com/hyperledger/fabric/core/chaincode.(*Handler).isValidTxSim
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:545
github.com/hyperledger/fabric/core/chaincode.(*Handler).HandleTransaction
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:259
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:1333
PUT_STATE failed: transaction ID: 5803343ead5d8c64f26a3a98f08cd214c47236c5c23cf9be69d562e2cd477431
github.com/hyperledger/fabric/core/chaincode.(*Handler).HandleTransaction
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:276
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:1333
```
```bash
2019-06-06 13:25:34.840 UTC [chaincode] HandleTransaction -> ERRO 24328 [7e618958] Failed to handle GET_STATE. error: no ledger context
github.com/hyperledger/fabric/core/chaincode.(*Handler).isValidTxSim
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:545
github.com/hyperledger/fabric/core/chaincode.(*Handler).HandleTransaction
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:259
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:1333
GET_STATE failed: transaction ID: 7e6189587bb77a72ab9e911402de1a46f0b2653e00280072ed2719a0b43a6c48
github.com/hyperledger/fabric/core/chaincode.(*Handler).HandleTransaction
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:276
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:1333
```
```bash
error sending
failed to execute transaction 56efc78ac84f99c44d79dc43441ff4b2b88434b27775f3f2f003e209a4555592
github.com/hyperledger/fabric/core/chaincode.processChaincodeExecutionResult
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:244
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:239
github.com/hyperledger/fabric/core/endorser.(*SupportImpl).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/support.go:147
github.com/hyperledger/fabric/core/endorser.(*Endorser).callChaincode
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:142
github.com/hyperledger/fabric/core/endorser.(*Endorser).SimulateProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:237
github.com/hyperledger/fabric/core/endorser.(*Endorser).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:456
github.com/hyperledger/fabric/core/handlers/auth/filter.(*expirationCheckFilter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/expiration.go:61
github.com/hyperledger/fabric/core/handlers/auth/filter.(*filter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/filter.go:32
github.com/hyperledger/fabric/protos/peer._Endorser_ProcessProposal_Handler.func1
/opt/gopath/src/github.com/hyperledger/fabric/protos/peer/peer.pb.go:169
github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware.ChainUnaryServer.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware/chain.go:31
github.com/hyperledger/fabric/common/grpclogging.UnaryServerInterceptor.func1
/opt/gopath/src/github.com/hyperledger/fabric/common/grpclogging/server.go:91
github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware.ChainUnaryServer.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware/chain.go:34
github.com/hyperledger/fabric/common/grpcmetrics.UnaryServerInterceptor.func1
/opt/gopath/src/github.com/hyperledger/fabric/common/grpcmetrics/interceptor.go:30
github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware.ChainUnaryServer.func1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/grpc-ecosystem/go-grpc-middleware/chain.go:39
github.com/hyperledger/fabric/protos/peer._Endorser_ProcessProposal_Handler
/opt/gopath/src/github.com/hyperledger/fabric/protos/peer/peer.pb.go:171
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).processUnaryRPC
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:982
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).handleStream
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:1208
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:686
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:1333
```
ShobhitSrivastava (Fri, 14 Jun 2019 10:08:06 GMT):
Hi Kartik, per my knowledge there is no concept of mining in fabric. Create transaction is based on proposal response from the endorsing peers. If all the the response are same then it gets to ordering state and eventually to committer state. For query you can query from your your respective peer. If you want to check response from all peers then you have to query from all peers.
hanubc7743 (Wed, 19 Jun 2019 19:36:45 GMT):
Has joined the channel.
hanubc7743 (Wed, 19 Jun 2019 19:36:56 GMT):
Hi Can we integrate oracle db instead of couch db in hyperledger fabric?
qizhang (Wed, 19 Jun 2019 20:15:43 GMT):
Hi, is the `BASEIMAGE_RELEASE = 0.4.15` option in `Makefile` under `fabric` used to specify which version of `fabric-baseimage` will be used to compile `fabric-peer` image?
HLFPOC (Thu, 20 Jun 2019 05:20:05 GMT):
Has joined the channel.
raj_shekhar (Thu, 20 Jun 2019 09:00:36 GMT):
Has joined the channel.
aviralwal (Fri, 21 Jun 2019 13:57:12 GMT):
Has joined the channel.
troyronda (Wed, 26 Jun 2019 19:34:45 GMT):
I'm wondering if there is a status update on the cache work (e.g., https://gerrit.hyperledger.org/r/c/fabric/+/31360)... thanks :)
handy (Thu, 27 Jun 2019 08:28:53 GMT):
Has joined the channel.
handy (Thu, 27 Jun 2019 09:08:03 GMT):
Hi, so I have 1 orderer 3 peers (`peer0.org1.com`, `peer1.org1.com`, and `peer0.org2.com`) and I have problem with the endorsement policy. In the `crypto-config.yaml` I enable `EnableNodeOUs: true` for all of the `OrdererOrgs` and `PeerOrgs` member
My chaincode structure is similar with https://github.com/IBM/car-auction-network-fabric-node-sdk/blob/master/chaincode/carauction.js with seperate `Init(stub)` and `initLedger(stub, args)`. After I install the chaincode to all peers, I instantiate my chaincode on `peer0.org1.com` with:
```
peer chaincode instantiate -C $CC_CHANNEL_ID -n $CC_NAME -v $CC_VERSION -c '{"Args":[""]}' -l node -P "AND ('Org1.peer','Org2.peer')"
sleep 5s
peer chaincode invoke -C $CC_CHANNEL_ID -n $CC_NAME -c '{"Args":["initLedger","a","100","b","200"]}'
```
The command run without error:
```
2019-06-27 07:08:22.466 UTC [chaincodeCmd] InitCmdFactory -> INFO 003 Retrieved channel (airline-channel) orderer endpoint: SO.ME.I.P:7050
2019-06-27 07:08:22.471 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 004 Using default escc
2019-06-27 07:08:22.471 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 005 Using default vscc
2019-06-27 07:09:24.359 UTC [chaincodeCmd] InitCmdFactory -> INFO 003 Retrieved channel (airline-channel) orderer endpoint: SO.ME.I.P:7050
2019-06-27 07:09:24.387 UTC [chaincodeCmd] chaincodeInvokeOrQuery -> INFO 004 Chaincode invoke successful. result: status:200 payload:"-\347`z\270\247\212\330\232\226,\336"
```
But when I run `peer chaincode query -C $CC_CHANNEL_ID -n $CC_NAME -c '{"Args":["query","a"]}'` on `peer0.org1.com`, it returns:
```
Error: endorsement failure during query. response: status:500 message:"transaction returned with failure: Error: Failed to get state for a"
```
what cause the endorsement failure?
KartikChauhan (Fri, 28 Jun 2019 19:47:10 GMT):
I'm running a Fabric 1.4.1 network with one peer and one orderer. I'm using Prometheus to monitor them. The targets are up and Prometheus is able to scrape the metrics. But I think I'm not getting all the metrics that are listed on https://hyperledger-fabric.readthedocs.io/en/latest/metrics_reference.html
Plus many of the metrics names look different than the ones mentioned in the list. This probably could be because the documentation is of version 1.4 and I'm running a network of 1.4.1. Just want to confirm if this is the sole reason or if there could be any other reason as well.
KartikChauhan (Mon, 01 Jul 2019 07:18:47 GMT):
Can a newly added organization create its own channel? I know how to add an organization to a running fabric network. But can that organization create a channel of its own?
mfaisaltariq (Tue, 02 Jul 2019 13:20:36 GMT):
Has joined the channel.
seokm0 (Tue, 02 Jul 2019 23:14:43 GMT):
Has joined the channel.
sstone1 (Wed, 03 Jul 2019 16:16:58 GMT):
@KartikChauhan if the new organization is added into the ordering service configuration (not just the configuration of an existing channel), then that new organization can also create channels
KartikChauhan (Wed, 03 Jul 2019 16:32:29 GMT):
Can we do that without stopping and restarting our orderer?
sstone1 (Wed, 03 Jul 2019 16:33:29 GMT):
yes - you need to edit the config of the orderer system channel (badly named testchainid in v1.4)
KartikChauhan (Wed, 03 Jul 2019 16:37:06 GMT):
But what profile will I provide during channel creation?
aatkddny (Thu, 11 Jul 2019 00:34:03 GMT):
There are two things you need to do.
I'm going to answer the second one because I think that's the question you are asking here.
The first is to add the new org into the system channel. There's instructions on how to do that all over the place, but the trick is to use the crypto from an orderer to sign the channel update.
The second is the same as creating a channel when you initialize the network - you need to create a profile insane ide a configtx.yaml file and then run configtxgen to create a channel genesis block (and possibly anchor peer updates).
configtxgen doesn't seem to mind too much if you append channel profiles to configtx.yaml and rerun it - we do it all the time.
If the org is new iirc you need to also add the org definition into the `Organizations` piece of configtx.yaml too. I'm being vague because I automated it all and I don't feel like tracing through the code.
aatkddny (Thu, 11 Jul 2019 00:34:03 GMT):
There are two things you need to do.
I'm going to answer the second one because I think that's the question you are asking here.
The first is to add the new org into the system channel. There's instructions on how to do that all over the place, but the trick is to use the crypto from an orderer to sign the channel update.
The second is the same as creating a channel when you initialize the network - you need to create a profile inside a configtx.yaml file and then run configtxgen to create a channel genesis block (and possibly anchor peer updates).
configtxgen doesn't seem to mind too much if you append channel profiles to configtx.yaml and rerun it - we do it all the time.
If the org is new iirc you need to also add the org definition into the `Organizations` piece of configtx.yaml too. I'm being vague because I automated it all and I don't feel like tracing through the code.
soumyanayak (Thu, 11 Jul 2019 12:11:50 GMT):
Has joined the channel.
soumyanayak (Thu, 11 Jul 2019 12:13:50 GMT):
Hi All,
How to increase the timeout period when trying the query on the peer from node SDK . I was trying to query and its getting timeout in 20-25 seconds.
Regards,
Soumya
krabradosty (Thu, 11 Jul 2019 16:23:16 GMT):
Hello. Sometimes peers just freeze and doesn't react on any interaction (send proposal, subscribe to channel blocks). Only restart on container helps. Here you can find logs output of one of the peer: https://pastebin.com/e4uC5cB2. Other peers work fine. Grps error message continue to emerge infinitely until I restart container:
```
streaming call completed grpc.service=protos.Deliver grpc.method=DeliverFiltered grpc.peer_address=172.19.0.1:43574 error="context canceled" grpc.code=Unknown grpc.call_duration=44.945012168s
```
krabradosty (Thu, 11 Jul 2019 16:23:16 GMT):
Hello. Sometimes peers just freeze and doesn't react on any interaction (send proposal, subscribe to channel blocks). Only restart on container helps. Here you can find logs output of one of the peer: https://pastebin.com/e4uC5cB2. Other peers work fine. Grps error message continue to emerge infinitely until I restart container:
```
streaming call completed grpc.service=protos.Deliver grpc.method=DeliverFiltered grpc.peer_address=172.19.0.1:43574 error="context canceled" grpc.code=Unknown grpc.call_duration=44.945012168s
```
What can cause this problem?
krabradosty (Thu, 11 Jul 2019 16:23:16 GMT):
Hello. Sometimes peers just freeze and doesn't react on any interaction (send proposal, subscribe to channel blocks). Only restart of container helps. Here you can find logs output of one of the peer: https://pastebin.com/e4uC5cB2. Other peers work fine. Grpc error message continue to emerge infinitely until I restart container:
```
streaming call completed grpc.service=protos.Deliver grpc.method=DeliverFiltered grpc.peer_address=172.19.0.1:43574 error="context canceled" grpc.code=Unknown grpc.call_duration=44.945012168s
```
What can cause this problem?
Utsav_Solanki (Mon, 15 Jul 2019 06:19:15 GMT):
Has joined the channel.
Utsav_Solanki (Mon, 15 Jul 2019 06:19:17 GMT):
UTC [gossip.comm] createConnection -> WARN 15effc Remote endpoint claims to be a different peer, expected fsdfdsfdfdfgdgfsdgfdsg but got fdsfdsgfdgfdfsdfs
Utsav_Solanki (Mon, 15 Jul 2019 06:22:13 GMT):
hello, i found this warninig in HLF fabric peer0 docker logs [UTC [gossip.comm] createConnection -> WARN 15effc Remote endpoint claims to be a different peer, expected djslkflsdfndskjfla but got fnldfnsdfnlsdf ] , can any one have solution / idea for why its happening
Utsav_Solanki (Mon, 15 Jul 2019 06:22:13 GMT):
hello, i found this warninig in HLF fabric peer0 docker logs [UTC [gossip.comm] createConnection -> WARN 89eddsc Remote endpoint claims to be a different peer, expected djslkflsdfndskjfla but got fnldfnsdfnlsdf ] , can any one have solution / idea for why its happening
shrugupt (Mon, 15 Jul 2019 08:12:10 GMT):
Has joined the channel.
yacovm (Mon, 15 Jul 2019 09:55:01 GMT):
You have a network misconfiguration, or the peer changed its certificate.
Utsav_Solanki (Mon, 15 Jul 2019 11:36:14 GMT):
Thanks for reply but how can i change this PKI ID to exact peer
Utsav_Solanki (Mon, 15 Jul 2019 11:40:58 GMT):
because as i compared [ expected key and PKI ID key with my peers ca, tls, msp in located directory but no mach found ]
yacovm (Mon, 15 Jul 2019 12:01:08 GMT):
just don't change the certificate
Utsav_Solanki (Mon, 15 Jul 2019 12:21:02 GMT):
i do not change certificate but what other changes i have to do in my peer
Utsav_Solanki (Mon, 15 Jul 2019 12:21:55 GMT):
can i have steps to do that
yacovm (Mon, 15 Jul 2019 12:33:17 GMT):
ah just restart it
Utsav_Solanki (Mon, 15 Jul 2019 12:41:05 GMT):
i did before that before,
Utsav_Solanki (Mon, 15 Jul 2019 12:41:05 GMT):
i did before this logs errors,
Utsav_Solanki (Mon, 15 Jul 2019 12:41:05 GMT):
exact peer logs are
Utsav_Solanki (Mon, 15 Jul 2019 12:45:22 GMT):
2019-07-15 11:29:06.186 UTC [gossip.comm] createConnection -> WARN 16e4f6 Remote endpoint claims to be a different peer, expected asdsafsdfdf6dfs6cb6f809ae3436 but got 4d1f0f020429089928b5f36f5c7e1b9fc19b23f521aaa6161f33c7be4a0f5c53
2019-07-15 11:29:06.186 UTC [gossip.comm] sendToEndpoint -> WARN 16e4f7 Failed obtaining connection for ip:port, PKIid:asdsafsdfdf6dfs6cb6f809ae3436 reason: authentication failure
2019-07-15 11:29:06.186 UTC [gossip.discovery] expireDeadMembers -> WARN 16e4f8 Entering [asdsafsdfdf6dfs6cb6f809ae3436]
2019-07-15 11:29:06.186 UTC [gossip.discovery] expireDeadMembers -> WARN 16e4f9 Closing connection to Endpoint: ip:port, InternalEndpoint: , PKI-ID: asdsafsdfdf6dfs6cb6f809ae3436, Metadata:
2019-07-15 11:29:06.187 UTC [gossip.discovery] expireDeadMembers -> WARN 16e4fb Exiting
Utsav_Solanki (Mon, 15 Jul 2019 12:48:09 GMT):
does peers change their certificate automatically because none of PKIid:asdsafsdfdf6dfs6cb6f809ae3436 and Entering [1bc2a17b1e8b6fa32311c9b5fce3255cb6f809ae34365bf25a1391bd277cff0b]
Utsav_Solanki (Mon, 15 Jul 2019 12:48:09 GMT):
does peers change their certificate automatically because none of PKIid:asdsafsdfdf6dfs6cb6f809ae3436 and Entering [1bc2a17b1e8b6fa32311c9b5fce3255cb6f809ae34365bf25a1391bd277cff0b] i am using
Utsav_Solanki (Mon, 15 Jul 2019 12:48:09 GMT):
does peers change their certificate automatically because NONE OF KEY / CERTS I AM USING AS PKIid:asdsafsdfdf6dfs6cb6f809ae3436 and Entering [1bc2a17b1e8b6fa32311c9b5fce3255cb6f809ae34365bf25a1391bd277cff0b] BUT STILL IN LOGS ITS COMING THESE PKI AND ENTERING
Utsav_Solanki (Tue, 16 Jul 2019 06:26:38 GMT):
any idea ?
Utsav_Solanki (Tue, 16 Jul 2019 06:26:38 GMT):
any idea on above issue ?
soumyanayak (Sat, 20 Jul 2019 03:04:17 GMT):
Hi all,
when i am trying to do "peer node status" from the fabric-tools container the below error --
root@0d473a576d81:/opt/scripts# peer node status
2019-07-20 02:55:14.105 UTC [nodeCmd] status -> INFO 001 Error trying to get status from local peer: rpc error: code = Unavailable desc = transport is closing
status:UNKNOWN
Error: Error trying to connect to local peer: rpc error: code = Unavailable desc = transport is closing
the mspconfigpath is set to peer admin msp while running the above command
Utsav_Solanki (Sat, 20 Jul 2019 07:26:17 GMT):
how can i access peers ledger?
Utsav_Solanki (Sat, 20 Jul 2019 07:26:17 GMT):
how can i access peers ledger? i want to see older hash and data that maintained in peer ledger.
mfaisaltariq (Tue, 23 Jul 2019 07:32:46 GMT):
```
2019-07-22 15:48:53.998 UTC [blocksProvider] DeliverBlocks -> ERRO 032 [linuxctlchannel] Got error &{FORBIDDEN}
2019-07-22 15:48:54.116 UTC [blocksProvider] DeliverBlocks -> ERRO 033 [linuxctlchannel] Got error &{FORBIDDEN}
2019-07-22 15:48:54.336 UTC [blocksProvider] DeliverBlocks -> ERRO 034 [linuxctlchannel] Got error &{FORBIDDEN}
2019-07-22 15:48:54.748 UTC [blocksProvider] DeliverBlocks -> ERRO 035 [linuxctlchannel] Got error &{FORBIDDEN}
2019-07-22 15:48:55.569 UTC [blocksProvider] DeliverBlocks -> ERRO 036 [linuxctlchannel] Got error &{FORBIDDEN}
2019-07-22 15:48:57.157 UTC [blocksProvider] DeliverBlocks -> ERRO 037 [linuxctlchannel] Got error &{FORBIDDEN}
2019-07-22 15:49:00.383 UTC [blocksProvider] DeliverBlocks -> ERRO 038 [linuxctlchannel] Got error &{FORBIDDEN}
2019-07-22 15:49:06.796 UTC [blocksProvider] DeliverBlocks -> ERRO 039 [linuxctlchannel] Got error &{FORBIDDEN}
2019-07-22 15:49:16.815 UTC [blocksProvider] DeliverBlocks -> ERRO 03a [linuxctlchannel] Got error &{FORBIDDEN}
2019-07-22 15:49:26.813 UTC [blocksProvider] DeliverBlocks -> ERRO 03b [linuxctlchannel] Got error &{FORBIDDEN}
2019-07-22 15:49:36.837 UTC [blocksProvider] DeliverBlocks -> ERRO 03c [linuxctlchannel] Got error &{FORBIDDEN}
2019-07-22 15:49:36.837 UTC [blocksProvider] DeliverBlocks -> ERRO 03d [linuxctlchannel] Wrong statuses threshold passed, stopping block provider
```
Getting this error on Peer Join
Utsav_Solanki (Wed, 24 Jul 2019 07:52:09 GMT):
2019-07-24 07:35:35.535 UTC [gossip.comm] sendToEndpoint -> WARN 5673 Failed obtaining connection for ip:port, PKIid:4d1f0f020429089928b5f36f5adasfa1aaa6161f33c7be4a0f5c53 reason: context deadline exceeded
2019-07-24 07:35:35.535 UTC [gossip.discovery] expireDeadMembers -> WARN 5674 Entering [4d1f0f020429089928b5f36f5adasfa1aaa6161f33c7be4a0f5c53]
2019-07-24 07:35:35.535 UTC [gossip.discovery] expireDeadMembers -> WARN 5675 Closing connection to Endpoint: ip:port, InternalEndpoint: ip:port, PKI-ID: 4d1f0f020429089928b5f36f5adasfa1aaa6161f33c7be4a0f5c53, Metadata:
2019-07-24 07:35:35.535 UTC [gossip.discovery] expireDeadMembers -> WARN 5676 Exiting
i am getting peers logs and my peers getting exited becoz of memory drained
Utsav_Solanki (Wed, 24 Jul 2019 07:52:16 GMT):
any solution
krabradosty (Tue, 30 Jul 2019 06:59:26 GMT):
Hi all! I faced surprising bug, maybe will be useful for somebody. Peers reject signatures of identities with type of `client` and with affiliation also `client`. In certificate it looks like this: `OU=client+OU=client`. I have no idea what is the resason of the bug, but everything starts working as expected when I change affiliation.
Error messages from peers don't contain any unusual comments:
```
[33m2019-07-29 18:20:01.784 UTC [common.deliver] deliverBlocks -> WARN 18e[0m [channel: main-kyc] Client authorization revoked for deliver request from 10.17.39.246:52876: Failed evaluating policy on signed data during check policy on channel [main-kyc] with policy [/Channel/Application/Readers]: [implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Readers' sub-policies to be satisfied]
```
Utsav_Solanki (Wed, 31 Jul 2019 07:23:24 GMT):
this is peer_org1 container logs but why is giving [ isn't responsive: EOF ] in logs
Utsav_Solanki (Wed, 31 Jul 2019 07:23:26 GMT):
so all logs are
Utsav_Solanki (Wed, 31 Jul 2019 07:23:29 GMT):
2019-07-31 06:59:16.585 UTC [gossip.comm] func1 -> WARN 064 peer0.org2.example.com:7051, PKIid:33b6c19d1fffb3dd55d37531865fb940be3dc0fa42944a19e853088282894114 isn't responsive: EOF
2019-07-31 06:59:16.585 UTC [gossip.discovery] expireDeadMembers -> WARN 065 Entering [33b6c19d1fffb3dd55d37531865fb940be3dc0fa42944a19e853088282894114]
2019-07-31 06:59:16.586 UTC [gossip.discovery] expireDeadMembers -> WARN 066 Closing connection to Endpoint: peer0.org2.example.com:7051, InternalEndpoint: , PKI-ID: 33b6c19d1fffb3dd55d3753186sdfsdfsgs44a19e853088282894114, Metadata:
2019-07-31 06:59:16.586 UTC [gossip.discovery] expireDeadMembers -> WARN 067 Exiting
soumyanayak (Fri, 09 Aug 2019 11:19:05 GMT):
In CouchDB the order is going lexically , is it the default behavior or we can have any sorting order like numerical order - ascending based on key?
aatkddny (Mon, 12 Aug 2019 13:28:05 GMT):
Getting a lot of these. Network allows me to create channels and install and instantiate chaincode, so it can't be too badly messed up.
Are they expected or a symptom that something - I'd guess gossip between peers - isn't working correctly.
```
2019-08-12 13:19:27.755 UTC [grpc] DialContext -> DEBU c04 parsed scheme: ""
2019-08-12 13:19:27.755 UTC [grpc] DialContext -> DEBU c05 scheme "" not registered, fallback to default scheme
2019-08-12 13:19:27.755 UTC [grpc] watcher -> DEBU c06 ccResolverWrapper: sending new addresses to cc: [{peer0-someorg:7051 0
yacovm (Mon, 12 Aug 2019 14:41:51 GMT):
@aatkddny wthere are DEBUG and not warnings
yacovm (Mon, 12 Aug 2019 14:41:57 GMT):
you shouldn't care
aatkddny (Mon, 12 Aug 2019 14:45:41 GMT):
k. thx.
joeljhanster (Tue, 13 Aug 2019 06:01:09 GMT):
Has joined the channel.
indirajith (Thu, 15 Aug 2019 20:23:56 GMT):
Hi all, I encounter an error when I try to join peer2 to a channel from cli container I get the following:
```[grpc] createTransport -> DEBU 03b grpc: addrConn.createTransport failed to connect to {peer2-org1.local:7051 0
indirajith (Thu, 15 Aug 2019 20:23:56 GMT):
Hi all, I encounter an error when I try to join peer2 to a channel from cli container I get the following:
```[grpc] createTransport -> DEBU 03b grpc: addrConn.createTransport failed to connect to {peer2-org1.local:7051 0
soumyanayak (Fri, 16 Aug 2019 08:38:23 GMT):
CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE -- docker supports multiple types of networking. This var is used for the type of networking that you intend to use -- host, bridge, ipvlan, none.
You can check this link for this value - https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.con.doc/q131010_.htm
indirajith (Fri, 16 Aug 2019 16:24:08 GMT):
Thank you @soumyanayak but, as I am not using docker swarm, and have cli and peer on different hosts, I just want to iuse their IPs to communicate. I get connection refused, error while dialing on CLI and, context deadline exceeded error on peer2 while joining a channel. I think the error is not due to any networking problem. Could you shed some more light on this?
soumyanayak (Fri, 16 Aug 2019 21:26:24 GMT):
Indrajit , i am also not using the docker swarm, instead i am using something as "network_mode" = host in docker compose file. so from your CLI host machine just run the command nc -vz
ItaloCarrasco (Mon, 19 Aug 2019 20:00:55 GMT):
Has joined the channel.
ItaloCarrasco (Mon, 19 Aug 2019 20:00:57 GMT):
hello can anyone explain what does that error mean?
2019-08-19 19:56:14.044 UTC [statebasedval] ValidateAndPrepareBatch -> WARN 041 Block [7] Transaction index [0] TxId [fae901aee17d0ad8ff0349e6b165acd499c24e48ce238f8fd67fc8d2b732bf94] marked as invalid by state validator. Reason code [MVCC_READ_CONFLICT]
iramiller (Mon, 19 Aug 2019 22:38:04 GMT):
@#it
iramiller (Mon, 19 Aug 2019 22:38:04 GMT):
@ItaloCarrasco your state changed in the middle of your transaction https://en.wikipedia.org/wiki/Multiversion_concurrency_control
galaxystar (Tue, 20 Aug 2019 01:23:42 GMT):
Has joined the channel.
Adam_Hardie (Tue, 20 Aug 2019 10:31:18 GMT):
Has joined the channel.
Adam_Hardie (Tue, 20 Aug 2019 10:34:29 GMT):
hi all! I have setup a simple raft network, on docker swarm mode. I have been basing my config from byfn raft sample.
Orderer and Peer containers startup, and I can see Ordering nodes logging Raft consensus between them.
so, i now want to setup a channel for my Organisation. but it fails. the below error is printed in Orderer :
2019-08-20 10:23:30.894 UTC [core.comm] ServerHandshake -> ERRO 5d7 TLS handshake failed with error tls: failed to verify client's certificate: x509: certificate signed by unknown authority server=Orderer remoteaddress=10.0.0.4:32788
Easy enough to understand, however I have followed the examples.. Its hard to know where I went wrong. My channel creation is as follows:
docker exec $PEER_NAME peer channel create -o orderer0.company:7050 --tls --cafile /etc/hyperledger/fabric/ordererCerts/tlsca.company-cert.pem -c messagebus -f /etc/hyperledger/configtx/channel.tx --keyfile /etc/hyperledger/msp/users/Admin\@company/tls/client.key --certfile /etc/hyperledger/msp/users/Admin\@company/tls/client.crt --clientauth
Adam_Hardie (Tue, 20 Aug 2019 10:41:01 GMT):
in case it helps here are some of my configs :
orderer: https://pastebin.com/jjcmZGZc
peer: https://pastebin.com/azTnxNUA
indirajith (Thu, 22 Aug 2019 11:23:21 GMT):
Thank you Soumya! it makes sense to me now. But I have one more doubt. For CLI containers when peers of an organisation are on different networks, which port do we need to expose? I still quite don't get the environement variable we provide in CLI docker-compose file. we provide CORE_PEER_ADDRESS=peer1-org2:7051 fin CLI. Can you please explain me a bit more on this?
soumyanayak (Thu, 22 Aug 2019 11:29:01 GMT):
in my case the CORE_PEER_ADDRESS=
indirajith (Thu, 22 Aug 2019 11:32:38 GMT):
Okay, but the same port was also used by a peer on the same host and I have a second peer running on another host. Now the peer and the cli on the same host wouldn't it create any port conflict? Sorry for the repeated questions.
soumyanayak (Thu, 22 Aug 2019 11:35:20 GMT):
you should give a different one like 8051
under ports section
peer 1 --> 7050
soumyanayak (Thu, 22 Aug 2019 11:35:23 GMT):
HOST:CONTAINER
soumyanayak (Thu, 22 Aug 2019 11:35:33 GMT):
7050:7050 -- peer1
soumyanayak (Thu, 22 Aug 2019 11:35:53 GMT):
8050:7050 -- peer2
soumyanayak (Thu, 22 Aug 2019 11:36:18 GMT):
in the same machine you have to change the ports
indirajith (Thu, 22 Aug 2019 11:37:42 GMT):
Yeah, my doubt was as we use the same peer address for both cli and peer I am confused whether to use same port for both peer and cli on the same host or not.
indirajith (Thu, 22 Aug 2019 21:53:13 GMT):
Soumyanayak, I have found the solution. Thank you!
isilvalepe (Fri, 23 Aug 2019 14:46:51 GMT):
Has joined the channel.
isilvalepe (Fri, 23 Aug 2019 14:46:51 GMT):
https://chat.hyperledger.org/channel/fabric-questions?msg=WcivZdBQoCp7F2GPP
sarapaul (Sun, 25 Aug 2019 22:11:32 GMT):
Has joined the channel.
Utsav_Solanki (Mon, 26 Aug 2019 04:53:43 GMT):
in HLF peers container if we not perform any transaction for few days, does it automatically exited from HLF Network
Utsav_Solanki (Mon, 26 Aug 2019 04:53:43 GMT):
in HLF peers container if we not perform any transaction for few days, does it automatically exited from HLF Network,
Utsav_Solanki (Mon, 26 Aug 2019 04:53:43 GMT):
in HLF peers (peer0, peer1) container if we not perform any transaction for few days, does it automatically exited from HLF Network, my peer1, couchdb containers automatically exited(0)
Utsav_Solanki (Mon, 26 Aug 2019 05:05:18 GMT):
anyone knows why this happens?
Deepakshinde (Mon, 26 Aug 2019 12:14:42 GMT):
Has joined the channel.
Deepakshinde (Mon, 26 Aug 2019 12:14:44 GMT):
Peer machine IP changed, how to update transaction file and genesis block without regenerating artifacts?
akshay.lawange (Mon, 26 Aug 2019 12:32:14 GMT):
Clipboard - August 26, 2019 6:02 PM
akshay.lawange (Mon, 26 Aug 2019 12:32:16 GMT):
Hi all, I am using fabric 1.3.0, it works fine. However, sometime when a bigger transaction comes in (transaction json contains 2000-3000 json) it disconnects from peer and say `no ledger context`. Below is the error capture in peer0 of a node, which says invalid transaction but in fact it is not. Can someone help with this? its urgent. Thanks.
akshay.lawange (Mon, 26 Aug 2019 12:32:16 GMT):
Hi all, I am using fabric 1.3.0, it works fine. However, sometime when a bigger transaction comes in (transaction json contains 2000-3000 json) it disconnects from peer and say `no ledger context`. Above is the error capture in peer0 of a node, which says invalid transaction but in fact it is not. Can someone help with this? its urgent. Thanks.
dan13 (Mon, 26 Aug 2019 15:31:06 GMT):
Maybe something thought-provoking https://jira.hyperledger.org/browse/FABG-309?jql=text%20~%20%22%5C%22no%20ledger%20context%5C%22%22 but doesn't look like much here :(
dan13 (Mon, 26 Aug 2019 15:31:06 GMT):
Maybe something thought-provoking https://jira.hyperledger.org/browse/FABG-309?jql=text%20~%20%22%5C%22no%20ledger%20context%5C%22%22 but doesn't look like much here :( Googling "no ledger context" also gets some hits -- good luck!
akshay.lawange (Mon, 26 Aug 2019 15:41:38 GMT):
Thanks @dan13 ..i will check what i can find out..and it gets resolved i will post here.
akshay.lawange (Mon, 26 Aug 2019 15:41:38 GMT):
Thanks @dan13 ..i will check what i can find out..and if it gets resolved, i will post it here.
sstone1 (Tue, 27 Aug 2019 12:50:19 GMT):
`no ledger context` means that the chaincode is still running and trying to interact with the world state/ledger, but the peer has given up on the transaction. this can happen if the chaincode takes too long to run and the peer times the transaction out, or if the chaincode launches processing in other threads that it doesn't wait for.
akshay.lawange (Tue, 27 Aug 2019 16:04:10 GMT):
ok..thanks @sstone1 . So do we have to increase the transaction time in core.yaml?
aatkddny (Thu, 29 Aug 2019 13:34:09 GMT):
So we just started a new channel. First Tx update didn't go so well.
We can read it what we added.
So that triggers the code to try an update (rather than an add).
When we do that we get a "Not enough endorsers" error where one (of multiple) returns with "Item not found".
Looking at the peer you can see this - `response status 500 for txid: 2d4f4a2c82b4785917b9822295296d3778b1072847ab9d81b687dd8b7daaffb1`
I'm guessing this means the CC failed to instantiate in time, but the logs aren't showing a failure message.
*So my question is how do I fix this?* Reinstall the CC? Restart the peers?
Also I'm seeing a lot of these:
```
2019-08-27 18:50:36.014 UTC [grpc] HandleSubConnStateChange -> DEBU 19b8 pickfirstBalancer: HandleSubConnStateChange: 0xc003d50420, TRANSIENT_FAILURE
2019-08-27 18:50:36.502 UTC [grpc] func1 -> DEBU 19b9 Failed to dial peer0-org2:30030: context canceled; please retry.
2019-08-27 18:50:36.502 UTC [grpc] func1 -> DEBU 19ba Failed to dial peer0-org3:30050: context canceled; please retry.
2019-08-27 18:50:52.279 UTC [core.comm] ServerHandshake -> ERRO 19bb TLS handshake failed with error remote error: tls: bad certificate server=PeerServer remoteaddress=10.42.6.102:42518
2019-08-27 18:50:52.279 UTC [grpc] handleRawConn -> DEBU 19bc grpc: Server.Serve failed to complete security handshake from "10.42.6.102:42518": remote error: tls: bad certificate
2019-08-27 18:50:53.279 UTC [core.comm] ServerHandshake -> ERRO 19bd TLS handshake failed with error remote error: tls: bad certificate server=PeerServer remoteaddress=10.42.6.102:42526
2019-08-27 18:50:53.279 UTC [grpc] handleRawConn -> DEBU 19be grpc: Server.Serve failed to complete security handshake from "10.42.6.102:42526": remote error: tls: bad certificate
2019-08-27 18:50:54.666 UTC [core.comm] ServerHandshake -> ERRO 19bf TLS handshake failed with error remote error: tls: bad certificate server=PeerServer remoteaddress=10.42.6.102:42536
2019-08-27 18:50:54.666 UTC [grpc] handleRawConn -> DEBU 19c0 grpc: Server.Serve failed to complete security handshake from "10.42.6.102:42536": remote error: tls: bad certificate
```
I have multiple orgs inside this cluster. The SAN for all of them is set to be the node names, which allows me to bring them up and instantiate chaincode.
Not sure why it's failing here - is there some easy way to tell what it doesn't like in the cert?
yacovm (Thu, 29 Aug 2019 13:40:12 GMT):
> is there some easy way to tell what it doesn't like in the cert?
yeah... make the logging be `grpc=debug` as well and then it prints what is exactly wrong with the certificate @aatkddny
yacovm (Thu, 29 Aug 2019 13:40:19 GMT):
https://hyperledger-fabric.readthedocs.io/en/release-1.4/logging-control.html
yacovm (Thu, 29 Aug 2019 13:40:45 GMT):
`FABRIC_LOGGING_SPEC=grpc=debug:debug`
yacovm (Thu, 29 Aug 2019 13:40:48 GMT):
something like that
aatkddny (Thu, 29 Aug 2019 13:50:30 GMT):
It was.
```
"name": "FABRIC_LOGGING_SPEC",
"value": "grpc=debug"
```
Guess I need the second `:debug`?
aatkddny (Thu, 29 Aug 2019 13:50:30 GMT):
It was.
```
"name": "FABRIC_LOGGING_SPEC",
"value": "grpc=debug"
```
Guess I need the second `:debug`?
edit: Nope that doesn't change things.
aatkddny (Thu, 29 Aug 2019 13:50:30 GMT):
It was.
```
"name": "FABRIC_LOGGING_SPEC",
"value": "grpc=debug"
```
Guess I need the second `:debug`?
edit: Nope that doesn't change things. Any other ideas?
yacovm (Thu, 29 Aug 2019 14:02:38 GMT):
you don't see any gRPC logging? :/
yacovm (Thu, 29 Aug 2019 14:02:41 GMT):
ah wait
yacovm (Thu, 29 Aug 2019 14:02:44 GMT):
you already have it
yacovm (Thu, 29 Aug 2019 14:02:47 GMT):
sorry... i didn't notice
yacovm (Thu, 29 Aug 2019 14:03:16 GMT):
ok so you can capture the communication via `tcpdump` and you can open it with `wireshark` and look :(
yacovm (Thu, 29 Aug 2019 14:03:32 GMT):
i don't know how to debug it from Fabric in a different way
aatkddny (Thu, 29 Aug 2019 15:20:00 GMT):
K. And for the benefit of future generations restarting the peer fixed the out of sync error.
aatkddny (Thu, 29 Aug 2019 15:23:56 GMT):
Back to the tls filed to dial problem.
This is the peer trying to talk start communications across multiple orgs.
Is there anything that describes the correct way to do this? I'm guessing I need to provide it a cert from the server it's trying to talk to somehow?
But I'm really really guessing here...
Or is this expected and I just ignore it. It still seems to all work.
aatkddny (Thu, 29 Aug 2019 15:23:56 GMT):
Back to the tls `failed to dial` problem.
This is the peer trying to talk start communications across multiple orgs.
Is there anything that describes the correct way to do this? I'm guessing I need to provide it a cert from the server it's trying to talk to somehow?
But I'm really really guessing here...
Or is this expected and I just ignore it. It still seems to all work.
indirajith (Fri, 30 Aug 2019 11:34:07 GMT):
How to modify the logging levels dynamically without restarting peers and orderers? Is there a way for this? Like we can change the log levels if we encounter any problems then revert back.
wlahti (Fri, 30 Aug 2019 12:27:59 GMT):
Starting in fabric v1.4, the operations service was introduced and can be used to change the logging spec dynamically: https://hyperledger-fabric.readthedocs.io/en/release-1.4/operations_service.html
indirajith (Fri, 30 Aug 2019 13:05:19 GMT):
Thank you wlahti!
abel23 (Sat, 31 Aug 2019 11:36:50 GMT):
Has joined the channel.
guoger (Wed, 04 Sep 2019 08:35:10 GMT):
[this method](https://github.com/hyperledger/fabric/blob/d9b0ac2c38fc6ce9384a29dc35d6724cc65e0f51/core/common/validation/statebased/validator_keylevel.go#L184-L194) is not entirely clear to me. IIUC, it ultimately builds the `depsByLedgerKeyIDMap` within `validationContext` for a specific block, which can be done *in parallel*. And this method *proactively* builds dependencies for transactions *preceding*(incl.) current `tIdx`. However, the `mutex` there kills the concurrency in _worst case_ (`PreValidate` is called with ascending `txNum`), and profiling shows that this consumes a significant amount of time when a block contains a large number of txs. I wonder why couldn't we build dependencies map in parallel once for all? thx @aso @yacovm
```
func (klv *KeyLevelValidator) invokeOnce(block *common.Block, txnum uint64) *sync.Once {
klv.blockDep.mutex.Lock()
defer klv.blockDep.mutex.Unlock()
if klv.blockDep.blockNum != block.Header.Number {
klv.blockDep.blockNum = block.Header.Number
klv.blockDep.txDepOnce = make([]sync.Once, len(block.Data.Data))
}
return &klv.blockDep.txDepOnce[txnum]
}
```
guoger (Wed, 04 Sep 2019 08:37:37 GMT):
also, why couldn't we create a new validator per block to avoid state tracking and locks? excessive gc? just trying to understand the rationale here
guoger (Wed, 04 Sep 2019 09:51:41 GMT):
essentially i'm proposing this https://gerrit.hyperledger.org/r/c/fabric/+/33366, which is fairly small, doesn't introduce extra locks, but reduces validation time by more than 50%. Of course it's very likely that i'm overlooking something which breaks actually invariants in that area...
guoger (Wed, 04 Sep 2019 09:53:33 GMT):
(while reading the code, i also feel the validator can be further simplified and optimized...)
Utsav_Solanki (Wed, 04 Sep 2019 13:30:26 GMT):
my all peer1 containers and all couchDB contaners are getting exited (0) with out any error in 7 days after HLF NW up, i am using hyperledger fabric 1.4.2.
Utsav_Solanki (Wed, 04 Sep 2019 13:30:26 GMT):
my all orgs peer1 containers and all couchDB contaners are getting exited (0) with out any error in 7 days after HLF NW up, i am using hyperledger fabric 1.4.2.
Utsav_Solanki (Wed, 04 Sep 2019 13:32:42 GMT):
peer1 exited container logs are
Utsav_Solanki (Wed, 04 Sep 2019 13:32:59 GMT):
2019-08-30 13:19:01.474 UTC [ledger] CommitWithPvtData -> INFO 83f [newchnl] Committed block [663] with 1 transaction(s) in 80ms (state_validation=7ms block_and_pvtdata_commit=45ms state_commit=24ms) commitHash=[a684e2a781eefdsfdffsd76d]
2019-09-04 09:45:50.270 UTC [nodeCmd] handleSignals -> INFO 840 Received signal: 15 (terminated)
2019-09-04 09:45:50.270 UTC [gossip.service] Stop -> INFO 841 Stopping chain newchnl
2019-09-04 09:45:50.270 UTC [gossip.gossip] Stop -> INFO 842 Stopping gossip
2019-09-04 09:45:50.270 UTC [gossip.discovery] Stop -> INFO 843 Stopping
2019-09-04 09:45:50.270 UTC [gossip.discovery] Stop -> INFO 844 Stopped
2019-09-04 09:45:50.270 UTC [gossip.comm] Stop -> INFO 845 Stopping
2019-09-04 09:45:50.270 UTC [gossip.comm] Stop -> INFO 846 Stopped
Utsav_Solanki (Wed, 04 Sep 2019 13:32:59 GMT):
2019-08-30 13:19:01.474 UTC [ledger] CommitWithPvtData -> INFO 83f [newchnl] Committed block [663] with 1 transaction(s) in 80ms (state_validation=7ms block_and_pvtdata_commit=45ms state_commit=24ms) commitHash=[a684e2a781eefdsfdffsd76d]
2019-09-04 09:45:50.270 UTC [nodeCmd] handleSignals -> INFO 840 Received signal: 15 (terminated)
2019-09-04 09:45:50.270 UTC [gossip.service] Stop -> INFO 841 Stopping chain newchnl
2019-09-04 09:45:50.270 UTC [gossip.gossip] Stop -> INFO 842 Stopping gossip
2019-09-04 09:45:50.270 UTC [gossip.discovery] Stop -> INFO 843 Stopping
2019-09-04 09:45:50.270 UTC [gossip.discovery] Stop -> INFO 844 Stopped
2019-09-04 09:45:50.270 UTC [gossip.comm] Stop -> INFO 845 Stopping
2019-09-04 09:45:50.270 UTC [gossip.comm] Stop -> INFO 846 Stopped , also you can see the difference of date change in logs
Utsav_Solanki (Wed, 04 Sep 2019 13:34:35 GMT):
any soluiton, Thank you
Utsav_Solanki (Wed, 04 Sep 2019 13:34:35 GMT):
any solution, Thank you
soumyanayak (Thu, 05 Sep 2019 06:32:33 GMT):
i am getting the below error
*configtxlator: error: Error decoding: message of type %!s(
soumyanayak (Thu, 05 Sep 2019 12:22:20 GMT):
From the CLI how to check whether a peer is anchor peer or not ?
phantom.assasin (Fri, 06 Sep 2019 07:16:15 GMT):
Has joined the channel.
phantom.assasin (Fri, 06 Sep 2019 07:16:16 GMT):
How do i remove a peer from a channel?
mastersingh24 (Sun, 08 Sep 2019 20:10:16 GMT):
There is currently no API call that will allow you to do this ... the only option is to manually edit and remove the ledger files associated with the channel on the peer filesystem. There is a JIRA open to add a proper API for this
phantom.assasin (Mon, 09 Sep 2019 11:09:48 GMT):
Meanwhile one can also remove an org from channel by updating channel configurations
mastersingh24 (Mon, 09 Sep 2019 11:12:00 GMT):
Yes ... you can remove an organization from a channel via a config update and at that point peers from that org will no longer get blocks for that channel.
But if you just want one peer from an org to "unjoin" a channel, there's no API for that.
phantom.assasin (Mon, 09 Sep 2019 11:31:00 GMT):
Yes. I am removing org as a workaround until the real API is available
soumyanayak (Fri, 13 Sep 2019 11:46:00 GMT):
While running the configtxgen tool for generating the genesis block from configtx.yaml i am getting the below error --
2019-09-13 10:08:16.668 UTC [common.tools.configtxgen.localconfig] Load -> PANI 08a Error unmarshaling config into struct: 2 error(s) decoding:
'Orderer.Policies[Capabilities]' has invalid keys: V1_1, V1_3, V1_4_3
'Profiles[LegalDescriptionGenesis].Orderer.Policies[Capabilities]' has invalid keys: V1_1, V1_3, V1_4_3
2019-09-13 10:08:16.672 UTC [common.tools.configtxgen] func1 -> PANI 08b Error unmarshaling config into struct: 2 error(s) decoding:
generak (Sun, 15 Sep 2019 11:44:52 GMT):
Has joined the channel.
KartikChauhan (Tue, 17 Sep 2019 09:52:27 GMT):
How can I install and instantiate a typescript chaincode?
This is what I did so far to try to make it work:
1) Installed npm packages in local environment.
2) Compiled my typescript project to js.
Chaincode installed successfully but during instantiation I got the error `Error: could not assemble transaction, err proposal response was not successful, error code 500, msg chaincode registration failed: container exited with 0`.
I then removed all my ts files and kept only js files and package.json in the folder. Again, the chaincode installed successfully but got the above-mentioned error again during instantiation.
soumyanayak (Tue, 17 Sep 2019 11:11:57 GMT):
Hi All,
v1.4.3 Fabric - RAFT Orderer set up
The installation and instantiation of the chaincode is happening on the peer. But when from the tools container i am running the command
*peer chaincode list –instantiated -C legaldescriptionchannel*
*the chaincode containers are exiting. *
i had installed thrice with different versions and using upgraded using upgrade command but still the above issue lies.
soumyanayak (Tue, 17 Sep 2019 11:11:57 GMT):
Hi All,
v1.4.3 Fabric - RAFT Orderer set up
The installation and instantiation of the chaincode is happening on the peer. But when from the tools container i am running the command
*peer chaincode list –instantiated -C legaldescriptionchannel*
*the chaincode containers are exiting. *
i had installed thrice with different versions and upgraded using upgrade command but still the above issue lies.
soumyanayak (Tue, 17 Sep 2019 11:11:57 GMT):
Hi All,
v1.4.3 Fabric - RAFT Orderer set up
The installation and instantiation of the chaincode is happening on the peer. But when from the tools container i am running the command
*peer chaincode list –instantiated -C legaldescriptionchannel*
*the chaincode containers are exiting. *
i had installed thrice with different versions and upgraded using upgrade command but still the above issue lies.
The peer logs are as shown below
soumyanayak (Tue, 17 Sep 2019 11:50:26 GMT):
Clipboard - September 17, 2019 5:20 PM
KartikChauhan (Tue, 17 Sep 2019 12:06:51 GMT):
How can I know the role of a peer? I mean how can I know which peer is endorsing and which which one is committing/validating peer in a hyperledger fabric network?
tommyjay (Tue, 17 Sep 2019 20:01:56 GMT):
Has joined the channel.
soumyanayak (Wed, 18 Sep 2019 04:41:04 GMT):
anybody any idea about this issue
soumyanayak (Wed, 18 Sep 2019 09:11:14 GMT):
This issue is resolved . Actually there was an issue in the configtx.yaml where the allignment of the key - Organization under Application section was not proper it was under the ACLs.
Configtxgen tool generated the genesis file successfully, but that was the issue. So its a advice to everybody . Check the proper spacing and allignment in configtx.yaml before generating the artifacts
nleut (Wed, 18 Sep 2019 15:59:23 GMT):
Has joined the channel.
rahulhegde (Mon, 23 Sep 2019 23:02:02 GMT):
Hello - I am getting a orderer panic upon enabling promethus + mutual TLS on a different port for RAFT communication.
```
2019-09-23 22:59:43.612 UTC [orderer.common.cluster] loadVerifier -> INFO 00b Loaded verifier for channel goldsac from config block at index 2
2019-09-23 22:59:43.634 UTC [orderer.common.cluster] loadVerifier -> INFO 00c Loaded verifier for channel public from config block at index 5
2019-09-23 22:59:43.640 UTC [orderer.common.cluster] loadVerifier -> INFO 00d Loaded verifier for channel testchainid from config block at index 7
2019-09-23 22:59:43.640 UTC [orderer.common.server] initializeServerConfig -> INFO 00e Starting orderer with TLS enabled
panic: duplicate metrics collector registration attempted
goroutine 1 [running]:
github.com/hyperledger/fabric/vendor/github.com/prometheus/client_golang/prometheus.(*Registry).MustRegister(0xc0000d5d10, 0xc00097d9b0, 0x1, 0x1)
/go/src/github.com/hyperledger/fabric/vendor/github.com/prometheus/client_golang/prometheus/registry.go:387 +0xad
github.com/hyperledger/fabric/vendor/github.com/prometheus/client_golang/prometheus.MustRegister(0xc00097d9b0, 0x1, 0x1)
/go/src/github.com/hyperledger/fabric/vendor/github.com/prometheus/client_golang/prometheus/registry.go:172 +0x53
github.com/hyperledger/fabric/vendor/github.com/go-kit/kit/metrics/prometheus.NewCounterFrom(0x148371a, 0x4, 0x148363a, 0x4, 0x1489869, 0xb, 0x14c6470, 0x4f, 0x0, 0x0, ...)
/go/src/github.com/hyperledger/fabric/vendor/github.com/go-kit/kit/metrics/prometheus/prometheus.go:24 +0xe3
github.com/hyperledger/fabric/common/metrics/prometheus.(*Provider).NewCounter(0x1de4b18, 0x148371a, 0x4, 0x148363a, 0x4, 0x1489869, 0xb, 0x14c6470, 0x4f, 0x0, ...)
/go/src/github.com/hyperledger/fabric/common/metrics/prometheus/provider.go:20 +0x138
github.com/hyperledger/fabric/core/comm.NewServerStatsHandler(0x15bde60, 0x1de4b18, 0x2)
/go/src/github.com/hyperledger/fabric/core/comm/metrics.go:29 +0x74
github.com/hyperledger/fabric/core/comm.NewGRPCServerFromListener(0x15c3820, 0xc0000b4958, 0x12a05f200, 0xc0001ca2d0, 0x1d86bc0, 0xc000521ca0, 0x2, 0x2, 0xc000521cb0, 0x2, ...)
/go/src/github.com/hyperledger/fabric/core/comm/server.go:152 +0x87e
github.com/hyperledger/fabric/core/comm.NewGRPCServer(0xc0006d1980, 0xc, 0x0, 0xc0001ca2d0, 0x1d86bc0, 0xc000521ca0, 0x2, 0x2, 0xc000521cb0, 0x2, ...)
/go/src/github.com/hyperledger/fabric/core/comm/server.go:55 +0x14b
github.com/hyperledger/fabric/orderer/common/server.configureClusterListener(0xc000203200, 0x0, 0xc0001ca240, 0x1d86bc0, 0xc000521ca0, 0x2, 0x2, 0xc000521cb0, 0x2, 0x2, ...)
/go/src/github.com/hyperledger/fabric/orderer/common/server/main.go:376 +0x78c
github.com/hyperledger/fabric/orderer/common/server.Start(0x148462a, 0x5, 0xc000203200)
/go/src/github.com/hyperledger/fabric/orderer/common/server/main.go:141 +0xdf9
github.com/hyperledger/fabric/orderer/common/server.Main()
/go/src/github.com/hyperledger/fabric/orderer/common/server/main.go:91 +0x1ce
main.main()
/go/src/github.com/hyperledger/fabric/orderer/main.go:15 +0x20
```
```
- ORDERER_OPERATIONS_LISTENADDRESS=:36001
- ORDERER_METRICS_PROVIDER=prometheus
```
If i disable metric provider, orderer stands up and works.
```
```
rahulhegde (Mon, 23 Sep 2019 23:02:02 GMT):
Hello - I am getting a orderer panic upon enabling promethus + mutual TLS on a different port for RAFT communication.
```
2019-09-23 22:59:43.612 UTC [orderer.common.cluster] loadVerifier -> INFO 00b Loaded verifier for channel goldsac from config block at index 2
2019-09-23 22:59:43.634 UTC [orderer.common.cluster] loadVerifier -> INFO 00c Loaded verifier for channel public from config block at index 5
2019-09-23 22:59:43.640 UTC [orderer.common.cluster] loadVerifier -> INFO 00d Loaded verifier for channel testchainid from config block at index 7
2019-09-23 22:59:43.640 UTC [orderer.common.server] initializeServerConfig -> INFO 00e Starting orderer with TLS enabled
panic: duplicate metrics collector registration attempted
goroutine 1 [running]:
github.com/hyperledger/fabric/vendor/github.com/prometheus/client_golang/prometheus.(*Registry).MustRegister(0xc0000d5d10, 0xc00097d9b0, 0x1, 0x1)
/go/src/github.com/hyperledger/fabric/vendor/github.com/prometheus/client_golang/prometheus/registry.go:387 +0xad
github.com/hyperledger/fabric/vendor/github.com/prometheus/client_golang/prometheus.MustRegister(0xc00097d9b0, 0x1, 0x1)
/go/src/github.com/hyperledger/fabric/vendor/github.com/prometheus/client_golang/prometheus/registry.go:172 +0x53
github.com/hyperledger/fabric/vendor/github.com/go-kit/kit/metrics/prometheus.NewCounterFrom(0x148371a, 0x4, 0x148363a, 0x4, 0x1489869, 0xb, 0x14c6470, 0x4f, 0x0, 0x0, ...)
/go/src/github.com/hyperledger/fabric/vendor/github.com/go-kit/kit/metrics/prometheus/prometheus.go:24 +0xe3
github.com/hyperledger/fabric/common/metrics/prometheus.(*Provider).NewCounter(0x1de4b18, 0x148371a, 0x4, 0x148363a, 0x4, 0x1489869, 0xb, 0x14c6470, 0x4f, 0x0, ...)
/go/src/github.com/hyperledger/fabric/common/metrics/prometheus/provider.go:20 +0x138
github.com/hyperledger/fabric/core/comm.NewServerStatsHandler(0x15bde60, 0x1de4b18, 0x2)
/go/src/github.com/hyperledger/fabric/core/comm/metrics.go:29 +0x74
github.com/hyperledger/fabric/core/comm.NewGRPCServerFromListener(0x15c3820, 0xc0000b4958, 0x12a05f200, 0xc0001ca2d0, 0x1d86bc0, 0xc000521ca0, 0x2, 0x2, 0xc000521cb0, 0x2, ...)
/go/src/github.com/hyperledger/fabric/core/comm/server.go:152 +0x87e
github.com/hyperledger/fabric/core/comm.NewGRPCServer(0xc0006d1980, 0xc, 0x0, 0xc0001ca2d0, 0x1d86bc0, 0xc000521ca0, 0x2, 0x2, 0xc000521cb0, 0x2, ...)
/go/src/github.com/hyperledger/fabric/core/comm/server.go:55 +0x14b
github.com/hyperledger/fabric/orderer/common/server.configureClusterListener(0xc000203200, 0x0, 0xc0001ca240, 0x1d86bc0, 0xc000521ca0, 0x2, 0x2, 0xc000521cb0, 0x2, 0x2, ...)
/go/src/github.com/hyperledger/fabric/orderer/common/server/main.go:376 +0x78c
github.com/hyperledger/fabric/orderer/common/server.Start(0x148462a, 0x5, 0xc000203200)
/go/src/github.com/hyperledger/fabric/orderer/common/server/main.go:141 +0xdf9
github.com/hyperledger/fabric/orderer/common/server.Main()
/go/src/github.com/hyperledger/fabric/orderer/common/server/main.go:91 +0x1ce
main.main()
/go/src/github.com/hyperledger/fabric/orderer/main.go:15 +0x20
```
```
- ORDERER_OPERATIONS_LISTENADDRESS=:36001
- ORDERER_METRICS_PROVIDER=prometheus
```
If i disable metric provider, orderer stands up and works.
rahulhegde (Mon, 23 Sep 2019 23:02:02 GMT):
Hello - I am getting a orderer panic upon enabling promethus + mutual TLS on a different port for RAFT communication.
```
2019-09-23 22:59:43.612 UTC [orderer.common.cluster] loadVerifier -> INFO 00b Loaded verifier for channel goldsac from config block at index 2
2019-09-23 22:59:43.634 UTC [orderer.common.cluster] loadVerifier -> INFO 00c Loaded verifier for channel public from config block at index 5
2019-09-23 22:59:43.640 UTC [orderer.common.cluster] loadVerifier -> INFO 00d Loaded verifier for channel testchainid from config block at index 7
2019-09-23 22:59:43.640 UTC [orderer.common.server] initializeServerConfig -> INFO 00e Starting orderer with TLS enabled
panic: duplicate metrics collector registration attempted
goroutine 1 [running]:
github.com/hyperledger/fabric/vendor/github.com/prometheus/client_golang/prometheus.(*Registry).MustRegister(0xc0000d5d10, 0xc00097d9b0, 0x1, 0x1)
/go/src/github.com/hyperledger/fabric/vendor/github.com/prometheus/client_golang/prometheus/registry.go:387 +0xad
github.com/hyperledger/fabric/vendor/github.com/prometheus/client_golang/prometheus.MustRegister(0xc00097d9b0, 0x1, 0x1)
/go/src/github.com/hyperledger/fabric/vendor/github.com/prometheus/client_golang/prometheus/registry.go:172 +0x53
github.com/hyperledger/fabric/vendor/github.com/go-kit/kit/metrics/prometheus.NewCounterFrom(0x148371a, 0x4, 0x148363a, 0x4, 0x1489869, 0xb, 0x14c6470, 0x4f, 0x0, 0x0, ...)
/go/src/github.com/hyperledger/fabric/vendor/github.com/go-kit/kit/metrics/prometheus/prometheus.go:24 +0xe3
github.com/hyperledger/fabric/common/metrics/prometheus.(*Provider).NewCounter(0x1de4b18, 0x148371a, 0x4, 0x148363a, 0x4, 0x1489869, 0xb, 0x14c6470, 0x4f, 0x0, ...)
/go/src/github.com/hyperledger/fabric/common/metrics/prometheus/provider.go:20 +0x138
github.com/hyperledger/fabric/core/comm.NewServerStatsHandler(0x15bde60, 0x1de4b18, 0x2)
/go/src/github.com/hyperledger/fabric/core/comm/metrics.go:29 +0x74
github.com/hyperledger/fabric/core/comm.NewGRPCServerFromListener(0x15c3820, 0xc0000b4958, 0x12a05f200, 0xc0001ca2d0, 0x1d86bc0, 0xc000521ca0, 0x2, 0x2, 0xc000521cb0, 0x2, ...)
/go/src/github.com/hyperledger/fabric/core/comm/server.go:152 +0x87e
github.com/hyperledger/fabric/core/comm.NewGRPCServer(0xc0006d1980, 0xc, 0x0, 0xc0001ca2d0, 0x1d86bc0, 0xc000521ca0, 0x2, 0x2, 0xc000521cb0, 0x2, ...)
/go/src/github.com/hyperledger/fabric/core/comm/server.go:55 +0x14b
github.com/hyperledger/fabric/orderer/common/server.configureClusterListener(0xc000203200, 0x0, 0xc0001ca240, 0x1d86bc0, 0xc000521ca0, 0x2, 0x2, 0xc000521cb0, 0x2, 0x2, ...)
/go/src/github.com/hyperledger/fabric/orderer/common/server/main.go:376 +0x78c
github.com/hyperledger/fabric/orderer/common/server.Start(0x148462a, 0x5, 0xc000203200)
/go/src/github.com/hyperledger/fabric/orderer/common/server/main.go:141 +0xdf9
github.com/hyperledger/fabric/orderer/common/server.Main()
/go/src/github.com/hyperledger/fabric/orderer/common/server/main.go:91 +0x1ce
main.main()
/go/src/github.com/hyperledger/fabric/orderer/main.go:15 +0x20
```
```
- ORDERER_OPERATIONS_LISTENADDRESS=:36001
- ORDERER_METRICS_PROVIDER=prometheus
- ORDERER_OPERATIONS_TLS_ENABLED=false
- ORDERER_GENERAL_CLUSTER_CLIENTCERTIFICATE=/var/hyperledger/orderer/tlsclient/ord03.clsorder.cit.clsnet.pem
- ORDERER_GENERAL_CLUSTER_CLIENTPRIVATEKEY=/var/hyperledger/orderer/tlsclient/ord03.clsorder.cit.clsnet.sk
- ORDERER_GENERAL_CLUSTER_ROOTCAS=[/var/hyperledger/orderer/tlsintermediatecerts/tls.ca01.cit.clsnet.pem]
- ORDERER_GENERAL_CLUSTER_SERVERCERTIFICATE=/var/hyperledger/orderer/tlsserver/ord03.clsorder.cit.clsnet.pem
- ORDERER_GENERAL_CLUSTER_SERVERPRIVATEKEY=/var/hyperledger/orderer/tlsserver/ord03.clsorder.cit.clsnet.sk
- ORDERER_GENERAL_CLUSTER_LISTENPORT=5555
- ORDERER_GENERAL_CLUSTER_LISTENADDRESS=0.0.0.0
```
If i disable metric provider, orderer stands up and works.
```
#- ORDERER_OPERATIONS_LISTENADDRESS=:36001
#- ORDERER_METRICS_PROVIDER=prometheus
- ORDERER_OPERATIONS_TLS_ENABLED=false
- ORDERER_GENERAL_CLUSTER_CLIENTCERTIFICATE=/var/hyperledger/orderer/tlsclient/ord03.clsorder.cit.clsnet.pem
- ORDERER_GENERAL_CLUSTER_CLIENTPRIVATEKEY=/var/hyperledger/orderer/tlsclient/ord03.clsorder.cit.clsnet.sk
- ORDERER_GENERAL_CLUSTER_ROOTCAS=[/var/hyperledger/orderer/tlsintermediatecerts/tls.ca01.cit.clsnet.pem]
- ORDERER_GENERAL_CLUSTER_SERVERCERTIFICATE=/var/hyperledger/orderer/tlsserver/ord03.clsorder.cit.clsnet.pem
- ORDERER_GENERAL_CLUSTER_SERVERPRIVATEKEY=/var/hyperledger/orderer/tlsserver/ord03.clsorder.cit.clsnet.sk
- ORDERER_GENERAL_CLUSTER_LISTENPORT=5555
- ORDERER_GENERAL_CLUSTER_LISTENADDRESS=0.0.0.0
```
rahulhegde (Mon, 23 Sep 2019 23:02:02 GMT):
Hello - I am getting a orderer panic upon enabling promethus with different TLS certificate for client & server part for RAFT node.
```
2019-09-23 22:59:43.612 UTC [orderer.common.cluster] loadVerifier -> INFO 00b Loaded verifier for channel goldsac from config block at index 2
2019-09-23 22:59:43.634 UTC [orderer.common.cluster] loadVerifier -> INFO 00c Loaded verifier for channel public from config block at index 5
2019-09-23 22:59:43.640 UTC [orderer.common.cluster] loadVerifier -> INFO 00d Loaded verifier for channel testchainid from config block at index 7
2019-09-23 22:59:43.640 UTC [orderer.common.server] initializeServerConfig -> INFO 00e Starting orderer with TLS enabled
panic: duplicate metrics collector registration attempted
goroutine 1 [running]:
github.com/hyperledger/fabric/vendor/github.com/prometheus/client_golang/prometheus.(*Registry).MustRegister(0xc0000d5d10, 0xc00097d9b0, 0x1, 0x1)
/go/src/github.com/hyperledger/fabric/vendor/github.com/prometheus/client_golang/prometheus/registry.go:387 +0xad
github.com/hyperledger/fabric/vendor/github.com/prometheus/client_golang/prometheus.MustRegister(0xc00097d9b0, 0x1, 0x1)
/go/src/github.com/hyperledger/fabric/vendor/github.com/prometheus/client_golang/prometheus/registry.go:172 +0x53
github.com/hyperledger/fabric/vendor/github.com/go-kit/kit/metrics/prometheus.NewCounterFrom(0x148371a, 0x4, 0x148363a, 0x4, 0x1489869, 0xb, 0x14c6470, 0x4f, 0x0, 0x0, ...)
/go/src/github.com/hyperledger/fabric/vendor/github.com/go-kit/kit/metrics/prometheus/prometheus.go:24 +0xe3
github.com/hyperledger/fabric/common/metrics/prometheus.(*Provider).NewCounter(0x1de4b18, 0x148371a, 0x4, 0x148363a, 0x4, 0x1489869, 0xb, 0x14c6470, 0x4f, 0x0, ...)
/go/src/github.com/hyperledger/fabric/common/metrics/prometheus/provider.go:20 +0x138
github.com/hyperledger/fabric/core/comm.NewServerStatsHandler(0x15bde60, 0x1de4b18, 0x2)
/go/src/github.com/hyperledger/fabric/core/comm/metrics.go:29 +0x74
github.com/hyperledger/fabric/core/comm.NewGRPCServerFromListener(0x15c3820, 0xc0000b4958, 0x12a05f200, 0xc0001ca2d0, 0x1d86bc0, 0xc000521ca0, 0x2, 0x2, 0xc000521cb0, 0x2, ...)
/go/src/github.com/hyperledger/fabric/core/comm/server.go:152 +0x87e
github.com/hyperledger/fabric/core/comm.NewGRPCServer(0xc0006d1980, 0xc, 0x0, 0xc0001ca2d0, 0x1d86bc0, 0xc000521ca0, 0x2, 0x2, 0xc000521cb0, 0x2, ...)
/go/src/github.com/hyperledger/fabric/core/comm/server.go:55 +0x14b
github.com/hyperledger/fabric/orderer/common/server.configureClusterListener(0xc000203200, 0x0, 0xc0001ca240, 0x1d86bc0, 0xc000521ca0, 0x2, 0x2, 0xc000521cb0, 0x2, 0x2, ...)
/go/src/github.com/hyperledger/fabric/orderer/common/server/main.go:376 +0x78c
github.com/hyperledger/fabric/orderer/common/server.Start(0x148462a, 0x5, 0xc000203200)
/go/src/github.com/hyperledger/fabric/orderer/common/server/main.go:141 +0xdf9
github.com/hyperledger/fabric/orderer/common/server.Main()
/go/src/github.com/hyperledger/fabric/orderer/common/server/main.go:91 +0x1ce
main.main()
/go/src/github.com/hyperledger/fabric/orderer/main.go:15 +0x20
```
```
- ORDERER_OPERATIONS_LISTENADDRESS=:36001
- ORDERER_METRICS_PROVIDER=prometheus
- ORDERER_OPERATIONS_TLS_ENABLED=false
- ORDERER_GENERAL_CLUSTER_CLIENTCERTIFICATE=/var/hyperledger/orderer/tlsclient/ord03.clsorder.cit.clsnet.pem
- ORDERER_GENERAL_CLUSTER_CLIENTPRIVATEKEY=/var/hyperledger/orderer/tlsclient/ord03.clsorder.cit.clsnet.sk
- ORDERER_GENERAL_CLUSTER_ROOTCAS=[/var/hyperledger/orderer/tlsintermediatecerts/tls.ca01.cit.clsnet.pem]
- ORDERER_GENERAL_CLUSTER_SERVERCERTIFICATE=/var/hyperledger/orderer/tlsserver/ord03.clsorder.cit.clsnet.pem
- ORDERER_GENERAL_CLUSTER_SERVERPRIVATEKEY=/var/hyperledger/orderer/tlsserver/ord03.clsorder.cit.clsnet.sk
- ORDERER_GENERAL_CLUSTER_LISTENPORT=5555
- ORDERER_GENERAL_CLUSTER_LISTENADDRESS=0.0.0.0
```
If i disable metric provider, orderer stands up and works.
```
#- ORDERER_OPERATIONS_LISTENADDRESS=:36001
#- ORDERER_METRICS_PROVIDER=prometheus
- ORDERER_OPERATIONS_TLS_ENABLED=false
- ORDERER_GENERAL_CLUSTER_CLIENTCERTIFICATE=/var/hyperledger/orderer/tlsclient/ord03.clsorder.cit.clsnet.pem
- ORDERER_GENERAL_CLUSTER_CLIENTPRIVATEKEY=/var/hyperledger/orderer/tlsclient/ord03.clsorder.cit.clsnet.sk
- ORDERER_GENERAL_CLUSTER_ROOTCAS=[/var/hyperledger/orderer/tlsintermediatecerts/tls.ca01.cit.clsnet.pem]
- ORDERER_GENERAL_CLUSTER_SERVERCERTIFICATE=/var/hyperledger/orderer/tlsserver/ord03.clsorder.cit.clsnet.pem
- ORDERER_GENERAL_CLUSTER_SERVERPRIVATEKEY=/var/hyperledger/orderer/tlsserver/ord03.clsorder.cit.clsnet.sk
- ORDERER_GENERAL_CLUSTER_LISTENPORT=5555
- ORDERER_GENERAL_CLUSTER_LISTENADDRESS=0.0.0.0
```
rahulhegde (Mon, 23 Sep 2019 23:02:02 GMT):
Hello - I am getting a orderer panic upon enabling promethus with different client + server TLS certificate for RAFT node.
```
2019-09-23 22:59:43.612 UTC [orderer.common.cluster] loadVerifier -> INFO 00b Loaded verifier for channel goldsac from config block at index 2
2019-09-23 22:59:43.634 UTC [orderer.common.cluster] loadVerifier -> INFO 00c Loaded verifier for channel public from config block at index 5
2019-09-23 22:59:43.640 UTC [orderer.common.cluster] loadVerifier -> INFO 00d Loaded verifier for channel testchainid from config block at index 7
2019-09-23 22:59:43.640 UTC [orderer.common.server] initializeServerConfig -> INFO 00e Starting orderer with TLS enabled
panic: duplicate metrics collector registration attempted
goroutine 1 [running]:
github.com/hyperledger/fabric/vendor/github.com/prometheus/client_golang/prometheus.(*Registry).MustRegister(0xc0000d5d10, 0xc00097d9b0, 0x1, 0x1)
/go/src/github.com/hyperledger/fabric/vendor/github.com/prometheus/client_golang/prometheus/registry.go:387 +0xad
github.com/hyperledger/fabric/vendor/github.com/prometheus/client_golang/prometheus.MustRegister(0xc00097d9b0, 0x1, 0x1)
/go/src/github.com/hyperledger/fabric/vendor/github.com/prometheus/client_golang/prometheus/registry.go:172 +0x53
github.com/hyperledger/fabric/vendor/github.com/go-kit/kit/metrics/prometheus.NewCounterFrom(0x148371a, 0x4, 0x148363a, 0x4, 0x1489869, 0xb, 0x14c6470, 0x4f, 0x0, 0x0, ...)
/go/src/github.com/hyperledger/fabric/vendor/github.com/go-kit/kit/metrics/prometheus/prometheus.go:24 +0xe3
github.com/hyperledger/fabric/common/metrics/prometheus.(*Provider).NewCounter(0x1de4b18, 0x148371a, 0x4, 0x148363a, 0x4, 0x1489869, 0xb, 0x14c6470, 0x4f, 0x0, ...)
/go/src/github.com/hyperledger/fabric/common/metrics/prometheus/provider.go:20 +0x138
github.com/hyperledger/fabric/core/comm.NewServerStatsHandler(0x15bde60, 0x1de4b18, 0x2)
/go/src/github.com/hyperledger/fabric/core/comm/metrics.go:29 +0x74
github.com/hyperledger/fabric/core/comm.NewGRPCServerFromListener(0x15c3820, 0xc0000b4958, 0x12a05f200, 0xc0001ca2d0, 0x1d86bc0, 0xc000521ca0, 0x2, 0x2, 0xc000521cb0, 0x2, ...)
/go/src/github.com/hyperledger/fabric/core/comm/server.go:152 +0x87e
github.com/hyperledger/fabric/core/comm.NewGRPCServer(0xc0006d1980, 0xc, 0x0, 0xc0001ca2d0, 0x1d86bc0, 0xc000521ca0, 0x2, 0x2, 0xc000521cb0, 0x2, ...)
/go/src/github.com/hyperledger/fabric/core/comm/server.go:55 +0x14b
github.com/hyperledger/fabric/orderer/common/server.configureClusterListener(0xc000203200, 0x0, 0xc0001ca240, 0x1d86bc0, 0xc000521ca0, 0x2, 0x2, 0xc000521cb0, 0x2, 0x2, ...)
/go/src/github.com/hyperledger/fabric/orderer/common/server/main.go:376 +0x78c
github.com/hyperledger/fabric/orderer/common/server.Start(0x148462a, 0x5, 0xc000203200)
/go/src/github.com/hyperledger/fabric/orderer/common/server/main.go:141 +0xdf9
github.com/hyperledger/fabric/orderer/common/server.Main()
/go/src/github.com/hyperledger/fabric/orderer/common/server/main.go:91 +0x1ce
main.main()
/go/src/github.com/hyperledger/fabric/orderer/main.go:15 +0x20
```
```
- ORDERER_OPERATIONS_LISTENADDRESS=:36001
- ORDERER_METRICS_PROVIDER=prometheus
- ORDERER_OPERATIONS_TLS_ENABLED=false
- ORDERER_GENERAL_CLUSTER_CLIENTCERTIFICATE=/var/hyperledger/orderer/tlsclient/ord03.clsorder.cit.clsnet.pem
- ORDERER_GENERAL_CLUSTER_CLIENTPRIVATEKEY=/var/hyperledger/orderer/tlsclient/ord03.clsorder.cit.clsnet.sk
- ORDERER_GENERAL_CLUSTER_ROOTCAS=[/var/hyperledger/orderer/tlsintermediatecerts/tls.ca01.cit.clsnet.pem]
- ORDERER_GENERAL_CLUSTER_SERVERCERTIFICATE=/var/hyperledger/orderer/tlsserver/ord03.clsorder.cit.clsnet.pem
- ORDERER_GENERAL_CLUSTER_SERVERPRIVATEKEY=/var/hyperledger/orderer/tlsserver/ord03.clsorder.cit.clsnet.sk
- ORDERER_GENERAL_CLUSTER_LISTENPORT=5555
- ORDERER_GENERAL_CLUSTER_LISTENADDRESS=0.0.0.0
```
If i disable metric provider, orderer stands up and works.
```
#- ORDERER_OPERATIONS_LISTENADDRESS=:36001
#- ORDERER_METRICS_PROVIDER=prometheus
- ORDERER_OPERATIONS_TLS_ENABLED=false
- ORDERER_GENERAL_CLUSTER_CLIENTCERTIFICATE=/var/hyperledger/orderer/tlsclient/ord03.clsorder.cit.clsnet.pem
- ORDERER_GENERAL_CLUSTER_CLIENTPRIVATEKEY=/var/hyperledger/orderer/tlsclient/ord03.clsorder.cit.clsnet.sk
- ORDERER_GENERAL_CLUSTER_ROOTCAS=[/var/hyperledger/orderer/tlsintermediatecerts/tls.ca01.cit.clsnet.pem]
- ORDERER_GENERAL_CLUSTER_SERVERCERTIFICATE=/var/hyperledger/orderer/tlsserver/ord03.clsorder.cit.clsnet.pem
- ORDERER_GENERAL_CLUSTER_SERVERPRIVATEKEY=/var/hyperledger/orderer/tlsserver/ord03.clsorder.cit.clsnet.sk
- ORDERER_GENERAL_CLUSTER_LISTENPORT=5555
- ORDERER_GENERAL_CLUSTER_LISTENADDRESS=0.0.0.0
```
Deepakshinde (Wed, 25 Sep 2019 11:01:20 GMT):
Hi All, I am using fabric 1.4.3 with raft orderer getting error on executing below commands
Deepakshinde (Wed, 25 Sep 2019 11:01:34 GMT):
peer chaincode install -n ldbc -v 1.2 -p ldbc
Deepakshinde (Wed, 25 Sep 2019 11:01:55 GMT):
peer chaincode upgrade -o $ORDERER_ADDRESS --tls --cafile $ORDERER_ROOTCA_CERT -C legaldescriptionchannel -n ldbc -v 1.2 -c '{"Args":[]}' --clientauth --keyfile $ORDERER_TLS_CLIENTKEY_FILE --certfile $ORDERER_TLS_CLIENTCERT_FILE
Deepakshinde (Wed, 25 Sep 2019 11:02:16 GMT):
Error screnshot attaching
Deepakshinde (Wed, 25 Sep 2019 11:03:19 GMT):
chaincodeUpgradeError.JPG
Deepakshinde (Wed, 25 Sep 2019 11:04:47 GMT):
Then i want to upgrade endorsing parameter with the above command -
Deepakshinde (Wed, 25 Sep 2019 11:04:53 GMT):
peer chaincode upgrade -o $ORDERER_ADDRESS --tls --cafile $CORE_PEER_TLS_ROOTCERT_FILE -C legaldescriptionchannel -n ldbc -v 1.2 -c '{"Args":[]}' --clientauth --keyfile $CORE_PEER_TLS_CLIENTKEY_FILE --certfile $CORE_PEER_TLS_CLIENTCERT_FILE -P "AND('Org1.member', 'Org3.member')"
unlimited (Thu, 26 Sep 2019 02:05:52 GMT):
Hi, I'm trying to understand endorsements. In the PaperNet trading example, say A sells a stock to B. Both A and B have to agree on the price and accept the trade, and this can be set through endorsements. However it seems like endorsements is done automatically on the back end, instead of, say something pops up on the B user interface and alerts them to press the agree button or something?
Utsav_Solanki (Mon, 30 Sep 2019 05:56:36 GMT):
while joining channel i am getting
Error: proposal failed (err: bad proposal response 500: cannot create ledger from genesis block: LedgerID already exists)
knagware9 (Mon, 30 Sep 2019 12:23:08 GMT):
channel already exist , try to remove existing containers and retry
Utsav_Solanki (Mon, 30 Sep 2019 12:24:32 GMT):
i removed container but same error
Utsav_Solanki (Mon, 30 Sep 2019 12:28:25 GMT):
i am looking for location of ledgerID location directory
soumyanayak (Tue, 01 Oct 2019 06:09:06 GMT):
when tried joining a peer to the channel its giving the below error
peer1 | 2019-10-01 06:06:29.053 UTC [gossip.service] updateAnchors -> ERRO 321 Tried joining channel legaldescriptionchannel but our org( OrgA ), isn't among the orgs of the channel: [Org1] , aborting.
What does it mean
knagware9 (Tue, 01 Oct 2019 06:41:16 GMT):
try docker network prune and then restrat
Utsav_Solanki (Tue, 01 Oct 2019 06:53:12 GMT):
s
soumyanayak (Tue, 01 Oct 2019 09:38:51 GMT):
actually resolved this issue -- it comes when a config update is done adding anew org .. so Org1 was initially there and later orgA was added .. this issue was gone as per yacovm we can ignore this . it came for once twice and fater sync up with orderer everything ran fine
soumyanayak (Tue, 01 Oct 2019 13:33:50 GMT):
Hi All,
Any idea from CLI how to run the invoke chaincode command to send to multiple anchor peers from different orgs for endorsement?
soumyanayak (Tue, 01 Oct 2019 13:33:50 GMT):
Hi All,
Any idea from CLI how to run the invoke chaincode command to send to multiple anchor peers from different orgs for endorsement in Mutual TLS fabric set up?
indirajith (Wed, 02 Oct 2019 12:15:43 GMT):
Hi all, anyone has encountered the following error when instantiating chaincode?
" Error: could not assemble transaction, err proposal response was not successful, error code 500, msg chaincode registration failed: container exited with 2 ". I already have the following line for peers, orderers and cli in docker-compose file: GODEBUG=netdns=go .
indirajith (Wed, 02 Oct 2019 13:17:46 GMT):
Fixed this. the problem was with docker networking and its mode. Made sure the chaincode container and their peers are on the same docker network, it fixed the error.
soumyanayak (Thu, 03 Oct 2019 07:13:08 GMT):
Now am Able to invoke using the *--peerAddresses* and *--tlsRootCertFiles* attributes
soumyanayak (Thu, 03 Oct 2019 07:14:26 GMT):
But one more doubt i had was - lets say OrgA and OrgB peers have to endorse a transaction --- and OrgA initiates a transaction , so how orgA would be aware of the root certificate file for OrgB?
sanket1211 (Sat, 05 Oct 2019 09:14:42 GMT):
if there are three endorsers and i want to execute a transaction.i want a transaction proposal sent to three endorsers to accept or reject the transaction manually.can it be done? if yes plz let me know.
soumyanayak (Thu, 10 Oct 2019 13:02:38 GMT):
Hi All,
soumyanayak (Thu, 10 Oct 2019 13:06:25 GMT):
Hi All,
I am trying to set up Private Data between two orgs.
So when i am installing the chaincode for private data communication and instantiating from one of the orgs - the chaincode shows as instantiated from both the orgs but i could see the docker container of chaincode created only in one org but when checked in another machine for the other org the chaincode container is not getting created. I am not sure why. Can anybody help on this
soumyanayak (Thu, 10 Oct 2019 13:06:25 GMT):
Hi All,
Fabric - v1.4.3
I am trying to set up Private Data between two orgs.
So when i am installing the chaincode for private data communication and instantiating from one of the orgs - the chaincode shows as instantiated from both the orgs but i could see the docker container of chaincode created only in one org but when checked in another machine for the other org the chaincode container is not getting created. I am not sure why. Can anybody help on this
soumyanayak (Tue, 15 Oct 2019 10:16:26 GMT):
Any update anybody - This is the issue i am getting
Error: endorsement failure during query. response: status:500 message:"failed to execute transaction e77af488e03537a465c30e56c6c13330f4c7f8aae8eae1a92656607c91c8df83: [channel legaldescriptionchannel] failed to get chaincode container info for ldbc:1.0: could not get chaincode code: chaincode fingerprint mismatch: data mismatch"
soumyanayak (Tue, 15 Oct 2019 11:04:13 GMT):
Resolved the issue . The chaincode folder structure should be exactly same in both the peers to get the same hash fingerprintID which will create chaincode conatiners for both the org peers
soumyanayak (Tue, 15 Oct 2019 13:10:48 GMT):
When i am installing the private chaincode - i checked in both the peer org machines the IDs of the installed chaincode is same but still the container was only created in the machine from where the instantiate command was run for only one org.
aatkddny (Wed, 16 Oct 2019 16:22:49 GMT):
so the couchedb instances on two of our peers have got themselves out of synch somehow.
an asset is missing so one thinks it's an upsert and the other thinks it isn't there. this is causing "issues" as you can imagine.
if i take down the offending peer, delete the ledger and the couchdb storage and bring it back up it's supposed to catch itself back up and self-sync.
other than reinstalling chaincode is there anything else that needs to be done to get this to work?
yacovm (Wed, 16 Oct 2019 16:39:58 GMT):
@aatkddny - what version of Fabric are you using?
yacovm (Wed, 16 Oct 2019 16:41:28 GMT):
there is a rollback command https://hyperledger-fabric.readthedocs.io/en/release-1.4/commands/peernode.html
yacovm (Wed, 16 Oct 2019 16:41:39 GMT):
starting from some Fabric version ( I don't remember... 1.4.2 ? )
aatkddny (Wed, 16 Oct 2019 17:31:41 GMT):
1.4 - thx, I'll look and see if that does the trick.
yacovm (Wed, 16 Oct 2019 18:17:31 GMT):
@aatkddny can you somehow help us investigate why it happened?
yacovm (Wed, 16 Oct 2019 18:17:41 GMT):
do you have logs of the peers, perhaps?
yacovm (Wed, 16 Oct 2019 18:18:13 GMT):
if you have any information that can help investigate, please open a JIRA
aatkddny (Wed, 16 Oct 2019 18:52:59 GMT):
they were overwritten when we restarted the peer.
the problem started in event processing we think.
there's a bunch of workflow that's non germane to do with the order things can be added, but in essence we add an asset and throw an event that then goes and looks for orphan children and adds references to them to the original asset. i don't work on this part of the application, so this is second hand.
what we saw was a tx for peer1 passing the proposal and the same for peer0 failing for one org.
it passed the policy so went to the orderer. there it hung until it timed out. which isn't really a great way to handle things imo, but i digress.
looking inside the logs for peer0 we saw this:
```
10/16/2019 11:31:23 AM 2019-10-16 15:31:23.101 UTC [chaincode] HandleTransaction -> ERRO 155a [2cc0fa7a] Failed to handle GET_STATE. error: no revision tag detected
10/16/2019 11:31:23 AM github.com/hyperledger/fabric/core/ledger/util/couchdb.getRevisionHeader
10/16/2019 11:31:23 AM /opt/gopath/src/github.com/hyperledger/fabric/core/ledger/util/couchdb/couchdb.go:735
10/16/2019 11:31:23 AM github.com/hyperledger/fabric/core/ledger/util/couchdb.(*CouchDatabase).ReadDoc
10/16/2019 11:31:23 AM /opt/gopath/src/github.com/hyperledger/fabric/core/ledger/util/couchdb/couchdb.go:788
10/16/2019 11:31:23 AM github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/statedb/statecouchdb.(*VersionedDB).GetState
10/16/2019 11:31:23 AM /opt/gopath/src/github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/statedb/statecouchdb/statecouchdb.go:297
10/16/2019 11:31:23 AM github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/privacyenabledstate.(*CommonStorageDB).GetState
```
A little google-is-your-friend let to a stackoverflow post about reads on empty strings in couchdb throwing this error - which let to the supposition above.
As an aside we got round it by taking down peer0, running the same transaction in the channel and starting peer0 after it completed.
Next time I'll try the rollback though.
Not much help to you, but the best I have.
aatkddny (Wed, 16 Oct 2019 18:52:59 GMT):
@yacovm they were overwritten when we restarted the peer.
the problem started in event processing we think.
there's a bunch of workflow that's non germane to do with the order things can be added, but in essence we add an asset and throw an event that then goes and looks for orphan children and adds references to them to the original asset. i don't work on this part of the application, so this is second hand.
what we saw was a tx for peer1 passing the proposal and the same for peer0 failing for one org.
it passed the policy so went to the orderer. there it hung until it timed out. which isn't really a great way to handle things imo, but i digress.
looking inside the logs for peer0 we saw this:
```
10/16/2019 11:31:23 AM 2019-10-16 15:31:23.101 UTC [chaincode] HandleTransaction -> ERRO 155a [2cc0fa7a] Failed to handle GET_STATE. error: no revision tag detected
10/16/2019 11:31:23 AM github.com/hyperledger/fabric/core/ledger/util/couchdb.getRevisionHeader
10/16/2019 11:31:23 AM /opt/gopath/src/github.com/hyperledger/fabric/core/ledger/util/couchdb/couchdb.go:735
10/16/2019 11:31:23 AM github.com/hyperledger/fabric/core/ledger/util/couchdb.(*CouchDatabase).ReadDoc
10/16/2019 11:31:23 AM /opt/gopath/src/github.com/hyperledger/fabric/core/ledger/util/couchdb/couchdb.go:788
10/16/2019 11:31:23 AM github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/statedb/statecouchdb.(*VersionedDB).GetState
10/16/2019 11:31:23 AM /opt/gopath/src/github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/statedb/statecouchdb/statecouchdb.go:297
10/16/2019 11:31:23 AM github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/privacyenabledstate.(*CommonStorageDB).GetState
```
A little google-is-your-friend let to a stackoverflow post about reads on empty strings in couchdb throwing this error - which let to the supposition above.
As an aside we got round it by taking down peer0, running the same transaction in the channel and starting peer0 after it completed.
Next time I'll try the rollback though.
Not much help to you, but the best I have.
yacovm (Wed, 16 Oct 2019 20:31:13 GMT):
@dave.enyeart ^
aatkddny (Thu, 17 Oct 2019 18:24:20 GMT):
so installing chaincode for the first time that builds a set of indexes.
it says it built them ok and instantiates fine, but then when we try to invoke it we get this:
```2019-10-17 18:09:14.265 UTC [chaincode] ProcessStream -> ERRO 320c handling chaincode support stream: rpc error: code = Canceled desc = context canceled
10/17/2019 2:09:14 PM receive failed
10/17/2019 2:09:14 PM github.com/hyperledger/fabric/core/chaincode.(*Handler).ProcessStream
10/17/2019 2:09:14 PM /opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:427
10/17/2019 2:09:14 PM github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).HandleChaincodeStream
10/17/2019 2:09:14 PM /opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:191
10/17/2019 2:09:14 PM github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Register
10/17/2019 2:09:14 PM /opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:196
10/17/2019 2:09:14 PM github.com/hyperledger/fabric/core/chaincode/accesscontrol.(*interceptor).Register
10/17/2019 2:09:14 PM /opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/accesscontrol/interceptor.go:57
10/17/2019 2:09:14 PM github.com/hyperledger/fabric/protos/peer._ChaincodeSupport_Register_Handler
10/17/2019 2:09:14 PM /opt/gopath/src/github.com/hyperledger/fabric/protos/peer/chaincode_shim.pb.go:1066
10/17/2019 2:09:14 PM github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).processStreamingRPC
10/17/2019 2:09:14 PM /opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:1124
10/17/2019 2:09:14 PM github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).handleStream
10/17/2019 2:09:14 PM /opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:1212
10/17/2019 2:09:14 PM github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1
10/17/2019 2:09:14 PM /opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:686
10/17/2019 2:09:14 PM runtime.goexit
10/17/2019 2:09:14 PM /opt/go/src/runtime/asm_amd64.s:1333```
Never saw this before. Anyone know why it is doing this off the top of their head?
aatkddny (Thu, 17 Oct 2019 18:24:20 GMT):
so installing some GO chaincode for the first time that builds a set of indexes in couchDB.
it says it built them ok and instantiates fine, but then when we try to invoke it we get this:
```2019-10-17 18:09:14.265 UTC [chaincode] ProcessStream -> ERRO 320c handling chaincode support stream: rpc error: code = Canceled desc = context canceled
10/17/2019 2:09:14 PM receive failed
10/17/2019 2:09:14 PM github.com/hyperledger/fabric/core/chaincode.(*Handler).ProcessStream
10/17/2019 2:09:14 PM /opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:427
10/17/2019 2:09:14 PM github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).HandleChaincodeStream
10/17/2019 2:09:14 PM /opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:191
10/17/2019 2:09:14 PM github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Register
10/17/2019 2:09:14 PM /opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:196
10/17/2019 2:09:14 PM github.com/hyperledger/fabric/core/chaincode/accesscontrol.(*interceptor).Register
10/17/2019 2:09:14 PM /opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/accesscontrol/interceptor.go:57
10/17/2019 2:09:14 PM github.com/hyperledger/fabric/protos/peer._ChaincodeSupport_Register_Handler
10/17/2019 2:09:14 PM /opt/gopath/src/github.com/hyperledger/fabric/protos/peer/chaincode_shim.pb.go:1066
10/17/2019 2:09:14 PM github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).processStreamingRPC
10/17/2019 2:09:14 PM /opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:1124
10/17/2019 2:09:14 PM github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).handleStream
10/17/2019 2:09:14 PM /opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:1212
10/17/2019 2:09:14 PM github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1
10/17/2019 2:09:14 PM /opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:686
10/17/2019 2:09:14 PM runtime.goexit
10/17/2019 2:09:14 PM /opt/go/src/runtime/asm_amd64.s:1333```
Never saw this before. Anyone know why it is doing this off the top of their head?
aatkddny (Thu, 17 Oct 2019 18:24:20 GMT):
so installing some GO chaincode for the first time that builds a set of indexes in couchDB.
it says it built them ok and instantiates fine, but then when we try to invoke it we get this:
```2019-10-17 18:09:14.265 UTC [chaincode] ProcessStream -> ERRO 320c handling chaincode support stream: rpc error: code = Canceled desc = context canceled
10/17/2019 2:09:14 PM receive failed
10/17/2019 2:09:14 PM github.com/hyperledger/fabric/core/chaincode.(*Handler).ProcessStream
10/17/2019 2:09:14 PM /opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:427
10/17/2019 2:09:14 PM github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).HandleChaincodeStream
10/17/2019 2:09:14 PM /opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:191
10/17/2019 2:09:14 PM github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Register
10/17/2019 2:09:14 PM /opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:196
10/17/2019 2:09:14 PM github.com/hyperledger/fabric/core/chaincode/accesscontrol.(*interceptor).Register
10/17/2019 2:09:14 PM /opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/accesscontrol/interceptor.go:57
10/17/2019 2:09:14 PM github.com/hyperledger/fabric/protos/peer._ChaincodeSupport_Register_Handler
10/17/2019 2:09:14 PM /opt/gopath/src/github.com/hyperledger/fabric/protos/peer/chaincode_shim.pb.go:1066
10/17/2019 2:09:14 PM github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).processStreamingRPC
10/17/2019 2:09:14 PM /opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:1124
10/17/2019 2:09:14 PM github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).handleStream
10/17/2019 2:09:14 PM /opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:1212
10/17/2019 2:09:14 PM github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1
10/17/2019 2:09:14 PM /opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:686
10/17/2019 2:09:14 PM runtime.goexit
10/17/2019 2:09:14 PM /opt/go/src/runtime/asm_amd64.s:1333```
Never saw this before. Anyone know why it is doing this off the top of their head?
Chaincode is unchanged. The only thing that's new is the json to define the indexes in a META-INF folder.
metadata (Fri, 18 Oct 2019 06:52:51 GMT):
Has joined the channel.
SamYuan1990 (Wed, 30 Oct 2019 13:47:01 GMT):
Has joined the channel.
SamYuan1990 (Wed, 30 Oct 2019 13:47:02 GMT):
Hi all, I have go vandor folder in my chaincode install path and the peer returns 200 in install, but during Instantiating, it says 500, error can not find xxx in vendor tree
braduf (Fri, 01 Nov 2019 17:52:20 GMT):
Hi @SamYuan1990 , did you do a go get for xxx and are you sure it is in your vendor folder?
SamYuan1990 (Tue, 05 Nov 2019 04:48:24 GMT):
sorry for reply late, I noticed that I can't use latest image(2.0-xxx image) to build a chaincode in 1.4 version
jyxie2007 (Mon, 18 Nov 2019 03:59:52 GMT):
Has joined the channel.
SamYuan1990 (Mon, 18 Nov 2019 07:29:17 GMT):
Having questions about gossip between peer nodes apperciate for answer.
Following 1.4 code, it seems that gossip leader comparing a fixed id base on peer node's msp. (github.com/hyperledger/fabric@v1.4.3/gossip/election/election.go, NewLeaderElectionService)
So, if we have 5 peer, with msp, the leader will be the one having smallest or biggest ID from msp?
Here is how I tracing the source code.
peer node start ( peer.Initialize(func(cid string) -> peer.go service.GetGossipService().InitializeChannel... )
yacovm (Mon, 18 Nov 2019 11:54:37 GMT):
yep that is correct
yacovm (Mon, 18 Nov 2019 11:54:54 GMT):
the smallest / largest ID (don't remember which one)
RyanMathison (Mon, 25 Nov 2019 18:58:28 GMT):
Has joined the channel.
RyanMathison (Mon, 25 Nov 2019 18:58:32 GMT):
I am running into issues when trying commit a transaction when there is an "AND" policy on the channel. ```
```
RyanMathison (Mon, 25 Nov 2019 19:08:28 GMT):
I am running into issues when trying commit a transaction when there is an "AND" policy on the channel. ```
We have built on top of the balance transfer node app and previously we had no policy on the channel. ```
``` In order to make the node app more reliable and dynamic I have started using service discovery. ```
``` Everything worked fine, so I decided to see what would happen when I used a policy. ```
``` Now everything still works fine when I use an OR policy or a OutOf 1 policy, but if I use an AND policy or a OutOf 2+ then I get "signature set did not satisfy policy"```
Thinking this was due somehow to service discovery, I went back to the previous version of the node app and it still failed.```
I don't believe this is an issue of missing signatures as service discovery gets signatures from each org and in our previous app we were defaulting to signatures from each org as well.```
I have seen a stack overflow thread, https://stackoverflow.com/questions/54033274/hyperledger-endorsement-failure-when-invoking-chaincode-failed-signature-set?rq=1, where the same issue was seen with balance```
I have turned debugging on at the peer and am printing out everything we are sending to the orderer and everything seems to be there. Has anyone run into something similar?
``` transfer.```
```
```
```
```
```
RyanMathison (Mon, 25 Nov 2019 19:08:28 GMT):
I am running into issues when trying commit a transaction when there is an "AND" policy on the channel.
We have built on top of the balance transfer node app and previously we had no policy on the channel.
In order to make the node app more reliable and dynamic I have started using service discovery.
Everything worked fine, so I decided to see what would happen when I used a policy.
Now everything still works fine when I use an OR policy or a OutOf 1 policy, but if I use an AND policy or a OutOf 2+ then I get "signature set did not satisfy policy"
Thinking this was due somehow to service discovery, I went back to the previous version of the node app and it still failed.
I don't believe this is an issue of missing signatures as service discovery gets signatures from each org and in our previous app we were defaulting to signatures from each org as well.
I have seen a stack overflow thread, https://stackoverflow.com/questions/54033274/hyperledger-endorsement-failure-when-invoking-chaincode-failed-signature-set?rq=1, where the same issue was seen with balance
I have turned debugging on at the peer and am printing out everything we are sending to the orderer and everything seems to be there. Has anyone run into something similar?
``` transfer.```
```
```
```
```
```
RyanMathison (Mon, 25 Nov 2019 19:08:28 GMT):
I am running into issues when trying commit a transaction when there is an "AND" policy on the channel.
We have built on top of the balance transfer node app and previously we had no policy on the channel.
In order to make the node app more reliable and dynamic I have started using service discovery.
Everything worked fine, so I decided to see what would happen when I used a policy.
Now everything still works fine when I use an OR policy or a OutOf 1 policy, but if I use an AND policy or a OutOf 2+ then I get "signature set did not satisfy policy"
Thinking this was due somehow to service discovery, I went back to the previous version of the node app and it still failed.
I don't believe this is an issue of missing signatures as service discovery gets signatures from each org and in our previous app we were defaulting to signatures from each org as well.
I have seen a stack overflow thread, https://stackoverflow.com/questions/54033274/hyperledger-endorsement-failure-when-invoking-chaincode-failed-signature-set?rq=1, where the same issue was seen with balance transfer.
I have turned debugging on at the peer and am printing out everything we are sending to the orderer and everything seems to be there. Has anyone run into something similar?
```
```
```
```
RyanMathison (Mon, 25 Nov 2019 19:08:28 GMT):
I am running into issues when trying commit a transaction when there is an "AND" policy on the channel.
We have built on top of the balance transfer node app and previously we had no policy on the channel.
In order to make the node app more reliable and dynamic I have started using service discovery.
Everything worked fine, so I decided to see what would happen when I used a policy.
Now everything still works fine when I use an OR policy or a OutOf 1 policy, but if I use an AND policy or a OutOf 2+ then I get "signature set did not satisfy policy"
Thinking this was due somehow to service discovery, I went back to the previous version of the node app and it still failed.
I don't believe this is an issue of missing signatures as service discovery gets signatures from each org and in our previous app we were defaulting to signatures from each org as well.
I have seen a stack overflow thread, https://stackoverflow.com/questions/54033274/hyperledger-endorsement-failure-when-invoking-chaincode-failed-signature-set?rq=1, where the same issue was seen with balance transfer.
I have turned debugging on at the peer and am printing out everything we are sending to the orderer and everything seems to be there. Has anyone run into something similar?
yacovm (Mon, 25 Nov 2019 21:26:39 GMT):
@RyanMathison you can try to use the discovery CLI https://hyperledger-fabric.readthedocs.io/en/release-1.4/discovery-cli.html
yacovm (Mon, 25 Nov 2019 21:26:48 GMT):
and query the peer, imitating the SDK
yacovm (Mon, 25 Nov 2019 21:26:58 GMT):
and then you can tell me what is the result you get back from the peer
yacovm (Mon, 25 Nov 2019 21:27:55 GMT):
in any case what you say is weird, because Noutof(2, '0', '1') is basically an AND
yacovm (Mon, 25 Nov 2019 21:28:02 GMT):
which is super basic... it should work
yacovm (Mon, 25 Nov 2019 21:29:32 GMT):
make an endorsers query to the peer to ask it and then tell what you get
RyanMathison (Mon, 25 Nov 2019 22:09:03 GMT):
Will do, thank you
RyanMathison (Tue, 26 Nov 2019 22:15:46 GMT):
@yacovm Thank you for your help. It turns out the issue was with the chaincode. The chaincode we are using has been around a while and apparently had never been had an "AND" policy set on it. Internally the chaincode was generating an event time and adding it to the write set. So once we required more than 1 endorsement each peer generated a different write set, there was just no good way to see that it was the issue in the logs. I was able to confirm it was a read/write mismatch in the node app by using channel.compareProposalResponseResults(proposalResponses). I was also able to find a JIRA issue, https://jira.hyperledger.org/browse/FAB-14145, that pointed me in the write direction and talks about the poor log messages. Thanks again for the help.
yacovm (Wed, 27 Nov 2019 06:23:55 GMT):
@RyanMathison are you saying the node SDK doesn't compare it automatically ?
davidkel (Wed, 27 Nov 2019 08:04:12 GMT):
@yacovm No the node sdk (and I assume the other sdks as well) don't compare automatically as some consider it a performance impact so not something to be mandatory
yacovm (Wed, 27 Nov 2019 08:04:32 GMT):
how can it impact performance?
yacovm (Wed, 27 Nov 2019 08:04:37 GMT):
it's byte by byte comparison!!
davidkel (Wed, 27 Nov 2019 08:06:55 GMT):
It's always been separate, but we used to use it in composer by default but performance analysis showed it having an impact on the client so it got made optional.
yacovm (Wed, 27 Nov 2019 08:07:25 GMT):
but it's comparing bytes in memory, it should be at the worst - micro-seconds
davidkel (Wed, 27 Nov 2019 08:08:41 GMT):
I guess the performance tests were putting a lot of load on the client code with many txns and I guess the RW sets where not small
davidkel (Wed, 27 Nov 2019 08:09:13 GMT):
Also node.js is effectively single threaded
yacovm (Wed, 27 Nov 2019 08:10:06 GMT):
if you don't compare the results it means you are sending stuff with the wrong signatures
yacovm (Wed, 27 Nov 2019 08:10:21 GMT):
and there is no way the client will understand that this is the reason
yacovm (Wed, 27 Nov 2019 08:11:25 GMT):
also, most payloads are not large... you should aim to work well in the average case, not in the extreme case ;)
yacovm (Wed, 27 Nov 2019 08:11:56 GMT):
not blaming you, btw
davidkel (Wed, 27 Nov 2019 08:12:49 GMT):
Personally I like the idea of doing checks like this in the client code (plus some other checks such as determining peer disagreements at validation time) but to also make them optional in case of performance issues
davidkel (Wed, 27 Nov 2019 08:12:49 GMT):
Personally I like the idea of doing checks like this in the client code (plus some other checks such as determining peer disagreements at validation time) but to also make them optional in case of performance issues. So maybe something that's enabled by default but could turn them off.
yacovm (Wed, 27 Nov 2019 08:14:19 GMT):
@mastersingh24 your opinion ?
mastersingh24 (Wed, 27 Nov 2019 09:13:46 GMT):
The "average" case is the green path not the "bad path" - meaning there is generally no reason why as long as you collect enough endorsements with a proper setup your transaction(s) will not be valid.
The SDKs have always had the `verifyProposalResponse` method which is heavyweight as it checks signatures, etc. They also have the `compareProposalResponseResults` which just does the comparison on the results - which is what you are looking for here.
For the lower-level APIs, there's not reason to do this by default; it should be up to the developer to properly compose the API calls they want to use. I do agree that our samples should include these calls such that users are aware they exist and why/why not they might use them.
When it comes to the higher level programming model, I think we should automatically do the `compareProposalResponseResults` since we are already wrapping the lower level API
yacovm (Wed, 27 Nov 2019 09:15:00 GMT):
why not `compareProposalResponseResults` automatically?
mastersingh24 (Wed, 27 Nov 2019 09:15:17 GMT):
As an aside, there is a reason why I intentionally removed the balance transfer sample ;)
mastersingh24 (Wed, 27 Nov 2019 09:17:28 GMT):
I am not a fan of all of the hidden stuff we do in the low level API ... the reason for the higher level programming model was to hide all of the complexities ... so this is where we should do things like automatically call `compareProposalResponseResults`
david_dornseifer (Thu, 05 Dec 2019 16:01:19 GMT):
Hi everyone, just wondering how the key-level-endorsement is supposed to be used. Since that the discovery service cannot lookup the required orgs (and their peers) it seems to be up to the user to call the peers manually. Is that assumption correct?
yacovm (Thu, 05 Dec 2019 16:01:56 GMT):
you can query the chaincode for the organizations of a specific key
yacovm (Thu, 05 Dec 2019 16:02:09 GMT):
and then you can query discovery for a mapping of org -> peer list
yacovm (Thu, 05 Dec 2019 16:02:14 GMT):
and then deduce who you should contact
david_dornseifer (Thu, 05 Dec 2019 16:41:53 GMT):
@yacovm thanks for the fast answer. That means the standard way of chaincode / endorsement lookup via the discovery service cannot be used for key-level-endorsements.
david_dornseifer (Thu, 05 Dec 2019 16:43:47 GMT):
Basically all calls would require a query call first to check if a particular key that would be modified has a key level endorsement policy or not, if not the standard way to parameterize the SDK via the discovery service can be used. Otherwise, the peer endpoints need to be passed into the SDK manually.
yacovm (Thu, 05 Dec 2019 18:27:12 GMT):
@david_dornseifer are you stating something or asking me something?
david_dornseifer (Thu, 05 Dec 2019 19:23:15 GMT):
@yacovm that was just a conclusion how you would handle endorsements for chaincodes that have a combination of both, key- and chaincode-level endorsement :) . Was that conclusion correct?
yacovm (Thu, 05 Dec 2019 19:24:38 GMT):
yeah
david_dornseifer (Fri, 06 Dec 2019 04:41:44 GMT):
@yacovm thanks :)
karthiknvlr (Fri, 06 Dec 2019 05:53:44 GMT):
Has joined the channel.
indirajith (Mon, 09 Dec 2019 14:58:16 GMT):
Hi all. I get the following error when instantiating chaincode. Any help to rectify this problem?
``` Error: error endorsing chaincode: rpc error: code = Unknown desc = access denied: channel [twoorgschannel] creator org [/etc/hyperledger/org1/msp] ```
indirajith (Mon, 09 Dec 2019 14:58:16 GMT):
Hi all. I get the following error when instantiating chaincode. Any help to rectify this problem?
``` Error: could not assemble transaction, err proposal response was not successful, error code 500, msg chaincode registration failed: container exited with 2
```
RyanMathison (Thu, 12 Dec 2019 22:30:26 GMT):
@yacovm , @davidkel , @mastersingh24 Ok, so after resolving the chaincode issues, with a 4 org network I am now able to use OR and OutOf 1, 2 and 3 policies. However I am still unable to use OutOf 4 or AND policies as I get the following error, "No endorsement plan available for {"chaincodes":[{"name":"mycc". Now this makes it sound like anchor peers are not setup, https://cloud.ibm.com/docs/services/blockchain/howto?topic=blockchain-ibp-v2-troubleshooting&locale=zh-TW#ibp-v2-troubleshooting-anchor-peer, however we have setup anchor peers in each organization. Any idea what the issue may be
yacovm (Thu, 12 Dec 2019 22:31:19 GMT):
perform a peer query and see if it sees peers from other orgs
RyanMathison (Thu, 12 Dec 2019 22:52:20 GMT):
@yacovm Well I am logging the configuration returned from service discovery and it shows all 8 peers in the network, 2 per each org
yacovm (Thu, 12 Dec 2019 22:52:45 GMT):
then probably the chaincode is not installed on all of them
RyanMathison (Thu, 12 Dec 2019 22:55:54 GMT):
All anchor peers show that the chaincode is installed and instantiated
yacovm (Thu, 12 Dec 2019 22:56:25 GMT):
huh?
yacovm (Thu, 12 Dec 2019 22:56:33 GMT):
what does that even mean "all anchor peers show it"?
RyanMathison (Thu, 12 Dec 2019 22:57:00 GMT):
In the CLI I ran peer chaincode list --instantiated
RyanMathison (Thu, 12 Dec 2019 22:57:14 GMT):
For each anchor peer
yacovm (Thu, 12 Dec 2019 22:57:25 GMT):
please do a discovery peer query
yacovm (Thu, 12 Dec 2019 22:57:32 GMT):
it also tells you if the chiancode is installed :(
yacovm (Thu, 12 Dec 2019 22:57:36 GMT):
and on what peers
yacovm (Thu, 12 Dec 2019 22:57:49 GMT):
instead of doing the lousy `peer chaincode list` on several peers
yacovm (Thu, 12 Dec 2019 22:57:54 GMT):
you can do it on 1 peer only
RyanMathison (Thu, 12 Dec 2019 23:11:16 GMT):
I will have to look at it tomorrow, I keep getting failed to create new connection: context deadline exceeded
RyanMathison (Fri, 13 Dec 2019 14:00:57 GMT):
@yacovm So the results from discovery show that there are 8 peers in the network, 2 from each org, and they all have the mycc chaincode.
yacovm (Fri, 13 Dec 2019 14:10:24 GMT):
@RyanMathison - so it should work.... can you try an endorsement query and tell me what is logged in the peers?
yacovm (Fri, 13 Dec 2019 14:11:12 GMT):
use the discover CLI, not the SDK
RyanMathison (Fri, 13 Dec 2019 14:40:03 GMT):
@yacovm I get server returned: failed constructing descriptor for chaincodes:
yacovm (Fri, 13 Dec 2019 14:42:02 GMT):
What is the chaincore version installed on all peers? Is it thr same?
RyanMathison (Fri, 13 Dec 2019 14:43:51 GMT):
All are version 1.0 and we have chaincode installs scripted so that every peer gets the exact same chaincode and version installed
RyanMathison (Fri, 13 Dec 2019 16:11:53 GMT):
@yacovm I finally got the right debugging level turned on in the peers and found that it was caused by an issue in one of our configuration files. Thank you for your help and for introducing me to the discover CLI. I do have a question about discover CLI. Do you have any idea why the peer commands and discover commands can't use the same configuration? It seems to me that it is repetitive to define ENV variables for the peer command and a cofig file for the discover command when both are just looking for the certificates to contact a peer.
yacovm (Fri, 13 Dec 2019 17:14:33 GMT):
@RyanMathison i wrote the discover CLI myself
yacovm (Fri, 13 Dec 2019 17:14:49 GMT):
Because the peer CLI is unusable :joy:
yacovm (Fri, 13 Dec 2019 17:20:44 GMT):
It has zero code intersection with the peer CLI
indirajith (Mon, 16 Dec 2019 15:16:31 GMT):
Hi all, when instantiating chainode using CLI, I encounter the following error. It says the chanel's lscc is not found on couchDB. Can anyone help me understand this problem? ``` [couchdb] ReadDoc -> DEBU 804c90 [twoorgschannel_lscc] Entering ReadDoc() id=[mycc3]
2019-12-16 14:50:45.156 UTC [couchdb] handleRequest -> DEBU 804c91 Entering handleRequest() method=GET url=http://couchdbp1o1:5984 dbName=twoorgschannel_lscc
2019-12-16 14:50:45.156 UTC [couchdb] handleRequest -> DEBU 804c92 Request URL: http://couchdbp1o1:5984/twoorgschannel_lscc/mycc3?attachments=true
2019-12-16 14:50:45.156 UTC [couchdb] handleRequest -> DEBU 804c93 HTTP Request: GET /twoorgschannel_lscc/mycc3?attachments=true HTTP/1.1 | Host: couchdbp1o1:5984 | User-Agent: Go-http-client/1.1 | Accept: m
ultipart/related | Authorization: Basic cGVlcjEtb3JnMTpwMW8xY2RicHc= | Accept-Encoding: gzip | |
2019-12-16 14:50:45.162 UTC [couchdb] handleRequest -> DEBU 804c94 Error handling CouchDB request. Error:not_found, Status Code:404, Reason:missing
2019-12-16 14:50:45.162 UTC [couchdb] ReadDoc -> DEBU 804c95 [twoorgschannel_lscc] Document not found (404), returning nil value instead of 404 error ```
AbhijeetSamanta (Thu, 19 Dec 2019 05:09:08 GMT):
Has joined the channel.
AbhijeetSamanta (Tue, 24 Dec 2019 19:57:44 GMT):
Hi All, I am trying to setup on HLF on EKS. I had setup till generate artefact and cryto material. also raft orderer running, but when I am creating the peers its give error as " Could not connect to Endpoint: peer1-org1-service:7051, InternalEndpoint: peer1-org1-service:7051, PKI-ID:
konda.kalyan (Thu, 26 Dec 2019 06:00:50 GMT):
Has joined the channel.
root10 (Tue, 31 Dec 2019 14:43:02 GMT):
Has left the channel.
indirajith (Wed, 08 Jan 2020 13:25:04 GMT):
Hi all. iit seems like shim packages, peer proto packages and others are moved/ re structured. Is there any plac where I can find these changes? I am trying to run a very very basic chaincode with just two key values(a,b, 20, 100) and stuck with it instantiation failure for a long time. I am using binaries version 1.4.4 and is it necessary to package chaincode?
rahulhegde (Thu, 09 Jan 2020 13:30:45 GMT):
Hello - need clarification - @dave.enyeart
I am trying to understand, the commit to the ledger by peer & endorsement of proposal are two distinct activities and can execute during the same time period. This is also true if the commit & endorsement are working on the same keys.
Say current state of the ledger K1-V1, K2-V1
Commit will move the K1-V2, K2-V2 (fact: world state transaction scope is at the key update level)
Endorsement is received during the same time of commit that uses K1, K2.
Would the peer ensure
[1] endorsement happens in a deterministic way such that endorsement proposal will be executed either on (K1-V1, K2-V1) such that the commit is put on-hold OR (K1-V2, K2-V2) i.e. commit is executed successfully and endorsement is put on-hold OR
[2] endorsement proposal happens in a non-determinsitic way endorsement & commit can execute in parallel i.e. endorsement RW set could have (K1-V2, K2-V1).
Thanks.
rahulhegde (Thu, 09 Jan 2020 13:30:45 GMT):
Hello - need clarification - @dave.enyeart
I am trying to understand, the commit to the ledger by peer & endorsement of proposal by peer are two distinct activities and can execute during the same time period. This is also true if the commit & endorsement are working on the same keys.
Say current state of the ledger K1-V1, K2-V1
Commit will move the K1-V2, K2-V2 (fact: world state transaction scope is at the key update level)
Endorsement is received during the same time of commit that uses K1, K2.
Would the peer ensure
[1] endorsement happens in a deterministic way such that endorsement proposal will be executed either on (K1-V1, K2-V1) such that the commit is put on-hold OR (K1-V2, K2-V2) i.e. commit is executed successfully and endorsement is put on-hold OR
[2] endorsement proposal happens in a non-determinsitic way endorsement & commit can execute in parallel i.e. endorsement RW set could have (K1-V2, K2-V1).
Thanks.
rahulhegde (Thu, 09 Jan 2020 13:30:45 GMT):
Hello - need clarification - @dave.enyeart
I am trying to understand, the commit to the ledger by peer & endorsement of proposal by peer are two distinct activities and can execute during the same time period. This is also true if the commit & endorsement are working on the same keys.
Say current state of the ledger K1-V1, K2-V1
Commit will move the K1-V2, K2-V2 (fact: world state transaction scope is at the key update level)
Endorsement is received during the same time of commit that uses K1, K2.
Would the peer ensure
[1] endorsement happens in a deterministic way such that endorsement proposal will be executed either on (K1-V1, K2-V1) such that the commit is put on-hold OR (K1-V2, K2-V2) i.e. commit is executed successfully and endorsement is put on-hold OR
[2] endorsement proposal happens in a non-determinsitic way endorsement & commit can execute in parallel i.e. endorsement RW set could have (K1-V2, K2-V1).
Did the Peer behavior changed from Fabric v1.0 v/s Fabric v1.4?
Thanks.
rahulhegde (Thu, 09 Jan 2020 13:30:45 GMT):
Hello - need clarification - @dave.enyeart
I am trying to understand, the commit to the ledger by peer & endorsement of proposal by peer are two distinct activities and can execute during the same time period. This is also true if the commit & endorsement are working on the same keys.
Say current state of the ledger K1-V1, K2-V1
Commit will move the K1-V2, K2-V2 (fact: world state transaction scope is at the key update level)
Endorsement is received during the same time of commit that uses K1, K2.
Would the peer ensure
[1] endorsement happens in a deterministic way such that endorsement proposal will be executed either on (K1-V1, K2-V1) such that the commit is put on-hold OR (K1-V2, K2-V2) i.e. commit is executed successfully and endorsement is put on-hold OR
[2] endorsement proposal happens in a non-determinsitic way endorsement & commit can execute in parallel i.e. endorsement RW set could have (K1-V2, K2-V1).
[3] Did the Peer behavior changed from Fabric v1.0 v/s Fabric v1.4?
Thanks.
dave.enyeart (Fri, 10 Jan 2020 16:14:53 GMT):
@rahulhegde [2] is not possible, you are guaranteed that endorsements will be based on a stable snapshot of the data. if the endorsement arrives before the commit starts, you'll get (K1-V1,K2-V1), if the endorsement arrives after commit starts, it will wait until commit is done and will return (K1-V2,K2-V2)
dave.enyeart (Fri, 10 Jan 2020 16:15:05 GMT):
This behavior has not changed since v1.0
rahulhegde (Fri, 10 Jan 2020 18:08:44 GMT):
Thanks Dave for the response.
joaquimpedrooliveira (Mon, 13 Jan 2020 15:23:09 GMT):
Hello all. I'm trying to build the peer docker image with HSM support, but I'm getting an error. Here are the steps:
- git clone https://github.com/hyperledger/fabric.git
- edited `Makefile` to include `GO_TAGS ?= pkcs11`
- edited `images/peer/Dockerfile.in` to add my HSM lib install instructions and ENV vars in peer image
- edited `sampleconfig/core.yaml` to add BCCSP/PKCS11 configs and changed BCCSP/Default to `PKCS11`
- built peer with `make peer-docker`
- tested with `docker run hyperledger/fabric-peer:latest` but get the following error:
```
2020-01-13 15:20:46.554 UTC [main] InitCmd -> ERRO 001 Cannot run peer because error when setting up MSP of type bccsp from directory /etc/hyperledger/fabric/msp: could not initialize BCCSP Factories: Failed initializing SW.BCCSP: Could not initialize BCCSP SW [Failed to initialize software key store: An invalid KeyStore path provided. Path cannot be an empty string.]
```
joaquimpedrooliveira (Mon, 13 Jan 2020 15:23:09 GMT):
But the `Keystore` is configured in `core.yaml`:
```
BCCSP:
debug: true
Default: PKCS11
# Settings for the SW crypto provider (i.e. when DEFAULT: SW)
SW:
# TODO: The default Hash and Security level needs refactoring to be
# fully configurable. Changing these defaults requires coordination
# SHA2 is hardcoded in several places, not only BCCSP
Hash: SHA2
Security: 256
# Location of Key Store
FileKeyStore:
# If "", defaults to 'mspConfigPath'/keystore
KeyStore:
# Settings for the PKCS#11 crypto provider (i.e. when DEFAULT: PKCS11)
PKCS11:
# Location of the PKCS11 module library
Library: /usr/lib/libtacndp11.so
# Token Label
Label: Dinamo HSM
# User PIN
Pin: abcd1234
Hash: SHA2
Security: 256
FileKeyStore:
KeyStore: msp/keystore
```
joaquimpedrooliveira (Mon, 13 Jan 2020 15:35:59 GMT):
Hi, all! I'm trying to create peer docker images with HSM support, but I'm getting an error. The steps I followed:
- git clone https://github.com/hyperledger/fabric.git
- edited `Makefile` to add `GO_TAGS ?= pkcs11`
- edited `sampleconfig/core.yaml` to add BCCSP/Default to `PKCS11` and configured the BCSSP/PKCS11 section as:
```
# Settings for the PKCS#11 crypto provider (i.e. when DEFAULT: PKCS11)
PKCS11:
# Location of the PKCS11 module library
Library: /usr/lib/libtacndp11.so
# Token Label
Label: Dinamo HSM
# User PIN
Pin: abcd1234
Hash: SHA2
Security: 256
FileKeyStore:
KeyStore: msp/keystore
```
- edited images/peer/Dockerfile.in to add my HSM lib install instructions and ENV vars
- generated peer docker image with `make -B peer-docker`
But when I test with 'docker run --rm -it hyperledger/fabric-peer:latest` I get the folling message:
```
2020-01-13 15:20:46.554 UTC [main] InitCmd -> ERRO 001 Cannot run peer because error when setting up MSP of type bccsp from directory /etc/hyperledger/fabric/msp: could not initialize BCCSP Factories: Failed initializing SW.BCCSP: Could not initialize BCCSP SW [Failed to initialize software key store: An invalid KeyStore path provided. Path cannot be an empty string.]
```
What could be missing?
joaquimpedrooliveira (Mon, 13 Jan 2020 17:51:17 GMT):
Additional info: I'm using the `v1.4.4` tag
rahulhegde (Wed, 15 Jan 2020 22:56:04 GMT):
Hello - I am using Fabric v1.4 Peer CLI that allows to collate the endorsement proposal response from multiple peers. Peer CLI has protection which checks for proposal response bytes. Is creating the proposal response bytes deterministic from chaincode that uses maps as world state (write set), as some properties like iterate over map is not deterministic. Does peer ensure deterministic behavior always?
```
2020-01-13 23:50:57.816 UTC [msp.identity] Sign -> DEBU 049 Sign: digest: 9FA53D62C6F94CEAF5E6119C400D05F8C909A3F87639CFE5BE2230B0C00FE89D
Error: could not assemble transaction: ProposalResponsePayloads do not match - proposal response: version:1 response:
```
yacovm (Thu, 16 Jan 2020 00:58:18 GMT):
map iteration in Go isn't deterministic
rahulhegde (Thu, 16 Jan 2020 17:36:39 GMT):
Iteration is true and it would be chaincode' responsibility to ensure deterministic processing. However the question here is any chaincode write operation involving a map (PutState) that becomes part of the RW set, would Peer be constructing the endorsement proposal response in a deterministic way?
Chaincode uses json.marshal to create a byte stream that becomes the input and as per https://golang.org/pkg/encoding/json/#Marshal
```
Map values encode as JSON objects. The map's key type must either be a string, an integer type, or implement encoding.TextMarshaler. The map keys are sorted and used as JSON object keys by applying the following rules,
```
rahulhegde (Thu, 16 Jan 2020 17:36:39 GMT):
Iteration is true and it would be chaincode' responsibility to ensure deterministic processing. However the question here is any chaincode write operation involving a map (PutState) that becomes part of the RW set or hash attached to the endorsement proposal response, would Peer be constructing the endorsement proposal response in a deterministic way?
Chaincode uses json.marshal to create a byte stream that becomes the input and as per https://golang.org/pkg/encoding/json/#Marshal
```
Map values encode as JSON objects. The map's key type must either be a string, an integer type, or implement encoding.TextMarshaler. The map keys are sorted and used as JSON object keys by applying the following rules,
```
rahulhegde (Thu, 16 Jan 2020 17:36:39 GMT):
If you can check too @dave.enyeart
Iteration is true and it would be chaincode' responsibility to ensure deterministic processing. However the question here is any chaincode write operation involving a map (PutState) that becomes part of the RW set or hash attached to the endorsement proposal response, would Peer be constructing the endorsement proposal response in a deterministic way?
Chaincode uses json.marshal to create a byte stream that becomes the input and as per https://golang.org/pkg/encoding/json/#Marshal
```
Map values encode as JSON objects. The map's key type must either be a string, an integer type, or implement encoding.TextMarshaler. The map keys are sorted and used as JSON object keys by applying the following rules,
```
rahulhegde (Thu, 16 Jan 2020 17:36:39 GMT):
If you can check too please @dave.enyeart
Iteration is true and it would be chaincode' responsibility to ensure deterministic processing. However the question here is any chaincode write operation involving a map (PutState) that becomes part of the RW set or hash attached to the endorsement proposal response, would Peer be constructing the endorsement proposal response in a deterministic way?
Chaincode uses json.marshal to create a byte stream that becomes the input and as per https://golang.org/pkg/encoding/json/#Marshal
```
Map values encode as JSON objects. The map's key type must either be a string, an integer type, or implement encoding.TextMarshaler. The map keys are sorted and used as JSON object keys by applying the following rules,
```
dave.enyeart (Fri, 17 Jan 2020 16:03:00 GMT):
I agree with Yacov - map iteration in Go isn't deterministic
dave.enyeart (Fri, 17 Jan 2020 16:03:49 GMT):
Chaincode must ensure deterministic value in PutState()
dave.enyeart (Fri, 17 Jan 2020 16:03:49 GMT):
Chaincode must ensure deterministic value in PutState(). If the value in PutState() is deterministic, peer will package the chaincode results deterministically (obviously things like the peer signature will be different from each peer in the proposal response)
rahulhegde (Fri, 17 Jan 2020 17:29:06 GMT):
Thanks for response.
1. Map that is serialized using Json Marshal API and then passed to PutState by chaincode, would this be a deterministic endorsement proposal response?
Or if I have to rephrase the same question
Consider the PutState value as
map[string] int = {
"abc" : 1,
"123" : 2
}
However
- Peer 1 serializes the map
map[string] int = {
"abc" : 1,
"123" : 2
}
- Peer 2 serializes the map
map[string] int = {
"123" : 1,
"abc" : 2
}
Would this be handled to create a deterministic endorsement proposal response across peer?
Note: Please ignore the syntax error.
2. Does the order of PutState matter in constructing the Endorsement Proposal Response across peer
Peer1 ->
call 1 - PutState(K1, V1)
call 2 - PutState(K2, V2)
Peer2 ->
call 1 - PutState(K2, V2)
call 2 - PutState(K1, V1)
rahulhegde (Fri, 17 Jan 2020 17:29:06 GMT):
Thanks for response.
1. Map that is serialized using Json Marshal API and then passed to PutState by chaincode, would this be a deterministic endorsement proposal response?
Or if I have to rephrase the same question
Consider the PutState value as
map[string] int = {
"abc" : 1,
"123" : 2
}
However
- Peer 1 serializes the map
map[string] int = {
"abc" : 1,
"123" : 2
}
- Peer 2 serializes the map
map[string] int = {
"123" : 2,
"abc" : 1
}
Would this be handled to create a deterministic endorsement proposal response across peer?
Note: Please ignore the syntax error.
2. Does the order of PutState matter in constructing the Endorsement Proposal Response across peer
Peer1 ->
call 1 - PutState(K1, V1)
call 2 - PutState(K2, V2)
Peer2 ->
call 1 - PutState(K2, V2)
call 2 - PutState(K1, V1)
rahulhegde (Fri, 17 Jan 2020 17:29:06 GMT):
Thanks for response.
1. Map that is serialized using Json Marshal API and then passed to PutState by chaincode, would this be a deterministic endorsement proposal response?
Or if I have to rephrase the same question
Consider the PutState value as
map[string] int = {
"abc" : 1,
"123" : 2
}
However
- Peer 1 serializes the map
map[string] int = {
"abc" : 1,
"123" : 2
}
- Peer 2 serializes the map
map[string] int = {
"123" : 2,
"abc" : 1
}
Would this be handled to create a deterministic endorsement proposal response across peer?
Note: Please ignore the syntax error.
2. Does the order of PutState matter in constructing the Endorsement Proposal Response across peer
Peer1 ->
call 1 at t1 - PutState(K1, V1)
call 2 at t2 - PutState(K2, V2)
Peer2 ->
call 1 at t1 - PutState(K2, V2)
call 2 at t2 - PutState(K1, V1)
rahulhegde (Fri, 17 Jan 2020 17:29:06 GMT):
Thanks for response.
1. Map that is serialized using Json Marshal API and then passed to PutState by chaincode, would this action across peers resulting in a deterministic endorsement proposal response?
Or if I have to rephrase the same question - Consider the PutState value as
map[string] int = {
"abc" : 1,
"123" : 2
}
However
- Peer 1 serializes the map
map[string] int = {
"abc" : 1,
"123" : 2
}
- Peer 2 serializes the map
map[string] int = {
"123" : 2,
"abc" : 1
}
Would this be handled to create a deterministic endorsement proposal response across peer?
Note: Please ignore the syntax error.
2. Does the order of PutState matter in constructing the Endorsement Proposal Response across peer
Peer1 ->
call 1 at t1 - PutState(K1, V1)
call 2 at t2 - PutState(K2, V2)
Peer2 ->
call 1 at t1 - PutState(K2, V2)
call 2 at t2 - PutState(K1, V1)
rahulhegde (Fri, 17 Jan 2020 17:29:06 GMT):
Thanks for response.
1. Map that is serialized using Json Marshal API and then passed to PutState by chaincode, would this action across peers resulting in a deterministic endorsement proposal response?
Or if I have to rephrase the same question - Consider the PutState value as
map[string] int = {
"abc" : 1,
"123" : 2
}
However
- Peer 1 serializes the map
map[string] int = {
"abc" : 1,
"123" : 2
}
- Peer 2 serializes the map
map[string] int = {
"123" : 2,
"abc" : 1
}
Would this be handled to create a deterministic endorsement proposal response across peers?
Note: Please ignore the syntax errors.
2. Does the order of PutState matter in constructing the Endorsement Proposal Response across peer
Peer1 ->
call 1 at t1 - PutState(K1, V1)
call 2 at t2 - PutState(K2, V2)
Peer2 ->
call 1 at t1 - PutState(K2, V2)
call 2 at t2 - PutState(K1, V1)
dave.enyeart (Sat, 18 Jan 2020 03:07:16 GMT):
@rahulhegde 1. per the doc you provided, although maps are not ordered in Go, and although JSON spec does not guarantee an order of elements, the Go Marshal() function does sort them lexicographically.
dave.enyeart (Sat, 18 Jan 2020 03:07:49 GMT):
2. order of PutState() does not matter... peer orders the keys lexicographically when building the final read-write set.
rahulhegde (Sun, 19 Jan 2020 01:44:03 GMT):
In Fabric v1.4.x, on Chaincode GetState API call, does Fabric Peer respond from its own cache or perform massaging/modification to the response before sending it to chaincode or it is just pass through?
dave.enyeart (Mon, 20 Jan 2020 01:07:08 GMT):
Pass through... chaincode GetState() will request the value from peer, peer will retrieve the value from state database and pass it back to chaincode
rahulhegde (Mon, 20 Jan 2020 02:08:28 GMT):
thanks @dave.enyeart for your response.
braduf (Thu, 23 Jan 2020 15:08:37 GMT):
Hi all, is there a way to start a peer without having it's msp folder yet?
We are looking on how to automate infrastructure deployment and provisioning and we think it would be easier if we can first deploy the peer container and then provision the machine with the msp.
yacovm (Thu, 23 Jan 2020 15:12:14 GMT):
@braduf do you have access to the peer's file system?
yacovm (Thu, 23 Jan 2020 15:12:48 GMT):
if yes, then it should be straight forward to add a `time.Sleep` to the `main` of the peer and compile your own Fabric version
braduf (Thu, 23 Jan 2020 15:32:44 GMT):
Ok, thank you, we will try some things, maybe we can add a goroutine that checks for the msp when a configuration is set that says that the peer is started without msp. And when the goroutine returns a `wait` is interrupted and the peer continues booting normally...
braduf (Thu, 23 Jan 2020 15:32:44 GMT):
Ok, thank you, we will try some things, maybe we can add a goroutine that checks for the msp when a configuration is set that says that the peer is started without msp. And when the goroutine returns a 'wait' is interrupted and the peer continues booting normally...
thiliniweeray (Tue, 28 Jan 2020 06:34:27 GMT):
Has joined the channel.
guoger (Tue, 04 Feb 2020 07:31:14 GMT):
from @Jeremy
> I am testing a disaster recovery scenario where I am restoring snapshots of a network that was live and not shut down first so there were transactions in flight and the orderers or peers are ahead. In the case where the orderers are ahead, they come up fine, but the peers are missing private data so encounter errors as they catch up from the missing blocks. I was hoping I could truncate the orderer data to bring them in line with the latest peer data to avoid issues with missing private data.
it's not currently possible to revert blocks on orderers and i don't think we should attempt to that. In case of missing private data, don't we mark those transactions invalid? cc @yacovm
Jeremy (Tue, 04 Feb 2020 07:31:14 GMT):
Has joined the channel.
yacovm (Tue, 04 Feb 2020 07:40:29 GMT):
Of course not @guoger otherwise it'd be non-deterministic
yacovm (Tue, 04 Feb 2020 07:40:37 GMT):
if peer A has private data but peer B doesn't...
guoger (Tue, 04 Feb 2020 08:06:11 GMT):
does B keep polling A for missing data?
yacovm (Tue, 04 Feb 2020 08:07:10 GMT):
it will eventually give up
guoger (Tue, 04 Feb 2020 08:08:22 GMT):
also, is there a way to re-inject private data into its store? since B would find out its own signature on that tx, private data must be missing for some reason
yacovm (Tue, 04 Feb 2020 08:09:06 GMT):
the peer go back and try to pull the private data for prior committed blocks
guoger (Tue, 04 Feb 2020 08:21:48 GMT):
how does private data for prior committed blocks help here?
yacovm (Tue, 04 Feb 2020 08:44:59 GMT):
well if you committed a block but you couldn't collect the required private data then you can collect it later in the future
guoger (Tue, 04 Feb 2020 10:32:00 GMT):
by "later in the future", do you mean after committing subsequent blocks?
yacovm (Tue, 04 Feb 2020 10:36:29 GMT):
yes
Jeremy (Tue, 04 Feb 2020 18:41:21 GMT):
from @Jeremy
> I am testing a disaster recovery scenario where I am restoring snapshots of a network that was live and not shut down first
adianimesh (Thu, 06 Feb 2020 00:28:24 GMT):
Has joined the channel.
adianimesh (Thu, 06 Feb 2020 00:28:24 GMT):
Trying setup Hyperledger fabric with Safenet Gemalto Cloud HSM using PKCS11 and running into issues. Has anyone tried it before ?
adianimesh (Thu, 06 Feb 2020 00:28:49 GMT):
`Cannot run peer because error when setting up MSP of type bccsp from directory /u01/fd895b99-7e3a-4e0a-8dd8-f33163c1bce2/cm/msp: KeyMaterial not found in SigningIdentityInfo The command that is used is peer channel create -t 1800s -o 96eec90a-54b1-44cc-84e9-d5ede782f52a-orderer1:7050 -c default -f /u01/96eec90a-54b1-44cc-84e9-d5ede782f52a/cm/channel.tx --outputBlock /u01/96eec90a-54b1-44cc-84e9-d5ede782f52a/cm/channel.block`
adianimesh (Thu, 06 Feb 2020 00:29:10 GMT):
`2020-04-02 17:08:33.633 UTC [viperutil] EnhancedExactUnmarshalKey -> DEBU 017 map[peer.BCCSP:map[Default:PKCS11 PKCS11:map[FileKeyStore:map[KeyStore:msp/keystore] Hash:SHA2 Label:obp-test Library:/etc/hyperledger/fabric/dpod/obp-test/libs/64/libCryptoki2.so Pin:PasswordPO1 Security:256 SensitiveKeys:true SoftwareVerify:true]]]
2020-04-02 17:08:33.633 UTC [bccsp] initBCCSP -> DEBU 018 Initialize BCCSP [SW]
2020-04-02 17:08:33.633 UTC [bccsp_sw] createKeyStoreIfNotExists -> DEBU 019 KeyStore path [msp/keystore] missing [true]: [
adianimesh (Thu, 06 Feb 2020 00:29:28 GMT):
````
2020-04-02 17:08:33.633 UTC [viperutil] EnhancedExactUnmarshalKey -> DEBU 017 map[peer.BCCSP:map[Default:PKCS11 PKCS11:map[FileKeyStore:map[KeyStore:msp/keystore] Hash:SHA2 Label:obp-test Library:/etc/hyperledger/fabric/dpod/obp-test/libs/64/libCryptoki2.so Pin:PasswordPO1 Security:256 SensitiveKeys:true SoftwareVerify:true]]]
2020-04-02 17:08:33.633 UTC [bccsp] initBCCSP -> DEBU 018 Initialize BCCSP [SW]
2020-04-02 17:08:33.633 UTC [bccsp_sw] createKeyStoreIfNotExists -> DEBU 019 KeyStore path [msp/keystore] missing [true]: [
adianimesh (Thu, 06 Feb 2020 00:29:56 GMT):
```
2020-04-02 17:08:46.042 UTC [msp.identity] newIdentity -> DEBU 032 Creating identity instance for cert -----BEGIN CERTIFICATE-----
MIIBfzCCASWgAwIBAgIUVN3bthNL3GjHuakUsZwW0D47d0QwCgYIKoZIzj0EAwIw
HDEMMAoGA1UEChMDRjIwMQwwCgYDVQQDEwNGMjAwHhcNMTkxMjIwMTQ1NTAwWhcN
MzQxMjE2MTQ1NTAwWjAcMQwwCgYDVQQKEwNGMjAxDDAKBgNVBAMTA0YyMDBZMBMG
ByqGSM49AgEGCCqGSM49AwEHA0IABEpt5B7JfclGyr1FIebB/yJbyuSCEEzxC7kc
0lXDYTmBoJx+2fpn5f1Ky7ickPr0ZregZp+Krw5FS3FXIA8QZUSjRTBDMA4GA1Ud
DwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEBMB0GA1UdDgQWBBS02nub+XCj
h0cZr5va/IGu9fqeTzAKBggqhkjOPQQDAgNIADBFAiEAsHLKErPuU2BLSUGvXCYl
Etp7YZ476pwbVrJ503TuyXwCIAjj+synjR0epXftCmwBasW+k480/J82seJpRo/M
ALdw
-----END CERTIFICATE-----
2020-04-02 17:08:46.043 UTC [msp.identity] newIdentity -> DEBU 033 Creating identity instance for cert -----BEGIN CERTIFICATE-----
MIIB1zCCAX6gAwIBAgIUG7ursFvwI5MjHXZYVzWmNKhtqW0wCgYIKoZIzj0EAwIw
HDEMMAoGA1UEChMDRjIwMQwwCgYDVQQDEwNGMjAwHhcNMTkxMjIwMTQ1NTAwWhcN
MjAxMjE5MTUwMDAwWjAmMQ8wDQYDVQQLEwZjbGllbnQxEzARBgNVBAMTCkFuaW1l
c2hCUE0wWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASRFMaoN195CP4hEhG1nX9u
93V6zVVXysmHnSBUjoopUzbn638R/ZaOiJiulu8EVtFk1yIE+jIQ78+YD9bFPKyx
o4GTMIGQMA4GA1UdDwEB/wQEAwIHgDAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBST
7Uo2EPcgqLaibLwQ+XZvPp9CGTAfBgNVHSMEGDAWgBS02nub+XCjh0cZr5va/IGu
9fqeTzAwBgNVHREEKTAngglsb2NhbGhvc3SCGmFuYWRpdHlhLW1hYy5pbi5vcmFj
bGUuY29tMAoGCCqGSM49BAMCA0cAMEQCIAhGUWG69c/lxG4pqU6eo5dg3sh7zSJf
lGD442InVC6dAiBU9lhM7UBVGmLPHDElwfmDBivuisQFpxToJPd30lklHA==
-----END CERTIFICATE-----
2020-04-02 17:08:46.044 UTC [msp.identity] newIdentity -> DEBU 034 Creating identity instance for cert -----BEGIN CERTIFICATE-----
MIIB1zCCAX6gAwIBAgIUG7ursFvwI5MjHXZYVzWmNKhtqW0wCgYIKoZIzj0EAwIw
HDEMMAoGA1UEChMDRjIwMQwwCgYDVQQDEwNGMjAwHhcNMTkxMjIwMTQ1NTAwWhcN
MjAxMjE5MTUwMDAwWjAmMQ8wDQYDVQQLEwZjbGllbnQxEzARBgNVBAMTCkFuaW1l
c2hCUE0wWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASRFMaoN195CP4hEhG1nX9u
93V6zVVXysmHnSBUjoopUzbn638R/ZaOiJiulu8EVtFk1yIE+jIQ78+YD9bFPKyx
o4GTMIGQMA4GA1UdDwEB/wQEAwIHgDAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBST
7Uo2EPcgqLaibLwQ+XZvPp9CGTAfBgNVHSMEGDAWgBS02nub+XCjh0cZr5va/IGu
9fqeTzAwBgNVHREEKTAngglsb2NhbGhvc3SCGmFuYWRpdHlhLW1hYy5pbi5vcmFj
bGUuY29tMAoGCCqGSM49BAMCA0cAMEQCIAhGUWG69c/lxG4pqU6eo5dg3sh7zSJf
lGD442InVC6dAiBU9lhM7UBVGmLPHDElwfmDBivuisQFpxToJPd30lklHA==
-----END CERTIFICATE-----
2020-04-02 17:08:46.044 UTC [bccsp_p11] getSession -> DEBU 035 Reusing existing pkcs11 session 1 on slot 3
2020-04-02 17:08:48.906 UTC [bccsp_p11] getECKey -> DEBU 036 Private key not found [Key not found [00000000 42 da bd a2 79 2b 97 11 a1 9e 4e d5 c0 20 e2 c3 |B...y+....N.. ..|
00000010 f9 c2 36 4f 74 d7 c9 e5 82 bb cf 71 b3 33 c0 ef |..6Ot......q.3..|
]] for SKI [42dabda2792b9711a19e4ed5c020e2c3f9c2364f74d7c9e582bbcf71b333c0ef], looking for Public key
Failed getting key for SKI [[66 218 189 162 121 43 151 17 161 158 78 213 192 32 226 195 249 194 54 79 116 215 201 229 130 187 207 113 179 51 192 239]]
```
indirajith (Mon, 17 Feb 2020 13:36:04 GMT):
Hi all, I an getting an error when I try to commit chaincode package. I have got approvals from both the orgs. But still commit throws `2020-02-17 13:19:29.534 UTC [chaincodeCmd] ClientWait -> INFO 04d txid [2af110a86314c707e1246d25292af419888e63d52f00dc10187947826faa6c38] committed with status (ENDORSEMENT_POLICY_FAILURE) at peer1-org2.inuit.local:7051
2020-02-17 13:19:29.544 UTC [chaincodeCmd] ClientWait -> INFO 04e txid [2af110a86314c707e1246d25292af419888e63d52f00dc10187947826faa6c38] committed with status (ENDORSEMENT_POLICY_FAILURE) at peer1-org1.inuit.local:7051
Error: transaction invalidated with status (ENDORSEMENT_POLICY_FAILURE)`
checkcommitreadiness
`{
"approvals": {
"org1MSP": true,
"org2MSP": true
}
}
`
indirajith (Mon, 17 Feb 2020 13:36:04 GMT):
Hi all, I an getting an error when I try to commit chaincode package. I have got approvals from both the orgs. But still commit throws ```2020-02-17 13:19:29.534 UTC [chaincodeCmd] ClientWait -> INFO 04d txid [2af110a86314c707e1246d25292af419888e63d52f00dc10187947826faa6c38] committed with status (ENDORSEMENT_POLICY_FAILURE) at peer1-org2.inuit.local:7051
2020-02-17 13:19:29.544 UTC [chaincodeCmd] ClientWait -> INFO 04e txid [2af110a86314c707e1246d25292af419888e63d52f00dc10187947826faa6c38] committed with status (ENDORSEMENT_POLICY_FAILURE) at peer1-org1.inuit.local:7051
Error: transaction invalidated with status (ENDORSEMENT_POLICY_FAILURE)```
checkcommitreadiness
```{
"approvals": {
"org1MSP": true,
"org2MSP": true
}
}
```
indirajith (Mon, 17 Feb 2020 13:37:40 GMT):
Can anyone help fixing this issue?
indirajith (Mon, 17 Feb 2020 13:48:49 GMT):
Peer logs
PEER1_ORG2
```
2020-02-17 13:40:32.589 UTC [lifecycle] CheckCommitReadiness -> INFO 0c6 Successfully checked commit readiness of chaincode name 'cctest' on channel 'twoorgschannel' with
definition {sequence: 1, endorsement info: (version: '1', plugin: 'escc', init required: true), validation info: (plugin: 'vscc', policy: '12202f4368616e6e656c2f4170706c69636174696f6e2f456e646f7273656d656e74'), collections: (
indirajith (Mon, 17 Feb 2020 13:49:32 GMT):
PEER2_ORG1
```
2020-02-17 13:40:32.563 UTC [lifecycle] CheckCommitReadiness -> INFO 09d Successfully checked commit readiness of chaincode name 'cctest' on channel 'twoorgschannel' with
definition {sequence: 1, endorsement info: (version: '1', plugin: 'escc', init required: true), validation info: (plugin: 'vscc', policy: '12202f4368616e6e656c2f4170706c69636174696f6e2f456e646f7273656d656e74'), collections: (
braduf (Mon, 02 Mar 2020 23:53:27 GMT):
Hi all, i am trying to use the operations server for health checks of my peers. When I send to the /healthz endpoint however, I get the following message:
braduf (Mon, 02 Mar 2020 23:53:27 GMT):
Hi all, i am trying to use the operations server for health checks of my peers. When I send to the /healthz endpoint however, I get the following message:
```
{
"status": "Service Unavailable",
"time": "2020-03-02T23:42:14.990847103Z",
"failed_checks": [
{
"component": "docker",
"reason": "failed to ping to Docker daemon: Get http://unix.sock/_ping: dial unix /var/run/docker.sock: connect: no such file or directory"
}
]
}
```
I didn't change anything in the VM section of the core.yaml file. Could that be the reason and what should I verify there?
Thanks a lot in advance!
braduf (Tue, 03 Mar 2020 14:55:24 GMT):
Found my problem, I didn't had the docker.sock mounted in the container...
Antimttr (Wed, 11 Mar 2020 18:21:54 GMT):
Has joined the channel.
Antimttr (Wed, 11 Mar 2020 18:29:30 GMT):
Hello, I had a question about NodeOUs, if you use them they confer roles on identities with certs matching the OU int he Node's MSP. So if you don't use them how do you confer these roles?
dave.enyeart (Thu, 12 Mar 2020 11:52:15 GMT):
If you don't use them there are no such roles to distinguish peer from client from admin from orderer - each identity would simply be a 'member' of their org, and you'd have to define all roles using *.member, and identify admins using the adminscerts msp directory.
dave.enyeart (Thu, 12 Mar 2020 11:52:15 GMT):
If you don't use them there are no such roles to distinguish peer from client from admin from orderer within their org - each identity would simply be a 'member' of their org, and you'd have to define all roles using *.member, and identify admins using the adminscerts msp directory.
tommyjay (Thu, 12 Mar 2020 15:57:29 GMT):
got the classic `MSP error: the supplied identity is not valid: x509: certificate signed by unknown authority` error. i started a peer without an msp dir but i added `CORE_PEER_TLS_ENABLED`, `CORE_PEER_TLS_CERT_FILE`, `CORE_PEER_TLS_KEY_FILE` and `CORE_PEER_TLS_ROOTCERT_FILE` in the environment variables.
tommyjay (Thu, 12 Mar 2020 15:58:02 GMT):
i noticed it checks my org admin's cert just before it says that
tommyjay (Thu, 12 Mar 2020 15:58:02 GMT):
i noticed it checks my org admin's cert just before it logs the error
Abhishekkishor (Thu, 12 Mar 2020 19:28:49 GMT):
Has joined the channel.
tommyjay (Fri, 13 Mar 2020 19:19:48 GMT):
msp dir is needed
rahulhegde (Mon, 16 Mar 2020 20:26:45 GMT):
@dave.enyeart - I should have updated this before - we did find the issue in our chaincode. But this is specifically the way json.unmarshal for GO Map is implemented. GO JSON unmarshal preserves the previous elements in the map. Chaincode having Iteration over the map with Unmarshal call resulted endorsement proposal mismatch.
dan13 (Tue, 17 Mar 2020 21:29:58 GMT):
For the case where there is a desire to index current world state in Lucene, is exporting CouchDb as described in https://stackoverflow.com/questions/11639534/couchdb-dump-to-file-and-load-from-file reasonable, or is there some other approach suggested? This would *not* be a nightly process, and presumably normal transaction/event handling processing will keep the Lucene index current under normal conditions, but ultimately the source data is on the network, so looking for an approach. Thanks!
dave.enyeart (Wed, 18 Mar 2020 01:23:14 GMT):
No, I wouldn't recommend such workarounds, when there is a supported Fabric API for listening for block events as they occur, see the doc and sample:
dave.enyeart (Wed, 18 Mar 2020 01:23:31 GMT):
Doc: https://hyperledger-fabric.readthedocs.io/en/release-1.4/peer_event_services.html
Sample: https://github.com/hyperledger/fabric-samples/tree/master/off_chain_data
dan13 (Wed, 18 Mar 2020 01:30:14 GMT):
Thanks for the links Dave. We have a chaincode event listener, so taking your suggestion to logical conclusion, if we did need to rebuild index from scratch to match current world state, we could replay all the blocks. That should work, but seems like it would be much less efficient than dumping just the current state. I'll read through the off chain link in detail to pick up tips there -- thanks again.
dave.enyeart (Wed, 18 Mar 2020 01:34:29 GMT):
If you want to continuously index from CouchDB, the changes feed would likely be a better option than a full dump: https://docs.couchdb.org/en/stable/api/database/changes.html
dan13 (Wed, 18 Mar 2020 01:44:31 GMT):
Thank you, I will look into that as well!
rahulhegde (Thu, 19 Mar 2020 16:06:57 GMT):
Hello @dave.enyeart - In our production environment, we saw unusual case.
There was configuration block update that included CRL information only. This block was event'ed out across all the client. The problem part, It was noticed, another block that was 2 days old was also event'ed out soon after the configuration block across all the client. This (receiving old block) continued multiple times until a new block was added to the channel. We saw the same behavior across multiple channel.
Release Information: using Fabric v1.4.2 with Kafka Consensus, Java Client running on Fabric Java SDK 1.4.4
have we seen this issue or is there a way to understand why it happened
rahulhegde (Thu, 19 Mar 2020 16:06:57 GMT):
Hello @dave.enyeart - In our production environment, we saw unusual case.
There was configuration block update that included CRL information only. This block was event'ed out across all the client. The problem part, It was noticed, another block that was 2 days old was also event'ed out soon after the configuration block across all the client. This (receiving old block) continued multiple times until a new block was added to the channel. We saw the same behavior across multiple channel.
Release Information: using Fabric v1.4.2 with Kafka Consensus, Java Client running on Fabric Java SDK 1.4.4
Have we seen this issue on the said release or can you help us way to debug?
rahulhegde (Thu, 19 Mar 2020 16:06:57 GMT):
Hello @dave.enyeart @jyellick - In our production environment, we saw unusual case.
There was configuration block update that included CRL information only. This block was event'ed out across all the client. The problem part, It was noticed, another block that was 2 days old was also event'ed out soon after the configuration block across all the client. The receipt of the same old block continued multiple times until a new block was added to that channel. We saw the same behavior across multiple channel.
Release Information: using Fabric v1.4.2 with Kafka Consensus, Java Client running on Fabric Java SDK 1.4.4
Have we seen this issue on the said release or can you help us to way debug this problem?
gokulalex (Fri, 20 Mar 2020 12:09:52 GMT):
Has joined the channel.
aberwag (Tue, 24 Mar 2020 08:09:18 GMT):
Has joined the channel.
tommyjay (Thu, 26 Mar 2020 16:22:07 GMT):
how do you setup mutual tls between the peers and orderer? where do the client cert and keys for peer come from?
yacovm (Thu, 26 Mar 2020 16:34:11 GMT):
just use the server cert/key one
yacovm (Thu, 26 Mar 2020 16:34:13 GMT):
@tommyjay
yacovm (Thu, 26 Mar 2020 16:34:25 GMT):
cryptogen produces them to fit both client/server roles
tommyjay (Thu, 26 Mar 2020 16:41:26 GMT):
thanks, how about when cryptogen isn't being used
yacovm (Thu, 26 Mar 2020 16:41:38 GMT):
then you need to take care of it...
yacovm (Thu, 26 Mar 2020 16:41:51 GMT):
i mean it's your crafted stuff right?
root10 (Fri, 27 Mar 2020 15:51:01 GMT):
Has joined the channel.
root10 (Thu, 02 Apr 2020 11:14:55 GMT):
Hi guys. After some requests, I get the error:
```bash
# peer (1.4.6)
2020-04-01 16:53:35.518 UTC [comm.grpc.server] 1 -> INFO 20489cc unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.request_deadline=2020-04-01T16:53:35.518Z grpc.peer_address=172.28.0.6:60232 error="context canceled" grpc.code=Unknown grpc.call_duration=2m59.99990063s
```
```bash
# fabric-go-sdk (alpha-5)
[fabsdk/fab] 2020/04/01 16:53:35 UTC - peer.(*peerEndorser).sendProposal -> ERRO process proposal failed [rpc error: code = DeadlineExceeded desc = context deadline exceeded]
```
matanyahu (Mon, 06 Apr 2020 17:49:50 GMT):
Has left the channel.
tommyjay (Wed, 08 Apr 2020 17:30:24 GMT):
getting this error after my peer joins a channel and tries to get blocks from the orderer:
```
2020-04-08 17:28:54.686 UTC [grpc] createTransport -> DEBU 3ba grpc: addrConn.createTransport failed to connect to {orderer.example.com:7050 0
tommyjay (Wed, 08 Apr 2020 17:30:24 GMT):
getting this error after my peer joins a channel and tries to get blocks from the orderer:
```
2020-04-08 17:28:54.686 UTC [grpc] createTransport -> DEBU 3ba grpc: addrConn.createTransport failed to connect to {orderer.example.com:7050 0
MHBauer (Thu, 16 Apr 2020 21:19:29 GMT):
Has left the channel.
xhens (Thu, 16 Apr 2020 23:19:01 GMT):
Has joined the channel.
rahulhegde (Fri, 17 Apr 2020 18:42:22 GMT):
hello @dave.enyeart
Can you help what does this error mean in Peer Log during Chaincode Instantiation operation
```
2020-04-17 18:36:13.843 UTC [endorser] callChaincode -> INFO 0c1 [public][ad1ca7ae] Exit chaincode: name:"lscc" (148ms)
2020-04-17 18:36:13.843 UTC [endorser] SimulateProposal -> ERRO 0c2 [public][ad1ca7ae] failed to invoke chaincode name:"lscc" , error: Failed to generate platform-specific docker build: Error uploading input to container: API error (404): Could not find the file /chaincode/input in container 0297ce0e29a41a7fa997ab4ac15f83b35883bb7ff25deffbb267a122b04bf779
error starting container
error starting container
```
Ashish (Fri, 24 Apr 2020 10:33:43 GMT):
Hi
Regardless of whatever consensus mechanism we choose, the endorsement policy ( yaml based) is always going to be there in fabric??
I mean we can't have PBFT at transaction endorsement level??
tommyjay (Wed, 06 May 2020 16:04:07 GMT):
how do i find out who `identity 0` is
tommyjay (Wed, 06 May 2020 16:04:51 GMT):
peer logs
rahulhegde (Thu, 07 May 2020 02:28:13 GMT):
Hello - Every peer joined to a channel can have a different commit time for a transaction. Is this data persisted and if yes, is there a way to get this information in fabric v1.4.x?
rahulhegde (Thu, 07 May 2020 02:28:13 GMT):
Hello @dave.enyeart - Every peer joined to a channel can have a different commit time for a transaction. Is this data persisted and if yes, is there a way to get this information in fabric v1.4.x?
rahulhegde (Thu, 07 May 2020 02:28:13 GMT):
Hello @dave.enyeart - Every peer joined to a channel can have a different commit time for a transaction. Is this data persisted and if yes, is there a way to get this information in fabric v1.4.x?
Can you please sugges if there is way.
tommyjay (Fri, 08 May 2020 17:34:25 GMT):
hey there, why's it important to mount my /var/run/docker.sock into the peer container?
tommyjay (Fri, 08 May 2020 17:34:25 GMT):
hey there, why's it important to mount my /var/run/docker.sock into the peer container? my peer is unable to bring up the chaincode docker container
rahulhegde (Sat, 09 May 2020 14:10:07 GMT):
Peer container uses the Docker API to launch the chaincode as a docker container.
tommyjay (Mon, 11 May 2020 13:04:10 GMT):
is this a security risk? for a container to have access to the host's docker.sock? the folder `/var/run` contains more than just docker configs i.e. other apps on the host's machine use this folder. if a container is compromised and it has access to `var/run` then the host is also compromised
rahulhegde (Tue, 12 May 2020 00:15:35 GMT):
Check this 2 links -
https://jira.hyperledger.org/browse/FAB-11453
https://hyperledger-fabric.readthedocs.io/en/release-2.0/cc_service.html?highlight=external%20deployment#chaincode-as-an-external-service
rahulhegde (Tue, 12 May 2020 00:15:35 GMT):
Check these 2 links -
https://jira.hyperledger.org/browse/FAB-11453
https://hyperledger-fabric.readthedocs.io/en/release-2.0/cc_service.html?highlight=external%20deployment#chaincode-as-an-external-service
tommyjay (Tue, 12 May 2020 13:10:28 GMT):
thanks, is there an external service approach for 1.4?
dave.enyeart (Fri, 15 May 2020 12:22:17 GMT):
There are metrics for commit time that you can monitor and persist. See https://hyperledger-fabric.readthedocs.io/en/release-1.4/operations_service.html#metrics and https://hyperledger-fabric.readthedocs.io/en/release-1.4/metrics_reference.html
rsherwood (Tue, 19 May 2020 12:38:21 GMT):
Hi I've a question about endorsement certificate expiry. I know the peers can't check certificate expiry on ledger transaction for timing reasons , however does the fabric check the expiry time in other places. For example are the Local MSP certificates checked when a peer or orderer starts, and does the ordererer check the submitters cert when a transaction is received ?
wlahti (Tue, 19 May 2020 13:40:04 GMT):
I'm not an expert in this area, but I've looked into some of this code recently (while working on the new configtx library). The MSP code (used by the peer and the orderer) does not check the expiration of CA certificates. As far as the orderers go, based on this [doc](https://hyperledger-fabric.readthedocs.io/en/release-2.0/raft_configuration.html?highlight=expiration#certificate-expiration-related-authentication), it sounds like we do check for expiration of submitting certs for transactions unless you've enabled `NoExpirationChecks` as noted.
wlahti (Tue, 19 May 2020 13:40:04 GMT):
I'm not an expert in this area, but I've looked into some of this code recently (while working on the new configtx library). The MSP code (used by the peer and the orderer) does not check the expiration of CA certificates. As far as the orderers go, based on this [doc](https://hyperledger-fabric.readthedocs.io/en/release-2.0/raft_configuration.html?highlight=expiration#certificate-expiration-related-authentication), it sounds like we do check for expiration of submitting certs for transactions unless you've enabled `NoExpirationChecks` as noted. edit: also, I looked into the history of the `NoExpirationChecks` flag and it was added in 2.0.0 and backported to the release-1.4 branch.
rsherwood (Tue, 19 May 2020 14:11:34 GMT):
Thanks for that. I don't suppose you know if a peer connecting to an orderer to receive block distribution counts as a "transaction" and respects the expiry ( assume that a peer as to sends some signed message to prove its eligibility for blocks).
wlahti (Tue, 19 May 2020 14:15:18 GMT):
I'm fairly sure the expiration is checked for peers connecting to the deliver service but let me double check...
rsherwood (Tue, 19 May 2020 14:16:42 GMT):
We are still on 1.4 so could do with a response based on that version.
wlahti (Tue, 19 May 2020 14:17:23 GMT):
Yep, it does. I see the same check for the new `NoExpirationChecks` flag in the deliver service code.
wlahti (Tue, 19 May 2020 14:17:23 GMT):
Yep, it does. I see the same check for the new `NoExpirationChecks` flag in the deliver service code so by default it ensures the cert has not yet expired before sending blocks.
risc (Tue, 19 May 2020 16:58:27 GMT):
Has left the channel.
pritam_01 (Fri, 22 May 2020 08:24:33 GMT):
Has joined the channel.
pritam_01 (Fri, 22 May 2020 08:25:26 GMT):
no
tommyjay (Thu, 04 Jun 2020 17:52:23 GMT):
how fast is chanincode instantiation through the peer cli/binary?
tommyjay (Thu, 04 Jun 2020 17:52:23 GMT):
how fast is chaincode instantiation through the peer cli/binary?
SamYuan1990 (Wed, 17 Jun 2020 13:43:54 GMT):
I have a question
for any tx, I had endorse on Peer0
Will Peer0 re-run the tx (as fetch data from state db) when validate tx on Peer0
or
There some cache to ensure the tx won't be re-run?
govindvb (Thu, 18 Jun 2020 08:49:47 GMT):
Has joined the channel.
narendranathreddy (Mon, 22 Jun 2020 12:18:03 GMT):
Hi
iam experiencing a weird error in the fabric peer
i have 2,50,000 blocks and peers went offline due to some VM issues
peers ledger data is persisted
when peers come online, peers are not responding
when i see logs peer is recommiting blocks
2020-06-22 12:11:59.767 UTC [peer] Initialize -> INFO 02f Loading chain ucrnetchannel
2020-06-22 12:11:59.768 UTC [ledgermgmt] OpenLedger -> INFO 030 Opening ledger with id = ucrnetchannel
2020-06-22 12:11:59.909 UTC [kvledger] recommitLostBlocks -> INFO 031 Recommitting lost blocks - firstBlockNum=19, lastBlockNum=465621, recoverables=[]kvledger.recoverable{(*lockbasedtxmgr.LockBasedTxMgr)(0xc001faa510)}
2020-06-22 12:12:05.749 UTC [gossip.election] beLeader -> INFO 032 99021e650e66302177a0d0d385c95e1fcc053ffb2eb346b738810d7db4ce2a0e : Becoming a leader
2020-06-22 12:12:05.749 UTC [gossip.service] func1 -> INFO 033 Elected as a leader, starting delivery service for channel kycnetchannel
2020-06-22 12:12:05.750 UTC [deliveryClient] StartDeliverForChannel -> INFO 034 This peer will retrieve blocks from ordering service and disseminate to other peers in the organization for channel kycnetchannel
2020-06-22 12:12:05.759 UTC [deliveryClient] RequestBlocks -> INFO 035 Starting deliver with block [7844] for channel kycnetchannel
2020-06-22 12:14:26.639 UTC [lockbasedtxmgr] CommitLostBlock -> INFO 036 Recommitting block [1000] to state database
2020-06-22 12:17:23.566 UTC [lockbasedtxmgr] CommitLostBlock -> INFO 037 Recommitting block [2000] to state database
rahulhegde (Mon, 29 Jun 2020 15:42:55 GMT):
hello @dave.enyeart - can you confirm if there is any locking done by Peer during chaincode-2-chaincode call on another channel (https://github.com/hyperledger/fabric/blob/v1.4.2/core/chaincode/shim/interfaces.go#L62-L76)?
rahulhegde (Mon, 29 Jun 2020 15:42:55 GMT):
hello @dave.enyeart - we see chaincode-2-chaincode operation takes few 100-300 ms and Get/Put State are between 10-20ms ms. Can you please confirm if there is any locking done by Peer during chaincode-2-chaincode call on another channel (https://github.com/hyperledger/fabric/blob/v1.4.2/core/chaincode/shim/interfaces.go#L62-L76) or it will be based on the endorsement processing requirement?
rahulhegde (Mon, 29 Jun 2020 15:42:55 GMT):
hello @dave.enyeart - we see chaincode-2-chaincode operation takes few 100-300 ms and Get/Put State are between 10-20ms ms. Can you please confirm if there is any locking done by Peer during chaincode-2-chaincode call on another channel (https://github.com/hyperledger/fabric/blob/v1.4.2/core/chaincode/shim/interfaces.go#L62-L76) or when there are multiple chaincode-2-chaincode on the same channel?
dave.enyeart (Mon, 29 Jun 2020 19:23:42 GMT):
@rahulhegde chaincode-2-chaincode across channels needs to wait for a lock on the target channel as well. if the target channel is often busy with commits, yes this could be the cause of additional delay.
rahulhegde (Mon, 29 Jun 2020 20:04:07 GMT):
Our target channel does not have commits during that period. This is a public data channel which updates once at the start. Is there a way, i could find the delay using metrics?
rahulhegde (Mon, 29 Jun 2020 20:04:55 GMT):
Other thing - c2c calls are not endorsement call, would they be also categorized for lock on the channel?
dave.enyeart (Tue, 30 Jun 2020 12:55:48 GMT):
yes, there will still be a lock.
dave.enyeart (Tue, 30 Jun 2020 12:56:35 GMT):
The best way to see where the time is spent is to turn on some peer debug. I like this debug string since it removes the most chatty messages that won't add value here:
dave.enyeart (Tue, 30 Jun 2020 12:56:39 GMT):
`FABRIC_LOGGING_SPEC=debug:cauthdsl,policies,msp,grpc,peer.gossip.mcs,gossip,leveldbhelper=info`
dave.enyeart (Tue, 30 Jun 2020 12:57:17 GMT):
You can just send one c2c call in isolation of all other traffic, and then see in the debug log where time is spent.
rahulhegde (Tue, 30 Jun 2020 13:02:10 GMT):
I will try this string. I would be interested to see how much time is spent in the couch database rich query execution. We have few rich query execution, where a single couch database instance is hosting around 380 database and every rich query gives a different execution time from 50ms to 150ms.
rahulhegde (Tue, 30 Jun 2020 13:02:10 GMT):
I will try this string. I would be interested to see how much time is spent in the couch database rich query execution. We have few rich query execution, where a single couch database instance is hosting around 380 databases and every rich query gives a different execution time from 50ms to 150ms.
rahulhegde (Tue, 30 Jun 2020 13:06:34 GMT):
Couch database rich query uses index but rich query uses $in clause. I haven't find a way to improve further execution time and this would involve record scan.
Document structure in couch database - Key = date, value = array of string = [value1, value2, ....].
And the Rich Query is lte = data and value $in value1
Index is put on date. Is there a way, this can be further improved, I could not find any?
rahulhegde (Tue, 30 Jun 2020 13:06:34 GMT):
Couch database rich query uses index but rich query uses $in clause. I haven't find a way to improve further execution time and this would involve record scan.
Document structure in couch database - Key = date, value = array of string = [value1, value2, ....].
And the Rich Query is lte = date and value $in value1
Index is put on date. Is there a way, this can be further improved, I could not find any?
dave.enyeart (Tue, 30 Jun 2020 13:21:24 GMT):
For advanced CouchDB index and query questions, I would recommend reaching out to the CouchDB mailing list. Also I found one discussion here that may help: https://github.com/apache/couchdb/issues/1852
rahulhegde (Tue, 30 Jun 2020 13:24:36 GMT):
I did check the link but this was for $or. The above scenario is to find from the JSON array https://docs.couchdb.org/en/stable/api/database/find.html#condition-operators
TimFrHunter (Wed, 01 Jul 2020 14:16:11 GMT):
Has joined the channel.
TimFrHunter (Wed, 01 Jul 2020 14:16:11 GMT):
Hi guys, I'm trying to compile the peer binary and there is one file changes that get not compile, file who doesn't get compile is in protos/utils/, the command I run to compile the peer is : make -B peer . The command doesn't stuck or something else and works but not the changes that I make in the specific file. Is there some flags that I need to add ..? Great thanks.
rahulhegde (Tue, 14 Jul 2020 15:54:16 GMT):
hello @dave.enyeart
I am looking at slowness on the endorsement processing time. The client receives the response in 500-1000ms where the chainocde takes around 50ms. Looking at the peer log, i found a print
```
[34m2020-07-13 09:34:14.365 CEST [endorser] callChaincode -> INFO 731[0m [cls1obo][4fa59cdb] Entry chaincode: path:"bsl/clsnet-cls-chaincode/p2cls" name:"p2cls" version:"1.2"
[34m2020-07-13 09:34:14.412 CEST [endorser] callChaincode -> INFO 732[0m [cls1obo][4fa59cdb] Exit chaincode: path:"bsl/clsnet-cls-chaincode/p2cls" name:"p2cls" version:"1.2" (47ms)
[34m2020-07-13 09:34:15.686 CEST [comm.grpc.server] 1 -> INFO 733[0m unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=10.32.230.14:57030 grpc.code=OK grpc.call_duration=1.325757909s
```
GRPC duration is approximately the time taken for the endorsement by the client. Is Peer holding up the response or we need to tweak some value?
dave.enyeart (Wed, 15 Jul 2020 14:01:45 GMT):
@rahulhegde you can enable debug to better understand where time is spent, e.g. this debug will show the transaction flow but suppress other chatty components: `FABRIC_LOGGING_SPEC=debug:cauthdsl,policies,msp,grpc,peer.gossip.mcs,gossip=info`
rahulhegde (Wed, 15 Jul 2020 16:09:31 GMT):
Hello @dave.enyeart - I do have a print from another peer running on Debug
```
[34m2020-07-13 09:48:14.353 CEST [endorser] callChaincode -> INFO fe944[0m [cls1obo-cls2obo][230bd8e4] Exit chaincode: path:"bsl/clsnet-cls-chaincode/p2pcls" name:"p2pcls" version:"1.2" (1190ms)
[36m2020-07-13 09:48:14.353 CEST [lockbasedtxmgr] GetTxSimulationResults -> DEBU fe945[0m Simulation completed, getting simulation results
[36m2020-07-13 09:48:14.353 CEST [lockbasedtxmgr] Done -> DEBU fe946[0m Done with transaction simulation / query execution [230bd8e4220eadef21c4990fcb4c502690e4abac4ed13af00dc7f955d5a655fb]
[36m2020-07-13 09:48:14.353 CEST [endorser] SimulateProposal -> DEBU fe947[0m [cls1obo-cls2obo][230bd8e4] Exit
[36m2020-07-13 09:48:14.353 CEST [endorser] endorseProposal -> DEBU fe948[0m [cls1obo-cls2obo][230bd8e4] Entry chaincode: path:"bsl/clsnet-cls-chaincode/p2pcls" name:"p2pcls" version:"1.2"
[36m2020-07-13 09:48:14.353 CEST [endorser] endorseProposal -> DEBU fe949[0m [cls1obo-cls2obo][230bd8e4] escc for chaincode path:"bsl/clsnet-cls-chaincode/p2pcls" name:"p2pcls" version:"1.2" is escc
[36m2020-07-13 09:48:14.353 CEST [endorser] EndorseWithPlugin -> DEBU fe94a[0m Entering endorsement for {plugin: escc, channel: cls1obo-cls2obo, tx: 230bd8e4220eadef21c4990fcb4c502690e4abac4ed13af00dc7f955d5a655fb, chaincode: p2pcls}
[36m2020-07-13 09:48:14.354 CEST [msp.identity] Sign -> DEBU fe94b[0m Sign: plaintext: 0A2080FA565D53B193B98191E99A0F38...455254494649434154452D2D2D2D2D0A
[36m2020-07-13 09:48:14.354 CEST [msp.identity] Sign -> DEBU fe94c[0m Sign: digest: 8079A84325ACC55E6BC9752E2AC86000E615FD759B97FF47015CAE59A4DDF5B7
[36m2020-07-13 09:48:14.354 CEST [bccsp_p11] getSession -> DEBU fe94d[0m Reusing existing pkcs11 session 113 on slot 0
[36m2020-07-13 09:48:14.357 CEST [msp] GetDefaultSigningIdentity -> DEBU fe94e[0m Obtaining default signing identity
[36m2020-07-13 09:48:14.357 CEST [msp.identity] Sign -> DEBU fe94f[0m Sign: plaintext: 18012A340A221A20AFCA7C65F93C55C4...120E08B0ABDEF4C0DCBE901610B6AA01
[36m2020-07-13 09:48:14.357 CEST [msp.identity] Sign -> DEBU fe950[0m Sign: digest: 0E65F366A14E793C539C0ADC95B6468B2B71E3604E765B368A0E0FE0B81117F0
[36m2020-07-13 09:48:14.357 CEST [bccsp_p11] getSession -> DEBU fe951[0m Reusing existing pkcs11 session 14 on slot 0
[36m2020-07-13 09:48:14.457 CEST [msp] GetDefaultSigningIdentity -> DEBU fe952[0m Obtaining default signing identity
[36m2020-07-13 09:48:14.457 CEST [msp.identity] Sign -> DEBU fe953[0m Sign: plaintext: 0A1E706565723032636C736267623630...2E6A61732E636C736E65743A37303531
[36m2020-07-13 09:48:14.457 CEST [msp.identity] Sign -> DEBU fe954[0m Sign: digest: 6C1B23CE2C6C5C33FC97FCFE1321EAC8DCB6ADB018E5CCDD071CE1DF1D3EFAF5
[36m2020-07-13 09:48:14.457 CEST [bccsp_p11] getSession -> DEBU fe955[0m Reusing existing pkcs11 session 87 on slot 0
[36m2020-07-13 09:48:15.354 CEST [chaincode] handleMessage -> DEBU fe956[0m [] Fabric side handling ChaincodeMessage of type: KEEPALIVE in state ready
[36m2020-07-13 09:48:15.510 CEST [chaincode] handleMessage -> DEBU fe957[0m [] Fabric side handling ChaincodeMessage of type: KEEPALIVE in state ready
[36m2020-07-13 09:48:15.511 CEST [chaincode] handleMessage -> DEBU fe958[0m [] Fabric side handling ChaincodeMessage of type: KEEPALIVE in state ready
[36m2020-07-13 09:48:15.512 CEST [chaincode] handleMessage -> DEBU fe959[0m [] Fabric side handling ChaincodeMessage of type: KEEPALIVE in state ready
[36m2020-07-13 09:48:16.417 CEST [endorser] EndorseWithPlugin -> DEBU fe95a[0m Exiting {plugin: escc, channel: cls1obo-cls2obo, tx: 230bd8e4220eadef21c4990fcb4c502690e4abac4ed13af00dc7f955d5a655fb, chaincode: p2pcls}
[36m2020-07-13 09:48:16.417 CEST [endorser] endorseProposal -> DEBU fe95b[0m [cls1obo-cls2obo][230bd8e4] Exit
[36m2020-07-13 09:48:16.417 CEST [lockbasedtxmgr] Done -> DEBU fe95c[0m Done with transaction simulation / query execution [230bd8e4220eadef21c4990fcb4c502690e4abac4ed13af00dc7f955d5a655fb]
[36m2020-07-13 09:48:16.417 CEST [endorser] func1 -> DEBU fe95d[0m Exit: request from 10.32.230.14:51116
[34m2020-07-13 09:48:16.418 CEST [comm.grpc.server] 1 -> INFO fe95e[0m unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=10.32.230.14:51116 grpc.code=OK grpc.call_duration=3.255741695s
```
rahulhegde (Wed, 15 Jul 2020 16:10:25 GMT):
another logs -
```
[34m2020-07-13 09:51:15.485 CEST [endorser] callChaincode -> INFO 124a2a[0m [cls1obo-cls2obo][9b97559b] Exit chaincode: path:"bsl/clsnet-cls-chaincode/p2pcls" name:"p2pcls" version:"1.2" (893ms)
[36m2020-07-13 09:51:15.485 CEST [lockbasedtxmgr] GetTxSimulationResults -> DEBU 124a2b[0m Simulation completed, getting simulation results
[36m2020-07-13 09:51:15.485 CEST [lockbasedtxmgr] Done -> DEBU 124a2c[0m Done with transaction simulation / query execution [9b97559b7db78bfe07e8b25603670b7d13583f68ffb43ee290cf3958c6507e64]
[36m2020-07-13 09:51:15.485 CEST [endorser] SimulateProposal -> DEBU 124a2d[0m [cls1obo-cls2obo][9b97559b] Exit
[36m2020-07-13 09:51:15.485 CEST [endorser] endorseProposal -> DEBU 124a2e[0m [cls1obo-cls2obo][9b97559b] Entry chaincode: path:"bsl/clsnet-cls-chaincode/p2pcls" name:"p2pcls" version:"1.2"
[36m2020-07-13 09:51:15.485 CEST [endorser] endorseProposal -> DEBU 124a2f[0m [cls1obo-cls2obo][9b97559b] escc for chaincode path:"bsl/clsnet-cls-chaincode/p2pcls" name:"p2pcls" version:"1.2" is escc
[36m2020-07-13 09:51:15.485 CEST [endorser] EndorseWithPlugin -> DEBU 124a30[0m Entering endorsement for {plugin: escc, channel: cls1obo-cls2obo, tx: 9b97559b7db78bfe07e8b25603670b7d13583f68ffb43ee290cf3958c6507e64, chaincode: p2pcls}
[36m2020-07-13 09:51:15.485 CEST [msp.identity] Sign -> DEBU 124a31[0m Sign: plaintext: 0A2085A9F7A27DD078723F055193543F...455254494649434154452D2D2D2D2D0A
[36m2020-07-13 09:51:15.485 CEST [msp.identity] Sign -> DEBU 124a32[0m Sign: digest: 57FDD07CAE08146423DFC4E8B4D817225F6F401180B3A934A02FE3B224508A15
[36m2020-07-13 09:51:15.485 CEST [bccsp_p11] getSession -> DEBU 124a33[0m Reusing existing pkcs11 session 63 on slot 0
[36m2020-07-13 09:51:15.509 CEST [chaincode] handleMessage -> DEBU 124a34[0m [] Fabric side handling ChaincodeMessage of type: KEEPALIVE in state ready
[36m2020-07-13 09:51:15.511 CEST [chaincode] handleMessage -> DEBU 124a35[0m [] Fabric side handling ChaincodeMessage of type: KEEPALIVE in state ready
[36m2020-07-13 09:51:15.512 CEST [chaincode] handleMessage -> DEBU 124a36[0m [] Fabric side handling ChaincodeMessage of type: KEEPALIVE in state ready
[36m2020-07-13 09:51:16.522 CEST [msp] GetDefaultSigningIdentity -> DEBU 124a37[0m Obtaining default signing identity
[36m2020-07-13 09:51:16.522 CEST [msp.identity] Sign -> DEBU 124a38[0m Sign: plaintext: 0A1E706565723032636C736267623630...2E6A61732E636C736E65743A37303531
[36m2020-07-13 09:51:16.522 CEST [msp.identity] Sign -> DEBU 124a39[0m Sign: digest: 6C1B23CE2C6C5C33FC97FCFE1321EAC8DCB6ADB018E5CCDD071CE1DF1D3EFAF5
[36m2020-07-13 09:51:16.522 CEST [bccsp_p11] getSession -> DEBU 124a3a[0m Reusing existing pkcs11 session 87 on slot 0
[36m2020-07-13 09:51:16.579 CEST [endorser] EndorseWithPlugin -> DEBU 124a3b[0m Exiting {plugin: escc, channel: cls1obo-cls2obo, tx: 9b97559b7db78bfe07e8b25603670b7d13583f68ffb43ee290cf3958c6507e64, chaincode: p2pcls}
[36m2020-07-13 09:51:16.579 CEST [endorser] endorseProposal -> DEBU 124a3c[0m [cls1obo-cls2obo][9b97559b] Exit
[36m2020-07-13 09:51:16.579 CEST [lockbasedtxmgr] Done -> DEBU 124a3d[0m Done with transaction simulation / query execution [9b97559b7db78bfe07e8b25603670b7d13583f68ffb43ee290cf3958c6507e64]
[36m2020-07-13 09:51:16.579 CEST [endorser] func1 -> DEBU 124a3e[0m Exit: request from 10.32.230.14:51116
[34m2020-07-13 09:51:16.579 CEST [comm.grpc.server] 1 -> INFO 124a3f[0m unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=10.32.230.14:51116 grpc.code=OK grpc.call_duration=1.995867274s
```
rahulhegde (Wed, 15 Jul 2020 17:30:46 GMT):
This setup is running on HSM. Almost a sec is spent between API call, I am not able to pin-point what would be Peer waiting for before `EndorseWithPlugin -> DEBU 124a3b[0m Exiting`?
```
[36m2020-07-13 09:51:15.485 CEST [bccsp_p11] getSession -> DEBU 124a33[0m Reusing existing pkcs11 session 63 on slot 0
[36m2020-07-13 09:51:15.509 CEST [chaincode] handleMessage -> DEBU 124a34[0m [] Fabric side handling ChaincodeMessage of type: KEEPALIVE in state ready
[36m2020-07-13 09:51:15.511 CEST [chaincode] handleMessage -> DEBU 124a35[0m [] Fabric side handling ChaincodeMessage of type: KEEPALIVE in state ready
[36m2020-07-13 09:51:15.512 CEST [chaincode] handleMessage -> DEBU 124a36[0m [] Fabric side handling ChaincodeMessage of type: KEEPALIVE in state ready
[36m2020-07-13 09:51:16.522 CEST [msp] GetDefaultSigningIdentity -> DEBU 124a37[0m Obtaining default signing identity
[36m2020-07-13 09:51:16.522 CEST [msp.identity] Sign -> DEBU 124a38[0m Sign: plaintext: 0A1E706565723032636C736267623630...2E6A61732E636C736E65743A37303531
[36m2020-07-13 09:51:16.522 CEST [msp.identity] Sign -> DEBU 124a39[0m Sign: digest: 6C1B23CE2C6C5C33FC97FCFE1321EAC8DCB6ADB018E5CCDD071CE1DF1D3EFAF5
[36m2020-07-13 09:51:16.522 CEST [bccsp_p11] getSession -> DEBU 124a3a[0m Reusing existing pkcs11 session 87 on slot 0
[36m2020-07-13 09:51:16.579 CEST [endorser] EndorseWithPlugin -> DEBU 124a3b[0m Exiting {plugin: escc, channel: cls1obo-cls2obo, tx: 9b97559b7db78bfe07e8b25603670b7d13583f68ffb43ee290cf3958c6507e64, chaincode: p2pcls}
```
xachen (Tue, 21 Jul 2020 08:51:34 GMT):
Has joined the channel.
dave.enyeart (Tue, 21 Jul 2020 21:46:11 GMT):
@rahulhegde Sorry I missed this one... definitely related to HSM since the delay is after every "Reusing existing pkcs11 session" message (you can ignore those KEEPALIVE messages since they are not in the transaction execution path). I know that in v1.4.7 there are some HSM fixes, one of them handled bad sessions instead of leaving them in the cache.
dave.enyeart (Tue, 21 Jul 2020 21:46:11 GMT):
@rahulhegde Sorry I missed this one when I was out... definitely related to HSM since the delay is after every "Reusing existing pkcs11 session" message (you can ignore those KEEPALIVE messages since they are not in the transaction execution path). I know that in v1.4.7 there are some HSM fixes, one of them handled bad sessions instead of leaving them in the cache.
rahulhegde (Wed, 22 Jul 2020 00:57:06 GMT):
No problem @dave.enyeart, thanks for the response. This log is from Fabric v1.4.2. Are you referring to https://jira.hyperledger.org/browse/FAB-17728?
dave.enyeart (Wed, 22 Jul 2020 02:51:30 GMT):
@rahulhegde That was one of the HSM fixes, but I was talking about https://jira.hyperledger.org/browse/FAB-17722 . Not sure if a bad session would cause such a delay though.
rahulhegde (Wed, 22 Jul 2020 18:32:53 GMT):
@dave.enyeart - I feel we should expect error message in the logs by use of stale session during sign operation. I was not able to find anything that confirms in Jira or commit. Do you know?
rahulhegde (Wed, 22 Jul 2020 20:46:50 GMT):
@dave.enyeart another topic: Fabric v1.4.2, I see the chaincode rich query limit is been overwritten by a compulsory 1000 by the Peer. Is it done for a reason or can it be changed to retain the original value used in chaincode, because we explicitly try to set to a limit: 1. In case of $in clause in rich query it takes time in scanning all records rather exiting after receiving the first record.
dave.enyeart (Wed, 22 Jul 2020 21:46:47 GMT):
Sorry I don't know, could you follow up in a ticket?
dave.enyeart (Wed, 22 Jul 2020 21:47:20 GMT):
The limit can be configured at: https://github.com/hyperledger/fabric/blob/v1.4.2/sampleconfig/core.yaml#L616
dave.enyeart (Wed, 22 Jul 2020 21:48:21 GMT):
This is the size of each result set returned to the chaincode. As you iterate through the results in chaincode, the next batches of 1000 will automatically be requested from CouchDB.
rahulhegde (Wed, 22 Jul 2020 23:58:44 GMT):
But this would overwrite all the rich queries limit to a new value. we have queries w/o any limit set.
dave.enyeart (Thu, 23 Jul 2020 02:14:09 GMT):
there should be no functional change in the chaincode, you can iterate through all the results in the chaincode, they will just be batched in sets of 1000 between the chaincode and CouchDB.
sanket1211 (Mon, 17 Aug 2020 14:46:01 GMT):
hey guys...how can we verify if certain peer is leader peer? i have checked the log of the peer but didnt see there..plz help!
dave.enyeart (Wed, 19 Aug 2020 12:05:54 GMT):
@sanket1211 When a peer becomes a lead peer it will post a log message as follows:
dave.enyeart (Wed, 19 Aug 2020 12:05:58 GMT):
`[deliveryClient] StartDeliverForChannel -> INFO 106 This peer will retrieve blocks from ordering service and disseminate to other peers in the organization for channel mychannel`
jorgeRodriguez (Tue, 15 Sep 2020 02:07:28 GMT):
Has joined the channel.
robmurgai (Thu, 15 Oct 2020 15:58:34 GMT):
Has joined the channel.
sanket1211 (Wed, 21 Oct 2020 10:48:50 GMT):
2020-10-21T10:39:52.855Z - error: [ServiceEndpoint]: Error: Failed to connect before the deadline on Discoverer- name: peer0.org1.example.com, url:grpcs://localhost:7051
2020-10-21T10:39:52.855Z - error: [ServiceEndpoint]: waitForReady - Failed to connect to remote gRPC server peer0.org1.example.com url:grpcs://localhost:7051 timeout:3000
Getting error: Error: Failed to connect before the deadline on Discoverer- name: peer0.org1.example.com, url:grpcs://localhost:7051
ericmvaughn (Mon, 26 Oct 2020 16:27:36 GMT):
Has left the channel.
sanket1211 (Tue, 27 Oct 2020 06:24:47 GMT):
Failed to connect before the deadline on Discoverer- name: peer0.org1.example.com, url:grpcs://localhost:7051
sanket1211 (Wed, 28 Oct 2020 14:16:13 GMT):
DiscoveryService: mychannel error: access denied
troyronda (Wed, 28 Oct 2020 17:44:37 GMT):
Has left the channel.
heena066 (Mon, 02 Nov 2020 09:32:48 GMT):
Has joined the channel.
Benjamin (Tue, 03 Nov 2020 14:30:52 GMT):
Has joined the channel.
cynicalsnail (Wed, 18 Nov 2020 07:02:01 GMT):
Has joined the channel.
alacambra (Wed, 23 Dec 2020 22:09:23 GMT):
Has joined the channel.
alacambra (Wed, 23 Dec 2020 22:21:26 GMT):
Hi everybody! I have one question about the TX flow. *At with point exactly is a block event or chaincode event received? Before the peer finishes to write into the ledger an updates the Global state otr in some point btw?* I am asking that because I have some transactions that after being confirmed, I cannot query the data immediately, needing some more time until the date is available.
alacambra (Wed, 23 Dec 2020 22:21:26 GMT):
Hi everybody! I have one question about the TX flow. *At with point exactly is a block event or chaincode event received? Before the peer finishes to write into the ledger an updates the Global state or in some point btw?* I am asking that because I have some transactions that after being confirmed, I cannot query the data immediately, needing some more time until the date is available.
adanacs (Mon, 04 Jan 2021 05:33:39 GMT):
Has joined the channel.
adanacs (Wed, 06 Jan 2021 17:55:35 GMT):
Hi, I've had a number of certs expire - I've been able to work around the orderer tls certs with the time offset, but I'm unable to use the peer cli to send the transaction to the orderers because the peer signing cert has expired (the peer cli won't start and send the transaction). The peer cli will start if I update the signing certs but the transaction won't go through.
Does anyone have any pointers on how to start the peer cli with expired certs?
adanacs (Wed, 06 Jan 2021 17:55:35 GMT):
Hi, I've had a number of certs expire - I've been able to work around the orderer tls certs with the time offset, but I'm unable to use the peer cli to send the transaction to the orderers because the peer signing cert has expired (the peer cli won't start and send the transaction). The peer cli will start if I update the signing certs but the transaction won't go through.
`Cannot run peer because error when setting up MSP of type bccsp from directory /data/orgs/......./admin/msp: signing identity expired`
Does anyone have any pointers on how to start the peer cli with expired certs?
Does anyone have any pointers on how to start the peer cli with expired certs?
adanacs (Wed, 06 Jan 2021 17:55:35 GMT):
Hi, I've had a number of certs expire - I've been able to work around the orderer tls certs with the time offset, but I'm unable to use the peer cli to send the transaction to the orderers because the peer signing cert has expired (the peer cli won't start and send the transaction). The peer cli will start if I update the signing certs but the transaction won't go through.
`Cannot run peer because error when setting up MSP of type bccsp from directory /data/orgs/......./admin/msp: signing identity expired`
Does anyone have any pointers on how to start the peer cli with expired certs?
adanacs (Fri, 08 Jan 2021 23:45:16 GMT):
In addition to my question about starting the peer - I've found this https://jira.hyperledger.org/browse/FAB-18175 and the comments suggest it's trivial to build a peer that doesn't check signing cert expiry. Are there any pointers available to building the peer with this setting?
adanacs (Fri, 08 Jan 2021 23:47:29 GMT):
ideally I want to be able to do `peer channel signconfigtx .....` with the expired admin cert, so that I can add the new current certs
adanacs (Fri, 08 Jan 2021 23:48:19 GMT):
I have tried updating using `fabric-sdk-node` client, but I'm getting cert errors there as well
adanacs (Sat, 09 Jan 2021 01:20:29 GMT):
^^ ok -looks like I need to run the peer locally with my system time set so the original certs are valid to sign the transaction (since my network is on kubernetes), then the tlsHandshakeTimeShift flag works for submitting it with the peers with updated certs
Sandyzhanghs (Sun, 10 Jan 2021 05:01:36 GMT):
Has joined the channel.
awattez (Sun, 31 Jan 2021 13:16:09 GMT):
Hi, I asked a question on the channel, maybe it's more appropriate to ask it here:
https://chat.hyperledger.org/channel/fabric-questions?msg=tmZ9Mtcm2H6coFHa4
awattez (Sun, 31 Jan 2021 13:16:09 GMT):
Hi, I asked a question on the channel #fabric-questions, maybe it's more appropriate to ask it here:
https://chat.hyperledger.org/channel/fabric-questions?msg=tmZ9Mtcm2H6coFHa4
braduf (Fri, 05 Feb 2021 15:27:22 GMT):
Hi all, to enable mTLS, I was wondering if all certificate chains of all orgs should be configured again in CORE_PEER_TLS_CLIENTROOTCAS or if the peer automatically enables client connections from certificates issued by the tlscacerts and/or tlsintermediatecerts of the channel MSPs? Following the explanation in core.yaml it should be dynamically, but from experience, I think I encountered problems in the past with not having certificate chains of other orgs set in the parameter... so i would like to be sure. Thanks in advance!
braduf (Fri, 05 Feb 2021 15:31:17 GMT):
Hi @awattez , I think you can just borrow the Admins role in the organization policies of Org2.
Btw: Adrien Wattez, Capgemini, CWB? haha
braduf (Fri, 05 Feb 2021 15:31:17 GMT):
Hi @awattez , I think you can just remove the Admins role in the organization policies of Org2.
Btw: Adrien Wattez, Capgemini, CWB? haha
AbhijeetSamanta (Sun, 14 Feb 2021 19:25:18 GMT):
Hi All, I am getting error Getting error error: [Transaction]: Error: No valid responses from any peers. Errors: while submit transaction in hyperledger fabric 2.2. please anybody help me on this. I asked on stackoverlow also https://stackoverflow.com/questions/66199188/getting-error-error-transaction-error-no-valid-responses-from-any-peers-er
kartheekgottipati (Sat, 27 Feb 2021 07:48:47 GMT):
Has joined the channel.
suosuidewenqing (Tue, 02 Mar 2021 08:35:53 GMT):
Has joined the channel.
vanitas92 (Thu, 01 Apr 2021 11:38:03 GMT):
Has joined the channel.
sanket1211 (Tue, 15 Jun 2021 10:11:10 GMT):
Issue while Upgrading fabric from 1.4.4 to 2.2
we are able to update peer and orderer components to the latest version but while updating the channel capababilities to fetch the config block,peers are not able to connect with the orderer
Error: could not not connect to ordering service:could not dial endpoint:dial tcp:lookup orderer.example.com on 192.168.0.1:53 :no such host channel=mychannel
attaching the logs for more details
sanket1211 (Tue, 15 Jun 2021 10:11:22 GMT):
Screenshot from 2021-06-14 14-39-30.png
sanket1211 (Tue, 15 Jun 2021 10:11:22 GMT):
Screenshot from 2021-06-14 14-39-41.png
AfzaalLucky (Thu, 08 Jul 2021 22:34:03 GMT):
Has joined the channel.
akshay.sood (Mon, 30 Aug 2021 08:32:07 GMT):
Hey guys
My peers are throwing the following error
```
2021-08-30 08:25:41.727 UTC [vscc] Validate -> ERRO 243 VSCC error: stateBasedValidator.Validate failed, err unexpected EOF
2021-08-30 08:25:41.728 UTC [committer.txvalidator] validateTx -> ERRO 244 Dispatch for transaction txId = 463b57826a54e16921aa153617a824e39514550c25a7c5816fb77bde3386f357 returned error: unexpected EOF
2021-08-30 08:25:41.728 UTC [gossip.privdata] StoreBlock -> ERRO 245 Validation failed: unexpected EOF channel=assetschannel
2021-08-30 08:25:41.728 UTC [gossip.state] commitBlock -> ERRO 246 Got error while committing(unexpected EOF
github.com/hyperledger/fabric/gossip/state.(*GossipStateProviderImpl).commitBlock
/go/src/github.com/hyperledger/fabric/gossip/state/state.go:799
github.com/hyperledger/fabric/gossip/state.(*GossipStateProviderImpl).deliverPayloads
/go/src/github.com/hyperledger/fabric/gossip/state/state.go:571
runtime.goexit
/usr/local/go/src/runtime/asm_amd64.s:1374)
2021-08-30 08:25:41.728 UTC [gossip.state] deliverPayloads -> ERRO 247 Failed executing VSCC due to unexpected EOF. Aborting chain processing
```
and no transaction is getting committed after that. Even chaincode is not being upgraded. This happened after block 84 and orderer shows new blocks being created (logs below) but peers are not getting new blocks now.
```
2021-08-30 07:56:43.587 UTC [orderer.consensus.etcdraft] writeBlock -> INFO 047 Writing block [98] (Raft index: 130) to ledger channel=assetschannel node=2
2021-08-30 07:57:25.418 UTC [orderer.consensus.etcdraft] writeBlock -> INFO 048 Writing block [99] (Raft index: 131) to ledger channel=assetschannel node=2
2021-08-30 08:05:09.380 UTC [orderer.consensus.etcdraft] writeBlock -> INFO 049 Writing block [100] (Raft index: 132) to ledger channel=assetschannel node=2
2021-08-30 08:08:34.060 UTC [orderer.consensus.etcdraft] writeBlock -> INFO 04a Writing block [101] (Raft index: 133) to ledger channel=assetschannel node=2
```
This happened after adding key-based endorsement policy in the chaincode
akshay.sood (Mon, 30 Aug 2021 08:32:25 GMT):
has anyone faced this issue?
akshay.sood (Mon, 30 Aug 2021 08:41:17 GMT):
SO: https://stackoverflow.com/questions/68981164/hyperledger-fabric-peers-throwing-vscc-error-and-not-committing-new-blocks
indirajith (Sat, 25 Sep 2021 17:43:14 GMT):
Hi all, Can anyone help me fix this? One peer doea not respond to the queries
https://chat.hyperledger.org/channel/fabric?msg=oqMCi3qDeeTtLgnJF
Bert (Sat, 22 Jan 2022 09:23:34 GMT):
Has joined the channel.
rjones (Wed, 23 Mar 2022 17:35:25 GMT):
rjones (Wed, 23 Mar 2022 17:35:25 GMT):
rjones (Wed, 23 Mar 2022 17:35:25 GMT):
