feat: add a 'no-dataplane' option which allows for valid products to be installed with 'linuxDataplane: None' by doucol · Pull Request #4954 · tigera/operator

doucol · 2026-06-22T23:30:38Z

Description

A suggestion from Arvind for the hackathon: add support to the operator for installing our 2 cni/dataplane agnostic products (Calico Ingress Gateway and Istio Service mesh) without our CNI nor our dataplane enabled.

This results in cni.type = nil and linuxDataplane: None

"None" is a new enum value for our linuxDataplane.

Release Note

A new value 'None' is supported for the linuxDataplane which allows our Ingress Gateway and Istio Service Mesh to be installed without our dataplane components.

For PR author

Tests for change.
If changing pkg/apis/, run make gen-files
If changing versions, run make gen-versions

For PR reviewers

A note for code reviewers - all pull requests must have the following:

Milestone set according to targeted release.
Appropriate labels:
- kind/bug if this is a bugfix.
- kind/enhancement if this is a a new feature.
- enterprise if this PR applies to Calico Enterprise only.

BSD tar stops option parsing at the first non-option argument, so the trailing -O in the helm download recipe was treated as a file pattern rather than --to-stdout. On macOS this extracted a stray hack/bin/helm, wrote a 0-byte helm-<arch>-<version> via the shell redirection, and failed -- and since the empty file was left behind, subsequent runs died with "Permission denied". GNU tar permutes arguments, which is why this only broke on macOS. Move -O before the member name (portable to both tars) and drop the no-op -C/--strip-components flags. Also add .DELETE_ON_ERROR so a failed recipe can't leave a partial target that poisons later builds. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…g bugs

…clude headless

…ter issue in kind

…h no dataplane

…ll valid products

this address a couple of issues codex uncovered: 1. P1: Overlay-driven dataplane mode causes an infinite restart loop. Startup detection reads only the raw default Installation in cmd/main.go:520, but reconcile later applies the overlay Installation in pkg/controller/installation/core_controller.go:960 before comparing against r.dataplaneDisabled and calling osExitOverride(0) in pkg/controller/installation/core_controller.go:1057. If linuxDataplane: None is supplied via overlay, the pod starts with DataplaneDisabled=false, reconcile computes true, exits, and the next pod repeats the same startup read. The inverse case also loops. Startup detection needs to use the same effective spec calculation as GetInstallationSpec/reconcile. 2. P2: The new no-dataplane FV setup does not run in the intended controller mode. setupManager registers controllers before the no-dataplane Installation exists and never sets ControllerOptions.DataplaneDisabled in test/mainline_test.go:339. The no-dataplane specs create the Installation afterward, e.g. test/no_dataplane_test.go:212, so the first reconcile sees a mode mismatch and calls the real os.Exit(0) path from pkg/controller/ installation/core_controller.go:1057. That makes the new FV target either terminate the test binary or avoid exercising the corrected no-dataplane controller set. The FV helper should create the Installation before AddToManager, pass DataplaneDisabled: true, or override the exit path in-process.

electricjesus

looks pretty solid to me! just a few comments..

electricjesus · 2026-06-30T20:25:29Z

