-
Notifications
You must be signed in to change notification settings - Fork 74
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
AIP-157 Partial response implementation #717
base: main
Are you sure you want to change the base?
Conversation
Skipping CI for Draft Pull Request. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: 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 |
f603652
to
50dd2b9
Compare
32027d4
to
08b524b
Compare
/test all |
The following is the coverage report on the affected files.
|
08b524b
to
4ea8c19
Compare
/test all |
The following is the coverage report on the affected files.
|
/test pull-tekton-results-integration-tests |
1 similar comment
/test pull-tekton-results-integration-tests |
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.
finally got around to taking a pass at this @sayan-biswas
of course, being brand new / a novice to all this, consider that perspective when reviewing my feedback ;-)
internal/fieldmask/fieldmask.go
Outdated
mask := make(FieldMask) | ||
for _, path := range paths { | ||
current := mask | ||
fields := strings.Split(path, ".") |
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.
put a comment above this split with some sample paths to illustrate why we are splitting on .
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.
let's not make the coder have to do up to your README change to undersatand what is going on
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.
Added reference and an example in godoc format.
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.
awesome thanks
reflect.Set(fd, protoreflect.ValueOfBytes(b)) | ||
} | ||
} | ||
} |
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.
feels like we should have a default case to at least log unexpected messages, no?
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 would say no, because this is simply filtering. Any unknown cases will just be ignored.
And for logging, there's are some restrictions here. We cannot throw error
because then the client will receive the error. We cannot bring logger from the context, then the implementation will have dependency and can't be used as a library.
Although we can still log with normal golang's fmt
or logger
library, but that will break structured logging.
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.
valid reasoning
I still wonder about being able to debug in the future "why did my filter not catch 'X'"
could we emit events for the errors in this switch?
could we emit events for the default case? Or are there too many types besides MessageKind and BytesKind?
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.
Emit the events where? You mean kubernetes events?
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.
yes k8s events .... api server has a k8s client so in theory could emit events to help with debug, and you don't have the logging pain you noted earlier
cmd/api/main.go
Outdated
@@ -169,6 +171,7 @@ func main() { | |||
grpc_zap.UnaryServerInterceptor(grpcLogger, zapOpts...), | |||
grpc_auth.UnaryServerInterceptor(determineAuth), | |||
prometheus.UnaryServerInterceptor, | |||
fieldmask.UnaryServerInterceptor(), |
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.
shouldn't we have a feature enablement check of some sort ? presumably a client could send the extra headers or encoded data and it is OK to ignore ?
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 have added a feature flag implementation to handle all features control.
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.
feature gate looks good @sayan-biswas good think .... in looking at it though I raised some questions around changes you made to my recently added tuning options
I'll submit a separate review for those
The following is the coverage report on the affected files.
|
0acbbac
to
840e4cc
Compare
The following is the coverage report on the affected files.
|
This feature add capabilities to filter the response message from all the APIs. AIP detail: https://google.aip.dev/157
840e4cc
to
6b8e353
Compare
The following is the coverage report on the affected files.
|
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.
just a doc bit I think @sayan-biswas
@@ -6,13 +6,7 @@ DB_NAME=tekton-results | |||
DB_SSLMODE=disable | |||
DB_SSLROOTCERT= | |||
DB_ENABLE_AUTO_MIGRATION=true | |||
DB_MAX_IDLE_CONNECTIONS=10 |
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 assuming you did this @sayan-biswas because I didn't need to set these defaults when I added the tuning options ? If so, thanks for the correction.
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.
Or was this accidental? ...If it was, in hindsight, I does probably make sense to not set these, even to the defaults. (though 10 does not line up with the default as described in the doc.
Users can always add these to their config map.
| DB_ENABLE_AUTO_MIGRATION | Auto-migrate the database on startup (create/update schemas). For further details, refer to <https://gorm.io/docs/migration.html> | true (default) | | ||
| PROFILING | Enable profiling server | false (default) | | ||
| PROFILING_PORT | Profiling Server Port | 6060 (default) | | ||
| DB_MAX_IDLE_CONNECTIONS | The number of idle database connections to keep open | 2 (default for golang, but specific database drivers may have settings for this too) | |
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.
You deleted all my tuning options here in the README @sayan-biswas .... we need to minially document them, even if they are not specified in the config/base/env/config file
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.
Ohh.. Not sure why how this was missed. I'll rebase again to include the changes.
cmd/api/main.go
Outdated
@@ -169,6 +171,7 @@ func main() { | |||
grpc_zap.UnaryServerInterceptor(grpcLogger, zapOpts...), | |||
grpc_auth.UnaryServerInterceptor(determineAuth), | |||
prometheus.UnaryServerInterceptor, | |||
fieldmask.UnaryServerInterceptor(), |
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.
feature gate looks good @sayan-biswas good think .... in looking at it though I raised some questions around changes you made to my recently added tuning options
I'll submit a separate review for those
I don't seem to have permission to resolve comment threads @sayan-biswas Feel free to resolve all of mine except #717 (review) and the one about submitting k8s events (at least until you respond to my clarification there). |
bump @sayan-biswas on my last round of comments - #717 (review) |
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.
@sayan-biswas Can you rebase it again without removing Gabe's performance tuning changes?
@sayan-biswas: PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Sorry! I was caught up with other activities. I will rebase soon. |
In the present implementation, a user cannot filter the data in the response message, a feature provided by modern API implementations. This is particularly needed for the
List
APIs as these APIs return the whole object in the list. In scenario where the list and object definition are big, there's a lot network bandwidth wasted because the response of theList
API is mostly used to display a list of resources and theGet
API is then used to fetch the individual resource.This feature provides an easy and basic way to filter the response message across all APIs, which reduces the size of the payload and hence allows faster transfer over network.
Changes
This feature add capabilities to filter the response message from across all APIs.
AIP detail:
https://google.aip.dev/157
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you review them:
/kind <type>
. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tepRelease Notes