Support for MeshFrontendHostname cannot be indicated separately.

[LiorLieberman]

/area conformance

What happened:
Looking at mesh-frontend-hostname.go conformance test, it looks like every implementation that claims to support Mesh and also implements HTTPRouteResponseHeaderModification extended feature have to conform with this test.

However it does not look like it is the case. For example Istio, skips this test

Is this feature part of Core Mesh features or we should introduce new supportedFeature for it. Now there is not way to indicate if an implementation supports Mesh, HTTPRouteResponseHeaderModification but DOESNT support MeshFrontendHostname.

/assign @howardjohn
/cc @robscott

[robscott]

/cc @kflynn @keithmattix

[howardjohn]

I am a bit confused that we cannot report "not support MeshFrontendHostname"?

Is this not reported via

    skippedTests:
    - MeshFrontendHostname

[LiorLieberman]

Since there is no supportFeature for it, you cant really indicate it in GatewayClass Status (ref)

[robscott]

It seems like if an individual test is regularly skipped instead of just omitting a "SupportedFeature" we should add a feature for the functionality covered by that test so it can clearly be indicated by GatewayClass status. In this case, the conformance test is mesh-specific so it may not really make a meaningful difference since Meshes don't have a way to publish Supported Features via status yet. Even if it won't make a significant difference, I'd recommend just adding a supported feature for the sake of consistency with other tests.

[LiorLieberman]

Meshes don't have a way to publish Supported Features via status yet.

To clarify, we do publish "Mesh" in supportedFeatues in Gateway class if an implementation claims it supports AllFeatures (it comes from SupportMesh supportedFeature)

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[robscott]

This was actually fixed by #3035