+	// fixed when the manager starts. If the dataplane mode has changed since the operator
+	// started, reboot so the correct controllers are (de)registered. This mirrors the enterprise
+	// switch below; controller-runtime cannot add or remove controllers from a running manager.
+	if instance.DeletionTimestamp.IsZero() && r.dataplaneDisabled != instance.Spec.DataplaneDisabled() {


This reboot might never fire on a None→Iptables switch. We boot with the dataplane off, so the IPPool controller isn't registered. Flip back to Iptables and needsIPPools goes true, but there are no pools and nothing running to create them, so I think we'd hit the "waiting for enabled IP pools" return above and bail before reaching this check. Looks like the operator would get stuck and couldn't restart itself out of it..

Could we move this block up to right after dataplaneDisabled :=, above the cni and pool gates? That direction isn't covered by the test either, so might be worth a case.

Also might be worth a return after osExitOverride(0). os.Exit kills us in prod so it doesn't bite there, but checkActive returns right after its exit for the test no-op case and this one just falls through.

electricjesus · 2026-06-30T20:25:29Z

+			// There is no Calico dataplane, so spec.cni (which describes the CNI the
+			// operator integrates Felix with) must be omitted entirely.
+			if instance.Spec.CNI != nil {
+				return fmt.Errorf("spec.cni must not be set when spec.calicoNetwork.linuxDataplane is %s",


I think this might reject a config the user never actually wrote when None comes in via the overlay. The base install defaults spec.cni and we persist it, then the overlay sets linuxDataplane: None. OverrideInstallationSpec doesn't seem to clear CNI when only the base has it set (no AOnlySet case in merge.go), so the merged spec would carry both cni and None and land here degraded. main.go says the mode can come from the overlay, so I think this path is supposed to work..?

electricjesus · 2026-06-30T20:25:29Z

-	components = append(components, kubecontrollers.NewCalicoKubeControllers(&kubeControllersCfg))
+	// Build a configuration for rendering calico/kube-controllers, which is not rendered
+	// when the dataplane is disabled.
+	var kubeControllersCfg kubecontrollers.KubeControllersConfiguration


Looks like kube-controllers gets gated out here, but the WAF webhook cert above (wafWebhookTLS) and the cert render don't. So I think a no-dataplane cluster that turns on WAF in a GatewayAPI CR would end up with an orphan tigera-waf-webhook secret and a webhook that never runs, with no status to say why.. Might be worth gating the cert the same way, or surfacing that WAF-on-gateway isn't supported without the dataplane.

electricjesus · 2026-06-30T20:25:29Z

+
+			// Reject any remaining dataplane-only field that is explicitly set, reporting them
+			// all at once so the user can fix the spec in a single pass.
+			var disallowed []string


nit, not blocking: this is a deny-list, so I think a new calicoNetwork field added later might slip through in None mode by default. Some of these (hostPorts and friends) look like the ones that'd nil-panic on spec.cni downstream, which is why the block exists. An allow-list would fail closed. Worth a comment at least so the next person adding a field knows to touch this.

electricjesus · 2026-06-30T20:25:29Z

 	// BPF dataplane requires IP autodetection even if we're not using Calico IPAM.
+	// With the Linux dataplane disabled there is no calico-node to perform autodetection,
+	// so skip defaulting these fields (validation rejects them when the dataplane is disabled).
 	needIPv4Autodetection := *instance.Spec.CalicoNetwork.LinuxDataplane == operatorv1.LinuxDataplaneBPF


tiny: you deref LinuxDataplane here, then zero it out right below for the disabled case. Could maybe fold it: needIPv4Autodetection := !instance.Spec.DataplaneDisabled() && *...LinuxDataplane == LinuxDataplaneBPF.

doucol requested review from a team and marvin-tigera as code owners June 22, 2026 23:30

marvin-tigera added this to the v1.44.0 milestone Jun 22, 2026

marvin-tigera added docs-pr-required release-note-required labels Jun 22, 2026

doucol force-pushed the headless branch from 1fd0ae1 to 42d2a62 Compare June 23, 2026 18:15

doucol and others added 23 commits June 23, 2026 15:28

headless mode - first pass

cfb783e

add noMatchError cond

5ad7a90

add ability to create kind cluster with headless products, fix testin…

82a7b18

…g bugs

handle non cluster host reconcile in headless mode

abadb4a

add guards for headless mode

b41796a

code review updates

9afb527

add usage tests for headless mode

cd3f903

fix tests in headless mode

2b9be06

use waitForDaemonSetReady to fix flaky test

7d3c779

rm cni.type: None, now cni.type can default to null, updated CI to in…

7a7929b

…clude headless

rm remaining references to cni.type: None

1154074

add additional testing for ingress gateway and istio mode; fix rp_fil…

a09cf17

…ter issue in kind

limit rp_filter setting to just darwin

0ecdaa8

update headless (new name tbd) to prevent registering controllers wit…

1d8ba52

…h no dataplane

add a couple more tests

01bbb4b

rm remaining refs to CNI "None"

a52463c

rename from 'headless' to 'no-dataplane'

a1a3ce1

reduce diffs in this PR to essentials

d2bd316

reduce diffs in this PR to essentials

a92f9dc

add a Makefile target that constructs a 'no-dataplane' cluster with a…

a555894

…ll valid products

fix lint errs

3397c82

fix unit tests

4cd1c87

doucol force-pushed the headless branch from 3cca2ee to 4cd1c87 Compare June 23, 2026 19:29

doucol requested a review from electricjesus June 24, 2026 18:02

electricjesus reviewed Jun 30, 2026

View reviewed changes

address PR review

dcda3b2

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

feat: add a 'no-dataplane' option which allows for valid products to be installed with 'linuxDataplane: None'#4954

feat: add a 'no-dataplane' option which allows for valid products to be installed with 'linuxDataplane: None'#4954
doucol wants to merge 25 commits into
tigera:masterfrom
doucol:headless

doucol commented Jun 22, 2026 •

edited

Loading

Uh oh!

electricjesus left a comment

Uh oh!

electricjesus Jun 30, 2026

Uh oh!

electricjesus Jun 30, 2026

Uh oh!

electricjesus Jun 30, 2026

Uh oh!

electricjesus Jun 30, 2026

Uh oh!

electricjesus Jun 30, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

doucol commented Jun 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Release Note

For PR author

For PR reviewers

Uh oh!

electricjesus left a comment

Choose a reason for hiding this comment

Uh oh!

electricjesus Jun 30, 2026

Choose a reason for hiding this comment

Uh oh!

electricjesus Jun 30, 2026

Choose a reason for hiding this comment

Uh oh!

electricjesus Jun 30, 2026

Choose a reason for hiding this comment

Uh oh!

electricjesus Jun 30, 2026

Choose a reason for hiding this comment

Uh oh!

electricjesus Jun 30, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

doucol commented Jun 22, 2026 •

edited

Loading