conformance: Gateway Infrastructure Metadata

[dprotaso]

What type of PR is this?

/kind test
/area conformance

What this PR does / why we need it:
Include a conformance test and create a feature for this experimental functionality

Which issue(s) this PR fixes:
N/A

Does this PR introduce a user-facing change?:

NONE

[dprotaso]

/assign @howardjohn

[robscott]

I don't really know how you do more than this, but it seems like this isn't really testing much. If an implementation takes no action, they'll support this. The only thing that would fail this test is if an implementation went out of their way to mark this config as rejected?

[dprotaso]

If an implementation takes no action, they'll support this. The only thing that would fail this test is if an implementation went out of their way to mark this config as rejected?

Or there's some other machinery that rejects the creation of this Gateway.

The second aspect is there is no way currently for a GatewayClass to signal that they support this feature.

[dprotaso]

/assign @arkodg @mlavacca @sunjayBhatia # approvers
/cc @LiorLieberman @michaelbeaumont @Xunzhuo # reviewers

[dprotaso]

apologies - unsure why prow didn't assign - trying again without the # comment

/assign @arkodg @mlavacca @sunjayBhatia
/cc @LiorLieberman @michaelbeaumont

[dprotaso]

Conformance reviewers/approvers - can I get review please @arkodg @mlavacca @sunjayBhatia @michaelbeaumont @LiorLieberman @Xunzhuo

[arkodg]

imo I dont know this test is very useful, we ideally need a way to retrieve the metatdata from the data plane but since its unique, we are add a conformance test for it

[dprotaso]

way to retrieve the metatdata from the data plane

That's implementation specific.

The test really just asserts that we're able to set this property on the infrastructure stanza and it's accepted by the implementation - nothing else.

Also I think it's important to have a Feature enum so end users know they can use this feature and it's surfaced on the GatewayClass

[arkodg]

so the real use case is to surface the feature in the GatewayClass :) ?

[dprotaso]

It's part of it.

Like as an end-user I want to know if a class supports this feature. Likewise if an implementation advertises that then I expect I can set these attributes and the gateway is accepted and programmed. (which this test is doing)

[robscott]

I'm not sure about this one, it's not necessarily wrong, just also not clear that it provides much value. Just being able to set a value doesn't really mean it's not supported, it may just mean the Gateway implementation hasn't gone out of it's way to block this from being set. I know we don't really have strong guidelines for what does or doesn't fit as a conformance test, but this feels like it's on the edge, and I'd lean to say that it doesn't really provide sufficient value.

It seems conceptually similar to confirming that an implementation supports setting TLS options to some arbitrary value, I'm not sure how useful a test like this is without also confirming the desired result.

[dprotaso]

I'm fine with dropping this conformance tests - I guess I'm trying to answer the question

How do I know which implementations support setting this property and won't fail.

Is the conformance report a good place for that?

[dprotaso]

Maybe PR'ing the feature string makes sense and then we enable report generation to include additional features that don't have tests?

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: dprotaso, howardjohn
Once this PR has been reviewed and has the lgtm label, please assign youngnick for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[mlavacca]

+1 on the doubts already posed by @robscott and @arkodg. I do not see this test very useful, and also I think we should not include it just for the sake of having the feature listed in the GatewayClass status, which is a matter of a completely different GEP and feature, still experimental. On the other hand, I do not see a way to improve the test to increase its meaningfulness, as the feature relies very much on the implementation details.

[dprotaso]

Sounds good everyone