add Ports field in GatewayClient and enforce Port/Ports coherence

[MircoBarone]

Description

Part of the multi-tunnel WireGuard implementation. This is the 3rd PR related to issue #3225.

The Ports field was introduced in GatewayClientSpec. The idea is to store the list of endpoint ports that the gateway server has exposed for the WireGuard interfaces. Ports is not meant to replace the legacy Port field, which is kept for backward compatibility. The invariant is that Ports[0] must always be equal to Port.

To enforce this, a new function EnsurePortsCoherence was added to the ClientReconciler. At the beginning of each reconcile cycle, this function checks whether Port and Ports are consistent. If not, it normalizes them according to the following rules:

• If only Port is specified, Ports is set to []int32{Port}
• If Ports is specified, Port is overwritten with Ports[0]
• If neither is specified, both are set to the default value

After normalization, the resource is updated and the reconcile cycle is requeued.

[adamjensenbot]

Hi @MircoBarone. Thanks for your PR!

I am @adamjensenbot.
You can interact with me issuing a slash command in the first line of a comment.
Currently, I understand the following commands:

• /rebase: Rebase this PR onto the master branch (You can add the option test=true to launch the tests
  when the rebase operation is completed)
• /merge: Merge this PR into the master branch
• /build Build Liqo components
• /test Launch the E2E and Unit tests
• /hold, /unhold Add/remove the hold label to prevent merging with /merge

Make sure this PR appears in the liqo changelog, adding one of the following labels:

• feat: 🚀 New Feature
• fix: 🐛 Bug Fix
• refactor: 🧹 Code Refactoring
• docs: 📝 Documentation
• style: 💄 Code Style
• perf: 🐎 Performance Improvement
• test: ✅ Tests
• chore: 🚚 Dependencies Management
• build: 📦 Builds Management
• ci: 👷 CI/CD
• revert: ⏪ Reverts Previous Changes

[MircoBarone]

I have removed the coherence check (Ports[0] == Port) for GatewayClient from client_controller.go. The controller is not the appropriate place to handle validation or mutation of this resource.

The logic is now handled via CEL validation: if both Port and Ports are provided, Ports[0] must match Port, otherwise the resource is rejected. It remains possible to create a GatewayClient specifying only Port, only Ports, or neither. No mutation is performed on the resource.

Potential Issues

Ports is intended to replace Port. It populates the --endpoint-ports flag of the wireguard container, while Port populates the --endpoint-port flag.

• If a user uses a template that only supports --endpoint-port but provides the port via the Ports field, the configuration will not work.
• Conversely, if only Port is specified but the template only uses --endpoint-ports, it will fail because the value is not automatically copied to the new flag.

I believe these issues can be solved by using a more robust template, for example:

- --endpoint-port={{ if .Spec.Endpoint.Port }}{{ .Spec.Endpoint.Port }}{{ else if .Spec.Endpoint.Ports }}{{ index .Spec.Endpoint.Ports 0 }}{{ end }}
- --endpoint-ports={{ if .Spec.Endpoint.Ports }}{{ range $i, $p := .Spec.Endpoint.Ports }}{{ if $i }},{{ end }}{{ $p }}{{ end }}{{ else }}{{ .Spec.Endpoint.Port }}{{ end }}

I am moving this PR out of draft. Let me know if you think a Mutating Webhook is strictly necessary or if this CEL-based approach is sufficient. In my opinion, this approach can also serve as a base if we want to introduce mutation in the future