Replies: 1 comment
-
Since implementing the Jsonnet functionality, we've seen some success with templating workloads with pre-computed details. However, there is a significant improvement to be made, based on user feedback.
Since we already have access to the MVEL2 expression and templating language, and since it has an orb format which is already distinct from any other form we might use for variables, it could be a simpler approach than Jsonnet. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
In several scenarios, users have needed more expressive tools to test their systems with than just op templates. They have needed a facility to provide macro-level specification, or meta-programming of a test scenario.
These sceanrios include, for example, the ability to specify a set 1000 different operations which are structurally similar but which use a different field, or the ability to use a multitude of tables in a schema management test.
There are two primary ways of achieving this, and they are complimentary:
These can both be supported as needed for different usage scenarios.
Trade-offs between approaches
The direct API method is a natural extension of the existing NB runtime design. Scenario designers who are already used to building more advanced scenario scripts directly would simply have more options to pick from. Either they pass a workload file to an activity which uses the well-define op templating format (data structure), or they pass an object (data structure) as an activity parameter. In both cases, the data structure uses the well-established op template standards. With current NB machinery, this would remain an initialization-time option, as once the activity's sequence is computed, it is considered to be static for the life of the activity. This type of enhancement is already on the plan for future NB enhancements, although it does comes with trade-offs.
The pre-processor method is a way to bring less programmatic options to users. The usage of the jsonnet templating language, for example, could allow for some very simple meta programming of op templates without requiring all users to drop down to writing code. This could allow users who are already focused on data-driven and template-oriented design to use a tool that is already well established in the OSS ecosystem.
Option Three: Layering
There is another intriguing option which is why not both?. Given that there is merit for the use of both of these approaches, it is reasonable that bringing them both together would provide the most flexibility. The direct API method can be considered a meta-programming approach and the pre-processor can be considered a meta-templating approach. It is quite reasonable that someone would want to use the meta-templating within their use of programmatic data structure building.
Enabling pre-processing
There should not be an easy way to accidentally enable jsonnet processing on data which is not intended for such. Thus, a file extension which follows jsonnet conventions should be adhered to. Specifically, any file which is referenced as
.jsonnet
should be processed, after template variable expansion, into an equivalent.json
file, and loaded with the standard workload processing logic. JSON is a subset of YAML, so this is already supported in theory.Enabling direct API
The case for enabling the use of direct data structures for workload data should be obvious and explicit as well. Thankfully this is easy, as it is a simple matter of what type of reference is passed from the scripting environment to the scenario controller API. Essentially, if the
workload
parameter is a JSON object, then it should be considered the equivalent data structure to anything that can be loaded from a workload YAML or JSON file.Enabling jsonnet processing against data structure in the scripting environment is a different scenario altogether. This is the layering scenario. In this case, it should suffice to make an explicit service object in the scripting environment which provides jsonnet capability. This can simply be implemented as a scripting extension for NB. A
jsonnet
service object can provide JSON evaluation capabilities with optional context injection.Outcomes
If this capability is added to NB,
Beta Was this translation helpful? Give feedback.
All reactions