You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, the test controller must be manually updated to be aware of and modify new parameters which the system is capable of understanding in the config. At minimum, this means if a component learns of a new config option, and we want it to be controllable from the TC, that config option needs to be manually added into the TC and wait for it to be deployed.
There are kind of two ways we could improve this, one of which is a short-term workaround, the other is far better long-term.
Add an adhoc additional-parameter text-area
allow experimenter to arbitrarily add settings to the final config
allow the TC to parse out options which are valid for a given test configuration (parsing the same docopt input as the components)
enables simplifying the UI to only show options which are relevant given the components present in the test, and to automatically adjust to parameters available given the code checked out for the specified commit
Probably we should actually do both of these (since the first option enables some more significant agility quickly and with minimal effort), but the second solution is far more effectively long-term and will minimize a lot of maintenance boilerplate for new developments.
Right now, the test controller must be manually updated to be aware of and modify new parameters which the system is capable of understanding in the config. At minimum, this means if a component learns of a new config option, and we want it to be controllable from the TC, that config option needs to be manually added into the TC and wait for it to be deployed.
There are kind of two ways we could improve this, one of which is a short-term workaround, the other is far better long-term.
docopt
for each componentProbably we should actually do both of these (since the first option enables some more significant agility quickly and with minimal effort), but the second solution is far more effectively long-term and will minimize a lot of maintenance boilerplate for new developments.
cf. mit-dci/opencbdc-tx#81
The text was updated successfully, but these errors were encountered: