(Part 3) Command-line parsing and YAML config files in Rust#1278
(Part 3) Command-line parsing and YAML config files in Rust#1278stevenengler merged 10 commits intoshadow:devfrom
Conversation
Codecov Report
@@ Coverage Diff @@
## dev #1278 +/- ##
==========================================
+ Coverage 55.74% 56.19% +0.44%
==========================================
Files 142 140 -2
Lines 20960 20161 -799
Branches 5295 5018 -277
==========================================
- Hits 11685 11329 -356
+ Misses 6160 5941 -219
+ Partials 3115 2891 -224
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
e58c2e1 to
bfe22de
Compare
bfe22de to
735686b
Compare
aa54082 to
9e576ab
Compare
9e576ab to
d310f7b
Compare
1364109 to
bff5b2f
Compare
robgjansen
left a comment
There was a problem hiding this comment.
This looks great! It simplifies a lot of things and will make it much simpler to configure experiments. I'm looking forward to using this new format in my experiments :)
I don't have any complex changes, but I'd like to look at any changes you make anyway :)
| return EXIT_SUCCESS; | ||
| } | ||
|
|
||
| char* configName = clioptions_getConfig(options); |
There was a problem hiding this comment.
Might be worth commenting that this will never return a NULL configName.
There was a problem hiding this comment.
I changed this so that it can return NULL (before it would panic!()), but also added a NULL check in C.
| configFile = configfile_parse(configName); | ||
| } else { | ||
| configFile = configfile_parse("/dev/stdin"); |
There was a problem hiding this comment.
Might be worth commenting why configfile_parse might return NULL.
There was a problem hiding this comment.
Added a comment.
| configfile_free(configFile); | ||
|
|
||
| if (clioptions_getShowConfig(options)) { | ||
| config_showConfig(config); |
There was a problem hiding this comment.
Do we want to exit after showing the config?
| ConfigHandlerFn fn = g_array_index(experimentalOptions, ConfigHandlerFn, i); | ||
| fn(config); | ||
| } | ||
| g_array_free(experimentalOptions, true); |
There was a problem hiding this comment.
Do we want to set experimentalOptions to NULL to make sure we don't operate on it anymore (now that the array data has been freed)?
There was a problem hiding this comment.
Good idea, added.
| #define OPTIONS_TOKENPASTE(x, y) x##y | ||
| #define OPTIONS_TOKENPASTE2(x, y) OPTIONS_TOKENPASTE(x, y) |
There was a problem hiding this comment.
Do we want these to be used outside of this file? Or should we undef them at the end of this file?
There was a problem hiding this comment.
I don't think we can undef them since they're used by the ADD_CONFIG_HANDLER macro. (The build fails when I undef them.)
| rm -rf ${SHADOW_TEST_NAME}.data \ | ||
| && ${yaml2xml} ${SHADOW_TEST_SHADOW_CONFIG} --output - \ | ||
| | ${CMAKE_BINARY_DIR}/src/main/shadow \ | ||
| && ${CMAKE_BINARY_DIR}/src/main/shadow \ |
src/test/clone/clone.yaml
Outdated
| - plugin: test_clone | ||
| starttime: 1 | ||
| arguments: '' | ||
| host: |
There was a problem hiding this comment.
Super-nit: can we change the name of the host to something that is more apparently a hostname instead of host?
There was a problem hiding this comment.
Changed to testnode like the other tests.
| bandwidth_down: 819200 Kibit | ||
| bandwidth_up: 819200 Kibit |
There was a problem hiding this comment.
Some more Kibit -> Kibibit conversions here.
| bandwidth_down: 819200 Kibit | ||
| bandwidth_up: 819200 Kibit |
There was a problem hiding this comment.
Should we just set this bandwidth as the default for everyone in the host_defaults part of the config? Then we wouldn't need to duplicate it for each host.
Or even better, the topology only contains a single node, and that node already has the correct bandwidth, so I think all the hosts will already get assigned that bandwidth even if we don't specify it as a host option or host_default option.
There was a problem hiding this comment.
Some hosts have bandwidths of 819200 kibibit (102400 KiB/s), some have 81920 kibibit (10240 KiB/s), clients have no defined bandwidths, and the topology node has a bandwidth of 81920 kibibit. Is there a reason why the original configuration had these hosts with different bandwidths? And why some hosts had bandwiths 10x greater than the topology node? Since this is just a test, it should be fine giving them all the same bandwidth, right?
There was a problem hiding this comment.
Right, I don't think the bandwidths matter much in this small test. I think they can all be the same. Not sure why they were different before - probably because I decided that many many years ago and never changed it.
There was a problem hiding this comment.
Changed the topology bandwidth to 1 Gbit (rounded up from the ~800 Mbit that most hosts were using) and unset all of the other bandwidths.
robgjansen
left a comment
There was a problem hiding this comment.
Looks great! Thanks for the changes :)
Replaces Shadow's existing command-line and configuration file parsing code with Rust versions using Serde and Clap (version 3.0.0-beta.2). Shadow's XML configuration file format has been replaced by YAML in the process.
This PR will be easier to review as individual commits.
Closes #773.
Changed CLI options:
Changed configuration options:
Changed topology options:
Miscellaneous changes:
quantityfield for processesoptionsfield togeneral, and added new experimental options under the top-levelexperimentalfield, and new host default options under the top-levelhost_defaultsfield.experimentalgroup (Organize and remove legacy options #1220)optionsfieldplaintopology option (in addition to the existinggraphmlandpathoptions), which uses a simple built-in topology (Add default single-node topology in case user does not provide one #1221)logpcapandpcapdiroptions have been combined into a single optionpcap_directory-h,-i,-j, etc)killandtime(Remove old Shadow configuration options #1146)To do after this PR: