Feat/12394 v1 Prepare for release 1.0.2-dev (init command, CPU ranges, Suricata spec)

[KEIAHNY]

PR Type

Enhancement, Documentation

---

Description

• Add init command to generate default configuration file

• Support CPU range expansion in max_cpu_usage_vec

  • New parse_cpu_list and expand_cpu_range helpers
  • Accept string ranges like 0-6 in YAML config

• Document required Suricata branch and commit in README

• Bump version to 1.0.2-dev across project files

---

Diagram Walkthrough

flowchart LR
  CLI["CLI Args"] -- "init command" --> Init["config_gen::init writes DEFAULT_CONFIG"]
  CLI -- "var command" --> Parse["parse_cpu_list expands ranges"]
  Yaml["suriconf.yaml"] -- "string ranges" --> Find["find_max_cpu_usage_vec expands ranges"]

Loading

File Walkthrough

	Relevant files
Enhancement	5 files yaml.rs Add CPU range parsing and expansion helpers                            +51/-10  argument.rs Add Init command and change CPU vec to strings                      +14/-2    main.rs Handle Init command in main entrypoint                                      +10/-1    config_gen.rs New module generating default configuration file                  +16/-0    lib.rs Register config_gen module and DEFAULT_CONFIG constant      +4/-1
Documentation	1 files README.md Update version, Suricata commit, and init usage docs          +14/-8
Configuration changes	2 files suriconf.yaml Bump version and update default config values                        +4/-4      Cargo.toml Bump package version to 1.0.2-dev                                                +1/-1
Additional files	4 files ISSUES.md +0/-3      suricata.yaml +0/-2347 suricata.yaml.in +0/-2339 suriconf.yaml.in +0/-6

---

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Silent error swallowing In find_max_cpu_usage_vec, a string item that fails to expand (e.g., a quoted plain number like "3" in the YAML list, or any malformed range string like "abc") causes the ? operator to return None for the entire function. This makes an invalid value indistinguishable from a missing max_cpu_usage_vec key, and the caller then panics with the generic "Unable to parse max cpu usage vector." message. Quoted numeric entries are a realistic user input since the PR now advertises string values in this list, so a per-item error (or propagating the parse failure with a clearer message) would be more robust. Value::String(s) => { let expanded = expand_cpu_range(s)?; vec_cpus.extend(expanded);

[github-actions]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Return None instead of panicking on invalid values The function returns Option<Vec>, but unexpected or non-integer values (e.g. floats or booleans) trigger a panic! instead of a graceful None, and negative numbers panic via as_u64().expect(...). Use the ? operator and return None for invalid types to keep the error-handling contract consistent. src/yaml.rs [996-1008] for item in seq { match item { Value::Number(n) => { - vec_cpus.push(n.as_u64().expect("CPU index must be a non-negative integer.")); + vec_cpus.push(n.as_u64()?); } Value::String(s) => { let expanded = expand_cpu_range(s)?; vec_cpus.extend(expanded); } - other => { - panic!("Unexpected type in max cpu usage vector."); + _ => { + return None; } } } Suggestion importance[1-10]: 6 __ Why: The function signature returns Option<Vec<u64>>, but panic! and .expect(...) on invalid values (floats, booleans, negatives) break that contract and crash the program. Replacing them with ?/return None is a valid, consistent error-handling improvement matching the find_max_cpu_usage_vec contract.	Low
	Support single-number CPU strings in range expansion expand_cpu_range fails on a plain single-CPU string like "4" because split_once('-') returns None. This causes find_max_cpu_usage_vec to return None and the caller's .expect(...) to panic even though the input is valid. Handle single-number strings by returning them as a one-element vector. src/yaml.rs [1064-1074] fn expand_cpu_range(s: &str) -> Option<Vec<u64>> { - let (start, end) = s.split_once('-')?; - let start: u64 = start.trim().parse().ok()?; - let end: u64 = end.trim().parse().ok()?; + let s = s.trim(); + if let Some((start, end)) = s.split_once('-') { + let start: u64 = start.trim().parse().ok()?; + let end: u64 = end.trim().parse().ok()?; - if start > end { - return None; + if start > end { + return None; + } + + Some((start..=end).collect()) + } else { + Some(vec![s.parse().ok()?]) } - - Some((start..=end).collect()) } Suggestion importance[1-10]: 5 __ Why: Correct edge case: a quoted single-number string like "4" in max_cpu_usage_vec would cause expand_cpu_range to return None and make the caller's .expect(...) panic. The fix is accurate, though the scenario is somewhat unlikely since plain YAML integers parse as Value::Number.	Low
General	Handle init errors gracefully with exit code Using panic! for an expected, user-facing failure (e.g. the output file already exists) prints an alarming panic message with a stack-trace-like header instead of a clean error. Report the error to stderr and exit with a non-zero status code so it can be detected in scripts. src/main.rs [26-31] if let Some(Commands::Init { output, force }) = &args.cmd { if let Err(e) = init(output, *force) { - panic!("{e}"); + eprintln!("Error: {e}"); + process::exit(1); } process::exit(0); } Suggestion importance[1-10]: 6 __ Why: Using panic! for an expected user-facing error (e.g. file already exists) prints a scary panic header instead of a clean message. Printing to stderr and exiting with code 1 is a correct and meaningful UX improvement for a CLI tool.	Low
	Create missing parent directories before writing If the user passes an output path in a directory that does not yet exist (e.g. --output conf/suriconf.yaml), fs::write fails with a confusing NotFound error. Create the parent directories (if any) before writing the default configuration file. src/config_gen.rs [7-16] pub fn init(output: &PathBuf, force: bool) -> io::Result<()> { if output.exists() && !force { return Err(io::Error::new( io::ErrorKind::AlreadyExists, format!("refusing to overwrite {:?} (use --force)", output), )); } + if let Some(parent) = output.parent() { + if !parent.as_os_str().is_empty() { + fs::create_dir_all(parent)?; + } + } fs::write(output, DEFAULT_CONFIG)?; Ok(()) } Suggestion importance[1-10]: 5 __ Why: Valid enhancement: fs::write to a path in a nonexistent directory fails with a confusing NotFound error, so creating parent directories first improves the init command's robustness. The improved code correctly preserves the existing behavior and handles the empty-parent edge case.	Low

• Author self-review: I have reviewed the PR code suggestions, and addressed the relevant ones.

[KEIAHNY]

Closing - applying the suggestions.