feat(ingress): add HTTPRoute support for Grafana instances

[lexfrei]

Summary

Adds full support for Kubernetes Gateway API HTTPRoute resources to Grafana instances, enabling modern ingress capabilities alongside traditional Ingress and OpenShift Route objects.

Changes

API Changes

• Add HTTPRoute *HTTPRouteGatewayV1 field to GrafanaSpec
• Add PreferHTTPRoute *bool field to GrafanaClient for routing preference
• Implement HTTPRouteGatewayV1 type with Strategic Merge support

Controller Changes

• Parallel creation of Ingress and HTTPRoute when both are specified
• Implement reconcileHTTPRoute() method with merge logic
• Add getHTTPRouteSpec() helper for default HTTPRoute configuration
• Add getHTTPRouteAdminURL() for AdminURL extraction from HTTPRoute
• Add RBAC rules for gateway.networking.k8s.io/httproutes

Testing

• Add unit tests for HTTPRoute creation
• Add test for parallel Ingress + HTTPRoute creation
• Include Gateway API v1.3.0 CRDs in test environment
• Tests pass successfully

Examples

Added 4 comprehensive examples:

• httproute_basic/ - Basic HTTPRoute with Gateway parentRef
• httproute_tls/ - HTTPRoute with TLS via Gateway sectionName
• httproute_weighted/ - Weighted routing for A/B testing (90/10 split)
• httproute_filters/ - Request/response header modification

Gateway API Version Note ⚠️

This PR uses Gateway API v1.3.0 instead of v1.4.0.

Reason: Gateway API v1.4.0 contains invalid kubebuilder validation markers (+kubebuilder:validation:MaxLength applied to arrays instead of strings) that cause controller-gen to fail during manifest generation.

