generated from kubernetes/kubernetes-template-project
-
Notifications
You must be signed in to change notification settings - Fork 582
[GEP-2162] Updated a new field on supported features inference from boolean to enum and remove from report. #3885
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
Merged
Merged
Changes from 13 commits
Commits
Show all changes
20 commits
Select commit
Hold shift + click to select a range
af67628
Update inferred supported features report from bool to enum to accoun…
bexxmodd 79ef1ab
Changed enum names.
bexxmodd 8cb2054
Added comment to report enum
bexxmodd dceb6f6
Revert change caused by merge.
bexxmodd 9166ef2
Converted enums from int to string for better readability.
bexxmodd ce0a071
Removed unused import.
bexxmodd 8906f69
Updated unit tests to reflect enum change to strings.
bexxmodd dc78f69
Removed skip tests from determining if supported features are inferre…
bexxmodd d0e0045
Removed source update.
bexxmodd 94e5b27
Updated unit tests.
bexxmodd ce227ae
Removed source enum from report.
bexxmodd 44e7a5c
start error string with lowercase.
bexxmodd 9da830a
Removed source getter.
bexxmodd 39b4bf1
removed undefined enum and added check for mesh features.
bexxmodd 968565b
return error if mesh features are populated in gwc.
bexxmodd abf9d40
Updated unit tests.
bexxmodd 28bddef
Removed check for mesh profile before throwing error for publishing m…
bexxmodd 84b269a
removed extra else
bexxmodd 0b7a15e
Removed not needed field from function.
bexxmodd 61bc37a
Cleanup of extra field
bexxmodd File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.
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 still not quite clear on if/why this case should be distinct from
supportedFeaturesSourceManual
now and ifsupportedFeaturesSourceUndefined
is needed at all?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 it's Mesh profile, and has no GWC, there's no way for conformance to tell if features were inferred or not. Most likely this will get updated though in a follow up PR where
isOnlyMeshProfile
will be implemented based on previous discussion.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 guess my point is if it's not possible to infer features for mesh currently (if we're avoiding advertising on GatewayClass), doesn't that just imply
supportedFeaturesSourceManual
?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.
There are two aspects:
Initial plan was to not limit (gw+mesh) implementations to not post it on GatewayClass. so undefined becomes better for mesh, since it was somehow "temporarily defined" in GWC. Ofc since we go with option 1 above, this argument is less relevant
We wanted clear separation between implementations that choose to do manual and those who just have no choice.
That said, we could go an re-use manual here, until we come up with a solution for mesh, but it would be less clear to communicate the distinction for users. e.g. Mesh implementations would report "manual" while they have no other way to achieve that - this can look less compelling for users who browse the conformance results as they dont have the context we have here
I am fine with either
Uh oh!
There was an error while loading. Please reload this page.
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 there potential future work to have Mesh way of reporting supported features like GWC does, #2 makes more sense. Undefined will serve as a place holder, clearly separating if reporter chose to manually test features or service is not available (yet) for Mesh in this case.
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.
To avoid confusion later, it seems like it may be simpler to ignore any Mesh features specified on a GatewayClass and always require Mesh features to be manually specified since we're already very likely going to end up with a Mesh resource thanks to @kflynn's work in #3894. That would also allow us to remove the concept of an undefined source here.
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.
Currently, there's no conceptual difference for the final report if source has undefined or inferred. It doesn't appear on report and doesn't block report. It's only for internal use. If we convert this back to bool, should we treat mesh features as "inferred:true" ? that will be a lie. If we treat it "inferred:false" that it will block reports. So the only option is to have enum. Undefined serves as bridge between what is rn and what is expected to be there soon. If the issue is naming, we can change it to something like
SourceIgnore
orSourceSkipped
because at the end that's what it's 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.
@robscott per our offline discussion, removed
Undefined
field from enum and added check to determine if Mesh features are published under GWC.