Caliper requires configuration files to operate. Some of these are completely within the remit of a user - for instance the benchmark file itself (but hey, that's what the generator exists for)
It would be super handy if the Caliper CLI was capable of outputting a "consumable" network configuration file, that is generated based upon some sensible inputs. This would massively enhance the ability for Caliper to be consumed by users who may simply want to test an existing system.
For instance, if we consider the Fabric connector, we know that the network file is "an extended CCP". This puts us in the position where we could feed a CLI an exported CCP, along with some identity information, and the output is:
caliper network configuration file
defined internal client that uses the identity information
possibly a generated wallet with the identity within it?
this network file has the ability to be complete with "just" a CCP and identity information when discovery is enabled (core changes required there though), but we could augment the CLI with other required information if required.
Given the focus on using the new peer gateway to connect to fabric and thus how it simplifies how to describe how to interact with a fabric network, I wonder if there is much benefit to this now ?
Caliper requires configuration files to operate. Some of these are completely within the remit of a user - for instance the benchmark file itself (but hey, that's what the generator exists for)
It would be super handy if the Caliper CLI was capable of outputting a "consumable" network configuration file, that is generated based upon some sensible inputs. This would massively enhance the ability for Caliper to be consumed by users who may simply want to test an existing system.
For instance, if we consider the Fabric connector, we know that the network file is "an extended CCP". This puts us in the position where we could feed a CLI an exported CCP, along with some identity information, and the output is: