[tmpnet] Source tmpnet defaults from a configmap

[maru-ava]

Why this should be merged

Previously the scheduling label and value required to enable exclusive scheduling were defined as flag defaults. To enable the cluster to define these defaults, the defaults are now sourced from a configmap in the target namespace.

How this was tested

CI, manually

Need to be documented in RELEASES.md?

N/A

[Copilot]

Pull Request Overview

This PR centralizes tmpnet scheduling defaults in a Kubernetes ConfigMap rather than hardcoded flag defaults.

• Updated EnsureDefaultConfig to accept a context.Context and delegate to Kube-specific defaulting
• Added KubeRuntimeConfig.ensureDefaults to fetch scheduling labels from a tmpnet ConfigMap
• Removed static flag defaults and manual validation for scheduling labels

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
tests/fixture/tmpnet/network_test.go	Updated test to pass ctx into EnsureDefaultConfig
tests/fixture/tmpnet/network.go	Changed EnsureDefaultConfig signature and call sites to include ctx
tests/fixture/tmpnet/kube_runtime.go	Added ensureDefaults method to source scheduling defaults from ConfigMap
tests/fixture/tmpnet/flags/kube_runtime.go	Removed hardcoded flag defaults and validation for scheduling labels

Comments suppressed due to low confidence (4)

tests/fixture/tmpnet/kube_runtime.go:58

• [nitpick] This error message references flag names, but it can also be triggered by missing keys in the ConfigMap. Consider clarifying that missing config-map entries will produce this error.

var errMissingSchedulingLabels = errors.New("--kube-scheduling-label-key and --kube-scheduling-label-value are required when exclusive scheduling is enabled")

tests/fixture/tmpnet/flags/kube_runtime.go:79

• [nitpick] Since defaults now come from a ConfigMap, update the flag usage text to mention that no in-code default is set and that users should configure the tmpnet ConfigMap.

		"",

tests/fixture/tmpnet/kube_runtime.go:82

• Add unit tests for ensureDefaults to verify behavior when the ConfigMap contains valid defaults and when keys are missing.

func (c *KubeRuntimeConfig) ensureDefaults(ctx context.Context, log logging.Logger) error {

tests/fixture/tmpnet/network_test.go:29

• It looks like ctx isn’t defined in this test. Consider adding ctx := context.Background() and importing the context package at the top of the file.

	require.NoError(network.EnsureDefaultConfig(ctx, logging.NoLog{}))

[RodrigoVillar]

Is there a benefit to mix-and-matching between flag values and ConfigMap values here? I would think that the KubeRuntimeConfig would go with exclusively with flag values or exclusively with ConfigMap values.

[maru-ava]

Configmap values are defaults and only used when a flag has an empty value (as per the logging communicating their usage). The intention is to ensure that a cluster can provide appropriate defaults rather than to prevent a user from supplying values via flags.