-
Notifications
You must be signed in to change notification settings - Fork 473
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
conformance: Gateway Infrastructure Metadata #2845
Conversation
/assign @howardjohn |
Description: "A Gateway should accept infrastructure metadata", | ||
Features: []suite.SupportedFeature{ | ||
suite.SupportGateway, | ||
suite.SupportGatewayInfrastructureMetadata, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
/assign @arkodg @mlavacca @sunjayBhatia # approvers |
apologies - unsure why prow didn't assign - trying again without the /assign @arkodg @mlavacca @sunjayBhatia |
Conformance reviewers/approvers - can I get review please @arkodg @mlavacca @sunjayBhatia @michaelbeaumont @LiorLieberman @Xunzhuo |
Namespace: "gateway-conformance-infra", | ||
} | ||
|
||
conditions := []metav1.Condition{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so the real use case is to surface the feature in the GatewayClass
:) ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe PR'ing the feature string makes sense and then we enable report generation to include additional features that don't have tests?
Include a conformance test and create a feature for this experimental functionality
db71c1a
to
386f2bf
Compare
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: dprotaso, howardjohn The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+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.
Sounds good everyone |
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?: