fix: include all Linux network actions in k8s spec regardless of build platform

[xcaspar]

Summary

• Fix missing k8s pod-network commands (delay, loss, duplicate, corrupt, reorder, dnsdown) on darwin release builds
• Replace platform-dependent network.NewNetworkCommandSpec() with explicit construction of all Linux-compatible network actions
• Since k8s pods always run on Linux, the spec should always include all Linux network actions regardless of the build host OS

Root Cause

The k8s spec YAML is generated by compiling and running build/spec.go, which calls network.NewNetworkCommandSpec(). This function has platform-specific implementations:

• network_linux.go: Returns all 9 actions (delay, drop, dns, dnsdown, loss, duplicate, corrupt, reorder, occupy)
• network_darwin.go: Returns only 3 actions (drop, dns, occupy)

When the spec generator is built on macOS (via GOOS=$(CURRENT_OS) in the Makefile yaml target), Go's build tags select network_darwin.go, resulting in a k8s spec YAML missing tc-based commands.

Fix

Introduced newK8sNetworkCommandSpec() in exec/model/osexp.go that explicitly constructs the full network command spec with all Linux-compatible actions using platform-independent imports (network/tc package has no build tags).

Test Plan

• Build spec generator on macOS and verify generated YAML includes delay, loss, duplicate, corrupt, reorder actions
• Build spec generator on Linux and verify no regression
• Verify blade create k8s pod-network shows all expected subcommands

Fixes chaosblade-io/chaosblade#1275

Made with Cursor

[Copilot]

Pull request overview

Ensures the generated Kubernetes experiment spec always includes the full set of Linux network actions (tc-based actions like delay/loss/duplicate/corrupt/reorder) regardless of the host OS used to build the spec generator, avoiding macOS (darwin) build-tag filtering.

Changes:

• Added a k8s-oriented network command spec constructor that explicitly enumerates all Linux-compatible network actions.
• Replaced the platform-dependent network.NewNetworkCommandSpec() usage in the OS subresource model with the new explicit spec.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

This change is meant to guarantee that the generated k8s spec always includes the tc-based actions even when the spec generator is built on macOS. There’s currently no automated test covering the resulting action set; adding a small unit test (e.g., asserting NewOSSubResourceModelSpec() includes delay/loss/duplicate/corrupt/reorder/dnsdown) would prevent regressions and catch future dependency changes.

[Copilot]

The comment says “k8s pods always run on Linux”, but this helper is also used for node/container specs and the repo’s stated constraint is broader/clearer: build docs list the target platforms as Linux (amd64/arm64). Consider rewording the comment to reflect the project’s Linux-target assumption (per BUILD.md) rather than a universal Kubernetes property.

Suggested change

	// regardless of the build platform, since k8s pods always run on Linux.
	// based on the project's Linux (amd64/arm64) target platforms, independent
	// of the local build platform.

[Copilot]

newK8sNetworkCommandSpec is used by NewOSSubResourceModelSpec() (shared by node/pod/container), so the name is misleading (it’s not pod-only and not purely “k8s network” as a standalone spec). Consider renaming it to reflect that this is the operator’s Linux-targeted network spec used across k8s resources (e.g., newLinuxNetworkCommandSpecForK8sResources).

[Copilot]

This hard-codes the full list of network actions. That fixes the cross-build issue, but it also means future additions/removals in chaosblade-exec-os (e.g., new Linux network actions) won’t automatically show up in the k8s spec. To reduce drift risk, consider centralizing the action list (single source of truth) or adding an explicit assertion/test that enumerates the expected actions so updates fail loudly.

Suggested change

	// newK8sNetworkCommandSpec returns all Linux-compatible network actions
	// regardless of the build platform, since k8s pods always run on Linux.
	func newK8sNetworkCommandSpec() spec.ExpModelCommandSpec {
	return &network.NetworkCommandSpec{
	BaseExpModelCommandSpec: spec.BaseExpModelCommandSpec{
	ExpActions: []spec.ExpActionCommandSpec{
	tc.NewDelayActionSpec(),
	network.NewDropActionSpec(),
	network.NewDnsActionSpec(),
	network.NewDnsDownActionSpec(),
	tc.NewLossActionSpec(),
	tc.NewDuplicateActionSpec(),
	tc.NewCorruptActionSpec(),
	tc.NewReorderActionSpec(),
	network.NewOccupyActionSpec(),
	},
	ExpFlags: []spec.ExpFlagSpec{},
	// k8sNetworkActions defines the full set of network actions that are exposed
	// via the k8s OS subresource, independent of the current build platform.
	// This list is centralized here to reduce the risk of it silently drifting
	// from the underlying chaosblade-exec-os network actions.
	var k8sNetworkActions = []spec.ExpActionCommandSpec{
	tc.NewDelayActionSpec(),
	network.NewDropActionSpec(),
	network.NewDnsActionSpec(),
	network.NewDnsDownActionSpec(),
	tc.NewLossActionSpec(),
	tc.NewDuplicateActionSpec(),
	tc.NewCorruptActionSpec(),
	tc.NewReorderActionSpec(),
	network.NewOccupyActionSpec(),
	}
	// K8sNetworkActionSpecs returns a copy of the k8s network action specs.
	// It can be used by tests to assert that the k8s-exposed actions stay
	// in sync with the expected set of network actions.
	func K8sNetworkActionSpecs() []spec.ExpActionCommandSpec {
	out := make([]spec.ExpActionCommandSpec, len(k8sNetworkActions))
	copy(out, k8sNetworkActions)
	return out
	}
	// newK8sNetworkCommandSpec returns all Linux-compatible network actions
	// regardless of the build platform, since k8s pods always run on Linux.
	func newK8sNetworkCommandSpec() spec.ExpModelCommandSpec {
	return &network.NetworkCommandSpec{
	BaseExpModelCommandSpec: spec.BaseExpModelCommandSpec{
	ExpActions: k8sNetworkActions,
	ExpFlags: []spec.ExpFlagSpec{},