Scaffold EVPN Fabric Resource and Controller

[felix-kaestner]

This high-level CRD will take care of creating and managing all low-level resources that are required to build a EVPN VXLAN resource.

Its controller implementation is intentionally left empty to a large extend to be extended by future changes. The setup constructs a list of sub-reconciler functions that are called in sequence to build up the full lifecycle of the Fabric.

[nikatza]

Looks good to me :) The API is self-contained and explanatory, conventions also (the Unnumbered bool had let me thinking for a bit), the reconciler logic is also fitting for the purpose of this PR.

Before we merge I would like to sync on this issue: I am wondering if we would want to have a more modular and extendable design for the fabric type. For example, by default we could have a "plain routed" fabric with just deviceSelector, loopbacks, and underlay. Then, we could extend it with references to a specialized type, similar to what we do with the core types. Like this we could have support different fabrics, ike the current EVPN-VXLAN, EVPN MPLS, etc. Some of these fabrics would be reusing some types.

Obviously the evpn self-contained group is quite appealing too and eventually also the straight-forward way to go.

Thanks for opening this PR, looking forward 🚀

[nikatza]

I quite like this API definition, it is straightforward and self-explanatory. I think thought, that there are some assumptions being made and that are not clear/documented: e.g., one device and all sub-resources belong to just one fabric. Either if this holds of not, I think we would benefit from either adding a concept, or extending its documentation.

[felix-kaestner]

Added a godoc comment on DeviceSelector explicitly stating that a device must not match more than one Fabric, and that overlapping selectors lead to undefined behaviour.

[nikatza]

We currently wouldn't prevent a user defining two fabrics, with label selectors that intersect on some devices. This would result in a competition for the sub-resources and would potentially lead to an outage. At the same time, I understand that if we support two fabrics, some devices might actually need to be in both. I think the question in that case is, how do we ensure that a single brick is indirectly managed by just one fabric? should we also label the sub resources?

[felix-kaestner]

The controller now labels all sub-resources with evpn.networking.metal.ironcore.dev/fabric: <name> for discoverability (kubectl get interfaces -l evpn.networking.metal.ironcore.dev/fabric=my-fabric). Correctness is still handled via ownerReferences.

[github-actions]

This PR is stale because it has been open for 45 days with no activity.

[github-actions]

Merging this branch will not change overall coverage

Impacted Packages	Coverage Δ	🤖
github.com/ironcore-dev/network-operator/api/evpn/v1alpha1	0.00% (ø)
github.com/ironcore-dev/network-operator/cmd	0.00% (ø)
github.com/ironcore-dev/network-operator/internal/controller/evpn	0.00% (ø)

---

Coverage by file

Changed files (no unit tests)

Changed File	Coverage Δ	Total	Covered	Missed	🤖
github.com/ironcore-dev/network-operator/api/evpn/v1alpha1/doc.go	0.00% (ø)	0	0	0
github.com/ironcore-dev/network-operator/api/evpn/v1alpha1/fabric_types.go	0.00% (ø)	0	0	0
github.com/ironcore-dev/network-operator/api/evpn/v1alpha1/groupversion_info.go	0.00% (ø)	0	0	0
github.com/ironcore-dev/network-operator/api/evpn/v1alpha1/zz_generated.deepcopy.go	0.00% (ø)	0	0	0
github.com/ironcore-dev/network-operator/cmd/main.go	0.00% (ø)	0	0	0
github.com/ironcore-dev/network-operator/internal/controller/evpn/fabric_controller.go	0.00% (ø)	62 (+62)	0	62 (+62)

Please note that the "Total", "Covered", and "Missed" counts above refer to code statements instead of lines of code. The value in brackets refers to the test coverage of that file in the old version of the code.

Changed unit test files

• github.com/ironcore-dev/network-operator/internal/controller/evpn/fabric_controller_test.go
• github.com/ironcore-dev/network-operator/internal/controller/evpn/suite_test.go