Make the CA script logging more readable for users
trying to understand the fabric-ca-client commands.
Print the actual command to the log and remove the
debug logging which adds noise.
Signed-off-by: David Enyeart <enyeart@us.ibm.com>
Use the operations service health check to detect when nodes are started
in test-network-nano-bash instead of using arbitrary sleeps. Depending
on the host machine and whether CAs are used, this can reduce network
start time by up to 15 seconds.
Also ensure the Docker socket location is set correctly for Docker
contexts that use a non-default location. This is required to prevent
the health service from returning Docker connection errors.
Signed-off-by: Mark S. Lewis <Mark.S.Lewis@outlook.com>
Fix test-network-nano-bash orderer4 enrollment.
Also improve error handling and messages in CA interaction.
Signed-off-by: David Enyeart <enyeart@us.ibm.com>
test-network-nano-bash is often used with locally built
fabric and fabric-ca binaries.
As such the intent is to first look for locally
built binaries and then fall back to binaries downloaded
with the samples.
This was correct for fabric binaries but not the fabric-ca binaries.
Signed-off-by: David Enyeart <enyeart@us.ibm.com>
Since Fabric v3.0 builds on ubuntu 22.04,
it is necessary for samples CI to run on ubuntu 22.04.
Both Fabric v2.5 components (ubuntu 20.04) and
Fabric v3.0 components (ubuntu 22.04) work on
ubuntu 22.04 runtime.
The update also requires shell script updates to pass linting.
Signed-off-by: David Enyeart <enyeart@us.ibm.com>
- Correct sh compability in ca_utils.sh
- Correct linux compatibility in external builder
Signed-off-by: Chris Elder <celder628@gmail.com>
Signed-off-by: Chris Elder <celder@Chriss-MacBook-Pro.local>
This change adds:
- shell scripts to start CAs for each org
- optional flag (-c) to network.sh to start CAs
- generate crypto material in the same format as cryptogen using the CAs
- describe how to start the CAs using terminals
Signed-off-by: Chris Elder <celder@chriss-mbp.raleigh.ibm.com>
Fix regression in network.sh and update peer scripts to allow
chaincodeListenAddress and chaincodeAddress to be overridden if
required
Also updates the nano test network readme to describe the new
environment variables for the k8s builder
Fixes#1198
Signed-off-by: James Taylor <jamest@uk.ibm.com>
- Use calculatepackageid to set CHAINCODE_ID
- Use waitForEvent to wait for commit event intead of 2s sleep
Signed-off-by: David Enyeart <enyeart@us.ibm.com>
* Add in examples and notes on using PurgePrivateData
- Update the configtx.yaml to enable the 2.5 capabillity
- Added purge into the chancode
- Added pruge into the application client code.
Signed-off-by: Matthew B White <whitemat@uk.ibm.com>
* Temporarily remove java cc test
Signed-off-by: Matthew B White <whitemat@uk.ibm.com>
Fix minor bugs, and add network.sh script to simplify standing up the network
Note: the updated peerNadmin.sh scripts no longer create or join a channel and now only configure the environment for the relevant peer
Signed-off-by: James Taylor <jamest@uk.ibm.com>
This addresses Issue #504. This extends the test-network-nano-bash
sample to offer an option to run a fabric network without using any
containers at all. The chaincode is running as an external service
directly on the host machine.
Signed-off-by: Arnaud J Le Hors <lehors@us.ibm.com>
Fix CORE_PEER_ID for peer4.
This fix ensures that peer3 and peer4 don't share the
same chaincode container.
Signed-off-by: David Enyeart <enyeart@us.ibm.com>
CHAINCODEADDRESS is set to host.docker.internal which is
only available in MAC and Windows environments.
For that reason, it cannot launch chaincode on Linux.
This PR sets CHAINCODEADDRESS to 127.0.0.1 instead of
host.docker.internal.
Signed-off-by: Nao Nishijima <nao.nishijima.xt@hitachi.com>
Test network Nano bash provides a set of minimal bash scripts
to run a Fabric network on your local machine.
The network is functionally equivalent to the docker-based Test Network,
you can therefore run all the tutorials and samples that target the Test Network.
The Fabric release binaries are utilized rather than using docker containers
to avoid all unnecessary layers. Only the chaincode and chaincode builder
runs in a docker container behind the scenes.
Using the Fabric binaries also makes it simple for Fabric developers
to iteratively and quickly modify Fabric code and test a Fabric network as a user.
Signed-off-by: David Enyeart <enyeart@us.ibm.com>