Status: The issue is fixed in Gateway API main branch (PR #4178), but v1.4.1 patch release has not been published yet.

Upstream Issue: kubernetes-sigs/gateway-api#4172

Recommendation: Do not upgrade to Gateway API v1.4.0 until v1.4.1 is released or the validation marker issue is confirmed resolved.

Test Plan

make test              # All unit tests pass
make golangci-lint     # 0 issues
make manifests         # Successfully generates CRDs

Breaking Changes

None. This is a purely additive feature.

Related Issues

Addresses the need for Gateway API support in grafana-operator.

[CLAassistant]

All committers have signed the CLA.

[weisdd]

Thanks for the PR. I've added a few questions / comments.

As a side note, I'd say 30.4K of changes in a single commit is too much. Independent changes and any code generation should better be spread across multiple commits, especially due to the fact that you tried not only to implement new feature, but also to change the behaviour of things that have existed for years (more details in my review comments).

Also, please, note that there's another PR covering the same functionality #2273, which was opened a few days earlier. I think we haven't had conflicting PRs before, let's see which implementation will be better.

[weisdd]

crd folder is not intended to contain third-party CRDs, it should only contain resources generated by kubebuilder. Files required only for tests should be hosted elsewhere.

Also, not sure why you added the same HTTPRoute CRD twice (httproutes.yaml + standard-install.yaml)

[lexfrei]

Moved Gateway API CRDs to tests/fixtures/gateway-api/ as recommended.

Question for maintainers: Should we rely on Gateway API being pre-installed in test environment instead? Similar to approach in PR #2273.

[weisdd]

It's up for a discussion amongst maintainers, but I feel like it's not worth implementing as it would require too much complexity and wider cluster permissions for properly detecting protocol (HTTP/HTTPS).

[lexfrei]

Understood. Keeping PreferHTTPRoute for now but ready to remove if maintainers decide it's too complex.

The implementation does Gateway lookup to properly detect protocol, but we can simplify to basic hostname-only approach if preferred.

[weisdd]

I would prefer not to mix adding support for HTTPRoutes and changes in reconciliation behaviour under a single PR. - So far, we've required users to pick a single option, and I'm yet to see a convincing explanation why we should change that.

[lexfrei]

This addresses the migration use case: teams want to test HTTPRoute alongside stable Ingress without downtime.

Use case:

• Production: Ingress (proven, stable)
• Add HTTPRoute in parallel for validation
• Switch via preferHTTPRoute when ready
• Remove Ingress after full validation

No breaking changes - if only one specified, only one created. Can split into separate PR if preferred.

[weisdd]

Well, it would be breaking for someone who, for some reasons, has both Routes and Ingresses defined in their manifests. Any change in existing behaviour in a project with such a large user base as ours needs to be carefully considered and properly articulated in release descriptions.

In my view, in this particular PR, it's better to keep only implementation for HTTPRoutes, so we could reason here only about the feature. The best approach would be to preserve the existing precedence for Routes.

As for the behaviour change, please, open a new issue describing in details your reasoning, and you'll then get some feedback in the coming weeks (most of the time, issues are discussed at a weekly cadence). Once consensus is reached, a related PR would be welcomed.

[lexfrei]

Pardon, missed the breaking change. Kept the Route > Ingress logic, moved HTTPRoute to parallel. Nothing breaks now. Is this OK?

[weisdd]

Let's not have any parallel execution until it is discussed in a separate issue. And even then, any change in behaviour needs to be handled separately.

[lexfrei]

Got it. Changed to Route > Ingress > HTTPRoute precedence (mutually exclusive). No parallel execution.

[lexfrei]

@weisdd Thank you for the thorough review! I've addressed all the feedback and restructured the PR into 10 granular commits.

Changes Made

✅ go.mod: Reverted unrelated dependency changes (only gateway-api v1.3.0)
✅ Gateway API CRDs: Moved to tests/fixtures/gateway-api/
✅ suite_test.go: Fixed error handling for Gateway API scheme installation
✅ examples: Removed credentials, simplified filters example, deleted weighted example, updated version to v1.3.0
✅ Refactoring: Split HTTPRoute logic into separate httproute_reconciler.go file
✅ AdminURL: Improved implementation with proper Gateway lookup and listener matching
✅ Commit structure: Split into 10 logical commits (deps → api → model → rbac → controllers → tests → docs → generated)

Implementation Details

Gateway API v1.3.0: Using v1.3.0 instead of v1.4.0 due to invalid kubebuilder validation markers in v1.4.0 that cause controller-gen failures. Issue tracked at: kubernetes-sigs/gateway-api#4172

HTTPRouteReconciler: Extracted into separate file with proper Gateway status inspection for protocol detection (HTTP/HTTPS via listener TLS configuration).

Parallel Ingress+HTTPRoute: Addressed migration use case - details in inline comments.

Ready for re-review.

[weisdd]

@lexfrei Please, reply in the respective threads, otherwise conversations would be hard to follow.

[weisdd]

If the functionality gets accepted, the function will need to be refactored and covered by tests. - The current complexity is too high.
Related functions need to also be covered by tests.

[lexfrei]

Removed PreferHTTPRoute and Gateway lookup complexity to simplify initial implementation. Created #2284 to discuss this functionality separately.

[weisdd]

README here was not updated to have title and readfile instructions, but let's remove it instead. - "Basic HTTPRoute Example" example is enough, the rest can easily be found in Gateway API docs.

[lexfrei]

Removed httproute_tls example. Only httproute_basic remains.

[weisdd]

Things that also need to be covered in the PR:

• the operator must be able to function when the Gateway API CRD(s) is not present;
• e2e-tests need to be extended to cover cases where the CRD IS NOT present and when it IS present;
• controller-runtime needs to be configured to cache the HTTPRoute objects (check this for reference).

[weisdd]

Could you explain why it's implemented this way? Routes are also optional, but we don't suppress their registration errors (line 104).

[weisdd]

Not sure if that would work. Have you tried to run this code? (I see that all commits are signed by Claude, so not sure if any of this goes through human validation) - E.g. we've seen with Routes that caching configuration (mgrOptions.Cache.ByObject[&routev1.Route{}] = cacheLabelConfig) leads to panic when not hidden behind the isOpenShift check. - If you want to check whether HTTPRoutes are present, I think you have to implement something similar to what we did for OpenShift. It would also make sense to add a log message stating whether the CRD was successfully discovered.