Category
Code quality / code smell
Description
internal/config/config.WorkloadConfig has an Enabled bool field tagged mapstructure:"enabled", and docs/configuration.md shows enabled: true on every workload in the YAML schema example. The field has no effect today.
The orchestrator in cmd/virtwork/main.go runE determines which workloads to deploy from the --workloads flag (defaulting to AllWorkloadNames()), and unconditionally sets wlCfg.Enabled = true when building each workload's config. Setting workloads.cpu.enabled: false in YAML does not skip cpu.
This is a quiet correctness gap: users who configure enabled: false will assume the workload is skipped and won't notice it ran.
Severity
Medium — increases maintenance burden or risk of future bugs
Affected Files
internal/config/config.go — WorkloadConfig.Enabled definitioncmd/virtwork/main.go — runE iteration that builds wlCfg per workload namedocs/configuration.md — YAML schema example currently advertises enabled as a meaningful key
Proposed Fix
Pick one:
Option A — honor it. In runE, after looking up cfg.Workloads[name], skip the workload if fileCfg.Enabled was explicitly set to false. Add an audit event noting the skip. Add tests covering both flag-driven and YAML-driven enable/disable.
Option B — remove it. Drop the field from WorkloadConfig and update docs/configuration.md to stop showing enabled in the YAML schema. The --workloads flag is then the single source of truth for which workloads run.
Option A is more user-friendly for declarative configs; Option B is the smaller change.
Area
CLI / Configuration
Architecture Layer
Layer 4 - Orchestration (cmd, cleanup)
Category
Code quality / code smell
Description
internal/config/config.WorkloadConfighas anEnabled boolfield taggedmapstructure:"enabled", anddocs/configuration.mdshowsenabled: trueon every workload in the YAML schema example. The field has no effect today.The orchestrator in
cmd/virtwork/main.go runEdetermines which workloads to deploy from the--workloadsflag (defaulting toAllWorkloadNames()), and unconditionally setswlCfg.Enabled = truewhen building each workload's config. Settingworkloads.cpu.enabled: falsein YAML does not skip cpu.This is a quiet correctness gap: users who configure
enabled: falsewill assume the workload is skipped and won't notice it ran.Severity
Medium — increases maintenance burden or risk of future bugs
Affected Files
internal/config/config.go—WorkloadConfig.Enableddefinitioncmd/virtwork/main.go—runEiteration that buildswlCfgper workload namedocs/configuration.md— YAML schema example currently advertisesenabledas a meaningful keyProposed Fix
Pick one:
Option A — honor it. In
runE, after looking upcfg.Workloads[name], skip the workload iffileCfg.Enabledwas explicitly set tofalse. Add an audit event noting the skip. Add tests covering both flag-driven and YAML-driven enable/disable.Option B — remove it. Drop the field from
WorkloadConfigand updatedocs/configuration.mdto stop showingenabledin the YAML schema. The--workloadsflag is then the single source of truth for which workloads run.Option A is more user-friendly for declarative configs; Option B is the smaller change.
Area
CLI / Configuration
Architecture Layer
Layer 4 - Orchestration (cmd, cleanup)