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

[KEIAHNY]

PR Type

Enhancement, Documentation

---

Description

• Add init command to generate default config file

• Support CPU range expansion in max_cpu_usage_vec

  • Parse ranges like 0-6 into individual CPUs
  • Validate CPUs against available system cores
  • Deduplicate CPUs via HashSet

• Bump version to 1.1.0-dev with num_cpus dependency

• Update README with Suricata branch and init usage

---

Diagram Walkthrough

flowchart LR
  init["Init command"] -- "generates" --> config["suriconf.yaml from DEFAULT_CONFIG"]
  cpurange["CPU range string e.g. 0-6"] -- "expand_cpu_range" --> cpulist["Validated CPU vector"]
  cpulist -- "num_cpus check" --> system["Available system CPUs"]

Loading

File Walkthrough

	Relevant files
Enhancement	5 files yaml.rs Add CPU range parsing, expansion, and validation                  +77/-14  argument.rs Add Init command and change CPU vec to strings                      +14/-2    main.rs Handle Init command before main workflow                                  +10/-1    config_gen.rs New module generating default configuration file                  +16/-0    lib.rs Register config_gen module and embed default config            +4/-1
Formatting	1 files suricata.rs Refactor io import for delete_pid_file signature                  +2/-1
Documentation	1 files README.md Update version, Suricata spec, and init docs                          +14/-8
Configuration changes	1 files suriconf.yaml Bump version and update default configuration values          +4/-4
Dependencies	1 files Cargo.toml Bump version to 1.1.0-dev, add num_cpus                                    +3/-2
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 Possible Issue find_max_cpu_usage_vec now validates CPU ids from the YAML config against the machine's current core count (num_cpus::get() via expand_cpu_range/insert_cpu). This makes a previously valid suriconf.yaml fail with a panic ("Unable to parse max cpu usage vector") when the config was authored on a machine with more cores than the one it runs on (e.g., the old default [0,1,2,3,4,5,6] on a 4-core host), or when core counts change due to CPU hotplug/cgroup limits. Config-file values were previously accepted without this check; if this validation is intended only for CLI input, apply it only in parse_cpu_list. Error Handling The init command failure is reported via panic!("{e}"), which prints a Rust panic backtrace/stack trace to the user instead of a clean error message. Since init returns io::Result, handling it with an eprintln + non-zero exit code (like the error handling used for open_yaml would ideally be) gives a much better CLI experience. Impact is cosmetic but user-visible for the new init subcommand.

[github-actions]

PR Code Suggestions ✨

No code suggestions found for the PR.