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.
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
Add label filtering (-l) for describe commands #2934
Add label filtering (-l) for describe commands #2934
Changes from 1 commit
7857cfb
3c7b3e5
bc3262e
f69b125
c7c406d
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 believe this entire section can be taken outside the
switch
(say at Line 90) to reduce this code's repeatability across all thecase
-esThere 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 placed on line 90, gwctl will first check the label and then the resources. I think the label logic in
gwctl
should align withkubectl
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 get your point though I'm not sure if that's worthwhile.
As a user, I don't care (I never even noticed haha) the order of this validation (resource_type -> label OR label -> resource_type)
As a developer, I "personally" wouldn't find this reason strong enough to have this level of code repeatability across so many cases.
Moreover, this would add up to the cognitive load of copy-ing the same code again in case in the future a new set of resource types are introduced under gwctl.
Rest, this is just my personal pov.
I'd leave this to yours and @gauravkghildiyal 's judgement :)
Cheers!
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.
Yep we do have code-duplication in a couple of places at present that needs to be improved. (Sorry I may be responsible for many of those) @yeedove thanks for an eye towards such subtle details, that's really nice!
Is it not feasible to have a function like
parseLabelSelectorOrExit()
and still keep the error evaluation order as a middle ground? If that's not possible, I feel like it's fair game if we do get rid of the code duplication here as that may not affect the user experience drastically. (Thanks @yashvardhan-kukreja!)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.
Thanks for the change Dennis!
Yes you are right that the label selection (for the time being) is only for the immediate resource being fetched (like
gwctl describe httproutes -l mylabel=myhttproute
is only supposed to filter the HTTPRoutes, and not extend the filtering to resources associated with the HTTPRoute, like Gateways and Backends)From your present commit, the function under test for the tests happens to be
DiscoverResourcesForGatewayClass()
(and equivalent). Given this, can we please move them to thediscoverer_test.go
file within theresourcediscovery
package?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.
Same as https://github.com/kubernetes-sigs/gateway-api/pull/2934/files#r1550940269
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.
Same as https://github.com/kubernetes-sigs/gateway-api/pull/2934/files#r1550940269
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.
Thanks for the thorough tests @yeedove!
I was actually thinking about this part and I feel that maybe testing LabelSelector is something which is better handled through unit tests within
discoverer_test.go
which will test functions likefetchGatewayClass
(i.e.TestFetchGatewayClass
). Idea being, I really want unit tests to be focused on functionality provided by an independent package.The problem with LabelSelector tests right now is that they aren't just testing LabelSelector but are also testing how exactly the entire GatewayClass object gets printed (which is something that is already covered by the normal test functions like
TestGatewayClassesPrinter_PrintDescribeView
)(I know that tests like
TestGatewayClassesPrinter_PrintDescribeView
are also not close to perfect since they too are indirectly testing theresourcediscovery
package by relying onDiscoverResourcesForGatewayClass
instead of actually constructing the entire ResourceModel itself. This is something that I would like to correct in the future if possible)Within
discoverer_test.go
, these tests would only check that "given this label selector was provided, did I receive the correct GatewayClass names?"Additionally, we could then also get rid of the LabelSelector tests for the
gwctl get
.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.
get
anddescribe
commands before optimization to avoid potential issues. For instance, theget backend -l
command needs to displayREFERRED BY ROUTES
to these backends, but the relationship betweenHTTPRoutes
andServices
is not affected by labels, requiring additional handling. There may be better way :)
describe -l
, I found that the tests were overly dependent on the command’s output. As we plan toExpand output for gwctl describe resources
, updating tests for every change in output is not good idea. I will focus on correctly verifying GatewayClass names instead.