Support Multiple Providers in a Single Operator Deployment

[felix-kaestner]

Background

Currently, the network-operator is designed to run with a single provider per deployment, specified via the --provider flag at startup (cmd/main.go:90). The provider is selected globally for all controllers and applied uniformly to all network devices managed by that operator instance.

Available providers:

• openconfig (default) - Standards-based YANG models
• cisco-nxos-gnmi - Cisco NX-OS specific implementation

This architecture requires deploying separate operator instances when managing devices from different vendors or requiring different protocol implementations, which:

• Increases operational overhead (multiple deployments, RBAC configs, webhooks)
• Complicates multi-vendor network environments
• Limits flexibility in heterogeneous infrastructure

Proposed Enhancement

Enable the operator to support multiple providers simultaneously within a single deployment, allowing different devices to use different providers based on their vendor, capabilities, or configuration requirements.

[felix-kaestner]

Workaround: Multiple Deployments via Label Selector

While this issue targets single-deployment multi-provider support, there is already a mechanism in place that allows running multiple providers in the same cluster today — at the cost of multiple deployments.

Every controller respects a watch-filter label, defined as WatchLabel (networking.metal.ironcore.dev/watch-filter), and the operator binary exposes it via the --watch-filter flag (see cmd/main.go). Each controller's SetupWithManager (e.g. InterfaceReconciler, VRFReconciler, etc.) creates a label selector predicate from this value, so only objects carrying the matching label are ever reconciled by that instance.

This means two operator deployments can coexist in the same cluster today:

# Deployment A — OpenConfig provider
--provider=openconfig
--watch-filter=vendor=arista

# Deployment B — Cisco NX-OS provider
--provider=cisco-nxos-gnmi
--watch-filter=vendor=cisco-nxos

Any Device, Interface, VLAN, etc. resource that carries networking.metal.ironcore.dev/watch-filter: vendor=arista will only be reconciled by deployment A, and resources labelled vendor=cisco-nxos only by deployment B.

This workaround has two fundamental limitations that the issue is explicitly trying to remove:

1. Multiple deployments. Each provider still requires its own controller-manager Pod, its own Deployment, ServiceAccount, ClusterRoleBinding, webhook registration, and so on. In a large multi-vendor environment this operational overhead grows linearly with the number of providers.

2. Mandatory resource labeling. Every managed resource must carry the watch-filter label, or it will silently be ignored by all deployments. There is no default "catch-all" provider for unlabelled resources, and no way to have a single deployment dispatch to the right provider based on the device type without that label being explicitly set by the user.

The goal of this issue — a single deployment that inspects each Device's configuration (e.g. a providerRef or a vendor field on the Device spec) and routes reconciliation to the appropriate provider — is therefore not achievable with the current label-selector approach and requires the architectural changes described here.