-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Remove tap from public API and associated test infrastructure #3240
Conversation
fe79ed8
to
99f8242
Compare
The diff size in this PR will go down significantly since it is rebased off of #3241 |
Integration test results for 99f8242: success 🎉 |
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.
lgtm. shipit pending merge of #3241 🚢 👍
### Summary Changes from `bin/protoc-go.sh` An existing [draft PR](#3240) has a majority of its changes related to protobuf file updates. In order to separate these changes out into more related components, this PR updates the generated protobuf files so that #3240 can be rebased off this and have a more manageable diff. Signed-off-by: Kevin Leimkuhler <kleimkuhler@icloud.com>
99f8242
to
9c8795d
Compare
Integration test results for 9c8795d: success 🎉 |
@@ -8,5 +8,5 @@ option go_package = "github.com/linkerd/linkerd2/controller/gen/controller/tap"; | |||
|
|||
service Tap { | |||
rpc Tap(public.TapRequest) returns (stream public.TapEvent) { option deprecated = true; } | |||
rpc TapByResource(public.TapByResourceRequest) returns (stream public.TapEvent) {} |
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.
Is this actually deprecated? Isn't this the interface that the tap pod serves? (albeit as proto-over-http instead of gRPC)
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.
As of this PR, it's true that the TapByResource
endpoint in Tap's gRPC server is still accepting requests. In a followup PR, the plan is to remove that gRPC server.
Current request flow:
CLI -> K8s API Server -> Tap API Server -> Tap gRPC Server -> Proxy
The plan:
CLI -> K8s API Server -> Tap API Server -> Proxy
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 this is splitting hairs but I would say this grpc service definition here defines the contract of the Tap API server. i.e. it takes a TapByResourceRequest as input (encoded as proto-over-http) and returns a stream of TapEvents (encoded as proto-over-http).
Even though none of the grpc bindings generated from this IDL are used, I still wouldn't call it deprecated because it describes the server's interface.
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 true that there still exists a server endpoint that takes a proto-over-http TapByResourceRequest
and returns TapEvent
's, but I don't think it accurately describes the server's interface, since it's not a gRPC server, and there is not going to be an endpoint called TapByResource
.
I agree about documenting our API contracts. In that case, we would document the HTTP interface for the TAP APIService. This could be a starting point:
linkerd2/controller/tap/handlers.go
Lines 72 to 104 in 4d01e37
func initRouter(h *handler) *httprouter.Router { | |
router := &httprouter.Router{} | |
router.GET("/", handleRoot) | |
router.GET("/apis", handleAPIs) | |
router.GET("/apis/"+gvk.Group, handleAPIGroup) | |
router.GET("/apis/"+gvk.GroupVersion().String(), handleAPIResourceList) | |
router.GET("/healthz", handleHealthz) | |
router.GET("/healthz/log", handleHealthz) | |
router.GET("/healthz/ping", handleHealthz) | |
router.GET("/metrics", handleMetrics) | |
router.GET("/openapi/v2", handleOpenAPI) | |
router.GET("/version", handleVersion) | |
router.NotFound = handleNotFound | |
for _, res := range resources { | |
route := "" | |
if !res.namespaced { | |
route = fmt.Sprintf("/apis/%s/watch/%s/:namespace", gvk.GroupVersion().String(), res.name) | |
} else { | |
route = fmt.Sprintf("/apis/%s/watch/namespaces/:namespace/%s/:name", gvk.GroupVersion().String(), res.name) | |
} | |
router.GET(route, handleRoot) | |
router.POST(route+"/tap", h.handleTap) | |
} | |
return router | |
} | |
// POST /apis/tap.linkerd.io/v1alpha1/watch/namespaces/:namespace/tap | |
// POST /apis/tap.linkerd.io/v1alpha1/watch/namespaces/:namespace/:resource/:name/tap | |
func (h *handler) handleTap(w http.ResponseWriter, req *http.Request, p httprouter.Params) { |
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.
@adleong Does this make sense or did you have any more questions about 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.
Yeah. I guess this is weird either way. At the least, we should add comments to TapByResourceRequest
and TapEvent
to indicate that these structs are used by the tap API, since these structs are otherwise not used in any non-deprecated gRPC service.
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.
@adleong Good point--I added some comments that clarify they are only used by the tap APIServer right now. In the future when we are able to re-expose this to authorized users through the gRPC interface, the comments can be updated.
you'll need to rebase on master again, and then update
|
Signed-off-by: Kevin Leimkuhler <kleimkuhler@icloud.com>
9c8795d
to
e37ec3a
Compare
Integration test results for e37ec3a: fail 😕 |
Signed-off-by: Kevin Leimkuhler <kleimkuhler@icloud.com>
Integration test results for ef90517: fail 😕 |
Closes #7881 This makes the rest of the necessary fixes to satisfy the `staticcheck` lint. The only class of lints that are being skipped are those related to deprecated tap code. There was some discussion on the original change started by @adleong about if this _actually_ deprecated [here](#3240 (comment)); it doesn't look like we every came back around to fully removing it but I don't think it should be a blocker for enabling the lint right now. Signed-off-by: Kevin Leimkuhler <kleimkuhler@icloud.com>
Summary
After the addition of the tap APIServer, all the logic related to tap in the public API no longer needs to be there. The servers and clients that are created but not used, as well as all the old testing infrastrucure related to tap can be removed.
This deprecates TapByResource and therefore required an update to the protobuf files with
bin/protoc-go.sh
. While the change to deprecate this method was extremely small, a lot of protobuf fils were updated in the process. These changes to the code and protobuf files should probably remain coupled sinceTapByResource
is officially deprecated in the public API, but a majority of the additions/deletions are related to those files.This draft passes
go test
as well as a local run of the integration tests.Signed-off-by: Kevin Leimkuhler kleimkuhler@icloud.com